MCP (Model Context Protocol): The New Standard for AI Tools

AI models are increasingly capable of reasoning, planning, and taking action, but connecting them to business systems remains a major engineering challenge. Every assistant platform, model provider, and enterprise application tends to invent its own integration format, resulting in brittle connectors, duplicated authentication logic, and inconsistent tool definitions.

The Model Context Protocol, or MCP, is an open standard designed to solve that problem. It provides a common runtime contract for AI applications to discover and invoke tools, read contextual data, and exchange reusable prompts. MCP does not replace REST APIs, databases, or an AI model’s function-calling capability. Instead, it sits between the AI application and those existing systems, making them accessible through a vendor-neutral protocol.

This guide explains how MCP works, why it is attracting rapid adoption, and how developers can build a secure MCP server that is ready for production.

Why AI Tool Integration Needs a Standard

Suppose an AI assistant must look up a customer record, check inventory, create a support ticket, or schedule a meeting. Each action requires a capability with a defined input schema, output format, authentication model, and error behavior.

Without a shared protocol, developers must create custom adapters for every combination of model, agent framework, and target system. A connector written for one assistant may not work with another, while an API designed for conventional software may expose hundreds of endpoints that are difficult for a model to use safely.

MCP addresses four recurring problems:

• Discovery: The host can ask a server which tools, resources, and prompts it supports.
• Invocation: The host can call a capability with structured arguments and receive structured results.
• Context exchange: Servers can expose relevant data and reusable interaction templates.
• Extensibility: New servers can be added without modifying the AI application’s core integration code.

Anthropic introduced MCP in November 2024. In December 2024, the project was donated to the Linux Foundation’s Agentic AI Foundation, with Anthropic, OpenAI, and Block listed as founding members. Support has since expanded across model providers, IDEs, cloud platforms, and agent frameworks. The precise features supported by each product vary, so teams should still verify capabilities such as authentication, streaming, and sampling before committing to a design.

MCP is sometimes described as a USB-C port for AI applications. The analogy is useful: just as USB-C standardized the physical and logical connection between devices and peripherals, MCP aims to standardize how AI hosts connect to capability servers.

How MCP Architecture Works

MCP uses a client-server architecture built around JSON-RPC 2.0. It defines three principal roles:

• Host: The AI application that interacts with the user. It owns the model, conversation, available tools, approval policies, and session state.
• Client: The host’s connector for one MCP server. It translates host requests into MCP messages and handles the server’s responses.
• Server: A process or service that exposes tools, resources, and prompts.

A simplified request flow looks like this:

User request
    ↓
AI host and model
    ↓
MCP client
    ↓
MCP server
    ↓
REST API, database, SaaS platform, or local service

The host may create several clients, with one dedicated connection for each MCP server. This separation is important: the server does not need to know which model is active, while the host does not need to implement server-specific communication logic.

For example, an organization might run three separate MCP servers:

• A customer-service server with ticket and knowledge-base tools
• A finance server with invoice and refund capabilities
• A development server with repository, CI, and monitoring tools

The host can expose all three to the model while keeping permissions, deployment, and ownership isolated.

MCP’s Core Protocol Primitives

MCP currently defines three server-side primitives and three client-side features.

Server-Side Primitives

#### 1. Tools

Tools are functions that a model can choose to invoke. They are generally model-controlled: the assistant decides whether a capability is relevant based on the user’s request and the tool description.

A tool definition includes a name, a natural-language description, and an input schema based on JSON Schema. A typical definition looks like this:

{
  "name": "lookup_order",
  "description": "Look up an order by its unique order identifier.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "orderId": {
        "type": "string",
        "pattern": "^ord_[a-zA-Z0-9]+$",
        "description": "The order identifier beginning with ord_."
      }
    },
    "required": ["orderId"],
    "additionalProperties": false
  }
}

Tools can read data, change records, send messages, or trigger external workflows. Because they can cause side effects, a production host should apply approval policies based on tool annotations, permissions, and the requested operation.

#### 2. Resources

Resources represent data or content that an application can read. Unlike tools, resources are usually selected or exposed by the host rather than autonomously invoked by the model.

Resources are identified by URIs and can use templates, such as:

acme://customers/customer-123/orders
acme://projects/project-456/status
file:///workspace/reports/quarterly-summary.pdf

A server can advertise static resources and URI templates during discovery. The client then reads the selected resource through a request such as resources/read.

Resources are not automatically inserted into a model’s context. The host decides whether and when to retrieve them, which helps prevent irrelevant data from consuming the context window.

#### 3. Prompts

Prompts are reusable templates or workflow starters. They are typically user-controlled, meaning the user selects a prompt or explicitly invokes it from a command palette.

