Who created MCP and when?

Anthropic created MCP and open-sourced it on November 25, 2024. The initial release included the specification, software development kits for Python and TypeScript, and reference server implementations for common systems. Because the protocol is open, it is not limited to Anthropic products. Public documentation shows a broad ecosystem of clients and servers has adopted it, including other AI assistants and development tools. Lightbridge Labs works within the Anthropic and Claude ecosystem and treats MCP as an open standard rather than a single vendor's feature.

MCP follows a client-server architecture. An MCP host, which is the AI application, creates one MCP client for each MCP server it connects to, and each client maintains a dedicated connection to its server. Servers expose capabilities through three core primitives: tools, which are executable functions the model can invoke; resources, which are data sources the model can read; and prompts, which are reusable interaction templates. Under the hood the data layer uses JSON-RPC, and communication runs over one of two transports: standard input and output for local servers, or HTTP for remote servers that can serve many clients. Spec details evolve, so verify current specifics at modelcontextprotocol.io before building around a particular version.

Why does MCP matter for enterprises?

MCP matters because it turns integration from an N-by-M problem into a single standard. Before MCP, connecting several AI applications to several internal systems meant a custom connector for each pair, which is slow to build and hard to maintain. With MCP a system is exposed once as a server and every compliant AI application can reach it. For an enterprise, that means faster delivery, fewer bespoke integrations to maintain, and a cleaner boundary to govern, since access flows through a defined interface rather than scattered custom code. The tradeoff is that giving a model more reach raises the stakes on access control, which is why Lightbridge Labs pairs MCP work with governance.

Is MCP only for Claude?

No. MCP is an open standard, not a Claude-only feature. Anthropic created it and open-sourced it, and public documentation shows adoption across a wide range of AI assistants and development tools beyond Anthropic products. That openness is the point: a team can build one MCP server and connect it to any AI application that supports the protocol. Lightbridge Labs is aligned with the Claude and Anthropic ecosystem and builds on it, and it treats MCP as vendor-neutral connective tissue rather than a lock-in mechanism.

How is MCP different from tool use or function calling?

Tool use, sometimes called function calling, is a capability of a single model API: the model returns a structured request to call a function, and your application runs it. MCP is a standard for how those tools and data are exposed and discovered across applications. Put simply, function calling is how one model asks to use a tool; MCP is how a server publishes tools and data so any compliant client can find and use them without a custom integration. The two work together. An agent can use a model's tool-calling ability to invoke tools that an MCP server makes available. Lightbridge Labs covers the model-side mechanics in its guide to building with the Claude API.

RL Written by Robert LabardeeFounder and CEO

Last updated July 2026.

What is the Model Context Protocol (MCP)?

Lightbridge Labs defines the Model Context Protocol (MCP) as an open standard for connecting AI applications to external tools, data sources, and workflows through one common interface. Anthropic introduced and open-sourced MCP on November 25, 2024. It replaces bespoke, one-off integrations with a single protocol an AI application can speak to any compliant system.

Build agents with Lightbridge Labs Start with AI agents

MCP is one standard for connecting AI applications to outside systems.

The Model Context Protocol is an open standard that connects AI applications to the tools, data, and workflows they need to do real work. Anthropic introduced MCP on November 25, 2024 and open-sourced it, along with the specification, software development kits, and reference servers. The official documentation offers a plain analogy: MCP is like a USB-C port for AI applications. Just as USB-C gives devices one standard connector, MCP gives an AI application one standard way to reach an external system.

The problem it solves is fragmentation. Before a shared standard, every new data source an AI application needed meant its own custom connector, which does not scale as the number of applications and systems grows. MCP replaces that N-by-M tangle of bespoke integrations with a single protocol. A system is exposed once, and any compliant AI application can connect. For the vocabulary that runs through this and the surrounding guides, the AI glossary from Lightbridge Labs is a useful companion. Because the protocol moves quickly, verify current specifics at the official documentation site, modelcontextprotocol.io, before planning around a particular detail.

MCP uses a client-server architecture: host, client, server.

MCP follows a client-server model with three participants. An AI application acts as the host, it creates one client per server it connects to, and each client holds a dedicated connection to a single server. The pattern keeps every connection isolated and every server independent.

MCP host

The AI application that coordinates the work: an assistant such as Claude Desktop, an IDE such as Visual Studio Code, or a custom agent your team builds. The host manages one or more clients and decides how the context it receives is used. MCP itself does not dictate how the host uses a language model.

MCP client

