MCP Connectors
Connect external MCP servers so their tools sit beside Falcon's own
About
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
Discovery asks the server for its tool list and stores the result on the connector. Every successful discovery enables all returned tools, replacing any previous selection. You can then narrow that set to the tools Falcon is allowed to call. The UI requires at least one discovered tool to stay allowed.
Warning
Successful rediscovery resets your tool restrictions. OAuth reauthentication can also trigger discovery. Review and reapply your allowed-tool selection afterward, before continuing to use the connector.
Warning
Only use connectors from developers you trust. Future AGI does not control which tools developers make available and cannot verify that they will work as intended or that they won’t change.
The states you’ll see
The status chip reflects the connector’s stored active and verified state, not a live check of its tools.
| Chip | Meaning |
|---|---|
| Connected | The connector is active and its stored state is verified. This does not prove that tool discovery succeeded. |
| Pending | The connector is active but its stored state is not verified. |
| Inactive | The connector is marked inactive, regardless of its verification or tool list. |
Test Connection returns a test result without updating the stored verified state or tool inventory. Successful discovery stores the tool list and marks the connector verified. OAuth authentication can succeed even when discovery fails, so a Connected chip alone does not tell you whether tools were discovered.
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.
Next Steps
Questions & Discussion