Skip to main content
An MCP hub is a catalog of MCP servers your users browse and install from inside the app. Register one and nobody has to hand-write an MCP configuration, or wait for a redeploy when the catalog grows. Installing does not equip an agent. It adds the server to the user’s own pool of installed MCP servers, and equipping an agent is a separate step:
1

Install into the pool

The user picks a server, fills in whatever it asks for, and it joins their pool. Every hub feeds the same pool, so what came from which registry stops mattering once it is installed.
2

Equip an agent's workspace

In a chat, the user picks from the pool to add the server to that agent’s workspace. Its tools reach the agent immediately.
Splitting the two is what makes credentials a one-time cost. An API key is entered once at install time, and equipping that server in ten different workspaces never asks for it again. The pool belongs to the user, so it also outlives any single chat.

Available MCP Hubs

AgentScope ships one MCP hub today, and any other catalog can be wrapped with a custom hub: GitHubMCPHub works with no arguments, and every field below has a default:
Configure GitHubMCPHub

Quickstart

1

Start the Agent Service

MCP hubs are a feature of Agent Service, so you need a running service and a frontend to browse from. Follow the Agent Service quickstart to boot the bundled examples/agent_service backend together with the examples/web_ui frontend.
2

Register the hub

Pass your hubs to create_app through mcp_hubs. That one argument brings the routes, the store page, and the install flow with it:
Register an MCP hub
Register several to give users a choice of catalogs, each with its own hub_id:
Register several MCP hubs
Registering two MCP hubs under the same hub_id fails at startup rather than silently shadowing one.
3

Browse and install

Restart the service and open the MCP page. The sidebar lists your registered hubs plus Mine, the user’s own collection. Pick a hub, search, and open a card to see what the server does and what it needs.
Browsing an MCP registry

Browsing an MCP registry from the MCP page.

Install opens a form built from what the listing declares. On submit, the server is contacted straight away, so wrong credentials come back as an error on the form instead of a broken install. Everything installed shows up under Installed MCPs:
Installed MCP servers

The MCP servers a user has installed.

4

Equip an agent

Open a chat, expand the MCP panel, choose Add, and pick from Installed MCPs. The server’s tools reach the agent immediately.
Equipping an agent with an installed MCP server

Equipping an agent with installed MCP servers.

From Installed MCPs, users rename an install, turn it off without losing its configuration, update a rotated key, or delete it. Deleting leaves chats that already use it untouched.

Custom MCP Hub

Any catalog becomes a hub by subclassing MCPHubBase: a public registry, your company’s approved list, or a fixed set of servers you want to offer. Two methods are required, one to browse and one to fetch a single listing:
A hub over an internal catalog
Two more things shape how a hub behaves:

Control Visibility Per User

Both methods receive user_id as their first argument, so a catalog does not have to look the same to everybody. Filter on it to run a per-team allowlist, gate paid listings on entitlements from your billing system, or keep an unreleased server visible only to its authors:
A catalog that differs per user
Apply the same filter in get_mcp that you apply in list_mcps. Hiding a card from the listing alone is not access control: get_mcp is reachable with any id the caller cares to guess.

Declare Required Inputs

A card is a template rather than a ready connection. Write the parts the user supplies as ${placeholder}, then describe them with a standard JSON Schema so the frontend can render the form:
A card that asks for an API key
Mark every credential field with "writeOnly": true and "format": "password". That is what tells the frontend to mask the value and to leave the field blank when the user edits the install later.

Reuse One HTTP Client

A hub lives for the whole lifetime of the service, so it can hold a connection pool instead of opening one per request. Implement the async context manager methods and the service enters every hub on startup, closing them on shutdown:
Open and close a shared client

Further Reading

Skill Hub

The same idea for skills.

MCP

How the agent calls an MCP server’s tools.