Request a trial
Menu
Products
Solutions
ERP
Authentication
Apps
LearnDocsWhy SSOGENRequest a trial

SSOGEN / Learn / MCP vs API: What Changes for Sign-In and Permissions

Compare

MCP vs API: What Changes for Sign-In and Permissions

An API is a fixed interface a developer wires up; MCP lets an agent find and call tools, so the token must name the server and the person.

Request a Quote
MCP vs API side-by-side table: who calls, how tools are found and what sign-in and permissions change for AI agents
MCP usually sits on top of an API, as a thin layer.

MCP vs API comes down to who is calling.

An API is a fixed interface. A programmer wires an application to it.

The Model Context Protocol (MCP) lets an AI agent ask a server what tools it offers and call one, with no code written for that pairing ahead of time. An MCP server usually wraps one or more APIs.

For security, the caller is what matters. An API usually sees an application and its key. An MCP server may be called by an agent acting for a person.

MCP and API side by side

API MCP
Who calls it An application a developer wrote An AI agent, through a client
How the caller learns what exists Documentation read by a developer The client sends tools/list and gets each tool’s name, description and inputSchema
How a call is made Any request the API defines tools/call with a tool name and arguments
Who chooses the call The developer, in code The model, from the user’s request and the tool list
Sign-in in the standard Whatever the provider chose: key, OAuth, JWT Optional. For HTTP transports, an OAuth 2.1 based flow with the MCP server as resource server
What a token must name Varies The MCP server itself: servers must check the token was issued for them
Who the caller is Usually an application or a key Can be an agent acting for a user, if the token says so

Every MCP row comes from the MCP specification, version 2026-07-28 (read 2026-10-11). The tools page covers tools/list, tools/call and inputSchema. The authorization page covers the rest.

How MCP sits on top of an API

  • A thin layer. An MCP server is a thin layer that turns operations into tools.
  • An example. Say a finance system has an invoices API. The server might expose invoices.read as a tool, with a short description and a JSON Schema for its inputs.
  • The credential stays hidden. The agent never sees the API’s address or key. The server holds the credential and makes the call.
  • The result. The server returns content (and optionally structuredContent) to the agent.

They are not rivals. The API still does the work; MCP gives an agent one uniform way to find it and call it.

What changes for sign-in and permissions

With a plain API, the key identifies the application that holds it. Every request from that application looks the same, no matter whom it acts for.

MCP changes three things. The specification states all three:

  • The token is for one server. An MCP server must validate that an access token was issued for it, and the spec says servers “MUST NOT accept or transit any other tokens”. An agent cannot reuse one broad token across every tool server.
  • Scopes are asked for at the door. The server answers an unauthenticated call with 401 and a WWW-Authenticate header that can name the scope it needs. A token with too little scope gets 403 with insufficient_scope.
  • The tool list can depend on the caller. The tools page says tools/list may return a different set depending on the authorization presented, for example only the tools the caller’s scopes permit. Two agents can see different menus on one server.

The specification leaves two things open: who the agent is, and which person it acts for. Authorization is optional. How the authorization server works is out of scope.

An identity layer fills that gap. In SSOGEN, an agent has its own registered identity. Its credential lasts 240 seconds by default, 270 at most.

The credential names the person in sub and the agent in act. It is bound to the agent’s key.

The JWT decoder shows a sample. The MCP gateway page explains how each tool call is then checked.

When to use which

  • Use the API directly when a developer writes the integration and the calls are known ahead of time: a nightly export, a webhook, a fixed workflow.
  • Add an MCP server when an agent has to choose among tools at run time, or when several agents and clients should reach the same system the same way.
  • Put a check in front of the MCP server when agents act for people and some actions are sensitive. A gateway decides on each tool call, using the agent, the person and the scope.

Questions people ask

Will MCP replace APIs?
No. An MCP server usually calls an API to do its work, so MCP depends on APIs. APIs stay the right choice for fixed integrations a developer wires up in code. MCP adds a common way for an AI agent to find and call tools.
Is chatgpt an API?
No. ChatGPT is a chat app people use. An API is an interface software calls, and a model provider can offer one separately for developers. MCP is a third thing: a protocol an AI client uses to call tools on a server, whatever model sits behind it.
Is a MCP server like an API gateway?
No. An MCP server runs tools, such as invoices.read. An API gateway sits in front of HTTP endpoints and decides whether a request can pass. An MCP gateway is the closer match. It sits in front of MCP servers and decides, on each tool call, which agent acting for whom can go ahead.
How to convert an API to MCP?
Write an MCP server that exposes each API operation you want as a tool, with a name, a description and an input schema. Have the server make the API call, and keep the API credential on the server. Then add sign-in so the server accepts only tokens issued for it.

Where to go next

Sources, all read 2026-10-11: the MCP specification on tools and on authorization (version 2026-07-28).