MCP Servers

The MCP Servers catalog sits under the Hub · Catalog eyebrow and is described as "Pre-built MCP servers you can plug into Beak agents or any MCP-compatible client." Each server is a packaged, production-ready MCP implementation that exposes one or more tools. Teams connect a server to their tenant in a few clicks — the Hub stores the credentials, generates client configuration snippets, and makes the connection available to agents and MCP-compatible clients immediately.

---

Catalog Statistics

Three stat tiles above the grid summarise the current catalog state:

• Published servers — Total count of MCP server entries in the catalog.
• Total tools — Sum of all tools across all published servers.
• Categories — Count of distinct categories in use across the catalog.

---

Search and Filter

A search bar and a category filter sit above the card grid:

• Search the catalog — Filters cards in real time by server name or tagline. The input matches partial strings case-insensitively.
• Category filter — A set of pill buttons, one per distinct category present in the catalog. Selecting a category narrows the grid to entries in that category only. Selecting the same category again clears the filter and returns all entries.

---

Catalog Card Grid

Each MCP server is represented by a card in a responsive grid (one column on mobile, two on tablet, three on wide screens). The card surface shows:

• Category eyebrow — The server's category label, rendered in the category accent color.
• Server name — The primary identifier for the server.
• Tagline — A one-line description of what the server does.
• Connected badge — Shown only when the current user has one or more active connections to this server. If multiple instances are connected, the badge reads Connected · N.
• Tool count — Displayed at the bottom of the card alongside the version string in the form N tools · vX.Y.
• View link — Opens the server detail page.

---

Server Detail Page

Clicking any card navigates to the server detail page. The header shows the server name, category eyebrow, tagline, version, tool count, and the number of connected instances if any exist. A Back to catalog link returns to the grid.

Connect / Add Instance

The primary action button at the top right of the detail header is:

• Connect — Shown when no instances are connected. Opens the Connect dialog to register the first instance.
• Add instance — Shown when one or more instances are already connected. Opens the same Connect dialog to register an additional instance.

Connections Panel

When at least one instance is connected, a Connections section appears above the tabs. Each row in the panel shows:

• A green checkmark indicating the connection is active.
• Instance name — The label assigned when the connection was created.
• Scope — Either Shared with team (tenant-scoped) or Just me (user-scoped), plus the last-used date if the connection has been exercised.
• Disconnect button — Removes the connection for this instance.

Detail Tabs

Three tabs organize the server's detail content:

• Overview — Renders the server's full description as formatted markdown.
• Tools — Lists all tools exposed by the server. A search field at the top of the list filters by tool name or description. Each tool row shows the tool name (in monospace) and its description.
• Docs — Renders the server's extended documentation as formatted markdown.

---

Connect Dialog

The Connect dialog opens when Connect or Add instance is clicked. It collects the details needed to register a backend instance:

Instance Section

• Name — A short label (up to 80 characters) that distinguishes this backend from other connections to the same server. Examples shown in the placeholder: Prod, Sandbox, Team A.

Scope Section

• Just me — The connection is private to the current user. Only that user's agents can use it.
• Share with my team — The connection is shared across the entire tenant. Visible only to tenant admins; regular users see the option disabled.

Note: A third kind of connection is owned by an agent identity rather than a person. It is created for the agent through Hub's internal connections API, not from this dialog, and every tools/call on it is authorized against the agent's scopes before Hub forwards it — a refused call returns a JSON-RPC error with the reason. See Governing an Agent from Any Platform.

Configuration Section

Non-secret fields required by the server are collected here. Each field shows a label and an optional flag if it is not required.

Credentials Section

Secret fields (API keys, tokens, passwords) required by the server are collected here. Each field has a show/hide toggle so values can be verified before submission.

Note: The Configuration and Credentials sections appear only for servers that authenticate with a static credential. A server that uses OAuth has nothing for you to type — see Authentication Methods below.

Authorization Section

Shown instead of Configuration and Credentials when the server uses OAuth. Rather than collecting a credential, it states what you are about to authorize:

• Identity — For a personal connection, your own access decides what the server can reach; anything you cannot see, it cannot see. For a connection shared with your team, calls are made as a shared identity and are not attributable to a person.
• Permissions — Each one requested is listed individually.
• Consent — An explicit checkbox. The Authorize button stays disabled until you tick it, and Beak Hub refuses to start a flow that does not carry your consent.

