How to Connect Your First MCP Server to an AI Agent (Without Breaking Anything in Production)

Every MCP getting-started guide shows you the same thing: ten lines of code, a local file system server, and an agent that can read files. It works in five minutes. You show it to your team. Everyone is impressed.
Then someone asks whether it's ready to ship.
It isn't. Not yet. Not because MCP is hard — it isn't — but because getting from "works on my machine" to "works reliably in production with real users and a security team" requires a few additional decisions that the tutorial skipped.
This article covers both: the quick path to a working MCP setup, and the honest list of what you need to address before you let it anywhere near production data.

Part 1: What a Working MCP Setup Actually Looks Like

MCP has two sides: the client and the server.
The MCP server is a lightweight service that exposes tools. Each tool has a name, a description, an input schema, and a handler function that does the actual work. An MCP server for a database, for example, might expose tools called query_records, insert_record, and list_tables. The server handles the MCP protocol — receiving tool discovery requests, responding with the tool list, accepting tool calls, and returning results.
The MCP client is your agent — specifically, the part of your agent framework that communicates with MCP servers. Most major agent frameworks (LangChain, LlamaIndex, AutoGen, and others) now have native MCP client support. You point the client at an MCP server, it fetches the available tools, and those tools become available for the LLM to call.
A minimal working setup in Python looks roughly like this:

#Connect your agent to an MCP server
from your_agent_framework import MCPClient, Agent

# Point the client at your MCP server
mcp_client = MCPClient(server_url="http://localhost:8000")

# The client fetches available tools automatically
available_tools = mcp_client.list_tools()

# Pass tools to your agent
agent = Agent(
    llm="claude-sonnet-4",
    tools=available_tools
)

The agent can now call any tool the server exposes

response = agent.run("List all open support tickets assigned to me")
The agent sends the tool list to the LLM. When the LLM decides it needs to call list_tickets, it generates a structured tool call. The agent framework intercepts it, sends it to the MCP server, gets the result, and feeds it back into the LLM's context. The LLM continues reasoning with the tool result.
That's it locally. It takes minutes to get running and feels magical the first time.

Part 2: What Works in a Demo and Breaks in Production

Here's the honest part. The setup above has five characteristics that are fine for development and actively dangerous for production.
There's no authentication. The MCP server is open to anyone who can reach the URL. In local development that's only you. In a deployed environment, it's potentially anyone on the network.
There's no access control. Every agent that connects gets every tool. The concept of "this agent should only see read tools, not write tools" doesn't exist in the basic setup.
There's no audit trail. When the agent calls insert_record with certain arguments, there's no log connecting that tool call to the user who triggered it, the LLM call that produced it, or the business context that justified it.
There's no defence against tool poisoning. In April 2025, Invariant Labs demonstrated that a malicious MCP server can embed hidden instructions in tool responses that the LLM reads as commands. In the basic setup, tool responses flow directly from the server into LLM context with no inspection layer in between.
There's no centralised management. If you're running this with one agent, one server, and one developer, the above is manageable. When you have six teams, twenty agents, and forty MCP servers, managing credentials, access policies, and tool inventory in application code becomes a full-time job.
None of these are edge cases. They're the normal state of any MCP deployment that's been running for more than a few months and has more than one team contributing to it.

Part 3: The Three Things to Get Right Before You Ship

1. Authentication: Use your existing identity provider, not new credentials The worst outcome is a parallel credential system — new API keys, new user accounts, new rotation policies — maintained alongside your existing identity infrastructure. It creates duplication, increases surface area, and inevitably drifts out of sync. The right approach is to federate MCP authentication to your existing IdP. If your organisation uses Okta or Azure AD, MCP tool access should be governed by the same identities, the same roles, and the same access policies as everything else. When an employee's account is deactivated, their agent's tool access is revoked automatically. No separate step, no risk of missing it.
2. Tool scoping: Agents should only see what they're authorised to use The principle of least privilege applies to AI agents at least as much as it applies to human users. An agent handling customer support queries has no legitimate reason to call database administration tools. A finance workflow agent has no reason to trigger deployment pipelines. In a direct-connection setup, tool scoping requires each agent to filter its own tool list — which means it's implemented inconsistently, if at all. In a gateway setup, scoping is enforced at the discovery layer: the gateway intercepts the tools/list response and returns only the tools the requesting agent is authorised to see. The agent literally cannot discover tools it shouldn't have access to.
3. Logging: You need a record that connects the LLM call to the tool call to the outcome When something goes wrong — and with AI agents, something will eventually go wrong — you need to be able to reconstruct what happened. Not "the database was modified at 14:32" but "User A triggered Agent B, which called Tool C with Arguments D, based on LLM call E, which was triggered by User Request F." That chain of causation is what makes an AI system debuggable and auditable. It doesn't exist in the basic MCP setup and requires deliberate infrastructure to create.

The Production Path

The cleanest path from working demo to production-ready MCP deployment is to route your agents through an MCP gateway rather than connecting them directly to servers. The gateway handles authentication, access control, logging, and response inspection in one place. Your agent code doesn't change — it still talks to an MCP endpoint. The governance layer sits between the agent and the tools.
TrueFoundry's MCP Gateway is designed specifically for teams making this transition. It integrates with Okta, Azure AD, and other enterprise identity providers for centralised authentication. It enforces RBAC at the tool level so agents only discover what they're authorised to use. It captures full request traces linking every tool call to its triggering LLM call and user context. And it deploys within your own infrastructure — VPC, on-premises, or air-gapped — so no inference data leaves your environment.
You connect your agents to the gateway instead of directly to MCP servers. Everything else stays the same. The demo that impressed your team last week becomes the production system that doesn't keep your security team up at night.
Explore TrueFoundry's MCP Gateway →