MCP, Explained: It's a Resource Server With a Different Kind of Visitor

If you've built or secured a regular API, you already understand resource servers: the thing that holds the data, checks an incoming token, and decides whether to hand the data over. An MCP server is that same idea, aimed at a different kind of visitor — not a browser tab or a mobile app operated by a human, but an AI agent deciding, on its own, which tool to call and why.

That shift in who's asking changes less than you'd expect about the underlying security model, and more than you'd expect about everything around it — discovery, trust, and what "reasonable behavior" even looks like from the caller.

The restaurant kitchen analogy

Picture a restaurant with a dining room and a kitchen. Customers sit in the dining room, look at a menu, and place orders through a waiter — they never walk into the kitchen and start pulling ingredients off shelves themselves. The kitchen is a resource: the actual capability of turning ingredients into a meal, exposed through a controlled, well-defined interface — the menu and the waiter — rather than direct, unrestricted access.

A regular API is a kitchen with a fixed menu, printed in advance, that customers (or the applications built for them) read and order from. An MCP server is a kitchen that also hands out an actual capabilities list to anyone properly authorized to see it — "here's exactly what I can make, here's what ingredients each dish needs, here's what you get back" — because the "customer" in this case isn't a person who already knows what a restaurant is and how to order. It's an agent that has to figure out, at runtime, what's even possible to ask for, and needs that described in a structured way it can reason about rather than a static human-readable menu.

flowchart LR
    subgraph Regular["Regular API"]
        H["Human via App"] -- "pre-known endpoints" --> API["API (Resource Server)"]
    end
    subgraph MCPFlow["MCP"]
        Ag["Agent"] -- "discover capabilities" --> MCP["MCP Server (Resource Server)"]
        Ag -- "invoke a tool" --> MCP
        MCP -- "structured result" --> Ag
    end

That's the core of what MCP (Model Context Protocol) actually is: a standardized way for an agent to discover what tools/resources a server exposes and invoke them, so that connecting a new agent to a new capability doesn't require bespoke, hand-written integration code every single time — the same way a waiter at any restaurant can hand you a menu without needing to have personally trained you on how ordering food works.

Same trust question, sharper version of it

A resource server's core job has never really changed: given an incoming token, decide what this caller is allowed to do, and don't do more than that. MCP doesn't invent a new version of that question. What it does is make the answer matter more, because of who — or what — tends to be asking.

A human using a normal app is, in practice, a soft check on bad outcomes: if an app's UI is confusing or a feature seems dangerous, a person often hesitates, double-checks, or just doesn't click the button. An agent doesn't have that hesitation built in by default. If an MCP server exposes a tool that can delete records, and an agent's reasoning concludes that calling it is the right next step, it calls it — confidently, immediately, without the human pause that (imperfectly) protects a lot of ordinary systems today. That doesn't mean agents are inherently reckless; it means the safety net that used to live in human hesitation has to live somewhere else now, and "somewhere else" is exactly the resource server's authorization and scoping logic.

This is why the two questions that matter most for an MCP server aren't new in kind, just sharper in consequence: who is allowed to even see this tool exists (discovery), and once they can see it, what exactly are they allowed to do with it, and on whose authority (authorization). Get discovery too loose and you've published a capabilities map to anyone who asks, including things they should never have known were possible to invoke. Get authorization too loose and an agent that was only supposed to read data can just as easily be the agent that deleted it, because nothing at the resource-server layer distinguished "asked politely" from "was actually allowed to."

sequenceDiagram
    participant Agent
    participant MCP as MCP Server
    Agent->>MCP: Discover capabilities (with token)
    MCP->>MCP: Is this caller allowed to see this tool at all?
    MCP->>Agent: Filtered capability list
    Agent->>MCP: Invoke tool X
    MCP->>MCP: Is this caller (and whoever it's acting for) allowed to run X?
    MCP->>Agent: Result, scoped to what was authorized

Why "just reuse your existing OAuth setup" isn't quite enough

It's tempting to point an MCP server at whatever OAuth infrastructure already protects your other APIs and call it done, and directionally that's not wrong — MCP servers should absolutely sit behind standard OAuth-protected endpoints rather than inventing their own auth scheme. But two things tend to need more deliberate handling than a typical human-facing API gives them by default.

First, whether a delegated human is actually required. A lot of MCP use cases genuinely should refuse a token that represents nothing but a bare machine identity — "an agent with no human behind it at all" is a meaningfully riskier caller than "an agent acting on a specific, identifiable person's behalf," and a well-designed MCP server should be able to insist on the latter rather than silently accepting either.

Second, who gets to see the capability list at all, independent of who gets to invoke anything on it. A typical REST API's shape is rarely treated as sensitive — most teams don't think twice about an OpenAPI spec being fetchable by anyone with a token. An MCP server's discovery document is a more directly actionable map of what's possible, handed to something that will actually reason over it and act, which makes "should this be visible to just anyone with any valid token, or only to callers who've cleared a higher bar" a real design decision rather than an afterthought.

How ClavionX treats this

In ClavionX's model, an MCP Server isn't a bespoke concept sitting beside the platform's OAuth machinery — it's registered as a Resource Server with kind=MCP, governed the same structural way an Agent is governed on the client side: you don't hand-configure token TTLs or discovery rules individually, you assign the MCP Server an MCP Policy, a reusable rule set that determines them for you and can be changed once to apply across every server it governs.

The two sharper questions above are exactly what an MCP Policy is built to answer explicitly rather than leave implicit. requiresDelegatedUser (true by default) refuses tokens that are purely machine-to-machine — every caller has to carry a delegated user's context, a sub that traces back to an actual person through the token's act chain, not just an agent acting for itself with nobody behind it. discoveryVisibility controls who can even see the server's MCP discovery document at all — public, visible only to already-authenticated callers, or hidden entirely — so "who gets to see the menu" is a first-class setting, not a side effect of however the endpoint happened to get built.

Connecting a specific agent to a specific MCP server is its own explicit step, validated against the server's policy at connect time — a mismatch between what an agent's policy allows and what an MCP server's policy demands is rejected outright, not silently allowed through. And because the delegation chain underneath all of this runs on the same RFC 8693 token exchange used everywhere else in the platform, a resource server at the very end of a multi-hop agent chain still sees the full path — the original user, the agent that acted for them, the MCP server that acted for the agent — rather than a token that's lost track of where the request actually originated.

The shift worth internalizing

MCP doesn't ask you to rebuild your security model from scratch. It asks you to take two questions a normal resource server usually answers loosely — who can see what's possible, and who's actually authorized to do it — and answer them with the rigor you'd want if the caller on the other end never hesitates before acting on what you told it was possible. That's not a new problem. It's the same resource-server problem, with the safety margin that used to come from human hesitation now squarely the server's job to provide instead.