SSOGEN / Learn / What Is an MCP Server, and Who Is Signed In When It Runs?
Learn
What Is an MCP Server, and Who Is Signed In When It Runs?
An MCP server gives AI applications tools, data and prompts over the Model Context Protocol, and the question to ask is whose credentials it uses.
Updated

What is an MCP server? An MCP server is a program that provides context to AI applications through the Model Context Protocol (MCP). It advertises what it can do, such as “read an invoice” or “query this database”, and runs the action when the application asks. It runs either on the user’s own computer or on a remote host.
In both cases, someone’s credentials sit behind every action. Whose credentials they are determines how safe it is to let an agent use the server.
What an MCP server provides
The MCP documentation (specification version 2026-07-28, read 2026-10-11) defines three kinds of capability a server can expose, called primitives.
| Primitive | What it is | Example |
|---|---|---|
| Tools | Executable functions an AI application can call to perform actions | A file operation, an API call, a database query |
| Resources | Data sources that give the application context | File contents, database records |
| Prompts | Reusable templates that structure the interaction with a model | A system prompt, few-shot examples |
Tools matter most for security, because a tool changes state. Each tool has a name, a description and an input schema. The application discovers tools with tools/list and runs one with tools/call.
The three parts: host, client and server
The architecture overview defines three participants:
- MCP host: the AI application, such as Claude Code or Visual Studio Code, which manages the connections.
- MCP client: a component inside the host that keeps one connection to one server. The host creates one client for each server it uses.
- MCP server: the program that provides context to a client.
A host connected to a database server and a file server therefore holds two clients. The model never talks to a server directly; the host’s client does.
Local and remote MCP servers
“MCP server” names the program, wherever it runs. The protocol defines two transports, and each one produces a different type of server.
| Local server | Remote server | |
|---|---|---|
| Transport | stdio: messages over the standard streams of a process the client launches | Streamable HTTP: each message is an HTTP POST to one endpoint |
| Where it runs | On the same machine as the client | On a host reached over the network |
| Clients it serves | Typically one | Typically many |
| How it gets credentials | From the environment it was launched in. The authorization specification says stdio servers should not follow the OAuth flow and instead retrieve credentials from the environment | Through the OAuth-based flow, where the server acts as a resource server and checks the token |
What happens on one tool call
- The host connects a client to the server. The client may send
server/discoverto learn the server’s versions and capabilities. - The client sends
tools/listand receives each tool’sname,descriptionandinputSchema. - The model, working from the user’s request, picks a tool and arguments.
- The client sends
tools/callwith the toolnameandarguments. - The server runs the function and returns
content. If it failed, the result carriesisError.
The specification’s tools page adds two requirements:
- A human should always be in the loop, able to deny a tool invocation.
- Servers must validate inputs, apply access controls and rate limit calls.
Who is signed in when an MCP server runs
This is where servers differ most, and where most explanations stop.
Local server. It acts with whatever credentials its environment holds. If a developer starts it with a database password in the environment, every tool call uses that password.
Local server, the result. Every call uses that password regardless of which agent asked or which person the agent works for. The agent has no sign-in of its own.
Remote server. It can do better. Under the authorization specification, it validates an access token and must check that the token was issued for that server.
Remote server, the limit. Authorization is optional, however, and the specification does not identify the agent or the person it acts for. A token that names only the application hides both.
An identity layer fills that gap. In SSOGEN an agent is a registered identity with named human owners, and its credential works as follows:
- It lasts 240 seconds by default and never more than 270.
- It names the person the agent acts for and the agent itself.
- It is bound to the agent’s key.
The MCP gateway then checks each tool call against the agent, the person and the scope. A sample credential is in the JWT decoder.
Questions people ask
What do MCP servers stand for?
What is the best AI server?
What is MCP vs API?
In the MCP architecture, what are the three main components?
Where to go next
- Risks. Read about the confused deputy problem and Oracle MCP servers.
- Interfaces. Compare the protocol with ordinary interfaces in MCP vs API.
- Sign-in. See how sign-in works in MCP authentication.
- Enforcement. See how a MCP gateway checks every call.
- Agent credentials. See how AI agent identity gives an agent its own credential.
- Background. More is in the Learn hub.
Sources, all read 2026-10-11: the MCP architecture overview, the specification pages on tools, transports and authorization (version 2026-07-28).