Agent-First Access

Access from any agent platform, IDE, harness, or pipeline through one MCP endpoint.

Code-first, callable from any agent platform, any harness, any IDE. Mediafier shows up as native tools in whatever orchestrator your team is already running.

Agent-first access is Mediafier's primary surface. Every capability ships as an MCP tool. Model-neutral. Orchestration-neutral. The single gateway enforces auth, organization context, rate limiting, billing, and audit before any tool runs... so the security team reviews one enforcement chain, not forty per-tool integrations.

One way in: MCP

The canonical public ingress is:

POST https://mcp.mediafier.ai/mcp

It is callable from any MCP-aware agent, IDE or harness — nothing to install. Interactive clients register themselves and sign you in through the browser; headless workloads present a bearer token obtained from an Agent Credential (see Authentication & Agent Credentials). Organization context is server-derived from that identity. Clients never set tenant headers themselves. Setup for each client is on the client bootstrap, mcp.mediafier.ai/connect. (An advanced scoped per-server form exists for clients that need a single-server session — see MCP Access.)

Discover first. The first safe step is discovery: tools/list returns the tools your organization can call, and the list_commands tool returns the curated partner commands. Both are read-only.

What a tool call looks like

Every tool call follows the same shape regardless of which family owns the tool:

The agent picks a tool from the discovery surface (a governed resource the planner reads).
The MCP request is sent to the gateway.
The gateway runs the deterministic enforcement chain (Identity → Org → Authorization → Rate → Billing → Dispatch).
The gateway routes the call to the runtime that owns the tool.
The runtime executes; the response carries the trace ID so the call is correlatable end-to-end.

If any step in the chain fails, the gateway returns a structured error envelope — including the same trace ID — and the runtime never sees the call.

What you get

Capability

What it does for the agent

Discovery

The agent reads a governed list of available tools, with input schemas, descriptions, and capability hints — without integrating against internal systems.

Identity

Auth0 issues the bearer token; the gateway resolves the principal server-side.

Org isolation

Tenant context is derived from the authenticated identity. Cross-tenant calls are not possible from a client.

Billing

Calls are metered against an organization's credit ledger. Out-of-credits is signaled deterministically; the agent can re-plan or notify a human.

Audit

Every governed call — allowed or refused — produces an immutable audit row, correlated by trace ID.

Schema enforcement

Tool input schemas are validated before execution. The agent never reaches a runtime with malformed arguments.

Trace IDs everywhere

Every response — refusals included — carries an X-Trace-Id header, and error envelopes repeat it as trace_id. That ID is the single piece of information needed to reconstruct what happened across identity, billing, runtime, and audit logs. Customer support runs on it. Internal incident triage runs on it.

What an agent-first integration gives a security review

A security team auditing an agent-first integration sees one answer: every tool call goes through the same governed gateway, every action is metered, every action is audited, every action carries a trace ID.

That uniformity is the point. The security review evaluates one enforcement chain — "agents talk to one gateway, the gateway decides, the platform executes" — instead of one chain per tool integration. The same chain holds whether the agent is in a terminal, an IDE, a CI job, or a Slack-triggered runbook.

Where to go next

If you're…