For example, an organization might publish these prompts:

• Summarize the latest support incidents
• Review this pull request for security risks
• Draft a customer renewal plan

MCP prompt messages can include text, images, audio, or embedded resources. This allows a server to package domain-specific instructions alongside the data needed to execute them.

Client-Side Features

MCP also allows servers to use capabilities offered by the host:

• Sampling: The server asks the host to run an LLM completion. The host retains control over model selection, permissions, and context.
• Roots: The client tells the server which URI boundaries or workspace locations are available.
• Elicitation: The server requests additional information from the user through the host, such as a missing date range or confirmation of a preference.

These features reverse the usual direction of tool use. They are valuable for server-driven workflows, but they also expand the trust boundary. A host should never assume that a server’s request is safe simply because it arrived over MCP.

What Happens During an MCP Tool Call?\n

Before using a server, the client and server perform an initialization handshake. The client sends its supported protocol revision, capabilities, and implementation information. The server responds with its own capabilities and metadata.

An illustrative initialization request looks like this:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-06-18",
    "capabilities": {},
    "clientInfo": {
      "name": "example-ai-host",
      "version": "1.0.0"
    }
  }
}

Clients should negotiate a supported revision rather than assuming that every server implements the latest specification. After initialization, the host can call tools/list to discover capabilities.

A tool invocation then uses the standard tools/call method:

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "lookup_order",
    "arguments": {
      "orderId": "ord_10482"
    }
  }
}

The server returns content that can include text, structured data, links, or errors:

{
  "content": [
    {
      "type": "text",
      "text": "Order ord_10482 is shipped and is scheduled to arrive tomorrow."
    }
  ],
  "structuredContent": {
    "orderId": "ord_10482",
    "status": "shipped",
    "estimatedDelivery": "2026-02-18"
  },
  "isError": false
}

In a typical agent loop, the sequence is:

1. The host discovers the server’s tools.
2. It selects relevant tools and provides their schemas to the model.
3. The model requests a tool call.
4. The host validates the arguments and applies approval and authorization policies.
5. The MCP client invokes the tool.
6. The server performs the underlying operation.
7. The result is returned to the model, which produces the final response or requests another action.

The host is an enforcement point, not merely a message relay. It should validate arguments, enforce tenant boundaries, redact sensitive values, and require confirmation for high-impact operations.

Building a Practical MCP Server

The official Python SDK provides a lightweight FastMCP interface. Here is a minimal order-lookup server:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("Acme Orders")


@mcp.tool()
def lookup_order(order_id: str) -> dict:
    """Look up an order by its unique order identifier."""
    if not order_id.startswith('ord_'):
        raise ValueError('Invalid order identifier')

    return {
        'orderId': order_id,
        'status': 'shipped',
        'estimatedDelivery': '2026-02-18'
    }


if __name__ == '__main__':
    mcp.run(transport='streamable-http')

Install the SDK in an isolated environment:

python -m venv .venv
source .venv/bin/activate
pip install mcp

For local development, the server can also use standard input and output. A typical host configuration for a local server resembles the following:

{
  "mcpServers": {
    "acme-orders": {
      "command": "uv",
      "args": [
        "run",
        "--directory",
        "/srv/acme-orders",
        "python",
        "server.py"
      ]
    }
  }
}

Configuration syntax varies between MCP hosts, but the underlying idea remains the same: the host launches the server process and communicates with it over standard input and output. When using standard I/O, application logs must go to standard error because standard output is reserved for protocol messages.

The MCP Inspector is useful for exploring a server during development:

npx @modelcontextprotocol/inspector python server.py

Run the Inspector only against servers and dependencies you trust, because it gives an operator direct access to the server’s capabilities.

Transport Options and Deployment Models

MCP defines two widely used transports.

Transport	Best fit	Key characteristics
Standard I/O	Local tools and development	The host launches the server; messages travel over stdin and stdout.
Streamable HTTP	Remote and production services	A network endpoint supports client requests and optional server-to-client streaming.

Standard I/O

Standard I/O is simple, low-latency, and naturally scoped to the user who launched the process. It is a good fit for filesystem utilities, local development tools, and desktop assistants.

Its main limitation is that the server usually inherits the host user’s operating-system permissions. Sandboxing, restricted environment variables, and dedicated service accounts are therefore important when the tool performs sensitive operations.

Streamable HTTP

Streamable HTTP allows an MCP server to operate as a shared service. It can be placed behind a gateway, authenticated with OAuth 2.x or an organization’s existing identity system, and deployed using containers or serverless infrastructure.