Choosing Authorize sends you to your identity provider to sign in. When you return, the Connections panel shows the result.

---

Authentication Methods

Each catalog entry declares how connections to it are authenticated. The method determines what the Connect dialog asks you for, and what Beak Hub sends to the server on every call.

Method	Who is authenticated	What you provide
none	nobody	nothing
api_key	your tenant	the server's API key or keys
bearer	your tenant	a bearer token
beakiam	you, or a shared team identity	nothing — you authorize with your Beak account
oauth2_client_credentials	your tenant, at the server's own provider	nothing — configured once by an administrator
oauth2_authorization_code	you	nothing — you authorize with your account at the server's provider

The last three are OAuth methods and follow the Model Context Protocol authorization specification. Beak Hub acts as the OAuth client: it discovers the server's authorization server, requests a token bound to that specific server, stores it encrypted, and renews it automatically before it expires.

Acting as you, rather than as a shared secret

The difference that matters day to day is whose access is used. With a static credential, every person and every agent in your tenant reaches the server through one shared key, so the server cannot tell who is calling and cannot apply that person's own permissions.

With beakiam or oauth2_authorization_code on a personal connection, the token carries your identity. The server sees who is calling and enforces your own access. Two people connecting the same server get two separate authorizations, and revoking one does not affect the other.

A connection shared with your team, or owned by an agent for unattended work, uses a shared service identity instead. That is deliberate: an unattended run must not act as an absent person.

The pre-built Beak servers can act as you too

The section above is about how a connection is authenticated. A second, separate question is what the MCP server then sends to the system behind it — and for the pre-built servers that reach another Beak product, that used to be a shared service account no matter who triggered the call.

Eleven of them can now make that call as you instead:

Server	Reaches
Beak ELM	Beak ELM
Beak FinOps	Beak FinOps
Beak M365	Beak M365Lite
Beak ITSM	Beak ITSM
Beak Task Manager	Beak ITSM
Beak Observability	Beak Observability
Beak ITAM	Beak asset management
Beak Vulnerability	Beak security
Beak Endpoint Automation	Beak endpoint automation
Beak Patch Manager	Beak patch management
Beak Desk Task	Beak Desk

When this is enabled, the product authenticates the call as the person who triggered it and applies their role, permissions and company scoping — the same access they would have signing in to that product directly. Anything you cannot see there, the server cannot see for you. Your access is read live, so a permission granted or removed in the product takes effect on the next call without reconnecting anything.

It applies only to personal connections. A connection shared with your team, or owned by an agent for unattended work, keeps using the shared service identity, because an unattended run must not act as an absent person.

It is off by default, and an administrator turns it on per server. That is deliberate, and worth understanding before asking for it: an agent running today on a shared service account may have broader access than the people who use it. Switching that agent to per-user identity is the correct end state, but it can narrow what the agent can reach, and some calls will start being refused — correctly — because the person behind them does not have that access. Enable it once you are ready for that, one server at a time.

When a call is refused this way, the fix is in the product, not in Beak Hub: grant the person the product access, role or company they are missing, exactly as you would if they were using that product directly. The connection itself does not need to be recreated, and the change takes effect on their next call.

Four further servers reach Microsoft rather than a Beak product — Azure, Microsoft Entra, Microsoft Fabric and Azure DevOps. These reuse the Microsoft sign-in you have already done: if your company signs in to Beak through Microsoft, Microsoft issued a token for you at that moment, and Beak can call Microsoft with it. Your Beak identity is not exchanged for a Microsoft one — Microsoft does not accept a Beak identity for that — and no application secret is involved, so there is no separate app registration to create for this.

What that token can reach is limited, because Microsoft issues a token for one service at a time:

Server	Acts as you?
Microsoft Entra	Yes — your own directory permissions apply.
Microsoft Fabric	Only for the parts served by Microsoft Graph.
Azure	Not yet.
Azure DevOps	Not yet.

