MCP — the Model Context Protocol — is an open standard for letting a language model call external tools and read external data through one consistent interface. Instead of every application inventing its own plugin format, an MCP server describes its tools once and any MCP-capable client can discover and call them.
The shape is simple. A server advertises tools (things the model can call), resources (things it can read) and prompts. The client — an assistant, an IDE, an agent framework — connects, lists what is available, and calls what it needs. Transport is typically Streamable HTTP; the older SSE transport is being retired.
For industrial data this matters more than it might sound, because the alternative is bad in a specific way. Without MCP, giving an assistant access to machine telemetry means writing a bespoke integration per assistant, and each one needs to be told the shape of your data. With MCP the capability is described once and the model discovers it — fleet_health, normalize, predict_breach — without a human writing the call.
The prerequisite is the boring one: MCP moves the data, it does not make it coherent. An MCP server over raw vendor tags just hands the model the same mess through a nicer door. The combination that works is normalization underneath and MCP on top — which is what Forge exposes at https://mcp.foundrynet.io/mcp, 32 tools over Streamable HTTP, backed by 16,908 curated mappings.
Anthropic published it as an open standard, and it has since been adopted across multiple assistants and agent frameworks.
No. It sits alongside one. REST is for code you write; MCP is for a model that discovers and calls the capability itself.
Streamable HTTP. The older SSE transport is deprecated and some registries and clients reject SSE-only servers outright.