MCP: an in-depth introduction

To abuse a famous quote about monoids , “MCP is an open protocol that standardizes how applications provide context to LLMs, what’s the problem?”

But even after a few hours of reading about what MCP is  and working through an example , it can be confusing to follow exactly what is happening when and where. What does the LLM do? What does the MCP server do? What does the MCP client do? Where does data flow, and where are choices made?

This is an in-depth introduction to MCP: what it is, how it works, and a full walkthrough example showing how everything fits together and exactly what happens at each step.

Specifically, we deployed a deliberately buggy Cloudflare Worker. The error surfaced in Sentry, and an AI assistant (Cline) running inside Visual Studio Code (VS Code) pulled the stack trace via the hosted Sentry MCP Server, opened a matching GitHub issue through a local GitHub MCP Server, patched the code, committed the fix and redeployed - all under human approval. MCP cut the integration work from M × N bespoke bridges to M + N adapters, but it charged us in latency, security diligence, and a healthy learning curve.

Why we need MCP

When an AI assistant has to juggle real-world systems - Sentry for monitoring, GitHub for code, Jira for tickets, and Postgres for data - every extra pairing means another custom adapter, another token shim, another place to break. The result is a hairball of one-off glue code that takes maintenance time and adds security risks. MCP was created to replace that chaos with a single, predictable handshake, so any compliant host can talk to any compliant tool out of the box.

The M × N integration tax

Without MCP, each Large Language Model (LLM) host or agent (such as ChatGPT, Claude, Cline, or VS Code Copilot) plus each tool (such as Sentry, GitHub, Jira, MySQL, or Stripe) requires its own connector - that is M hosts x N tools bits of glue-code.

Every connector re-implements:

• Authentication and token refresh
• Data-format mapping
• Error handling and retries
• Rate-limiting quirks
• Security hardening

The cost grows quadratically. We imagine teams will end up prioritizing a handful of integrations and calling the rest “backlog”.

One protocol to rule the connectors

MCP proposes a USB-C moment for AI tooling: Every host implements MCP once, every tool exposes an MCP Server once, and any host-and-tool pair can talk. Complexity collapses to M + N. This claim sounded too good to ignore, so we put it to the test.

Before we get to our walkthrough, let’s go through a quick primer:

MCP 101

If you already speak LSP or JSON-RPC, you’ll feel at home. If not, here’s the 30-second cheat sheet:

Core vocabulary

Stateful by design

MCP insists on a persistent channel, which is usually HTTP + Server-Sent Events (SSE) for remote servers and plain stdio for local processes. The server can remember per-client context (for example, auth tokens, working directory, in-progress job IDs). This is heavier than stateless REST but enables streaming diffs, long-running jobs, and server-initiated callbacks.

Discovery flow

1. The client calls tools/list to ask the server, “What can you do?”

2. The server returns JSON describing each tool, including its name, summary, and JSON Schema for the parameters and result.

3. The host injects that JSON into the model’s context.

4. When the user’s prompt demands an action, the model emits a structured call:

5. The MCP Client executes it using the transport and streams back result chunks. The conversation then resumes.

Our demo scenario

The best way to learn a new protocol is by using it to solve a real problem, so here’s what we’ll do: We’ll create a real problem and build a real solution.

The recurring nightmare of the 5 PM regression alert

To help set the scene, imagine this scenario: It’s Friday afternoon, you’re the last one in the office, and just as you’re packing your bag, Slack starts screaming that there is a new regression in worker.ts:12.

We want to find the shortest route from that first Slack message to a deployed fix.

The demo stack

We want a realistic but snack-sized scenario:

A buggy Cloudflare Worker reports exceptions to Sentry, which surface through the hosted Sentry MCP (SSE) into Cline within VS Code. The same session then flows down to a local GitHub MCP (stdio) that is running in Docker, allowing the agent to file an issue, add comments, and push a pull request to the GitHub repository - all under human oversight.

Setup walkthrough

Let’s set up our stack.

Let’s take it for a spin.

Create a GitHub repository

We’ll use the GitHub MCP Server to create a new repository for our demo.

We asked Cline:

Here’s what happened next:

Fixing the bug using MCP

That was the fiddly part, which only happens once. Now we can fix the bug.

What we learned

We learned a lot about MCP, both the good and the bad. Here are our key takeaways:

The good: Protocol unification

