What is an MCP server, and why does "production-grade" mean more than a demo?
The Model Context Protocol (MCP) is an open standard from Anthropic that lets AI agents call tools, read resources, and use prompts through a uniform JSON-RPC 2.0 interface. A demo server exposes a few tools over stdio on a laptop; a production-grade one adds authentication, authorization, audit, rate limiting, and safe access to real systems.
- ▸Three primitives: tools (model-invoked actions), resources (readable context), and prompts (reusable templates). Enterprises mostly care about tools that touch systems of record.
- ▸Two transports matter: stdio for local or subprocess use, and Streamable HTTP for networked servers. Streamable HTTP replaced the older HTTP and SSE transport in a 2025 spec revision; because the protocol is date-versioned, verify the current revision against the official specification.
- ▸Production-grade is an operations bar, not a feature. The gap between a working tool and a safe multi-tenant service is identity, least privilege, observability, and blast-radius control.
For where this fits in the wider agent landscape, see AI Agents in the Enterprise 2026: From Chatbots to Autonomous Workflows.
Should an enterprise MCP server be stateless and cacheable?
Yes, wherever possible. Design tools to be stateless and idempotent so any replica can serve any request, horizontal scaling is trivial, and retries are safe. Cache read-heavy resources and expensive tool results behind explicit keys and TTLs. State that must persist belongs in a database or cache, never in server memory.
- ▸Statelessness enables scale. With no session affinity, you scale replicas behind a load balancer and survive restarts without dropping context.
- ▸Idempotency makes retries safe. Give mutating tools idempotency keys so a client retry after a timeout does not double-charge or double-create.
- ▸Cache deliberately. Read resources and deterministic tool outputs are cacheable; put a Redis layer in front with correct TTLs and invalidation so stale results never reach the model.
- ▸Keep tool results small and typed. Return structured, bounded payloads so the model's context stays cheap and predictable.
How do you authenticate and authorize MCP tool calls?
Treat the MCP server as an OAuth 2.1 resource server. Networked servers should require access tokens, validate them, and enforce per-tool authorization on every call. The MCP authorization spec builds on OAuth 2.1 with PKCE and resource indicators (RFC 8707), so tokens are bound to the intended server and cannot be replayed elsewhere.
- ▸Authenticate the caller, then authorize the action. A valid token is not permission to call every tool; enforce scopes and roles per tool and per resource.
- ▸Bind tokens to the audience. RFC 8707 resource indicators and RFC 9728 protected-resource metadata stop a token minted for one server from being accepted by another, the classic confused-deputy trap.
- ▸Propagate real identity to backends. The end-user or workload identity should reach the system of record, not a shared service account, so downstream audit and least privilege still hold.
- ▸Kill long-lived secrets. Prefer short-lived tokens and workload identity over static keys, per The End of the Long-Lived API Key: Workload Identity and Secretless Architecture in 2026.
What does an MCP gateway do, and why put one in front?
An MCP gateway is a policy enforcement point between agents and one or more MCP servers. It centralizes authentication, authorization, rate limiting, logging, and tool discovery so individual servers stay simple. Think of it as an API gateway specialized for the protocol, the single place to observe and control agent-to-tool traffic.
- ▸Centralize cross-cutting concerns: token validation, quota, and audit live once at the gateway instead of in every server.
- ▸Aggregate and curate tools. A gateway can expose a governed catalog, hiding dangerous tools from most callers and applying per-tenant allow-lists.
- ▸Rate-limit and cost-cap. Agents can loop; the gateway enforces per-client and per-tool limits, the same machine-siege discipline in APIs Under Machine Siege: Rate Limiting, GraphQL Cost Control, and Bot Defense in 2026.
- ▸Control egress. Route outbound tool calls through the gateway so traffic to third parties stays inspectable and policy-bound.
How do you make MCP audit logs that survive a compliance review?
Log every tool invocation as a structured, tamper-evident event: who (identity), what (tool and arguments), when, which backend, the result or error, and a correlation ID linking it to the agent session. Emit OpenTelemetry traces so a single agent task is reconstructable end to end. Redact secrets and keep the record immutable.
- ▸Capture the decision, not just the call. Record the authorization outcome, allowed or denied, and why, so reviewers see policy in action.
- ▸Correlate across hops. A trace or span ID that flows agent to gateway to server to backend answers "what did this agent actually do?" in one query.
- ▸Protect the log. Ship to append-only or WORM storage, and redact PII and credentials from arguments before they are persisted.
- ▸Make it queryable. Compliance and incident response need to filter by user, tool, and time; structured logs beat free text every time.
How do you connect legacy systems without exposing them?
Wrap the legacy system behind narrow, purpose-built tools, never expose raw database or admin access to the model. Each tool performs one bounded operation against the backend using a scoped service identity, validates its inputs, and returns typed results. The MCP server becomes an anti-corruption layer between the agent and fragile internals.
- ▸Least-tool, not full-API. Expose "get_invoice_status(id)" rather than "run_sql(query)". The smaller the tool surface, the smaller the blast radius.
- ▸Scope the backend credential. The service account behind each tool gets only the permissions that tool needs, so a manipulated agent cannot pivot.
- ▸Validate and constrain inputs. Enforce types, ranges, and allow-lists at the tool boundary; treat every model-supplied argument as untrusted.
- ▸Add resilience. Timeouts, circuit breakers, and idempotency keys keep a flaky mainframe or ERP from taking down the agent platform.
How do you defend against tool poisoning and prompt injection?
Assume tool descriptions, resource contents, and returned data can all carry malicious instructions. Tool poisoning hides directives in a tool's metadata; injected content in retrieved data can hijack the agent. Defense is layered: pin and review tool definitions, sandbox execution, require human approval for high-impact actions, and constrain permissions so a hijack cannot do much.
- ▸Pin and review tool definitions. Treat a changed tool description like a code change, diff and approve it, so a server cannot silently alter its instructions.
- ▸Isolate and least-privilege. Scope tokens and tools so the worst-case action is contained; see Least Privilege for AI Agents: Scoping Tools, Tokens, and Blast Radius.
- ▸Treat all text as hostile. Untrusted content is data, not commands, the core stance in Prompt Injection Defense in Depth: Assume the Text Is Hostile.
- ▸Gate irreversible actions. Payments, deletes, and privilege changes need human-in-the-loop confirmation or a second control, not agent discretion.
How TuniCyberLabs helps
We build enterprise MCP servers and gateways that pass security review: OAuth 2.1 authorization with scoped tools, tamper-evident audit through OpenTelemetry, stateless and cacheable design, and anti-corruption wrappers that connect legacy ERP, CRM, and databases without exposing them. We threat-model tool poisoning and prompt injection before you ship.
Planning an agent platform? Talk to our engineering team about a production-grade MCP architecture.