Understanding MCP: A Practical Primer for Platform Teams

The Model Context Protocol, or MCP, is a standard way for an AI assistant to call out to external tools and data instead of only working with whatever text is in the conversation. For a platform team, it removes the need to build and maintain a bespoke integration for every AI client someone on staff wants to use against the same internal systems. This primer is about the decision of whether and how to adopt MCP, not a step-by-step setup guide — that walkthrough exists separately and is linked below.

What MCP actually is

MCP is an open protocol that lets an AI assistant discover and call a defined set of tools, and read defined resources, exposed by a server your team controls.

That definition should hold up on its own, outside the context of this page: a platform team adopting MCP is standing up a server that speaks this protocol, and any MCP-compatible client — Claude Code, Claude Desktop, claude.ai, or something else entirely — can then discover what that server offers and call it, without the platform team writing custom integration code per client.

What MCP replaces

Before a shared protocol like this exists, connecting an AI assistant to internal tools and data means writing a separate integration for each assistant a team wants to support — one code path for one chat client, a different one for another, each with its own auth handling and its own way of describing what it can do. Every new client added to the list means another bespoke integration to build and keep working. MCP replaces that per-client integration work with one server surface that speaks a common protocol: build the server once, and any compliant client that already knows how to speak MCP can use it. The integration burden shifts from "one per client" to "one, period" — the server is the thing a platform team owns and maintains, not a growing set of client-specific adapters.

The three primitives that matter

Underneath the protocol, what a platform team is actually building or evaluating comes down to three things: the tools a server exposes, the resources it exposes, and the transport it speaks. PromptHub's own MCP server is a concrete, live example of all three. It exposes 15 tools spanning Prompts, Prompt Chains, Skills, PlugIns, and Agents — search and read operations, plus operations that actually execute something and spend tokens. Alongside the tools, it exposes 2 resource templates, prompthub://prompt/{id} and prompthub://chain/{id}, which resolve to a specific prompt's text or a specific chain's node structure. And it speaks Streamable HTTP as its transport, reachable at a single endpoint, https://promthub.ai/api/mcp/mcp, rather than requiring a locally-launched process for every client that wants to connect.

Tools are the part most people think of first — the actions a client can invoke, each scoped to what it's allowed to do. Resources are quieter but just as load-bearing: they're read access to specific, addressable pieces of data, structured so a client can fetch exactly the thing it needs by id rather than searching through a tool call. The transport question — how the client and server actually talk to each other over the wire — matters less for day-to-day use than the first two, but it's the thing that determines whether a server can be reached remotely over HTTP or only run as a local subprocess, which in turn shapes how a platform team can deploy and share it across a whole organization.

Authentication: two paths, two audiences

A platform team adopting MCP has to pick how clients will authenticate, and the honest answer is usually both, because the two paths serve different audiences:

The per-user API key path is the one most platform teams reach for first, because it's the fastest to stand up: keys are scoped to specific permissions at creation time, stored only as a hash on the server side, and revocable immediately if one is ever compromised. Nothing about the key itself needs a browser round-trip — it's just a credential a client sends on every request. OAuth 2.1 costs more to build correctly the first time, since it means implementing real discovery endpoints and a token-issuance flow, but it's what a web-based client needs when there's no config file to paste a static key into and the user instead needs to log in and consent through a browser.

The authorization model platform teams actually ask about

The question that comes up in almost every platform-team conversation about MCP is what happens when a credential's permissions and a user's actual permissions disagree. The honest answer, at least for a well-built server, is that the credential's scopes act as a ceiling set once at creation time, and the user's live role or permission set is checked again on every single call — so a scope granted to an API key never overrides a permission that was later taken away from the underlying account. If someone's role gets downgraded after a key was issued, that downgrade wins on the next call, not the scope the key was originally granted. This matters specifically because API keys tend to outlive the moment they were created — nobody goes back and re-audits every key every time a permission changes, so the server has to re-check the live permission state itself rather than trusting whatever the key claimed when it was minted.

The scopes themselves are typically granular rather than all-or-nothing. In PromptHub's case there are 8: prompts:read, prompts:improve, chains:read, chains:execute, skills:read, plugins:read, agents:read, and agents:execute — a read/write-style split repeated across every entity type the server exposes, so a client that only needs to search and display content never has to be granted the ability to spend tokens executing something. A platform team evaluating an MCP server worth adopting should expect this level of granularity as a baseline, not an advanced feature to ask for separately.

The safety property you should check in any MCP server

There's one property worth checking in any MCP server before pointing a client at it, and it has nothing to do with authentication: how the server handles content it reads back and hands to the model. If a server exposes a resource or a tool result that echoes back something stored internally — a document, a record, a piece of user-authored text — and that content isn't clearly marked as data rather than as instructions, a malicious or simply mischievous piece of stored content could be crafted to look like a new instruction and get followed by the model reading it. This is the prompt-injection-via-tool-result problem, and the mitigation is straightforward in principle even if it's easy to skip in practice: every piece of content coming back from a tool call or resource read should be explicitly labeled as data before it re-enters the conversation the model sees, so the model has a real signal that what it's looking at is content to reason about, not a command to follow.

Adopting it

The decision in front of a platform team isn't really "should we use AI tools" — it's "do we build one governed integration surface, or a growing pile of one-off client integrations." PromptHub's MCP server for platform and DevEx teams is a concrete example of the first option already built and running: API-key and OAuth 2.1 auth, RBAC applied to every tool call, and Prompts, Chains, Skills, PlugIns, and Agents all exposed as governed tools rather than bespoke code paths per client. If you're ready to actually connect a client rather than just evaluate the shape of the problem, the hands-on walkthrough — exposing a prompt library to your MCP client — covers the concrete config, the API key creation flow, and the tool reference this primer deliberately left out in favor of the higher-level adoption decision.

---

If the next question on your team is what an AI Agent actually is versus a single prompt or a chain, the AI agent definition post picks up exactly where this one leaves off.