What is MCP: The Infrastructure Powering Agentic AI

You might not be using AI agents yet, but you will soon. They'll schedule your meetings, analyze your data, write your code, and automate your workflows.

However, to accomplish any of this, they need to access your calendar, data, code, and systems. Large language models can do this the same way any software talks to any other, through your APIs, but APIs weren't designed for LLMs. They were built for traditional software, where developers write explicit code to handle each interaction.

LLMs need something different: a way to discover what's available, understand how to use it, and adapt to other contexts on the fly. Without this, you're stuck building custom integrations for every connection, translating between what your LLM can do and what your APIs expect.

This something different is Model Context Protocol, or MCP.

Bring real-time intelligence to your app. Explore Vision Agents on GitHub, a video-first, open-source framework that lets you build agents that can see, hear, and act.

What is MCP?

The official definition: MCP is an open standard for connecting AI applications to external systems. It lets AI models access data sources, execute tools, and run workflows.

Here's what that means in practice. When you want an LLM to interact with your systems, you need to solve a discovery problem and an execution problem. The LLM needs to know what's available (can I access this database? What functions can I call?) and how to use it (what parameters does this API require? What format should I use?).

Traditional APIs solve this for human developers who read documentation and write code. MCP solves it for LLMs that need to figure things out programmatically. The protocol defines a structured way for systems to advertise their capabilities and for LLMs to request and use them.

MCP handles three types of resources:

• Data sources are anything the LLM needs to read, including your file system, databases, APIs, and documents. An MCP server exposes these in a standardized format that the LLM can query and understand.

• Tools are functions that the LLM can execute: search engines, calculators, code runners, or any operation you want the LLM to perform. The MCP server describes the functionality of each tool and the inputs it expects.

• Workflows are reusable prompts and processes, consisting of specialized instructions, multi-step procedures, or templates that help the LLM handle specific tasks consistently.

When an AI application connects to an MCP server, it receives a comprehensive map of what's available and how to utilize it. The server tells the LLM, "Here's what I have, here's how to ask for it," and the LLM can immediately start working with those resources.

Why MCP Matters

Without MCP, every AI application needs custom integrations for every data source and tool. If you have 10 AI tools and 10 APIs, that's 100 potential integrations to build and maintain. MCP addresses this by standardizing how AI systems interact with external resources.

The impact is similar to what happened with USB. Before USB, every peripheral had its own connector and driver. After USB, you plug anything into anything. MCP does the same for AI: build one MCP server for your API, and any MCP-compatible AI tool can use it. Build one MCP client into your AI application, and it can access thousands of MCP servers, including those already supported by popular MCP-compatible frameworks.

This matters because it removes the integration bottleneck that's been holding back agentic AI. Instead of spending weeks building custom connections, developers can expose their APIs to AI systems in hours. Instead of AI applications being limited to pre-built integrations, they can dynamically discover and use any MCP-compatible resource.

What is the MCP Architecture?

MCP follows a client-server model, but with a specific structure that might not be what you expect. An AI application, such as Claude Desktop or VS Code, acts as the MCP host. When it needs to connect to an MCP server (such as your file system or a database), it doesn't connect directly. Instead, it creates an MCP client for that connection. Each MCP client maintains a one-to-one relationship with a single MCP server.

This means if your AI application connects to three different MCP servers, it instantiates three separate MCP clients:

• One client for the filesystem server

• One client for the database server

• One client for the API server

Each client handles communication with its corresponding server independently. The MCP host coordinates all these clients and aggregates the information they provide.

The protocol consists of two distinct layers that work in tandem.

The data layer is where the actual work happens. This includes the lifecycle management (how connections start and end), capability negotiation (what each side can do), and the primitives we discussed earlier (tools, resources, prompts). When a client asks a server, "What tools do you have?" or executes a function, that's happening at the data layer.

The transport layer handles how messages actually move between clients and servers. MCP supports two transport mechanisms:

• Stdio transport: Uses standard input/output streams for local processes on the same machine. Fast, with no network overhead.

• Streamable HTTP transport: Uses HTTP POST for messages and optionally Server-Sent Events for streaming. Enables remote servers and supports standard authentication like OAuth, bearer tokens, and API keys.

The key insight is that the transport layer abstracts away the communication details. Whether you're using stdio or HTTP, the JSON-RPC messages at the data layer stay the same. A tool discovery request looks identical regardless of how it's transmitted.