A component inside the host that maintains a dedicated connection to a single server and obtains context from it. The host creates one client per server, so each connection stays isolated. Four servers means four clients, each holding its own session.

MCP server

A program that exposes tools and data to clients over the protocol, regardless of where it runs. A local server communicates over standard input and output on the same machine; a remote server communicates over HTTP and can serve many clients at once.

Beneath the participants sit two layers. A data layer, built on JSON-RPC, defines the messages clients and servers exchange. A transport layer defines how those messages travel: standard input and output for local servers, or HTTP for remote servers that serve many clients and can carry standard authentication. The transport is where access control lives, which makes it central to any enterprise rollout.

MCP servers expose three primitives: tools, resources, and prompts.

The heart of MCP is a small set of server primitives. They define what a server can offer a client and, through it, the model. A client discovers what is available, then reads and calls what the task needs.

Tools

Executable functions an AI application can invoke to perform actions: a database query, an API call, a file operation. The client discovers available tools, and the model chooses when to call one and with what arguments. Tools are how MCP lets a model act on the outside world.

Resources

Data sources that provide context to the model: file contents, database records, API responses. Resources supply the information a model reads to reason well, rather than an action it takes. A server exposes them for the client to retrieve on demand.

Prompts

Reusable templates that structure an interaction, such as a system prompt or a set of few-shot examples. A server can package a proven prompt once and offer it to every client that connects, so interaction patterns are shared rather than rewritten.

Tools are the primitive that matters most for agents, because tools are how a model takes action rather than only reading. That connects MCP directly to agent design: an AI agent reaches tools and data to do multi-step work, and MCP is one standard way to supply that reach. For the engineering path of constructing an agent, the Lightbridge Labs guide on how to build an AI agent covers the loop, the tools, and the guardrails.

The MCP ecosystem spans hosts, tools, servers, and SDKs.

Because MCP is an open standard, a wide ecosystem has grown around it. The categories below describe the kinds of software that speak MCP. This is an explainer of categories and how they fit together, not a ranking. Product names are descriptive only, and the right choice for any team depends on fit, not on which name is loudest.

AI assistants and hosts

AI applications that act as MCP hosts, connecting to servers to reach tools and data. Examples include Claude and, per public documentation, ChatGPT.

Development tools

Editors and IDEs that embed an MCP host so a coding assistant can reach project tools and context. Examples include Visual Studio Code and Cursor.

MCP servers

Programs that expose a system's tools and data over MCP. Reference implementations cover file systems, databases, and common developer platforms.

SDKs and reference implementations

Official software development kits, published for multiple languages, that implement the protocol so teams build servers and clients without hand-rolling the wire format.

MCP is deliberately provider-agnostic. A team can build one server and connect it to any AI application that supports the protocol. Where an integration touches a specific business platform, ownership of that platform's advisory content sits elsewhere in the Lightbridge family: connecting AI to NetSuite is covered by Lightbridge ERP, and connecting AI to Salesforce is covered by Lightbridge Cloud. Lightbridge Labs owns the AI-agent, MCP, and agent-infrastructure side of the picture.

Enterprises adopt MCP to standardize integration and govern access.

The enterprise case for MCP is not novelty. It is that one standard replaces a sprawl of custom connectors, which cuts delivery time and maintenance and creates a single, governable boundary between AI applications and internal systems. The same reach that makes MCP useful is what makes access control the central concern. Lightbridge Labs approaches adoption through a few disciplined moves.

Decide what to expose, not just how

The first MCP decision is scope. Which systems should a model reach, which tools should it be allowed to call, and which data should it read. Expose the smallest useful surface first. A tight server is easier to reason about and easier to govern than one that hands a model the keys to everything.

Prefer remote servers with real authentication

A remote server over HTTP can serve many clients and carry standard authentication such as OAuth. For anything touching business systems, that is the path to control who and what a server will answer, rather than a local process with no access boundary.

Govern the tools a model can call

MCP makes a model more capable by giving it actions. That is exactly why the tool set is a governance decision. Constrain permitted tools, log every call, and place human review on consequential actions. The protocol carries the connection; your program decides what is allowed.

Treat MCP as plumbing, not strategy

MCP is a connection standard. It does not decide which tasks are worth an agent, how you evaluate one, or how you keep it safe. Those are the questions a Lightbridge Labs engagement answers around the protocol, not inside it.

