The 2026 Guide to the MCP Ecosystem

What MCP Actually Is (And What It Isn't)

Model Context Protocol is not a framework, not an orchestration layer, and not a replacement for REST. It is a protocol - a specification for how AI agents communicate with external tools and data sources. Anthropic open-sourced it in November 2024 and the current stable version is the 2025-11-25 spec. Since March 2025, when OpenAI adopted it for their Agents SDK, it has become the closest thing to a universal standard the AI tooling world has.

The protocol defines three core primitives. Resources are read-only data that a server exposes - think a file, a database record, or a paginated API response. Tools are callable functions - create a ticket, send a message, fetch an employee. Prompts are reusable templates with parameters, useful when you want the server to provide structured instruction patterns. Most production MCP use centers on Tools, because that is what agents actually invoke.

The mechanics work like this: an MCP client - Claude Desktop, Cursor, Cline, or whatever agent runtime you're using - opens a session with an MCP server by sending an initialize request. The server responds with its capabilities. The client then calls tools/list to get the full schema of every available tool, including their names, descriptions, and input schemas. The agent uses this schema to decide which tools to call and how to call them. Critically, this discovery happens at runtime, not at design time. The developer does not pre-wire which tools an agent will use - the agent figures it out from the schema.

That runtime discovery is the meaningful difference from a REST API. When you integrate a REST API, you write code that calls specific endpoints. When an agent uses an MCP server, it reads what's available and makes decisions. The same agent code can work with a completely different MCP server and route its calls correctly, because the capability description travels with the server. This is what makes MCP composable in a way that hardcoded REST integrations are not.

What MCP is not worth confusing with: it does not replace your REST API. Every MCP server wraps a REST API (or a database, or a filesystem) underneath. The MCP layer sits between the agent and the underlying system — it provides the agent-readable schema and handles session state. The actual work still happens via HTTP calls, SQL queries, or filesystem reads.

The current spec (2025-11-25) introduced Streamable HTTP as the preferred transport for remote servers, replacing the older HTTP+SSE approach. Local servers still use stdio. If you're reading an older MCP tutorial that mentions SSE, the underlying mechanics are the same but the transport has been updated.

MCP vs REST API vs SDK: When Each One Makes Sense

The question engineers ask when they first encounter MCP is whether it replaces the tools they already have. The short answer is no — but the longer answer explains when MCP actually earns its overhead.

A REST API is stateless and synchronous. You call an endpoint, you get a response, you close the connection. The developer who writes the integration knows exactly which endpoints exist, what parameters they take, and how to handle the response. This works perfectly when a human writes the code — the developer is the decision-maker. The problem is that AI agents are not great at reading OpenAPI specs and reasoning about which of 200 endpoints to call for a given task. REST is built for developers, not for agents.

An SDK wraps a REST API in a language-specific client. It makes the developer's job easier — instead of hand-rolling HTTP calls, you call client.employees.list(). But the agent is still in the same position: it needs the developer to pre-select which SDK calls are available. You can expose SDK methods as LangChain tools or LlamaIndex tools, but that's just another way of hardcoding the capability list at design time.

MCP changes the design contract. The capability list is defined on the server and discovered at runtime. You write the MCP server once — you define what tools exist, what they do, and what parameters they accept. Every MCP client that connects to it gets that schema automatically. You don't need a new SDK per client runtime, and you don't need to update client code when you add a new tool to the server.

The practical implication: use MCP when the agent is making dynamic decisions about which tools to call. Use direct REST calls when the logic is deterministic — your code always calls the same endpoint with predictable parameters. Building a background job that syncs payroll data nightly does not benefit from MCP overhead. Building an agent that answers questions about your employees by deciding whether to query the HRIS, the payroll system, or the ATS — that is where MCP earns its place.

One cost to be honest about: MCP sessions are stateful, which means your infrastructure needs to maintain session state. Stateless REST calls are easier to scale horizontally. For high-throughput production systems, stateful MCP sessions add operational complexity. Most hosted MCP infrastructure (Composio, Pipedream, Knit) handles this for you — but if you're self-hosting MCP servers at scale, session management is an architectural decision, not a solved problem.

The MCP Ecosystem Map: Clients, Servers, and Infrastructure

The MCP ecosystem has three distinct layers that are worth keeping separate in your mental model.

The client layer is where agents live — the applications that connect to MCP servers and invoke their tools. The dominant clients in 2026 are IDE-based coding agents: Cursor, Cline (a VS Code extension), Windsurf, and VS Code's native agent mode. Claude Desktop is the most widely known, but engineering teams working with MCP day-to-day are usually inside their IDE. Goose, Block's open-source CLI agent, is worth knowing for terminal-native workflows. Continue.dev serves teams that want an open-source coding assistant with MCP support inside VS Code or JetBrains IDEs.

Most production agent work with MCP happens in Cursor. If you're picking a client to test against first, start there.

The server layer is where tools are exposed. This is a function the developer writes — you define what the server can do, implement the handlers, and expose it over stdio (for local use) or HTTP (for remote/hosted use). An MCP server can wrap a single API (a Slack MCP server), a category of APIs (all HRIS systems), or an internal system (your company's database). The MCP SDK for TypeScript and Python makes building a basic server a few hours of work. Over 12,000 servers across public registries cover most common developer tools as of April 2026.

The infrastructure layer is what most teams actually need to think about carefully: who is running the MCP servers, how are OAuth tokens managed, and how does your agent authenticate with the underlying services? This is where managed platforms enter. Running a community MCP server from GitHub for a personal project is fine. Connecting your production agent to your customers' Workday, Salesforce, and Greenhouse instances — each requiring OAuth, token refresh, and data normalization — is an infrastructure problem that takes weeks to build and months to maintain.

The infrastructure landscape breaks down like this:

Zapier launched Zapier MCP in 2025, which exposes Zapier actions as MCP tools. The 8,000+ app and 40,000+ action count is impressive and probably the widest in terms of apps supported, however its not the best fit for everyone. In practice, Zapier actions are surface-level automations - form submissions, email triggers, basic record creation - not deep API operations with full schema normalization. Engineers building production agents find the abstraction too shallow.

Pipedream is event-driven workflow infrastructure that now exposes workflows as MCP tools. If your use case is event-triggered automation — a webhook fires, some processing happens, a notification goes out — Pipedream's model maps naturally to that. Where it gets awkward is when agents need to make dynamic decisions about which workflows to invoke. Pipedream's sequential trigger model and agent tool-calling are philosophically different patterns.

Knit (mcphub.getknit.dev) takes the opposite approach: vertical depth over horizontal breadth. The covered verticals are HRIS, ATS, CRM, Payroll, and Accounting - 150+ pre-built servers where the differentiator is not just OAuth proxying but depth of coverage and a robuld Access control layer which is critical to enterprise integrations

Setup takes under 10 minutes: log in at mcphub.getknit.dev, select the tools to include, name the server, and receive a URL and token. Two lines of JSON in your Claude Desktop or Cursor config and the server is live — no OAuth plumbing, no token refresh logic, no API version maintenance.

Top MCP Servers by Use Case (And When to Self-Host)

The 12,000+ community MCP servers across public registries cover an enormous surface area, but most production agent work falls into a handful of verticals. Here is how to think about the build-vs-use decision for each.

Developer tooling — GitHub, Linear, Jira, Notion, Slack — has well-maintained official or near-official MCP servers. GitHub's official MCP server handles repository operations, pull request management, and code search. Linear's MCP server exposes issue creation, filtering, and status updates. For this category, use existing servers. Building your own GitHub MCP server is wasted work.

Business data — HR, payroll, and ATS — is where the build decision gets expensive quickly. Connecting to Workday requires an enterprise API agreement. Connecting to BambooHR, Rippling, Greenhouse, Lever, ADP, and Gusto each requires separate OAuth integrations, different field naming conventions, and ongoing maintenance as providers update their APIs. A team building an HR assistant agent that needs to answer "who manages this person", "when was their last performance review", and "what's their current compensation" needs to pull from three different systems that each return employee IDs differently. This is the problem Knit's unified schema solves — one get_employee tool call returns the same normalized object regardless of whether the underlying system is Workday or BambooHR.

Internal data systems — your company's database, internal APIs, proprietary data stores — are the one case where self-hosting is justified. If you're building an MCP server that wraps your internal PostgreSQL analytics database, you should host that yourself. No managed platform will have your internal schema, and you shouldn't be sending your internal data through a third-party proxy.

Communication and productivity tools — Slack, Gmail, Google Drive, Notion — have good first-party or community servers. The main maintenance concern is OAuth token lifecycle and API version changes. Composio or Nango are reasonable choices for managing token refresh on these.

A note on server count: the instinct when discovering MCP is to connect as many servers as possible. Resist it. Every MCP server connected to your agent adds its tool list to the context window. An agent with 40 MCP servers and 500 available tools wastes tokens on tools/list responses, risks poor tool selection from name collisions, and adds latency to every agent turn. The right architecture is purpose-specific: a coding agent has GitHub + Linear + Slack. An HR analytics agent has Knit's HRIS and payroll servers. Build focused agents, not Swiss Army knife agents.

How to Build Your Own MCP Server

When you have an internal system, a proprietary data source, or an API that no managed server covers, building your own MCP server is a straightforward process. The official TypeScript SDK is the most mature option.

Install the SDK:

# v1.x — current stable production release
npm install @modelcontextprotocol/sdk

A minimal MCP server that exposes one tool looks like this:

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import {
  ListToolsRequestSchema,
  CallToolRequestSchema
} from "@modelcontextprotocol/sdk/types.js";

const server = new Server(
  { name: "internal-hr-server", version: "1.0.0" },
  { capabilities: { tools: {} } }
);

server.setRequestHandler(ListToolsRequestSchema, async () => ({
  tools: [
    {
      name: "get_employee",
      description: "Fetch an employee record by their internal ID",
      inputSchema: {
        type: "object",
        properties: {
          employee_id: {
            type: "string",
            description: "The employee's internal system ID"
          }
        },
        required: ["employee_id"]
      }
    }
  ]
}));

server.setRequestHandler(CallToolRequestSchema, async (request) => {
  if (request.params.name === "get_employee") {
    const { employee_id } = request.params.arguments as { employee_id: string };

    // Replace with your actual data source call
    const employee = await fetchFromInternalHRSystem(employee_id);

    return {
      content: [{ type: "text", text: JSON.stringify(employee, null, 2) }]
    };
  }

  throw new Error(`Unknown tool: ${request.params.name}`);
});

const transport = new StdioServerTransport();
await server.connect(transport);

For local use (Claude Desktop, Cursor), stdio transport is sufficient. The client launches the server as a subprocess and communicates over stdin/stdout. You register the server in your Claude Desktop config (claude_desktop_config.json) or Cursor settings:

{
  "mcpServers": {
    "internal-hr-server": {
      "command": "node",
      "args": ["/path/to/your/server/dist/index.js"]
    }
  }
}

For remote use - when you need the server accessible over the network, shared across a team, or running on managed infrastructure — use the HTTP transport. The 2025-11-25 spec introduced Streamable HTTP as the preferred approach:

import { StreamableHTTPServerTransport } from "@modelcontextprotocol/sdk/server/streamableHttp.js";
import express from "express";

const app = express();
app.use(express.json());

const transport = new StreamableHTTPServerTransport({ sessionIdGenerator: () => crypto.randomUUID() });
await server.connect(transport);

app.post("/mcp", (req, res) => transport.handleRequest(req, res));
app.get("/mcp", (req, res) => transport.handleRequest(req, res));

app.listen(3000);

Remote clients reference the server by URL:

{
  "mcpServers": {
    "internal-hr-server": {
      "url": "https://your-server.internal.example.com/mcp",
      "headers": { "Authorization": "Bearer YOUR_SERVER_TOKEN" }
    }
  }
}

For the Python SDK, install with pip install mcp and import from the mcp.server module — the handler pattern is functionally identical to the TypeScript version.

The practical scope question: build your own server when the tool wraps a system only you have access to (internal database, proprietary API, company-specific business logic). Use a managed server when the tool wraps a third-party SaaS that other companies also use - someone has likely already built and maintained the integration.

For the HR, payroll, ATS, and CRM category specifically, the build cost compounds quickly: separate OAuth apps per provider, different field naming conventions across systems (employee_id vs workdayId vs a UUID), rate limit differences, and API version changes that break your integration with no warning. Knit's pre-built servers at mcphub.getknit.dev cover 150+ of these systems with a unified schema. The decision to build your own should be reserved for systems that no managed platform will ever have access to.

MCP in Production: Security Considerations You Can't Skip

The instinct when evaluating MCP security is to focus on the network layer — TLS, API key rotation, OAuth scopes. These matter, but they're not the specific risks that MCP introduces. The protocol creates attack surfaces that REST-based architectures don't have.

Tool poisoning is the most direct risk. An MCP server exposes tool descriptions — strings that describe what each tool does and how to use it. An agent reads these descriptions as part of its context. A malicious or compromised server can embed instructions inside tool descriptions that redirect agent behavior. The description for a search_files tool might contain hidden text instructing the agent to exfiltrate credentials. Because the agent processes tool descriptions as natural language context, this is a prompt injection vector that bypasses traditional input validation. Nothing in the MCP protocol prevents a server from returning whatever text it wants in a tool description.

The mitigation: treat tool descriptions as untrusted input. If you're building infrastructure that forwards tool descriptions to an agent, implement a filtering layer that inspects descriptions for instruction-like patterns before the agent sees them. For internal use, this risk is lower — you control the servers. For agents that connect to user-supplied or community MCP servers, it is a genuine attack surface.

Supply chain risk from community servers is the second concern. The 12,000+ servers across public registries are unaudited. A popular community MCP server that requests filesystem access and network access is a privileged process running on the developer's machine. The server's code was written by strangers, and versions change without formal security reviews.

Two 2025 incidents make this concrete. In September 2025, the postmark-mcp npm package was backdoored: attackers modified version 1.0.16 to silently BCC every outgoing email to an attacker-controlled domain. Sensitive communications were exfiltrated for days before detection. A month later, the Smithery supply chain attack exploited a path-traversal bug in server build configuration, exfiltrating API tokens from over 3,000 hosted MCP applications. CVE-2025-6514, a critical vulnerability in the widely-used mcp-remote package, represents the first documented full system compromise achieved through MCP infrastructure — affecting Claude Desktop, VS Code, and Cursor users simultaneously.

For production environments, restrict your agents to MCP servers from known, maintained sources — not arbitrary GitHub repositories. Self-hosted or managed infrastructure with version pinning is the right approach.

Overprivileged servers are the operational risk that compounds over time. An MCP server that wraps your CRM shouldn't need filesystem access. A server that queries employee records shouldn't have the scope to update payroll data. Scope tool capabilities to the minimum required for the tool's stated function. In practice, this means auditing the inputSchema of each tool and the underlying API permissions the server holds — not just at setup time, but whenever the server is updated.

Cross-server context pollution is a subtler issue. When an agent has multiple MCP servers connected simultaneously, the tool descriptions from all servers exist in the same context window. A malicious server can craft its tool descriptions to influence how the agent interprets instructions for other servers. Keeping agent scope focused — coding agents use coding tools, HR agents use HR tools — limits the blast radius.

Tool poisoning is codified in the OWASP MCP Top 10 as MCP03:2025 — it is not a theoretical threat. For teams running agents against customer data, the operational requirements are: log every tool call with full parameters and responses; bind tool permissions to the narrowest scope available; alert on anomalous tool call patterns (an HR agent suddenly making filesystem calls is a signal, not a coincidence). The OWASP MCP Top 10 is the right starting point for a formal threat model.

Managed, vertically-scoped infrastructure reduces the attack surface in a specific way: you know in advance what each server can touch. A Knit HRIS server has access to employee data — and nothing else. There is no filesystem access, no shell execution, no access to systems outside the declared scope. You are connecting to a defined server with a published schema, not running arbitrary code from the internet. The tool poisoning risk still exists (any server could return malicious text in descriptions), but the supply chain risk — the npm backdoor, the compromised registry — is substantially lower when you're using infrastructure with clear ownership, versioning, and a support contact. The OWASP MCP Top 10 is still the right framework for your threat model regardless of which infrastructure you choose.

FAQ

What is the Model Context Protocol (MCP)?

‍MCP (Model Context Protocol) is an open protocol created by Anthropic that standardizes how AI agents communicate with external tools and data sources. Instead of developers pre-wiring specific API calls, MCP servers expose a discoverable tool schema at runtime — the agent calls tools/list, sees what's available, and decides which tools to invoke autonomously. Knit uses MCP to let agents connect to HRIS, payroll, ATS, and CRM systems through a single normalized interface.

How is MCP different from a REST API?

‍A REST API is stateless and consumed by developer-written code that calls specific endpoints. MCP is a stateful protocol where an AI agent discovers available tools at runtime via tools/list and decides which to call — without the developer hardcoding the routing logic. MCP servers typically wrap REST APIs underneath; the protocol layer sits between the agent and the underlying system.

What MCP clients are available in 2026?

‍The major MCP clients are: Claude Desktop (Anthropic), Cursor, Cline (VS Code extension), Windsurf (Codeium), VS Code (native agent mode), Goose (Block), Zed, and Continue.dev. Most production agent work with MCP happens inside IDE-based clients — Cursor and Cline are the most commonly used by engineering teams.

What is a managed MCP server and when do I need one?

‍A managed MCP server is hosted infrastructure that wraps third-party APIs with MCP-compatible schemas and handles OAuth token management. You need one when your agent needs to connect to third-party SaaS tools that require OAuth flows, schema normalization, or ongoing API maintenance — for example, connecting to your customers' HRIS or payroll systems. Knit provides managed MCP servers for 150+ HRIS, ATS, CRM, payroll, and accounting tools.

How many MCP servers should I connect to one agent?

‍As few as the task requires. Each connected MCP server adds its full tool list to the agent's context window. Connecting 40 servers with 500 aggregate tools wastes tokens on tools/list responses, increases tool selection errors, and adds latency. The right architecture is purpose-specific: a coding agent uses GitHub + Linear + Slack; an HR assistant uses HRIS and payroll servers. Build focused agents.

What are the main security risks with MCP?

‍The two MCP-specific risks that don't exist in standard REST integrations are: (1) tool poisoning — a server embeds malicious instructions inside tool descriptions, which the agent processes as context, and (2) supply chain attacks — unaudited community MCP servers requesting elevated permissions (filesystem, network) run as privileged processes. Mitigate by using managed, versioned MCP infrastructure rather than arbitrary community servers, and filtering tool descriptions for instruction-like patterns before they reach the agent.

Can I build my own MCP server?

‍Yes. The official TypeScript SDK (@modelcontextprotocol/sdk) and Python SDK (mcp) make it straightforward. You implement two handlers: ListToolsRequestSchema (returns your tool schema) and CallToolRequestSchema (executes the tool). Build your own server when wrapping an internal database or proprietary API. For third-party SaaS integrations that other companies also use, a managed server from Knit or Composio saves months of OAuth plumbing and maintenance work.

‍