The token from your sign-in is issued for Microsoft Graph, and a Microsoft token is only accepted by the service it was issued for. Azure, Azure DevOps and the Fabric and Power BI parts of Microsoft Fabric therefore say so and refuse, rather than quietly falling back to a shared identity that would act as somebody else. Widening this to those services is planned work.

Two things an administrator sets up first, and both fail loudly rather than silently:

• Let Beak act as you at Microsoft. On your company's Microsoft sign-in in Beak IAM, turn on keeping the provider's tokens, and allowing them to be read back. This stores a Microsoft credential for each person who signs in, so it is a deliberate decision rather than a default — see Company SSO. It only captures sign-ins that happen after it is switched on, so people already signed in need to sign in again, and the read-back permission only reaches people who link to Microsoft after it is on.
• Point the server at Beak IAM. Each of the four needs two things, once per environment: which Microsoft sign-in to read your token from, and which Beak IAM address is the legitimate one. The second is a safety check rather than a convenience — the address a request carries is not trusted on its own, so a server will only ever fetch your token from an address an administrator has listed, and refuses any other.

Until both are done, these servers report exactly which of the two is missing. A person who signed in with a Beak password rather than through Microsoft has no Microsoft token to act with, and is told that too.

The last five in the table above reach an older part of the platform, which needs one extra step from an administrator before it will work — see below. Everything a user sees is the same once it is set up.

Two pre-built servers cannot do this at all: Beak NOC and Smart Work Analytics. The systems behind them do not accept a Beak identity on any route. They state so on their catalog entry, so an administrator granting access to one knows they are granting whatever that shared credential can reach.

The five older-platform servers need one setting first

Beak ITAM, Beak Vulnerability, Beak Endpoint Automation, Beak Patch Manager and Beak Desk Task reach the older platform, which does not read a Beak identity directly. Instead the server hands your identity to it once and receives a session for you, then makes every call in that session — so the end result is the same: the product applies your own role and company access.

Two things an administrator has to do before enabling it there, and both fail loudly rather than silently falling back to the shared account:

• A shared key between the two sides — The older platform's sign-in check expects requests to come from a browser and refuses one that does not say where it came from. An administrator sets one matching value on the MCP server and on the older platform, which tells it the caller is a Beak service rather than a browser. It is not a password for anything: the person's own identity still has to be present and is still verified, so the key on its own grants no access. Set it once per environment; until it is set, the server reports exactly that rather than a generic authentication error.
• An existing account — This flow does not create one. Someone who can sign in to Beak but has never been set up in the older product is refused with a message saying so, and an administrator provisions them first.

Turning it on, one server and one environment at a time

Enabling a pre-built server involves two settings that stay deliberately separate: one decides how a person authorizes to Beak Hub, the other decides whether their identity is then passed on to the product behind it. A server with the first and not the second authenticates the person but still calls the product as the shared account.

• Register the server in Beak IAM — Creates a dedicated client for that tenant and server, with an audience binding so a token issued for one server is not accepted by another, plus an access role. There is no administration screen for this yet, so it is an API call today.
• Grant people the access role — Until someone holds it their authorization is refused, so this is the control over who may use the server at all, separate from what they can see once they are in.
• Switch the connection method for this environment — Set per environment rather than in the server's catalog entry. Each environment has its own identity provider, and one catalog entry is shared by every environment, so the entry keeps its static-credential default and an environment is switched over explicitly. This is what makes the Connect dialog offer authorization instead of asking for a key.
• Confirm the server passes the identity on — The per-user setting described above, declared by the server itself and safe to leave on everywhere: it does nothing until an environment is switched over and a personal connection exists.

Note: Authorizing requires being signed in to Beak already. The flow deliberately never shows a Beak IAM screen, so people only ever see Beak's own sign-in — start it from a browser with an active session, or it will end on a sign-in error rather than a consent prompt.

Order matters in one respect: anyone who authorizes before they hold the access role is refused and has to authorize again afterwards.

External identity providers

beakiam routes authorization through Beak IAM, which can federate to your organization's own identity provider — Microsoft Entra ID, Okta, Google, any OpenID Connect provider, or SAML. You sign in with your corporate account, and Beak IAM issues the token the MCP server accepts. Administrators manage who may reach which MCP server in one place rather than per server.

Reaching a server with a token you already have