MCP is one piece of a larger build. Deciding which tasks deserve an agent, wiring a model to tools, evaluating behavior, and keeping the whole thing safe is the work around the protocol. Developers can start with the model-side mechanics in building with the Claude API, and teams that want a partner to design and deliver the system can work with the Lightbridge Labs AI agents practice. Governance runs alongside every build through the AI governance practice, which operates to ISO 42001 controls with certification in progress.

What is MCP: frequently asked questions

What is the Model Context Protocol (MCP)?: The Model Context Protocol, or MCP, is an open standard for connecting AI applications to external tools, data sources, and workflows through one common interface. Anthropic introduced and open-sourced MCP on November 25, 2024. A useful analogy from the official documentation is a USB-C port for AI applications: just as USB-C gives devices one standard way to connect, MCP gives an AI application one standard way to reach outside systems. Instead of writing a custom integration for every data source, a developer builds against MCP once and can then connect to any system that speaks the protocol.
Who created MCP and when?: Anthropic created MCP and open-sourced it on November 25, 2024. The initial release included the specification, software development kits for Python and TypeScript, and reference server implementations for common systems. Because the protocol is open, it is not limited to Anthropic products. Public documentation shows a broad ecosystem of clients and servers has adopted it, including other AI assistants and development tools. Lightbridge Labs works within the Anthropic and Claude ecosystem and treats MCP as an open standard rather than a single vendor's feature.
How does MCP work?: MCP follows a client-server architecture. An MCP host, which is the AI application, creates one MCP client for each MCP server it connects to, and each client maintains a dedicated connection to its server. Servers expose capabilities through three core primitives: tools, which are executable functions the model can invoke; resources, which are data sources the model can read; and prompts, which are reusable interaction templates. Under the hood the data layer uses JSON-RPC, and communication runs over one of two transports: standard input and output for local servers, or HTTP for remote servers that can serve many clients. Spec details evolve, so verify current specifics at modelcontextprotocol.io before building around a particular version.
What are the core primitives in MCP?: MCP defines three core primitives that a server can expose. Tools are executable functions an AI application can invoke to perform actions, such as querying a database or calling an API. Resources are data sources that provide context to the model, such as file contents or database records. Prompts are reusable templates that structure an interaction, such as a system prompt or few-shot examples. A client discovers what a server offers, then retrieves resources, reads prompts, and calls tools as the task requires. The protocol also defines primitives a client can expose back to servers, but the three server primitives are the ones most builders work with first.
Why does MCP matter for enterprises?: MCP matters because it turns integration from an N-by-M problem into a single standard. Before MCP, connecting several AI applications to several internal systems meant a custom connector for each pair, which is slow to build and hard to maintain. With MCP a system is exposed once as a server and every compliant AI application can reach it. For an enterprise, that means faster delivery, fewer bespoke integrations to maintain, and a cleaner boundary to govern, since access flows through a defined interface rather than scattered custom code. The tradeoff is that giving a model more reach raises the stakes on access control, which is why Lightbridge Labs pairs MCP work with governance.
Is MCP only for Claude?: No. MCP is an open standard, not a Claude-only feature. Anthropic created it and open-sourced it, and public documentation shows adoption across a wide range of AI assistants and development tools beyond Anthropic products. That openness is the point: a team can build one MCP server and connect it to any AI application that supports the protocol. Lightbridge Labs is aligned with the Claude and Anthropic ecosystem and builds on it, and it treats MCP as vendor-neutral connective tissue rather than a lock-in mechanism.
How is MCP different from tool use or function calling?: Tool use, sometimes called function calling, is a capability of a single model API: the model returns a structured request to call a function, and your application runs it. MCP is a standard for how those tools and data are exposed and discovered across applications. Put simply, function calling is how one model asks to use a tool; MCP is how a server publishes tools and data so any compliant client can find and use them without a custom integration. The two work together. An agent can use a model's tool-calling ability to invoke tools that an MCP server makes available. Lightbridge Labs covers the model-side mechanics in its guide to building with the Claude API.

This guide is independent, general educational information published by Lightbridge Labs. The Model Context Protocol is an open standard; specifics change over time, so verify current details at modelcontextprotocol.io. Claude and Anthropic are trademarks of Anthropic, PBC. Lightbridge Labs is not affiliated with, endorsed by, or a partner of Anthropic, PBC.

From understanding MCP to connecting AI to your systems safely.

When the question shifts from what MCP is to how to connect AI to your data and tools under real access control, Lightbridge Labs designs the integration, builds the agents around it, and pairs both with governance.

Talk to Lightbridge Labs See the AI agents practice