--- description: "The AO Hub is the home of the registry of known MCP (Model Context Protocol) servers." --- # AO Hub The **AO Hub** is the home of the registry of known MCP (Model Context Protocol) servers — a browseable, filterable catalog of what exists, what each server can reach, and how risky handing it to an autonomous agent is. > This page is the **registry** — the **MCPs** tab: discover, curate, and review. The catalog itself never changes what a running Agent can reach; that happens only when you add a server to an Agent (see *Assigning from the catalog to an Agent* below). ## The AO Hub Page Sidebar → **AO Hub** → **MCPs** tab. The list merges two kinds of entries: - **Bundled definitions** — a curated catalog that ships with the product (Filesystem, Git, GitHub, GitLab, Postgres, Slack, Notion, Linear, Sentry and more). These are global: every Workspace sees them. - **Workspace definitions** — entries your Workspace Administrator authored, including **customizations** of bundled ones. A Workspace definition with the same slug as a bundled one **replaces it** for this Workspace only — other Workspaces keep the bundled entry. ### Filters Filter by **Category**, **Transport** (`stdio` / `http`), **Risk level** (`low` / `medium` / `high` / `critical`), or a free-text **search** over name, vendor, slug, description and tags. The filter dropdowns always offer every value present in the catalog, even while a filter is active. `%` and `_` in the search box are treated as ordinary characters, not wildcards. ### Sorting Click any column header (Server, Category, Risk, Transport, Tools, Source, Updated) to sort by it; click again to reverse. The active column carries an ascending/descending arrow; sorting stays in effect while filters are changed or the list is reloaded. ### Reading an entry - **Risk level** is the prominent field — a "Verified" badge is a claim about authorship, never a guarantee that a high-risk server is safe. - **Tools** lists what the server is expected to expose, each with its own risk level. - **Credentials** shows the *shapes* a human will have to supply later (e.g. `Authorization: Bearer `). A definition never contains a real credential. ## Authoring and Curating (Administrators) **Add Definition** opens the editor. Pick a transport: - **stdio** — launch command plus arguments (e.g. `npx -y @some/mcp-server`). - **http** — a URL. Everything else is descriptive: vendor, category, homepage/docs links, the expected tool list, credential templates, tags, risk level, and whether the entry is verified. ### Workspace vs. instance scope By default a definition you author is **private to this Workspace**. A user with the instance-wide **MCP registry** grant (managed by a System Administrator under Global Settings → user administration) can instead publish to `scope: instance`, which makes the entry visible to **every** Workspace on the instance. ### Editing and versions - **Editing a bundled definition** is not possible directly — create a workspace customization instead (the UI offers this; the customization remembers what it was derived from). - A **version** is recorded whenever the *reach* changes — transport, command/args/url, credential templates, or the tool list. Rewording a description, re-tagging, or changing the risk level does **not** create a version: history answers "what could an agent reach", not "how was it worded". - **The slug is permanent.** It is the stable key a future connection will pin to; renaming a definition changes its display name only. ### Restore and delete - **Restore** (offered on customizations of bundled entries) discards the Workspace copy — the bundled entry resurfaces immediately. - **Delete** removes a Workspace-owned entry. If it was shadowing a bundled one, the bundled entry is visible again right away. Bundled and instance-shared entries cannot be deleted from a Workspace page. ## Audit Every change — create, update, delete, restore — is recorded in the Workspace **Audit Log** with the acting user, the definition, and the changelog note. ## For API callers The registry is also available over REST: `GET/POST/PATCH/DELETE /api/v1/workspaces/{id}/mcp-definitions` (plus `POST …/{id}/restore`). Every mutation returns the whole merged list, so a client never needs a second read. See the API reference → "MCP Hub — server-definition registry". ## Assigning from the catalog to an Agent Browsing stops where an Agent starts: on any Agent's **MCP Servers** tab, **"Add from catalog"** opens a picker over this same registry. Selecting an entry prefills the add-server dialog — name, transport, command/args or URL, environment keys from the definition's credential templates, header names — and you fill in the values (API keys, tokens) yourself; the catalog only ever carries the *shape* of what to supply, never a value. The saved server row remembers where it came from: it is marked **"From catalog"** on the card, and its assignment is recorded in the Workspace Audit Log (`mcp.assigned`). Editing a catalog-assigned server later (for example to rotate a token) never loses that provenance; deleting the definition it came from also never breaks the working server row. Note what this does *not* mean yet: the row still reaches whatever its command/URL says, exactly like a hand-configured server — per-tool enforcement, approvals and call auditing are the next phases (connections/credentials, then governance).