Skip to content

MCP servers

A Model Context Protocol (MCP) server exposes capabilities an AI agent can call directly: tools it can invoke, resources it can read, and prompts it can reuse.

The API Portal & MCP Hub publishes MCP servers next to your APIs. They share the same catalog, subscription, and credential machinery—this is the "MCP Hub" half of the product.

How MCP servers differ from APIs

An MCP server is stored as another artifact in the same catalog, so most of what you know about APIs carries over. The differences that matter:

API MCP server
Contract OpenAPI, AsyncAPI, GraphQL SDL, or WSDL A definition listing tools, resources, and prompts
Catalog page APIs in the sidebar MCP Servers in the sidebar
Detail page sections Endpoints, Resources or Channels, Scopes MCP Server URL, Tools, Resources, Prompts
Interactive console Try It, or a type-specific tryout client MCP Playground
Consumed by Application code you write An MCP client, configured with the server's URL
Agent visibility Publisher sets it per API Always agent-visible; the catalog marks every server AI Ready

Everything else works the same way. MCP servers carry tags, labels, icons, subscription plans, and attached documents, appear in the portal's machine-readable endpoints, and are subscribed to directly rather than through an application.

Note

A portal only serves MCP servers when its operator lists mcp-servers in enabled_types. Leave it out and the sidebar entry, the catalog, and every MCP route disappear. See Artifact types.

How servers reach the hub

Two routes put an MCP server in the catalog, and which one was used affects what you see.

Registered by an admin

An admin adds the server through Settings → MCP Servers, using the same wizard as an API with the type preset to MCP. They supply the details, upload the definition listing the tools, resources, and prompts, and attach documentation. See Manage MCP Servers.

The same thing happens when a server is created on a gateway and pushed to the portal—the artifact carries a reference back to that gateway proxy.

Published through the MCP registry

A client posts the server to the portal's registry API, an implementation of the Model Context Protocol registry specification. The portal stores the result as a catalog artifact exactly like any other MCP server, mapped to the default label so it shows up in views that include it.

Registry-published servers are identified by a reverse-DNS name such as example.com/travel-assistant rather than by a gateway reference, and they get one entry per version. Their generated Markdown documentation also omits the authentication walkthrough that other artifacts carry, because the registry payload doesn't describe a security scheme.

See MCP Registry API.

Where to go next

  • Manage MCP Servers: the admin side of adding and publishing servers
  • AI Agent Discovery: the machine-readable endpoints that expose MCP servers to agents
  • Artifact types: whether this deployment serves MCP servers
  • Concepts: how MCP servers fit alongside APIs, plans, subscriptions, and keys