What an MCP Server Exposes—and Who Controls Access

An MCP server is a program that exposes tools or context to an AI application through the Model Context Protocol. OpenAI’s MCP server overview lists tools, readable resources, reusable prompts and server instructions among the capabilities it can provide. The server describes and handles those capabilities; connecting to it does not, by itself, approve a tool call or entitle a user to private data.

The AI application is the host. It creates an MCP client to communicate with a particular server, which may run locally or remotely. The model can propose a tool and its arguments, but the host controls whether that proposal is sent. Once a request arrives, the server and the system behind it must decide whether the requested operation is permitted for the relevant identity.

What the server exposes

Tools are callable operations: a lookup, a search or an action in another system. Resources provide content a client can read, while prompts provide reusable templates for an interaction. Server instructions can give general guidance about using its capabilities. These are different kinds of exposure: a resource can supply context without executing a lookup, while a tool can run code or contact a service when called.

A tool description includes a name, a description and an input schema; it may also define an output schema. The schema specifies the arguments the call should contain and their types. If a hypothetical order lookup requires an order ID as a string, that rule helps the host form a valid request and lets the server reject malformed input. It cannot establish that the person asking owns the order. A well formed request and an authorized request are separate tests.

One order lookup, end to end

Suppose a hypothetical shop exposes a tool called get_order_status, and a customer asks an AI assistant where an order is. The route is: user → host → MCP client → MCP server → shop system → MCP server → client → host → user. The arrows carry a request and then a result; they do not represent a single shared permission decision.

Discover the tool. The host’s client asks the server for its available tools and receives the name, description and input schema for get_order_status. The MCP architecture guide describes this tools/list exchange as discovery of callable operations, which gives the host a menu of requests but no proof that this customer may view a particular order.
Propose and route a call. The model supplies an order ID in the shape the tool expects. The host determines whether to send the proposed call through its MCP client and whether its own policy requires user approval first. The client then sends a tools/call request naming the tool and carrying its arguments. The model’s choice of arguments is a proposal, not proof of authority.
Validate and execute. The server checks the request and invokes the tool handler. For private order data, the handler must identify the caller and enforce access rules, including any restrictions imposed by the shop system it queries. A valid ID and a valid credential need not grant access to that specific order. In this hypothetical example, an order associated with another account should be refused rather than disclosed.
Return the result. If the lookup is allowed, the shop system supplies a status to the server. The server returns tool content or structured data to the client, and the host gives the result to the model to answer the customer. If the lookup fails or access is refused, that outcome should reach the host as a failure, not be treated as a successful order status.

This route also explains why the model is not the MCP client. The model suggests a call from tool descriptions it has been given; the client is the component that exchanges protocol messages with the server. The server runs the handler. A product may present all of this as one assistant conversation, but the boundaries remain relevant when a request fails or private content is at stake.

Where permission decisions belong

User approval is a decision in the host’s workflow about proceeding with a proposed call. A host might prompt for a sensitive action or apply an existing user or administrator policy. Approval can establish that the user wanted the host to send this request; it cannot establish ownership of the record named in the arguments. The server cannot infer that ownership from the mere arrival of a call.

Authentication identifies the caller or supplies credentials to the server. Authorization asks whether that identity may perform the operation and access the particular data. OpenAI’s server building guidance calls for authentication when tools read private data or act for a user, and for authorization in the server on every request rather than a decision by the model. The shop’s own order system may impose another check when the server queries it.

Those checks can reject different things. A tool schema can reject a missing or mistyped order ID. Authentication can reject an invalid credential. Authorization can reject a perfectly formed lookup for another person’s order. If the shop system has narrower account or record rules, the server’s handler must respect them as well. Putting every failure under the vague label “MCP permissions” would hide which component made the decision.

What a connection proves

A working connection proves that the host’s client and server can exchange MCP messages. A discovered tool proves that the server advertises an operation with a defined interface. Neither fact guarantees that a given user can run it, that the host will approve it, or that its answer will be accurate. Those questions depend on the host’s workflow, the identity presented to the server, the handler’s rules and the underlying service.

The server therefore has a precise job and a precise limit. It exposes capabilities, receives structured calls, executes permitted operations and returns results. The common protocol makes that exchange portable across applications. It does not merge the model, host, user and external service into one trusted actor, and a tool name or schema cannot make their separate consent and access decisions disappear.