MCP in Production: Giving AI Agents Safe Tools

Tools Are Where Agents Get Dangerous

Let me be direct: a language model that can only talk is safe and mostly useless. A model that can call tools, look up an order, issue a refund, write to a database, is useful and genuinely dangerous. The moment you give an agent the ability to act, you have to answer the questions a security team asks about any actor: what can it do, who authorized it, and what did it actually do.

The Model Context Protocol, or MCP, has become the standard way to give AI agents tools. It is a clean protocol, and that is exactly why the hard part is not connecting tools, it is governing them. An MCP server that exposes your business operations to an agent without authorization, limits, and audit is a breach waiting to happen. This guide is how to run MCP in production without that.

Connecting a tool to an agent is a five-minute job. Making sure the agent cannot do more than its job, that every call is authorized, and that you can reconstruct what happened, is the actual engineering.

We run MCP in production in our own Exfinity platform, where an MCP server exposes commerce, analytics, and market-intelligence tools to agents under strict governance. This guide is that architecture. For the wider agent picture, see our agentic AI systems guide, and this is core AI services work.

Who Cares About What

What MCP Actually Is

MCP is a protocol for exposing tools, and context, to AI agents in a standard way. Instead of writing custom integration glue for every model client, you run an MCP server that advertises a set of tools, and any MCP-capable client, a coding assistant, a chat agent, your own runtime, can discover and call them.

The value is standardization: one tool server, many clients, a consistent contract. The risk is also the standardization: a tool exposed over MCP is exposed to whatever agent connects, so the governance has to live at the server, not be assumed at the client. Our multi-agent architecture guide covers how agents and tools compose.

Designing Tools an Agent Can Use Safely

A good MCP tool is not just an API endpoint with a description. It is designed for an actor that will call it in ways you did not anticipate.

In Exfinity, tools are grouped by what they touch, commerce, recommendations, analytics, market intelligence, and a tenant only sees the tools its plan and permissions allow. The design rule: a tool's blast radius should match its permission, so a read tool can be open while a tool that moves money is tightly gated. Our API design guide covers designing these contracts to last.

Three-Point Policy Enforcement

This is the core of safe MCP, and it is where most implementations are thin. You enforce policy at three points in every tool call, not one.

Agent asks to call a tool
   │
   ▼
[1] Pre-execution   ── is this tenant/agent allowed to call this tool?
   │                    (reject here if not)
   ▼
[2] Runtime         ── guardrails inside the tool: scope constraints,
   │                    "never book without explicit consent"
   ▼
Tool executes
   │
   ▼
[3] Post-execution  ── log the call: who, what, input, output, when

Pre-execution validation checks whether this tenant and agent are permitted to call this tool at all, before anything runs. A permission failure stops here.

Runtime guardrails live inside the tool, encoding constraints the policy cannot express as a simple yes or no, like never taking an irreversible action without explicit user consent.

Post-execution audit records every call with the tenant, the actor, the tool, the input, the output, and the time, so the whole thing is reconstructable after the fact.

Exfinity enforces all three on every tool call. One check is not enough, because a tool that is allowed to run can still be asked to do something it should not, and an action that ran still needs to be on the record. Our AI governance guide covers this defense-in-depth posture.

Capability Scopes: Not All Tools Are Equal

A refund tool and a search tool should not carry the same permission. The way to make that real is capability scopes: group tools by the kind of power they hold, and gate each group separately.

Exfinity gates write tools, content tools, and crawl tools separately from read tools, so an agent scoped to answer questions cannot suddenly execute a booking. The principle: the more irreversible or expensive the action, the tighter the gate. This is the same least-privilege thinking as our cloud security hardening guide, applied to agent tools.

A Worked Example: One Tool Call, Governed

Trace a single tool call through the governance, because the three-point model is clearest in motion.

A customer tells a chat agent "cancel my booking XFt-55231 and refund me." The agent decides to call the cancelBooking tool. Here is what the MCP server does.

1. Discover   the agent's tenant only sees tools its plan allows; cancel
              is present because this tenant has it
2. Pre-check  is this tenant and this agent permitted to call cancelBooking?
              cancel is a write, monetary-adjacent tool, tightly scoped.
              permitted -> continue; not -> reject here, nothing runs