Streamable HTTP uses a single MCP endpoint. Clients send messages through HTTP POST, while GET requests can establish a stream for server-initiated messages. Older HTTP-and-SSE transport variants remain in some ecosystems, but new implementations should prefer the current Streamable HTTP transport and verify compatibility with target hosts.

For enterprise deployment, consider separating these concerns:

AI host
  ↓
MCP gateway
  ├── Authentication and tenant policy
  ├── Rate limiting and audit logging
  ├── Tool approval routing
  └── Secrets and credential brokering
  ↓
Domain MCP servers
  ├── Customer service
  ├── Finance
  └── Engineering

A gateway is not mandatory, but it prevents every domain server from becoming a separate security boundary with duplicated policy enforcement.

Security Is the Most Important Part of MCP Design

MCP makes integrations easier to expose, which also makes unsafe integrations easier to discover. A server should be treated as a privileged extension of the AI host, not as a harmless data source.

Apply Least Privilege

Each server and each tool should receive only the permissions required for its function. A read-only reporting tool should not share a database credential with a refund tool. For multi-tenant systems, scope credentials to the active user and tenant rather than using a global service account.

Validate Every Input and Output

Validate arguments against the declared JSON Schema and enforce business rules in the server. Schema validation can establish shape, but it does not determine whether an order belongs to the current customer or whether a requested date is permitted.

Outputs should also be bounded. Avoid returning entire database rows, credential-bearing documents, or unbounded histories. Use explicit fields, pagination, result limits, and server-side redaction.

Require Approval for Side Effects

Read-only operations may run automatically, while actions such as deleting records, sending email, publishing content, or spending money should require explicit confirmation. MCP tool annotations such as readOnlyHint, destructiveHint, idempotentHint, and openWorldHint can help a host classify risk.

These annotations are hints, however, not security guarantees. A malicious or buggy server can mislabel a tool, so hosts should also enforce their own policies.

Defend Against Prompt Injection

Tool results are untrusted input. A customer record, web page, PDF, or issue comment could contain text instructing the model to ignore its policies or disclose secrets. The model should treat retrieved content as data rather than authoritative instructions.

Production systems should add controls that:

• Separate system instructions from tool content
• Mark or label untrusted content
• Restrict which tools an injected instruction can invoke
• Prevent sensitive data from being sent to unapproved destinations
• Validate model-proposed arguments independently
• Require human review for consequential actions

Secure Remote Connections

Remote MCP servers should use TLS, authenticated users, short-lived credentials where possible, and explicit authorization scopes. Do not forward an end-user access token from the host to the server unless the protocol design and threat model explicitly permit it. The MCP authorization guidance discourages insecure token passthrough because it can expose credentials to an untrusted resource server.

Also protect against server-side request forgery. If a tool accepts URLs, restrict outbound access to approved domains and block private network ranges, cloud metadata endpoints, and sensitive local addresses as appropriate.

Isolate and Audit

Run high-risk servers with restricted file-system access, limited network egress, and no ambient production credentials. Record tool name, request ID, duration, result status, approval decision, and tenant in audit logs, but redact secrets and sensitive business data.

MCP, REST, Function Calling, and A2A Are Complementary

MCP is frequently confused with other AI integration technologies. Their responsibilities are different.

Technology	Primary purpose	Typical consumer
MCP	Runtime connection, discovery, and invocation of AI context capabilities	AI hosts and agent clients
REST/OpenAPI	Contract for network APIs and data resources	Conventional applications and services
Model function calling	Asking a model to emit structured tool requests	AI model and provider API
Agent-to-agent protocols	Communication and collaboration between autonomous agents	Agent-to-agent workflows

REST remains the right contract for a public backend API. An MCP server can wrap that REST API and translate natural tool schemas into agent-friendly operations.

Function calling and MCP also work together. The host may retrieve MCP tool definitions, convert them into the function schema expected by a particular model, and translate the model’s function request back into an MCP tools/call message.

MCP is not a model gateway, agent planner, or policy engine. It standardizes the connection layer. Organizations still need identity systems, orchestration logic, evaluation frameworks, and governance controls.

Patterns for Enterprise-Grade MCP Servers

The Facade Pattern

Expose a small number of business-oriented tools instead of mirroring every internal API endpoint. A tool such as prepare_customer_refund is safer and easier to use than exposing generic database query, HTTP request, and shell execution capabilities.

Good tools have narrow purposes, clear descriptions, strict schemas, and predictable side effects. If a tool requires several operations, the server can perform them as one controlled workflow and return a business-level result.

The Gateway Pattern

Use an MCP gateway to centralize:

• Authentication and token exchange
• Tenant and role enforcement
• Rate limits and quotas
• Auditing and observability
• Tool routing and versioning
• Human approval workflows

This prevents individual servers from becoming isolated security silos.

