MCP tools

An agent is only as useful as the tools it can reach. Give an agent your issue tracker, your design files, your observability stack, and your own internal services, and the work it can do stops being "describe the change" and starts being "make it." MCP, the Model Context Protocol, is the open standard that carries those tools to an agent, and Disco Parrot turns connecting one into a few clicks: install from a curated catalog, sign in once, choose exactly which tools are on, and test the connection before any run relies on it.

For the model behind it, why an agent's reach is enumerated and why credentials stay server-side, read approved actions. This page is how you set the connections up.

What you are setting up

A connection is one MCP server plus how the platform authenticates to it and which of its tools you have turned on. Each connection you add declares exactly which tools reach the agent, and anything you do not turn on is not available to it. The credential the server needs is held by the platform and applied server-side when a run actually calls a tool, so the key, the token, or the OAuth session never enters the agent's sandbox.

There are two ways to add a connection: install one from the catalog in a few clicks, or add one by hand when you are connecting something the catalog does not cover. Both end in the same place, a connection you attach to a sandbox profile so the sessions and Flows that use that profile can reach its tools.

Browse the catalog

Open Platform, then MCP, and browse the catalog: a curated set of connectors for the tools teams reach for most, GitHub, Linear, Slack, Notion, Jira, Sentry, Figma, and more. Each entry is a card with the publisher, a short description, and the categories it belongs to, and the ones already connected in your workspace carry an Installed badge so you can tell at a glance what is set up. Search narrows the list by name, publisher, and description.

Open an entry and the detail page lays out what you are about to connect: what the server is for, the kinds of things an agent can do with it, how it connects, the permissions you will grant when you sign in, and a representative list of the tools it exposes. The full tool list is discovered live from the server the moment you connect, so you configure against what the server actually exposes today, not a catalog snapshot that drifted since someone last updated it.

Connect from the catalog

Installing from the catalog is a short, guided flow. Click Add, review what you are connecting, and sign in: a provider window opens, you authorize the connection, and it closes. The platform then connects to the server, discovers its real tool list, and runs a test so you start from a connection that is already known to work. Last, you choose which sandbox profiles the connection attaches to, and you are done.

Two things happen automatically and are worth knowing. The platform stores the credential from your sign-in server-side, scoped to this connection, so no key is ever pasted into a config or handed to an agent. And a small set of a server's tools that are known not to work with agent runtimes are excluded for you at install, so you start with the tools that behave rather than the ones that will error mid-run. You can see them on the connection, marked and turned off.

A few catalog servers need a pre-registered OAuth client of their own, and for those the one-click sign-in cannot complete on its own. When that happens the install backs itself out cleanly and points you at Customize before install, where you supply the client details once and finish the connection by hand. Most catalog servers are the one-click path, and the few that need their own OAuth client fall back to that Customize flow rather than leaving a half-connected server behind.

Connecting Linear, start to finish

Sarah's Analytics team runs its work in Linear, and she wants the agent able to read and file issues there without anyone pasting a token into a config. She opens Platform, then MCP, and searches the catalog for Linear. The card already tells her what she is about to wire up: the publisher, what the connector is for, and the categories it sits in.

She opens the entry, reads what an agent can do with Linear and the scopes she is about to grant, clicks Add, and signs in. The guided flow does the rest: the provider window authorizes and closes, the platform discovers Linear's real tools and tests the connection, and the tools that do not behave under an agent come pre-excluded. She lands on a working connection without having pasted a token anywhere.

Now she narrows the surface. Linear exposes more than the team needs, so she leaves on the handful that matter, read an issue, create an issue, comment, search, and turns the rest off. Those are the only Linear tools anything in the workspace can reach through this connection.

Last, she attaches it to the Insights project's sandbox profile. From the next session on, Priya can ask the agent in chat to pull the open issues on a plan, and Maya's CSV Export Flow can file a follow-up issue as one of its steps, both reaching Linear through the same connection, both authenticated by the sign-in Sarah did once and the platform now holds. Nobody on the team ever sees the token.

Add a server by hand

When you are connecting something the catalog does not cover, an internal service, a server you run yourself, or one that needs a token instead of a sign-in, you add it by hand from the MCP Configs page. A connection by hand gives you the full set of options the catalog one-click flow keeps simple.

You choose a transport, the way the platform talks to the server:

• stdio, a local server the platform runs alongside the agent and talks to over standard input and output. You give it a command to run.
• HTTP, a remote server reached over a streamable HTTP endpoint. You give it a URL.
• SSE, a remote server reached over server-sent events. You give it a URL.