3. Runtime    the tool's own guardrail: cancellation over a value threshold
              requires explicit confirmation, so it pauses for consent
              rather than cancelling immediately
4. Execute    on consent, the cancellation runs, scoped to this tenant's
              booking only, never able to touch another tenant's data
5. Audit      the call is logged: tenant, actor, tool, input, output, time,
              and the policy decision, all reconstructable later

Three separate gates did three separate jobs. The pre-check decided whether the call was allowed at all. The runtime guardrail caught the thing a yes-or-no permission cannot express, that a high-value cancellation needs consent. The audit made the whole thing reconstructable. Remove any one and you have a hole: no pre-check means an unauthorized agent acts, no runtime guardrail means an authorized agent does something rash, no audit means you cannot prove what happened. All three, every call. Our AI governance guide covers why this layering matters.

Rate Limits and Timeouts: Containing a Runaway

An agent in a loop can hammer a tool hundreds of times, and a slow tool can hang an agent turn. Both need bounds.

Per-session rate limits cap how many tool calls an agent can make in a window, and per-tool timeouts stop a slow call from hanging the turn. In Exfinity, a session is capped at a bounded number of tool calls per minute with a per-tool execution timeout, so a misbehaving or compromised agent cannot turn your tool server into a denial-of-service on your own systems. Combined with the per-turn agent bounds from our agent memory guide, these limits are what let you expose real operations to an autonomous agent and still sleep. Our designing systems for failure guide covers this containment mindset.

Custom Tools: Extending Without Losing Control

Real platforms need per-tenant tools, a customer's own endpoint exposed to their agents. The trap is letting that become an ungoverned hole.

The safe pattern is registration plus the same governance. A tenant registers an external endpoint with an allowed-host and a parameter schema, and the MCP server exposes it dynamically alongside the built-in tools, under the same three-point policy enforcement. In Exfinity, custom connector tools are defined centrally and exposed per tenant, policy-enforced exactly like built-in tools, so extending the toolset does not weaken the governance. Our enterprise integration guide covers wiring external systems safely.

Getting Started

1. Design tools narrowly. One job per tool, idempotent writes, read and write separated.
2. Enforce at three points. Pre-execution permission, runtime guardrails, post-execution audit.
3. Scope by capability. Gate write and irreversible tools far tighter than reads.
4. Bound every session. Rate limits and per-tool timeouts to contain a runaway.
5. Govern custom tools identically. Registration plus the same policy, no ungoverned holes.

This is staged and fits our methodology. Our custom software and consulting teams build governed MCP servers. Start at contact or get a scoped quote.

Common Ways This Goes Wrong

1. Exposing tools without authorization. A tool over MCP is open to whatever connects. Gate at the server.
2. One check, not three. Allowed-to-run is not the whole story. Enforce pre, runtime, and post.
3. Equal permission for all tools. A refund is not a search. Scope by capability.
4. No rate limits. A looping agent becomes a self-inflicted denial of service. Bound every session.
5. Ungoverned custom tools. Per-tenant tools need the same policy as built-ins. No exceptions.

Who Builds This

Oronts is a founder-led software company in Munich. Refaat Al Ktifan, our founder and solution architect, leads a senior team across backend, AI, and security. We run a governed MCP server in our own Exfinity platform, exposing real operations to agents under three-point policy enforcement, capability scopes, and audit. We design the tools, build the governance, and hand you an MCP surface you can expose to agents without losing control. See our services and solutions pages.

Takeaways

• MCP standardizes agent tools. The hard part is governing them, not connecting them.
• Design tools narrowly, with idempotent writes and read separated from write.
• Enforce policy at three points: pre-execution permission, runtime guardrails, post-execution audit.
• Scope tools by capability and gate irreversible actions far tighter than reads.
• Bound every session with rate limits and timeouts, and govern custom tools identically.

Giving an agent tools is giving it the power to act. Treat the MCP server like any other privileged actor: least privilege, every action authorized, every action logged. Then autonomy is safe instead of scary.

Exposing real operations to AI agents? Tell us what they need to do. Start at contact or get a scoped quote.