A user who has already signed in at their own organization's identity provider can reach an MCP server without a second login. Their provider's token is exchanged, through Beak IAM, for a token bound to that one MCP server and carrying that user's identity.

Three separate decisions govern this, and all three must be satisfied:

Decision	What it controls	Where it is made
Audience binding	which MCP server a token is valid for	automatic, when the server is registered
The access role	which users may reach that server	per user, granted by an administrator
Permitted providers	which identity providers a user may arrive from	per (server, provider) pair, granted by an administrator

The third is the one that is easy to overlook. Registering a server and granting a user access is not enough: the provider the user arrives from must also be permitted for that server. Until it is, exchanges are refused.

Note: A user's provider token can only be exchanged once their Beak account is linked to that provider, which takes one interactive sign-in. The link is created the first time they sign in through it interactively, or by the directory sync. A user who was created by bulk import and has never signed in has no link, and their exchange is refused with a message saying so. They sign in once and it works from then on.

Renewal and re-authorization

Each connection in the Connections panel shows the state of its authorization:

• Authorized — working normally.
• Renewing automatically — the access token is being refreshed. No action is needed; this is routine.
• Needs re-authorizing — the identity provider has refused the stored authorization, usually because it was revoked, it expired beyond renewal, or your account changed. Reconnect the instance to restore access.
• Authorization removed — the authorization was deliberately removed. Reconnect to use it again.

Removing an authorization does not delete the connection or change its bearer token, so every client already configured with that token keeps working once you re-authorize. Disconnecting the instance entirely does invalidate the token.

A note on how this is implemented today

Beak IAM performs this exchange using the identity platform's token-exchange grant. The Model Context Protocol's Enterprise-Managed Authorization extension specifies a different grant for the same purpose, which the currently deployed identity-platform version does not provide. The result is the same — a token bound to one MCP server, carrying the user's own identity — and callers go through Beak IAM rather than composing the request themselves, so the mechanism will change to the specified grant at the next identity-platform upgrade without affecting anything that calls it.

If a server asks for more permission later

A server can refuse an individual tool call because the authorization does not cover it. Beak Hub records the additional permission the server asked for and marks the connection as needing re-authorization. When you reconnect, the request includes both the permissions you already granted and the new one, so re-authorizing never silently drops access that other tools depend on.

---

Post-Connection Snippets

After a successful connection, the dialog transitions to a snippets panel with two sections:

• Hub-routed access — The default path: the client sends requests to the Hub Gateway, which proxies them to the MCP server using the stored credentials. A bearer token is shown (revealed once; copy it before closing). Client configuration snippets are available on tabs: Claude Desktop, Cursor, curl, and Studio.
• Standalone access — An alternative path for clients that communicate directly with the MCP server (customer-attached deployments, on-premises, or servers on their own hostname). A standalone API key and the MCP endpoint path are shown here. The API key can be passed as x-api-key, api-key, or Authorization: Bearer ….

Note: The bearer token and standalone API key are displayed once. Copy them before closing the dialog; they cannot be retrieved after dismissal. To obtain new credentials, disconnect and reconnect the instance.

---

Best Practices

• Name instances descriptively (e.g., Prod, EU-West, Sandbox) so teammates can distinguish them in the Connections panel without opening the server detail page.
• Prefer a personal connection on a server that supports OAuth. The server then enforces your own access, and a call can be attributed to you. Reserve shared connections for genuinely shared automation.
• Reconnect promptly when a connection reads Needs re-authorizing. Agents using it will fail until you do, and the failure appears at the tool call rather than on this page.
• Use Just me scope while testing a new connection; promote to Share with my team (admin-only) once the configuration is validated.
• If your client communicates directly with the MCP server rather than through Hub Gateway, use the Standalone access credentials from the snippets panel.
• The Tools tab is useful for verifying that the expected capabilities are available before wiring the server into an agent workflow.
• Rotating credentials requires disconnecting and reconnecting an instance; the instance name can be reused.

---

Related Pages

• Overview — Beak Hub landing page and catalog summary.
• Agents — Browse pre-built agents that consume MCP server tools.
• Agent Suites — Bundles that include MCP servers alongside agents and skills.
• Tenants & API Keys — Register tenants and manage the API keys their services authenticate with.