Model Context Protocol (MCP)

The mechanism by which a foundation model outputs structured data—typically a JSON object with a function name and parameters—rather than freeform text. This structured output is parsed by a runtime to execute a specific API call, database query, or equipment command. In MCP, function calling is the primary interaction pattern: the model selects a tool from the MCP server's manifest and generates the precise payload required to invoke it. Unlike prompt-based tool use, function calling guarantees a deterministic, parseable schema that eliminates regex extraction and reduces failure modes in production.

A declarative schema exposed by an MCP server that enumerates every available tool, its input parameters, expected types, and human-readable descriptions. The manifest acts as a contract between the model and external systems:

• Each tool has a unique name and description the model uses for selection
• Input schemas follow JSON Schema specification, enforcing type safety
• The model reads the manifest at connection time and uses it to decide which tool to invoke In manufacturing, a tool manifest might expose query_opcua_sensor, adjust_setpoint, or retrieve_maintenance_log as discrete, callable capabilities.

A lightweight, headless process that implements the Model Context Protocol and exposes tools, resources, and prompts to connected AI hosts. Each server is a sidecar to a specific data source or system:

• Wraps legacy industrial protocols like OPC UA, Modbus, or MQTT behind a uniform interface
• Handles authentication, rate limiting, and error serialization
• Can run locally on factory-floor hardware or as a cloud-side service Multiple MCP servers can be composed, allowing a single model to simultaneously interact with a PLC historian, a vector database of manuals, and an ERP API through a unified protocol.

The AI application layer—such as an IDE, chatbot, or autonomous agent runtime—that initiates connections to one or more MCP servers. The client is responsible for:

• Connection lifecycle management: establishing and maintaining persistent sessions
• Context assembly: aggregating tool manifests from all connected servers into a unified prompt context
• Tool execution orchestration: receiving the model's function call, routing it to the correct server, and returning the result to the model's context window In a manufacturing copilot, the host might be a natural language interface on the shop floor that connects to MCP servers for equipment control and documentation retrieval.

A read-only data access primitive in the Model Context Protocol that exposes structured or unstructured content to the model without executing side effects. Unlike tools, resources are idempotent and safe—they cannot modify system state. Examples in manufacturing:

• sensor://line3/temperature — current reading from a specific sensor
• docs://manuals/pump-ax200 — the full text of an equipment manual
• schema://erp/orders — the database schema for the order table Resources use URI templates for parameterized access and support content negotiation for different MIME types, enabling models to browse available data before retrieval.

The communication substrate that carries MCP messages between clients and servers. The protocol defines two standard transports:

• stdio: JSON-RPC messages over standard input/output streams, ideal for local, single-machine integrations where the client spawns the server as a subprocess
• Streamable HTTP: JSON-RPC over HTTP with optional Server-Sent Events for streaming responses, enabling remote, networked deployments across factory subnets Both transports use JSON-RPC 2.0 as the message format, ensuring a consistent request/response/notification pattern regardless of the underlying channel. Transport selection is a critical architectural decision balancing latency, security, and deployment topology.