This layered architecture means MCP servers can run anywhere. A "local" MCP server might run on your machine using stdio transport. A "remote" MCP server might run on a cloud platform using HTTP transport. However, from the data layer's perspective, they function in the same manner.

An MCP Walkthrough

This all sounds cool, but abstract. Let's make it more tangible by building a simple MCP server that connects to Stream and enables users to interact with a Stream project using natural language.

We'll build an MCP server that exposes five tools for working with Stream Chat: creating channels, sending messages, querying channels, creating users, and querying messages. The complete code is about 200 lines, and you can see precisely how MCP works in practice.

Declaring Tools

The first thing an MCP server needs to do is tell clients what tools it offers. Each client knows to call this specific function from the MCP protocol, which basically responds to the client's "what can you do?" request.

Here's how we declare the create_channel tool:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
server.setRequestHandler(ListToolsRequestSchema,  async  ()  =>  {
  return  {
    tools:  [
      {
        name:  "create_channel",
        description:  "Create a new Stream chat channel",
        inputSchema:  {
          type:  "object",
          properties:  {
            channel_type:  {
              type:  "string",
              description:  "Type of channel (e.g., 'messaging', 'livestream', 'team')",
            },
            channel_id:  {
              type:  "string",
              description:  "Unique identifier for the channel",
            },
            created_by_id:  {
              type:  "string",
              description:  "User ID of the channel creator",
            },
            name:  {
              type:  "string",
              description:  "Name of the channel (optional)",
            },
          },
          required:  ["channel_type",  "channel_id",  "created_by_id"],
        },
      },
      // ... other tools
    ],
  };
});

Each tool declaration includes three critical pieces:

• name: A unique identifier the LLM will use when calling the tool

• description: Natural language explanation of what the tool does (this is what the LLM reads to decide when to use the tool)

• inputSchema: A JSON Schema defining the parameters, their types, descriptions, and which ones are required

The descriptions matter more than you might think. The LLM uses them to understand when to call each tool. "Create a new Stream chat channel" tells the LLM that this tool is for channel creation, not message sending or user management.

Executing Tools

When the LLM decides to use a tool, it sends a request with the tool name and arguments. The server's job is to execute the requested operation and return the results. Here's the complete implementation for create_channel:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
server.setRequestHandler(CallToolRequestSchema,  async  (request)  =>  {
  try  {
    const  {  name,  arguments:  args  }  =  request.params;
    switch  (name)  {
      case  "create_channel":  {
        const  channel  =  client.channel(
          args.channel_type,
          args.channel_id,
          {
            name:  args.name,
            created_by_id:  args.created_by_id,
          }
        );
        await  channel.create();
        return  {
          content:  [
            {
              type:  "text",
              text:  JSON.stringify({
                success:  true,
                channel_id:  args.channel_id,
                channel_type:  args.channel_type,
              },  null,  2),
            },
          ],
        };
      }
      // ... other cases
    }
  }  catch  (error)  {
    return  {
      content:  [
        {  type:  "text",  text:  JSON.stringify({  success:  false,  error:  error.message  },  null,  2)  }
      ],
      isError:  true,
    };
  }
});

The flow is straightforward:

1. Extract the tool name and arguments from the request

2. Execute the Stream SDK operation (in this case, client.channel().create())

3. Format the response as MCP content (an array of content objects)

4. Return the result to the client

Here is the absolutely critical part: the Stream SDK does the actual work of creating the channel. The MCP server serves as a translation layer between what the LLM wants to do and what the Stream API can accomplish. You're not writing entirely new APIs or backends to work with LLMs and MCPs—you're just creating this translation.

Connecting to Claude Desktop

Once the server is created, you can use it with all kinds of clients. For instance, to use this MCP server with Claude Desktop, you add it to Claude's configuration file. On macOS, that's at ~/Library/Application Support/Claude/claude_desktop_config.json:

1
2
3
4
5
6
7
8
9
10
11
12
{
  "mcpServers":  {
    "stream":  {
      "command":  "node",
      "args":  ["/absolute/path/to/stream/mcp/index.js"],
      "env":  {
        "STREAM_API_KEY":  "your_api_key_here",
        "STREAM_API_SECRET":  "your_api_secret_here"
      }
    }
  }
}

