Skip to main content
MCP (Model Context Protocol) is how services expose purpose-built tools directly to agents. When a service publishes an MCP server, connecting it gives your agent a set of tools designed for agent use, not just access to a REST API. One-click, via the catalog: Many MCP servers use OAuth with dynamic client registration, which means no manual setup. Click the service in the catalog, authorize with your account, and the agent is connected. The credential is stored securely and attached to every request automatically. By URL, for any MCP server: A server your team hosts, or any server not in the catalog, connects the same way: point the agent at its URL.
Or add the URL in the agent’s tools settings, or wire it up yourself in the agent’s repository config. The agent picks the server up on its next turn and the tools appear alongside the built-ins.

​
When the server needs authorization

A Connect card opens. The agent follows the standard MCP authorization flow: it reads the server’s OAuth discovery documents, registers as a client where the server allows it, and asks you to approve access in your browser. You approve once. After that the proxy attaches the token to every request automatically, and the token never appears in the agent’s prompts. See Connecting services for how credentials are stored. If you run the server, allow these two URLs in your OAuth setup: If your identity provider only allows pre-registered OAuth apps, tell the agent. A server that takes a static token connects without OAuth: the agent adds it to its MCP config with your key as a request header, and the proxy sends it on every request the same way.
An MCP connect card grants access at whatever level that server’s OAuth app requests, which is often the full workspace or account. This is different from some OAuth flows (like Notion’s) where you pick individual pages. On MCP Connect you won’t see an item picker.

​
What MCP adds over an API

An API gives the agent endpoints. An MCP server gives it tools with descriptions, typed arguments, and semantics written for an agent to read. The agent spends less effort working out how to call the service and more on the actual job.

​
Managing a connection

Once a service is connected, manage it from the integration’s card in your workspace. The card shows which agents use the connection and gives you two options to pull access back:
  • Remove from one agent. The connection stays live for your other agents.
  • Disconnect entirely. This revokes Skydive’s access at the provider and removes it from every agent using it.

Catalog

Every service available to connect.

Permissions

How credentials stay out of the model’s reach.