An agent that answers well but cannot verify anything is still a chatbot. What changes everything is its ability to call your systems: an invoice, a stock level, an order status. Wiring each tool by hand quickly becomes unmanageable. That is where MCP comes in: an open standard describing how an agent discovers and calls tools, without rewriting your information system.
MCP in one sentence
MCP stands for Model Context Protocol. It is an open protocol, introduced in late 2024, defining a JSON-RPC exchange between a client — the agent — and a server that exposes capabilities. Three primitives are enough to understand it: tools, actions the agent can call; resources, data it can read; prompts, reusable templates. Transport is local (stdio) for development or remote (HTTP) for production. Think of it as a standard plug: each tool is connected once, and every compatible agent can use it.
MCP, REST API, custom function: what to choose
- An existing REST API: exposing it through an MCP server avoids changing it and makes it discoverable.
- Logic very close to the platform: an internal function may suffice, but it stays tied to a single agent.
- A tool reused by several teams: MCP is the right level, because the contract is explicit and wiring is standard.
- A document to read: the knowledge base (RAG) fits better than a tool.
The practical rule: facts and actions go through tools, knowledge goes through RAG. You do not ask a document for an account balance, and you do not hard-code a pricing rule in an API.
What MCP really changes
- Discovery: the agent lists available tools instead of relying on hardcoded wiring.
- Contract: each tool declares its name, description and input schema, which allows call validation.
- Wiring without redeployment: adding a tool does not require rebuilding the agent.
- Reuse: the same server serves several agents, teams and environments.
- Governance: permissions, secrets and logs are managed at tool level, not in the prompt.
Anatomy of a useful MCP server
A good server exposes few tools, but clear ones: “get_invoice”, “list_payments”, “check_stock”, “create_ticket”. Each tool has a precise description, because that is what the model reads to choose. It also declares a strict input schema: customer ID, order number, period. Separate read tools from write tools: a support agent does not need to delete a customer. Finally, version the server: a contract change without notice silently breaks flows.
Security: the six rules to set
- Least privilege: read-only by default, write only for tools that need it.
- Server-side secrets: never an API key in a prompt or a conversation.
- Input validation: amount bounds, verified identifiers, required fields.
- Locked-down network: in production, private addresses and cloud metadata must stay blocked to prevent SSRF-style abuse.
- Logging: who called what, when, with which result, so every decision can be explained.
- Idempotency: an action that debits or credits must be replayable without doubling the effect.
Three questions before connecting a tool
Is the tool read or write? A tool that changes data deserves a guardrail, a threshold and a trace. Who can call it? A billing tool has no place in the agent answering delivery questions. What happens if it fails? A timeout, a retry and an honest message beat an agent looping forever. Answer these three questions before writing a line of code: they prevent most incidents.
Connecting an MCP server in Deep Agent Studio
The path is deliberately short: open Tools then MCP, add a remote server by URL or a local server, test the connection, check the list of exposed tools, enter secrets, then enable only the tools the agent needs. Play the scenarios in the simulator before publishing. Calls remain visible in traces: you know which tool was used and what it returned.
Three concrete use cases
Billing: “get_invoice” returns the amount, date and charges; “create_refund” triggers the refund within the allowed range. The agent verifies identity by SMS before calling the write tool.
Commerce: “check_stock” answers on availability, “create_order” records an order. Two separate tools, two permission levels.
CRM: “get_customer” gives account status, “create_ticket” opens a case for the advisor. The human handoff leaves with all information already gathered.
Common mistakes
A vague description makes the model pick the wrong tool. A catch-all tool with twenty parameters makes behaviour unpredictable. Exposing a write without guardrails turns a misunderstanding into a real incident. Sharing an admin key across all agents makes it impossible to know who did what. Forgetting timeouts and retries hangs a conversation on a slow service. Finally, testing only the happy path lets errors, empty responses and timeouts through.
FAQ
Do I need to code an MCP server? Only if your tools do not exist yet. An existing API can be exposed by a server, often without changing it.
Does MCP replace APIs? No. It exposes them cleanly to agents, with a contract and permissions.
Local or remote? Local for prototyping and development, remote for production and sharing across teams.
How do I know which tool was called? Simulator traces and the call log give the tool, parameters and result.