This tells Claude Desktop:

• Launch the MCP server using Node.js

• Pass the path to your server script

• Include your Stream credentials as environment variables

When Claude Desktop starts, it reads this config, spawns your MCP server using stdio transport, and establishes the connection. From that point on, Claude can discover your tools and execute them when needed.

Seeing It In Action

Once connected, you can ask Claude to interact with Stream in natural language. When you say, "Can you create a Stream channel called MCP," here's what happens:

Claude recognizes this requires the create_channel tool, determines the appropriate arguments (channel_type: "messaging", channel_id: "mcp", etc.), and calls the tool. In this case, it also realized that we were missing a key component and messaged the user in natural language.

The MCP server then executes the Stream API call and returns the result. We can verify the channel was created by checking the Stream dashboard:

The channel exists in Stream, created entirely through natural language interaction. No API calls, no code, just conversation.

The MCP Ecosystem

MCP is becoming infrastructure. Companies are building MCP servers for their platforms, developers are creating tools to simplify server development, and marketplaces are emerging to help people discover what's available, alongside a growing landscape of AI agent toolkits

Who's Building MCP Servers

Major companies are treating MCP as critical infrastructure for AI integration:

• Stripe's MCP server enables AI agents to interact with their payment API and access their documentation. Developers can use natural language to create customers, process payments, and query their Stripe data.

• Neon's MCP server for their serverless Postgres platform allows AI tools to manage databases and execute queries through conversation.

• Linear's MCP server enables users to bring issue tracking and product development directly into AI assistants, whether refining specs in Claude or creating issues from emails.

• Sentry's MCP server lets users query error data and create projects directly from their IDE or AI assistant.

• Microsoft has released multiple MCP servers, including one that provides real-time access to Microsoft Learn documentation, solving the problem of AI assistants being out of date on the latest frameworks.

MCP Tooling, Discovery, and Hosting

With thousands of MCP servers now available, finding and deploying the right ones has become its own challenge. Platforms like MCP Market, MCP.so, and Smithery allow developers to discover and even host MCP servers.

A tooling ecosystem is emerging around MCP, with different categories of tools addressing specific needs in the development lifecycle:

• Development SDKs: Official SDKs in Python, TypeScript, C#, and Java provide the foundation for building MCP servers in any language.

• Testing and debugging: Tools like the MCP Inspector help developers test their servers locally before deployment, verifying tool schemas and message flows.

• Hosting platforms: Cloudflare Workers and similar edge platforms provide infrastructure for deploying remote MCP servers with global distribution.

• Authentication and security: OAuth implementations and token management systems ensure secure access to MCP servers, particularly crucial for remote deployments.

• Observability: Monitoring and logging tools track MCP server performance, tool invocations, and error rates in production.

• MCP generation: Tools like Stainless that automatically convert existing APIs into MCP servers, eliminating the need to build servers from scratch.

This infrastructure layer is what's accelerating MCP adoption. You don't need to be an expert in AI protocols to expose your API to language models anymore. The tools handle the complexity, and the marketplaces handle discovery.

A Different Way to Build and Use Software

MCP changes software for everyone.

If you're a user, MCP changes how you interact with software. Instead of jumping between dozens of apps and learning different interfaces, you'll work through natural language. Need to check your database, create a GitHub issue, and update your calendar? Just ask. The AI handles the translation, the tools do the work.

If you're a developer, MCP solves the distribution problem. You've built an API, but getting it into AI workflows meant waiting for each AI company to create a custom integration. Now, you can build one MCP server, and every compatible AI tool can use it. Your API becomes accessible to millions of users through the AI assistant of their choice.

The result is a different kind of software ecosystem. Users get unified access to everything through conversation. Developers get a single integration point that unlocks an entire category of usage. The barrier between "I want to do something" and "it's done" drops to near zero.

If you want to get started with MCP:

• For API providers: Start by exploring the official MCP documentation and the MCP specification. If you have an OpenAPI spec, tools like Stainless can generate an MCP server in minutes.

• For developers building AI tools: Check out the MCP SDKs in Python, TypeScript, C#, and Java. The reference implementations show working examples for everyday use cases.

• For discovery: Browse the above marketplaces to see what servers are already available. The ecosystem is growing daily.

The infrastructure is here. The tooling is maturing. The adoption is accelerating. Now it's about building on it.