The Workflow Tool Pattern

Some tasks naturally take longer than an interactive request. A server can accept a workflow request, return a job identifier, and expose a status tool or resource. The host can then check progress without holding a connection open.

The Read-Only Pilot Pattern

The safest adoption strategy is to begin with read-only tools such as search, status lookup, or report generation. This lets teams validate discovery, schemas, latency, and context usage before introducing write operations and approval requirements.

Performance and Context Efficiency

MCP solves connectivity, but it does not solve the context-window problem. A server that returns thousands of records can make an agent slower, less accurate, and more expensive.

Teams should:

• Return only fields required for the next decision
• Use pagination, filtering, and result limits
• Prefer structured results over verbose prose
• Summarize large datasets and expose drill-down resources
• Cache only when user, tenant, and authorization context are respected
• Set timeouts and distinguish retryable from permanent failures
• Move long-running work to asynchronous jobs
• Version stable tool contracts without silently changing semantics

A well-designed tool should make the next model decision easier. Returning concise, structured data is usually more valuable than returning a polished paragraph that the model must parse again.

Observability and Testing

Traditional API monitoring is necessary but not sufficient. MCP introduces model selection, tool choice, argument generation, and approval decisions into the operational path.

Useful telemetry includes:

• Tool discovery and invocation counts
• Latency and timeout rates by server and tool
• Error rates grouped by JSON-RPC code and application error
• Approval request, approval, rejection, and abandonment rates
• Tool-result size and estimated context consumption
• Model retries and repeated calls to the same tool
• Authentication failures and policy denials

Avoid logging raw prompts, credentials, or sensitive tool arguments by default. Use request IDs to correlate MCP operations with model requests, traces, and downstream API calls.

Testing should cover more than normal application behavior. A production MCP server needs:

• JSON Schema validation tests
• Protocol and SDK compatibility tests
• Contract tests for every tool
• Permission and tenant-isolation tests
• Prompt-injection and data-exfiltration tests
• Approval and rollback tests
• Load, timeout, and retry tests
• Golden traces for model tool selection

Because tool descriptions influence whether and how a model selects a function, they should be versioned and evaluated like any other prompt or model-facing interface.

Current Limitations and Open Questions

MCP is promising, but it is still evolving rapidly. Client and server SDKs may implement different revisions, optional features may be unevenly supported, and remote authentication patterns are still maturing. Organizations should pin protocol and SDK versions, run compatibility tests, and avoid depending on undocumented behavior.

There are also broader governance questions. Tool marketplaces need stronger provenance and reputation mechanisms. Servers need consistent identity, revocation, and capability metadata. Enterprises need shared audit formats so they can evaluate an MCP server before allowing it to access sensitive systems.

Most importantly, MCP cannot make an unsafe tool safe. Standardization improves interoperability, but authorization, isolation, input validation, and human oversight remain the server’s responsibility.

A Practical Roadmap for MCP Adoption

A sensible adoption plan follows these steps:

1. Inventory high-value use cases. Start with tasks where an assistant needs reliable business data or a narrowly defined action.
2. Choose a read-only pilot. Measure tool-selection accuracy, latency, context usage, and user trust.
3. Design business-level tools. Avoid exposing raw infrastructure or generic execution capabilities.
4. Define strict schemas. Use JSON Schema, realistic examples, enums, formats, and bounded string lengths.
5. Implement identity and least privilege. Scope every credential to the minimum user, tenant, tool, and operation it needs.
6. Add approval workflows. Classify tools by reversibility, data sensitivity, and external impact.
7. Instrument the full path. Measure calls from host to model, MCP client, server, and downstream service.
8. Test adversarial behavior. Treat prompt injection, malformed arguments, and excessive output as expected inputs.
9. Operationalize the server. Add version pinning, health checks, deployment automation, rollback procedures, and ownership.
10. Expand gradually. Introduce write operations only after the read-only path has proven reliable.

Conclusion

MCP is emerging as the connective tissue for AI tools. By standardizing discovery, invocation, context access, and structured results, it can reduce the cost of building integrations and make capabilities portable across models and hosts.

Its success will depend on more than protocol adoption. The organizations that benefit most will treat MCP servers as production APIs and privileged services: they will design narrow tools, enforce least privilege, validate every boundary, control side effects, and monitor the complete agent workflow.

The immediate opportunity is to identify one valuable read-only workflow, publish a small set of well-described tools, and test them with real users. From there, teams can build a governed path toward agentic automation without giving up security or control.

Tanok Tech helps organizations design and implement secure MCP servers, AI agent workflows, and production-ready AI platforms. If you are evaluating MCP for your organization, contact our team to plan a focused proof of value and a secure adoption roadmap.