Introduction to MCP
Understand the protocol primitives that let AI applications discover and use external capabilities.
The protocol problem
An AI application often needs calendars, files, databases, search, or internal services. Without a shared interface, each host must implement a separate integration, discover its capabilities differently, and translate errors by hand. MCP defines a common conversation between a host, a client connection, and a server. The benefit is portability: a capability can be exposed once and connected to several compatible hosts. The protocol does not make an integration safe automatically. Your application still owns identity, authorization, validation, approval, observability, and the business rules that decide whether an action is appropriate.
Host, client, and server
The host is the user-facing AI application and remains responsible for the overall interaction. It creates an MCP client for each server connection, while the server owns the tools and resources it exposes. A client is therefore a protocol boundary, not usually the business system itself. Keeping these roles distinct makes security reviews clearer: the host decides which servers are trusted, the client negotiates and transports messages, and the server validates and executes requests. Never assume that because a model suggested an action, the host or server has approved it.
import json
request = {
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "get_invoice_status",
"arguments": {"invoice_id": "INV-1042"}
}
}
print(json.dumps(request))Tools, resources, and prompts
Tools represent callable operations such as searching orders or creating a ticket. Resources represent data that a client or model can read, such as a document, schema, or status view. Prompts are reusable interaction templates that can guide a task without being executable actions. Design each capability around its user outcome, not around a large internal API. A narrow tool like get_invoice_status is easier to authorize and explain than a generic run_query tool. Return structured results so the host can validate, display, cite, or transform them safely.
Discovery and capability negotiation
A client normally begins by establishing a connection and learning which protocol capabilities the server supports. It can then list available tools, resources, and prompts, inspect their names and input schemas, and decide what to make visible to the model. Treat every description and schema as untrusted metadata. A server should not be able to rewrite host policy through a persuasive description. The host should allowlist servers and capabilities, check versions, enforce size limits, and handle the case where a capability is missing or changed.
Request and result flow
A typical tool call starts with a user goal, model selection of an approved tool, client-side argument validation, server-side authorization, execution, and a structured result. The result may contain text, structured content, or references to resources. Keep the chain explicit in logs and user interfaces so people can see what was requested and what actually happened. Tool output is data, not automatically a new instruction. Delimit it in the model context and prevent returned content from silently changing permissions or triggering another privileged operation.
Errors, cancellation, and limits
Reliable MCP integrations expect ordinary failure. A server may be offline, a request may exceed a deadline, a tool may reject an argument, or a user may cancel while work is running. Return stable error categories and safe messages rather than stack traces or secrets. Set timeouts, maximum result sizes, concurrency limits, and budgets for expensive operations. Retry only operations that are demonstrably safe and idempotent. Cancellation should stop downstream work where possible, because abandoned requests can otherwise continue changing external state.
A practical first integration
Start with a read-only server for one small domain, such as looking up public documentation. Write a capability inventory, threat model, input and output schemas, approval policy, and evaluation cases before adding writes. Test discovery, valid calls, malformed arguments, unavailable servers, oversized results, prompt injection in returned data, and permission failures. Observe latency and logs with realistic requests. Once the boundary is stable, add one narrowly scoped mutation behind explicit confirmation. MCP becomes useful when its flexibility is paired with deliberately boring controls.
Walkthrough: invoice lookup
A host can receive “is invoice INV-1042 paid?”, discover the approved `get_invoice_status` tool, validate the invoice identifier, and send a JSON-RPC call. The server should return a structured status, issue date, and source record—not a paragraph that the host has to parse. The host can cite that record in the answer and stop because the task is read-only. If the server returns an instruction embedded in an invoice note, the host must treat it as content, not as a new permission or tool request.
Trade-offs and protocol boundaries
MCP reduces one-off integration work, but it does not remove the need for adapters, policy enforcement, version compatibility, or observability. A broad server is convenient for discovery but creates a larger trust boundary; a narrow server requires more connections but makes review easier. Standardized transport improves interoperability while leaving business semantics to your application. Keep protocol handling separate from domain authorization so a protocol update cannot silently change what a user may do.
Practical exercise: map one capability
Choose a read-only capability from a real workflow. Write its tool name, input schema, output schema, source of truth, permission, maximum result size, timeout, and error categories. Draw the host-client-server message flow and mark where validation and authorization occur. Test a valid request, an unknown tool, invalid arguments, an oversized result, and hostile text in returned data.
Sources and further reading
These primary or specialist references informed the concepts in this guide. Product details can change, so verify current documentation before implementation.