The MCP approach delivered on its promise. We only had to set up each service once, rather than having to build custom bridges between every pair of services. This was our first concrete experience with the theoretical M + N vs M × N difference.

Consider our modest demo setup with just three components (the Cline host, Sentry server, and GitHub server):

The difference is small, with just a few components, but scales dramatically. With 10 hosts and 10 tool backends (100 potential connections), MCP requires just 20 adapters.

Moreover, we found that the JSON Schema system improved tooling discoverability. When Cline connected to a server, it automatically received comprehensive documentation about available operations without having to consult external API references.

The challenges: Latency, security, learning curve

MCP may not be suitable for all use cases. We encountered several challenges that could limit its applicability.

Latency

The MCP approach introduces additional layers between the LLM and the APIs. This comes with a latency cost.

In our testing, each MCP hop added a little time overhead, which is negligible for most use cases but could become significant in latency-sensitive applications or during complex multi-step workflows.

This isn’t a flaw in the protocol, but rather a trade-off for the convenience of having a single, unified interface. The latency is manageable for most applications, but it’s worth considering if you’re building a performance-critical application.

Security

Authentication represents one of the more challenging aspects of MCP. The protocol requires the secure handling of access tokens, which introduces additional security considerations.

1. Token management: Each server requires its own authentication approach (OAuth for Sentry, API tokens for GitHub).
2. Permission scoping: The user needs to grant permissions for each server, which can be cumbersome.
3. Token refresh: OAuth flows with refresh tokens add complexity.

This may be a symptom of the relative immaturity of the ecosystem, but most MCP Clients do not yet support OAuth flows or token refreshes. This is exactly why the Sentry MCP Server is called via npx mcp-remote, which is a wrapper MCP Server that handles the OAuth flow and token refresh for you:

Learning curve

While the protocol is reasonably straightforward for developers familiar with JSON-RPC, we encountered a few hurdles.

1. Sparse documentation: The specification is comprehensive, but practical guides are limited.
2. Debugging challenges: When tools failed, error messages weren’t always clear. The first time we tried to run the Sentry MCP Server, we encountered an authentication error that was difficult to diagnose.

Ecosystem maturity

MCP is still in its early days. The available servers are primarily reference implementations rather than production-ready services. We identified several areas needing improvement.

1. Standardization: Common operations (like CRUD) aren’t yet standardized across servers.
2. Host support: LLM host support is limited and extremely variable. Some hosts support only tools, while others support resources and tools. Some hosts support only stdio, while others support SSE.

Despite these challenges, the direction is promising. Each new MCP Server adds disproportionate value to the ecosystem by enabling any compliant host to connect to it.

Future improvements

Here’s a wishlist of improvements we think would benefit the MCP ecosystem:

Performance optimizations

Future MCP implementations could benefit from several performance optimizations:

1. Connection optimization: Using streaming HTTP instead of SSE for long-lived connections would reduce the need for persistent connections and improve performance. (This is already in development in the MCP SDK and spec.)
2. Schema caching: Hosts and LLMs could cache tool schemas to avoid repeated discovery calls and wasted token usage.
3. Request batching: Grouping related operations into a single request would increase efficiency by reducing round trips between the client and server.
4. Partial schema loading: Loading only the schemas for tools likely to be used in a given context could reduce token usage and improve tool selection.

Our Cline session for this problem sent 413,300 tokens and received 2,100 in total. This is a lot of tokens for a single session, and we could have saved plenty of tokens by caching the schemas and using partial schema loading.

Enhanced security

The security model could be strengthened with:

1. Granular permissions: Token scopes limited to specific tools rather than entire servers would allow for granular permissions. This is part of the MCP specification (in the form of MCP Roots) but isn’t widely supported by clients or servers yet.
2. Approval workflows: Using more sophisticated approval UIs for dangerous operations could ensure the user is aware of the implications of each action and help them avoid prompt injection attacks.
3. Audit logging: Comprehensive tracking of all MCP operations would improve the security model.

Verdict and recommendations

We’re excited about the potential of MCP and think the protocol will become a key part of the AI ecosystem. However, we’d recommend caution for production use. Audit the security of any MCP Server you use and be prepared to work around the ecosystem’s current fragmentation.

While everyone is still figuring out the security details, perhaps deactivate YOLO mode and stick to human-in-the-loop workflows for now.