A stdio server can also carry an install command the platform runs once when it provisions the sandbox, so a server shipped as a package is in place before the first run. Any connection can set environment variables passed to the server at launch, for the host and config values a server needs that are not secrets. The platform and runtime reference lists every transport and auth mode by its exact name.

Two GitHub servers ship as presets, the GitHub MCP server and the GitHub agentic-workflows server, so connecting them is a matter of picking the preset rather than filling in transport and auth by hand. A preset locks the transport and auth shape to what that server expects and leaves the identity fields for you to fill. Everything you set is versioned, so a connection's configuration has a history the same way a skill or your Agent Instructions do.

Authentication

A connection authenticates without ever giving the agent a standing secret. You pick how the platform signs in, and the credential is resolved and attached server-side at the moment a run calls a tool.

• None, for a server that needs no credential.
• Browser OAuth, where you sign in through the provider's own window and the platform holds the resulting session, refreshing it as it nears expiry. This is what the catalog one-click flow uses. For providers that sign in with a one-time code, the same path runs a device-code sign-in: the platform shows you a short code to enter on the provider's site. A hand-configured connection like Azure DevOps authenticates this way.
• CLI session, where the connection reuses a command-line tool you are already logged into on the host, for example the GitHub CLI's gh auth session, so a local server inherits a login you already have.
• Env bearer token and custom header, where the platform holds a token you have stored as a secret, or pointed at from the host environment, and presents it as a bearer token or a header of your choosing.

Whichever you choose, the credential is the platform's to hold, not the agent's. When a run calls a tool, the platform attaches the credential to the outbound connection through a short-lived lease, and token-shaped values are stripped from anything the agent can see. A connection that the platform cannot authenticate is left out of the agent's tool set for that run, and the run continues with the tools that are ready rather than carrying a broken connection. Nothing half-connected reaches the work.

Choose which tools are on

Once a connection is reachable, the platform discovers the server's real tools and lists them. The list is an allowlist: every tool you leave on becomes an action your agents can take, and every tool you turn off is hidden from every skill and chat session that uses the connection. Turn on the handful your team actually needs and leave the rest off, and those are the only tools anything can reach through that server.

The allowlist is enforced where it counts, server-side, as the agent's tool set is assembled for a run, not as a display filter that a clever prompt could talk around. Tools known to be incompatible with agent runtimes stay turned off and cannot be enabled, so a connection never offers the agent something that will fail the moment it is called.

What to turn on, and what to leave off

A connection is at its best when its allowlist is short. The instinct on a fresh connection is to leave everything on, since the server offers it and turning tools off feels like giving something up. The opposite holds in practice: every tool you leave on is one more action an agent can take and one more thing you have to reason about when you ask what a run could have done. A connection you can describe in a sentence, "it can read and file issues, nothing else," is one you can trust without re-reading it.

A few habits keep a connection legible.

• Turn on the verbs the work needs, not the ones the server has. A server might expose forty tools; a team usually reaches for four. Read an issue, file one, comment, search is a complete issue-tracker surface for most work. The admin and bulk-management tools a server ships are rarely what an agent should hold.
• Prefer read over write until a Flow asks for write. A connection that can only read is a connection that cannot change anything by accident. Turn write tools on when a Flow actually needs to file or push, and you will know exactly which step relies on them.
• One connection per system, attached where it belongs. Resist a single catch-all connection wired to every profile. A connection scoped to one system and attached to the profiles that do that work is the unit you can reason about, and the profile is where you decide which work gets which reach.
• Re-read the list when the work changes, not before. The allowlist is a one-place edit that reaches every run after it, so widen it the day a Flow needs more and narrow it the day a tool stops earning its place.

The test for whether a tool belongs on a connection is the same one you would apply to a teammate's access: if you cannot name the task that needs it, leave it off. You can always turn it on the day the work calls for it, and until then it is one less thing an agent can reach and one less thing you have to account for.

Where the tools show up

A connection's tools do not announce themselves as a menu the way a skill does. They join the agent's working set the same way reading a file or running a command does, and the agent reaches for one when a task needs it.

