MCP Connectors

An MCP connector links Falcon to an external tool server

An MCP connector is a workspace’s connection to an external server that speaks the Model Context Protocol: a workspace-level object with a name, a server address, and everything Falcon has learned about that server since. Once that server is connected, its tools sit beside Falcon’s own platform tools in the same conversation turn, so a single request can read an evaluation and open an issue in your tracker without you switching tools. Skills can reach for those same enabled tools too, alongside platform tools, when a workflow calls for them. Falcon’s connector panel frames the idea plainly: “Add MCP connectors to give Falcon access to external services like GitHub, Slack, databases, and more.”

Two moments decide what Falcon can actually do with a connector: discovery, when Falcon asks the server what it offers, and enabling, when you choose which of those discovered tools it’s allowed to call. For the steps to add a connector and authenticate it, see Connect an MCP server.

flowchart TD
accTitle: Where an MCP connector's tools sit relative to a Falcon conversation turn
accDescr: An MCP connector holds the tools it discovers on its external server. Enabled tools are a subset within that discovered set. The current turn's tool set combines Falcon's platform tools with the connector's enabled tools.
subgraph Connector["MCP connector"]
  subgraph Discovered["Discovered tools"]
    Enabled["Enabled tools"]
  end
end
Platform["Platform tools"]
Turn(("This turn's tool set"))
Platform --> Turn
Enabled --> Turn

Discovered tools are not the same as enabled tools

This is the distinction that matters most. Discovery is Falcon asking the connected server what it can do: it queries the server’s tool list, and a successful discovery turns every one of those tools on, so Falcon can call everything the server offered. Enabling is what happens afterward, and it only ever narrows that starting set down: you choose which discovered tools stay on and disable the rest. Falcon may only call the subset you’ve left enabled, and that subset can never grow past what discovery found.

The states you’ll see

A connector moves through four stages, but the app tracks them with only three status chips: “Connected”, “Pending”, or “Inactive”. The chip is coarser than the stages, so several of the stages below share the same chip.

• Added. The connector exists with a name and a server address. Falcon hasn’t confirmed it can reach or use anything yet, so the chip reads “Pending”
• Authenticated. Falcon has verified it can talk to the server, and the chip changes to “Connected”. If verification fails instead, the error shows on the connector card in the Customize panel, so you can see it without having to reproduce it
• Tools discovered. Falcon keeps the tool list it got back from the server, and the chip still reads “Connected”
• Tools enabled. This is where you narrow the default set down to just the tools you want Falcon to use, and the chip still reads “Connected” here too

A connector can also be turned off outright, at which point the chip reads “Inactive” regardless of what was discovered or enabled underneath it.

To choose exactly which discovered tools stay enabled, see Choose connector tools.

Choosing how a connector authenticates

Different servers expect different things from a client, so a connector’s authentication is a choice, not a fixed requirement, and it’s a property of the server you’re connecting to, not something Falcon decides for you:

• None. Some servers need no authentication at all
• API key or bearer token. Some expect a credential you hold and hand to Falcon directly
• OAuth. Some run a full sign-in, where you approve access in the provider’s own window rather than typing a secret into Falcon

Check the server’s own documentation, or ask whoever runs it, to find out which one applies.

Why it matters

Vetting the server, and narrowing its enabled tools down to just what you want Falcon to use, is on you.

Keep exploring