MCP Beast

MCP Fundamentals

What Is the Model Context Protocol?

By Antoine van der Lee·

Every enterprise AI integration built before the Model Context Protocol is a liability waiting to surface. Custom connectors, bespoke auth flows, one-off error handling — each one a maintenance burden that compounds as the number of agents and tools grows. MCP is the open standard Anthropic published in late 2024 to collapse that complexity: a single protocol that lets any AI host talk to any tool, without custom glue code for every pair.

If you're evaluating AI infrastructure decisions in 2026, understanding what is model context protocol — and what it doesn't cover — is the prerequisite.

The Problem MCP Solves: M×N Integration Hell

The failure mode is an M×N matrix: M AI applications multiplied by N external systems, each pair requiring its own connector. A coding assistant might need separate integrations for GitHub, Jira, Confluence, Postgres, and internal CI — each with different auth patterns, different context-passing conventions, different failure modes.

At scale, teams spend more time wiring integrations than building the AI features those integrations were supposed to enable. MCP collapses the matrix: tools expose a standard interface once; AI hosts consume that interface once; the protocol handles the middle.

The Core Architecture: Host, Client, Server

MCP defines three roles:

  • Host — the application running the AI model and driving the conversation. Examples include chat interfaces, IDE extensions, and autonomous agent runtimes. The host controls which MCP servers are accessible and manages session lifecycle — making it the natural enforcement point for policy.
  • Client — a component inside the host that holds a one-to-one connection to a single MCP server. It speaks the protocol: sends requests, receives responses, surfaces server capabilities. Without a client-layer gateway, every host manages its own server connections independently — which is how sprawl starts.
  • Server — a lightweight process (local or remote) that exposes specific capabilities to the AI. A server might wrap a file system, a database, a REST API, or a browser. It declares what it offers, and the host can instruct the model to use it.

The protocol runs over standard transports — stdio for local processes, HTTP/SSE for remote — and uses JSON-RPC 2.0 as its message format. The model never talks directly to MCP servers; it issues tool-call instructions and the host/client layer executes them. That indirection is where LLM tool calling intersects with MCP's transport layer.

What MCP Actually Exposes

MCP servers surface three primitive types:

  • Tools — callable functions the model can invoke: run a SQL query, create a GitHub issue, send a Slack message. Tools carry a name, a natural-language description the model uses to decide when to call them, and a JSON Schema defining their inputs. Without scoped access control on tools, any agent with server access can call any function — the blast radius of a misconfigured agent is the full tool surface.
  • Resources — read-only data the model can reference: files, database rows, API responses. Resources provide context without executing side effects — a customer record a model can read without issuing a write command. The distinction matters for AI agent access control policy: read and write primitives should be governed separately.
  • Prompts — reusable prompt templates the host can inject into conversations. Less commonly deployed but useful for standardizing how agents interact with a given system — and for reducing prompt injection surface by keeping template content out of user-controlled inputs.

Enterprise deployments today are heavily tool-focused, with resources gaining ground as teams shift toward retrieval-augmented workflows.

What MCP Is Not

MCP is frequently conflated with adjacent concepts. The distinctions matter for architecture decisions:

  • MCP is not a REST API. REST APIs are designed for applications to call on demand. MCP is designed for AI agents — it exposes metadata and descriptions that help a model decide whether and how to call something. The interface is self-describing in a way REST APIs are not. For a deeper comparison, see MCP vs API.
  • MCP is not an agent framework. Frameworks like LangChain or CrewAI handle orchestration, memory, and multi-agent coordination. MCP is the connectivity layer underneath them — usable with or without a framework.
  • MCP is not a security boundary. The protocol specifies how capabilities are described and invoked, not who is authorized to invoke them. Access control, authentication, and policy enforcement are the responsibility of infrastructure surrounding the servers. This gap is the central challenge in MCP security for enterprise environments.
  • MCP is not vendor-specific. Anthropic wrote the spec; OpenAI, Google DeepMind, Microsoft, and dozens of tool vendors have adopted it. Choosing MCP as your integration layer doesn't lock you to any model provider.

Why Enterprise Teams Are Paying Attention

MCP adoption is accelerating for the same reason microservices adoption did a decade ago: the alternative — custom integrations everywhere — doesn't scale. But enterprise deployment surfaces governance problems the base protocol doesn't solve:

  • Server sprawl — MCP servers multiply as teams deploy agents. Without a server registry, it's impossible to inventory what capabilities exist, who owns them, or whether they're still maintained.
  • Trust and policy — an agent with unrestricted access to dozens of MCP servers carries significant blast radius. Enterprises need controls over which agents can call which servers, under what conditions, with what rate limits — the core problem MCP best practices address.
  • Audit and attribution — when an agent modifies a record or sends a message, compliance teams need to know which model issued the instruction, through which server, with what inputs and outputs. The base protocol carries no audit metadata; that requires AI agent audit logs infrastructure layered on top.
  • Cost and ROI visibility — MCP calls consume tokens and incur infrastructure costs. Without instrumentation, there's no way to tie AI spend to business outcomes — a gap that undermines any credible AI agent ROI case.

These are governance and platform engineering problems, not protocol problems. The protocol gives you the wiring. What you do with it is an infrastructure question.

How MCP Works in Practice

Understanding the runtime flow clarifies where controls must sit. An agent issues a tool-call instruction — say, "query the customer database." The host's MCP client routes that to the appropriate server. The server executes the query and returns structured results. The host surfaces those results back to the model for the next reasoning step.

In a flat deployment with no gateway, each host manages its own server connections directly — no shared policy, no centralized logging, no cross-agent visibility. That architecture works for a proof of concept; it fails when you have multiple teams, multiple agents, and compliance requirements. MCP server management and MCP monitoring and observability are the operational disciplines that make the protocol production-safe.

For a deeper look at how servers are structured and deployed, see What Are MCP Servers?.

Frequently Asked Questions

What is the Model Context Protocol in simple terms?

MCP is a standard that lets AI models connect to external tools and data sources — databases, APIs, file systems — through a common interface. Build or deploy an MCP server once, and any AI host that speaks the protocol can use it without custom integration code.

Who created MCP and who supports it?

Anthropic published the initial specification in November 2024. OpenAI, Google DeepMind, Microsoft, and a large ecosystem of tool vendors and open-source contributors have since adopted it. The spec is maintained as an open standard — not proprietary to any single vendor.

Is MCP the same as function calling?

Not exactly. Function calling (as in OpenAI's API) is a feature of a specific provider's API — available functions are declared in each request. MCP is a standalone protocol outside any provider's API: the same MCP server works with any model or host that supports the protocol, without re-declaring capabilities on every call. That portability is what makes MCP viable as enterprise infrastructure.

What are the main security risks of MCP?

The protocol itself doesn't enforce authentication, authorization, or audit logging — those must be added at the infrastructure layer. The primary risks are unauthorized tool invocation, prompt injection through server-returned content, and lateral movement between servers an agent shouldn't reach.

MCP Beast is a control plane for enterprise MCP deployments — centralized registry, policy enforcement, and audit logging across all MCP infrastructure. Request an architecture review for your team.

Related: