Amelfi documentation

THE GOVERNED MCP GATEWAY

Connect your agents to the tools they need. Decide what they can access, keep upstream credentials inside the gateway, and understand every decision.

Make your first call ↗Understand the architecture →

Architecture / trust boundaryAM / 05

One governed path to your tools

Scroll the diagram sideways to see the full flow →

↻ Replay

01020304

4 / 4

Only an allowed call reaches the approved upstream. The gateway records audit metadata.

Read the full explanation

1. Administrators approve servers, policy, and credential bindings in the control plane.
2. A data plane validates and activates an approved runtime projection.
3. The client sends its identity and tool request to the data plane. Policy is enforced here.
4. Only an allowed call reaches the approved upstream. The gateway records audit metadata.

What would you like to do?

01Getting started ↗Connect a client and verify your first governed call.02Core concepts ↗Understand what happens between an agent and a tool.03Guides ↗Register servers, publish policy, and configure access.04Recipes ↗Combine the pieces for a specific use case.05Operations ↗Deploy, observe, investigate, and recover.06Reference ↗Look up API contracts, commands, and reason codes.

Start with one server and one agent

Amelfi sits between an MCP client and an approved MCP server or selected API operation. The control plane manages configuration. The data plane enforces that configuration when a client discovers or calls a tool.

For a first evaluation, use a test environment and a harmless read operation. Verify that an allowed call succeeds, that an unauthorized tool stays hidden, and that the audit trail explains both outcomes.

Already running a gateway? Read runtime configuration delivery to understand how an approved change reaches each replica, or agent-scoped credentials to design access for an agent.