• In chat, the tools on a connection are part of what the agent can do in any session launched from a profile that carries it. Ask the agent to check the open issues on a plan and it calls the issue-tracker tool; ask it to pull the error behind a bug and it calls the observability one. You do not invoke a tool by name. You describe the work, and the agent uses the tools its profile makes available.
• In a Flow, the same tools are available to every step that runs on a profile carrying the connection. The connection's allowlist sets what those steps can reach, and a profile in strict-command mode holds a run to exactly the tools you named, so the surface a Flow works inside is the one you drew on the connection and the profile.

What an agent reaches for is its own decision in the moment; what it is able to reach is the allowlist you set. That split is the whole point. You decide the surface once, on the connection, and every session and every step that runs on that profile works inside it without anyone choosing a tool by hand.

Test before you rely on it

Every connection has a test. It connects to the server for real, runs the credential through whatever sign-in you configured, and lists the tools the server exposes, then reports one of three plain results: ready, with the count of tools discovered; needs sign-in, when the connection is reachable but not yet authorized; or an error, with the reason. The result is saved on the connection, so the status you see on the page is the last real check, not a guess. Save a connection before you test it, so the test runs against exactly what you have configured.

When a connection takes effect

A connection reaches your agents through a sandbox profile. You attach the connection to one or more profiles, and from then on every chat session and every Flow run those profiles launch picks it up with its current tools and credentials. Change the allowlist or re-authenticate, and the next session that profile starts carries the change. Connecting tools is a setup step you do once and your team gets on every run after. That is also why a connection attaches deliberately to the profiles that should have it, rather than switching on everywhere at once: the profile is how you decide which work gets which reach.

Editing and removing a connection

A connection is not frozen once it works. Open it from the MCP Configs page to change the transport, re-authenticate, or turn tools on and off, and every save snapshots a version the same way a skill does, so a connection's configuration has an ordered history with an author on each change. The profiles that carry the connection pick up the new shape on their next session, so widening or narrowing the allowlist is a one-place edit that reaches every run after it.

Removing a connection is deliberate, because other things lean on it. A connection attached to a sandbox profile is in use, and deleting it would pull tools out from under every session and Flow that profile launches. So a delete is blocked while a connection is still attached, and the platform names the profiles to detach it from first. Detach it, then remove it, and nothing in flight loses a tool without someone deciding it should.

What to connect first

The connections that earn their place fastest are the systems your team is already in all day, the ones an agent has to reach to do real work rather than describe it. A few come up on almost every team.

• Your issue tracker. Linear, Jira, or GitHub Issues, so an agent can read the issue it is working, file a follow-up, and leave a comment where the team already looks. This is the connection that turns "summarize this" into "summarize this and file what it found."
• Your code host. GitHub or your Git provider, so a Flow can open the pull request at the end of a run instead of handing back a diff for someone to push by hand.
• Your observability stack. Sentry or your monitoring tool, so a triage skill can pull the actual error and the stack behind it rather than work from what a person remembered to paste.
• Your design and docs surfaces. Figma or Notion, so an agent drafting a plan can reach the spec and the design it is planning against.

Start with one. Connect the system your team reaches for most, turn on the three or four tools that do the work, attach it to the profile your agents already run on, and watch one Flow get sharper because a step can now act instead of guess. The next connection picks itself: it is the one the first Flow kept reaching for and could not.

Who can browse, connect, and authorize

Connecting tools is a permissioned activity, kept separate from using them, so the people who decide which tools an agent can reach are the people you choose.

Browsing the catalog and seeing what is connected ship on every content-facing role, so anyone can see the tools the workspace has. Adding and editing connections is the elevated permission, and it is part of the custom-MCP capability on your plan. Signing a connection in is split into two scopes on purpose: authorizing a shared, workspace-wide credential is an elevated action, while authorizing your own credential for a connection is something you can do for yourself.

Why MCP works this way

An agent that can act is the point. An agent that can reach anything is the problem, because you can no longer say what a run was able to do. Disco Parrot's answer is to make reach a thing you assemble rather than a thing you inherit. Every tool an agent can call traces back to a connection you added and an allowlist you set, the credential behind it is the platform's to hold and never the agent's, and a connection that cannot authenticate is left out rather than passed in broken.

For your team, the tools you live in show up where agent work happens, and you wire them up once. For an engineer, a connection is something you can read: a transport, an auth method, and a list of exactly the tools that are on, with nothing reaching the agent that is not on it. For a security or platform owner, this is least privilege made concrete, an enumerated tool surface, credentials the platform holds and the agent never sees, and a sign-in split so that workspace-wide access and personal access are granted by different people. For a new hire, the catalog is the fastest read on what the team has connected and what an agent here can actually do.