Model Context Protocol (MCP)

MCP provides a universal schema for describing tools and resources. This includes:

• Function signatures with typed parameters and return values.
• Resource definitions for data sources like databases or APIs.
• Structured metadata for documentation, authentication, and usage policies. This standardization allows any MCP-compliant model (like Claude or GPT) to understand and use any MCP-compliant server without custom integration code.

MCP enforces a client-server architecture where the AI model (client) requests actions, but execution happens on the MCP server. Key security features include:

• No direct model access: The model only sees tool descriptions, not live credentials or data.
• Explicit user consent: Tools often require user approval per invocation.
• Parameter validation and sanitization occurs server-side before execution. This design prevents prompt injection attacks from forcing unauthorized tool use and contains the blast radius of any compromised model session.

MCP is designed to work over multiple transport layers, making it adaptable to different deployment environments.

• Standard Input/Output (stdio): Common for local development and CLI integrations.
• HTTP/SSE (Server-Sent Events): For web-based applications and remote servers.
• Custom Transports: The protocol can be adapted for other message-passing systems. This flexibility allows the same MCP server to power a local code editor plugin, a cloud-based agent, and an enterprise orchestration platform.

MCP servers can provide dynamic context to the AI model beyond static tool definitions. This includes:

• Resource listing and sampling: The model can discover available data (e.g., database tables, files) and request previews.
• Incremental context loading: Large resources (like documents) can be loaded in chunks as needed, preserving the model's context window.
• Real-time data streaming: For resources that change, like logs or metrics. This turns the model from a static function caller into a context-aware explorer of a live data environment.

MCP cleanly separates three distinct roles in an AI system:

1. The Model: Responsible for reasoning, planning, and generating structured requests.
2. The MCP Client: Manages the session, forwards requests, and handles responses (often part of an application like an IDE).
3. The MCP Server: Owns the business logic, data access, and secure execution of tools. This architecture allows domain experts to build and maintain MCP servers (e.g., a finance tool server) independently of the AI application developers who integrate them.

MCP servers implement critical security and governance logic between the AI model and sensitive operations. The server acts as a policy enforcement point.

Core security functions include:

• Authentication & Authorization: Validate the calling client's identity and check permissions before executing a tool.
• Input Validation & Sanitization: Enforce strict type checking, range limits, and regex patterns on all parameters to prevent injection attacks.
• Audit Logging: Record every tool invocation with full context (user, parameters, timestamp, result) for compliance.
• Rate Limiting & Quotas: Prevent abuse by limiting the number or frequency of calls to expensive or sensitive tools.

MCP serves as an adapter layer for legacy or non-RESTful systems that lack modern APIs. A custom MCP server can wrap these systems, presenting a clean, standardized interface to AI models.

Example integrations:

• Mainframe Green Screens: A server that uses screen-scraping or 3270 emulation to interact with legacy IBM mainframe applications.
• Industrial IoT Protocols: A server that communicates via OPC UA or Modbus to query sensor data or send commands to machinery.
• Desktop Automation: A server that uses UI automation frameworks to control legacy desktop software that has no API.

This allows AI agents to operate within entire existing digital ecosystems without requiring costly, wholesale re-engineering.

Function calling is a core language model capability that enables a model to identify when an external tool or API should be invoked and to generate a structured request containing the necessary parameters for that invocation. It is the foundational behavior that protocols like MCP standardize.

• Mechanism: The model receives a list of available functions with their signatures (names, parameter schemas, descriptions). Based on user input, it decides if a call is needed and outputs a structured object (typically JSON) matching the schema.
• Purpose: Bridges natural language understanding with deterministic program execution, allowing models to perform actions like querying databases, sending emails, or fetching real-time data.
• Example: A user asks, "What's the weather in Tokyo?" The model calls a get_weather(location: string) function with {"location": "Tokyo"}.

The OpenAPI Specification is a standard, language-agnostic interface description for RESTful APIs. It is a common source for defining the functions and tools that can be exposed to a model via protocols like MCP.

• Role in MCP: An MCP server can translate OpenAPI definitions into the standardized resource and tool descriptions that clients (like AI applications) understand. This allows existing API ecosystems to be easily integrated into AI workflows.
• Structure: Defines API endpoints, HTTP methods, request/response schemas (using JSON Schema), authentication methods, and descriptions—all in a machine-readable YAML or JSON file.
• Key Benefit: Provides a universal contract for web services, which MCP leverages to create a uniform interface for AI models, abstracting away HTTP-specific details.

Structured output refers to model-generated data that conforms to a predefined schema, such as JSON, XML, or a Protocol Buffer. It is the essential format for reliable function calling and machine-to-machine communication.

• Requirement for MCP: For an MCP client to reliably execute a tool, the model's request must be a perfectly formatted JSON object matching the tool's parameter schema. This is a non-negotiable requirement for deterministic integration.
• Enforcement Techniques: Achieved through prompt engineering (explicit instructions), grammar-based sampling (constraining the model's output tokens), or output parsing libraries that retry or reformat malformed responses.
• Contrast with Unstructured Text: Unlike a creative story, structured output for tool calling has zero tolerance for deviation; a missing bracket or misnamed field will cause the call to fail.

Tool selection is the decision-making process where a language model or an orchestration framework chooses the most appropriate external function or API from a set of available tools to fulfill a user's request. MCP standardizes how these tools are described to inform this selection.

• Process: The model evaluates the user's intent against the descriptions and capabilities of all tools provided by an MCP server. It must reason about which single tool or sequence of tools can complete the task.
• Challenges: Requires the model to understand nuanced differences between similar tools and to handle ambiguity when no tool is a perfect fit (requiring fallback logic).
• Orchestration: In complex agents, tool selection may be managed by a separate orchestrator or router that uses a smaller, faster model to choose a tool before a larger model handles parameter extraction.

The ReAct (Reasoning and Acting) framework is a prompting paradigm that interleaves a language model's internal reasoning traces with external tool calls to solve complex, multi-step problems. MCP is often the protocol used for the "Act" step.

• Pattern: The model output follows a format like Thought: [Reason about next step]\nAction: [Tool Name]\nAction Input: [JSON Parameters]. The system then executes the tool and returns the result as Observation: [Tool Output], and the loop continues.
• Synergy with MCP: MCP provides the standardized, secure interface for the Action step. The model's Thought reasons over which MCP resource or tool to use next.
• Use Case: Solving a research query: Thought: I need to search for recent articles. Action: web_search Thought: From the results, I need to summarize the top one. Action: summarize_content.

Guardrails are software constraints that validate, sanitize, or block tool invocations. Input sanitization is the specific process of cleansing user-provided data before it is passed as parameters. Both are critical for secure MCP deployments.

• MCP Context: An MCP server or client should implement guardrails that check if a requested tool call is permitted for the given user/session, if parameters are within safe bounds, and if the call rate is limited.
• Sanitization Examples: Escaping special characters in a database query parameter, validating that a file_path parameter doesn't contain ../ sequences, or truncating a string input to a maximum length.
• Defense-in-Depth: MCP's standardized interface allows these security checks to be centralized at the protocol layer, rather than being scattered across individual application code, providing a consistent security posture for all AI-tool interactions.