Skip to content
Agent Orchestrator Docs
Esc
↑↓navigate↵open⌘Jpreview
On this page

AO Hub

The AO Hub is the home of the registry of known MCP (Model Context Protocol) servers.

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 <personal access token>). 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).