MCP tool servers
Expose your systems as Model Context Protocol tools with per-agent scopes, schema validation, and rate limits. Meridian ships servers for common HR and finance systems; add your own.
Platform
Gateway. Bring any agent. Govern it here.
The Gateway connects third-party and custom agents to the Registry through open standards: Model Context Protocol for tools, agent-to-agent protocols for handoffs, OpenTelemetry for observability, and your identity provider for access.
app.meridian.example/gateway
Policy v41
- Connected agents
- 17
- Calls today
- 48,211
| Agent | Protocol |
|---|---|
| Planning AgentMeridian | MCP |
| Contract Review AgentMeridian | MCP |
| Expense AuditorPartner | A2A |
| Vendor Risk CheckStudio | MCP |
| Treasury ForecastCustom · Python | A2A |
| Ticket TriagePartner | MCP |
Held for approvalControls Agent →
ap.release_payment$48,211.90 · INV-2291awaiting S. Bhatt · rule AP-14 · policy v41What is the Gateway?
Enterprises will not run one vendor's agents. They will run dozens from many sources, plus their own. The question is whether those agents share one identity model, one policy layer, and one log, or whether each brings its own. The Gateway is where they converge.
Agents connect over protocols they already speak. Tools are exposed through Model Context Protocol servers with per-agent scopes. Handoffs between agents use A2A-style agent-to-agent protocols with the originating user's identity carried through. Traces, metrics, and logs are emitted in OpenTelemetry format to your observability stack. Identity comes from your IdP over OpenID Connect or SAML, and provisioning over SCIM.
Every call through the Gateway is evaluated against policy: which agent may call which tool, on whose behalf, with what data scope, at what rate and cost. Calls that require human approval are held at the Gateway until an authorized person acts. The result is one place to see and constrain everything agents do, regardless of who built them.
- Third-party agents register in under an hour with an MCP manifest and an IdP client
- Approval holds enforced at the Gateway apply to every agent, including ones Meridian did not build
- OTLP export means agent traces sit next to application traces in your existing dashboards
- Policies are versioned; every allow, deny, and hold records the policy version that decided it
Capabilities
What Gateway does
6 capabilities, each enforced below the agent so they apply to Meridian, partner, and Studio-built agents alike.
Agent-to-agent handoffs
Agents delegate sub-tasks to other agents over A2A-style protocols. The originating user's identity and approval context travel with the request.
Policy enforcement point
Every tool call is checked against policy: allowed tools, data scopes, cost ceilings, and approval requirements. Denials and holds are logged with the rule that fired.
OpenTelemetry observability
Traces, metrics, and logs for every agent step in OTLP format, exportable to the observability platform you already run.
Identity from your IdP
OpenID Connect and SAML for authentication, SCIM for provisioning. Agents act on behalf of users, and user offboarding revokes agent access.
Cost and rate governance
Per-agent and per-workspace ceilings on credits, model tokens, and tool calls, with alerts before limits are reached.
Specification
Gateway specification
Standards, protocols, and limits as of September 2026. Your account team can confirm coverage for a specific stack.
| Item | Specification |
|---|---|
| Standards |
|
| Tool protocol | Model Context Protocol (MCP) servers and clients with per-agent scopes, schema validation, and rate limits |
| Agent handoffs | A2A-style agent-to-agent protocols; originating user identity and approval context travel with the request |
| Observability | Traces, metrics, and logs for every agent step in OpenTelemetry (OTLP) format |
| Identity | OpenID Connect and SAML for authentication; SCIM for provisioning and deprovisioning |
| Policy | Versioned policies on allowed tools, data scopes, cost ceilings, and approval requirements; every allow, deny, and hold records the policy version |
| Limits | Per-agent and per-workspace ceilings on credits, model tokens, and tool calls, with alerts before limits are reached |
| Onboarding | A third-party agent registers in under an hour with an MCP manifest and an IdP client |
| Plan availability | Growth and Enterprise |
How it fits
How Gateway fits the platform
One identity model, one policy layer, one log. The other components and the trust model that binds them.
Questions
Questions about Gateway
An agent gateway is the control point through which AI agents reach tools, data, and each other. It authenticates the agent and the user it acts for, enforces policy on each call, and records what happened. Meridian's Gateway does this using open protocols so agents from any source can connect without custom integration.
Yes. Tools are exposed as MCP servers, and agents connect as MCP clients. Meridian adds per-agent scopes, schema validation, rate limits, and approval holds on top of the protocol.
Yes. Any agent that can speak MCP for tools and authenticate with your IdP can register. Handoffs to and from Meridian agents use A2A-style protocols. Registered agents appear in the Registry with full logging.
Approval policies are enforced at the Gateway, not inside the agent. When a registered agent calls a tool that policy marks as consequential, the call is held and routed to an approver. The agent cannot proceed until a person acts. This applies equally to agents Meridian did not build.
Get started
Put the first agent to work this quarter.
Start with one workflow, one approver, and one number to move. Most design partners were live in five weeks.