MCP Connectors & the Connect Page — Wire AI Agents to 3,000+ Apps
What is an MCP Connector?
An MCP Connector is a node you drop on a Text Graph that hands your agent every tool a third-party app exposes — Slack, Gmail, Airtable, HubSpot, Notion, Stripe, and 3,000+ more — without anyone writing an integration for it first.
Definition — MCP (Model Context Protocol): An open standard for describing the tools an application offers, so an AI agent can discover and call them at runtime instead of relying on hand-written wrappers.
Langoedge resolves connectors against a hosted MCP catalogue covering the full third-party app directory. Two consequences worth understanding up front:
- The catalogue is discovered live, not hardcoded. When an app adds an action, or a new app joins the directory, it shows up in your picker without a Langoedge release.
- Adding an app is configuration, not engineering. Pick the app, pick the tools, attach the connector to a step. There is no code and no waiting for a connector to be built.
Two steps, always in this order
1. **Connect the account** on the **Connect** page — this is the OAuth handshake that gives Langoedge permission to act as you in that app. 2. **Add an MCP Connector node** to your graph and attach it to a step — this is what actually gives the agent the tools.
Skipping step 1 doesn't break the builder; it just means the connector can't list any tools yet.
Part 1 — The Connect Page
Go to Connect in the dashboard. This page is the credential vault for your whole workspace: every account you link here is scoped to your user and reusable across every graph you own.
Linking an account
Find the app
Click Connect Account
Confirm it landed
Disconnecting
Each account card has a Disconnect button. Disconnecting revokes Langoedge's access immediately and clears the cached tool catalogue, so any graph step relying on that app will start reporting a missing connection on its next run.
One account per app, per user
Accounts are scoped to your Langoedge user. Two people on the same workspace each connect their own Slack. A graph runs against its owner's connected accounts, not the accounts of whoever triggers it — which matters when you publish a graph or embed a widget: the actions are performed as the graph owner.
Part 2 — Required Connections
Some connections aren't optional extras — the platform gates on them.
Beyond that, the graph editor checks the models your graph actually uses and blocks the canvas if the matching provider isn't connected. The mapping is by model name prefix:
| Model name looks like | Provider you must connect |
|---|---|
gpt-…, o1…, o3…, o4… |
OpenAI |
claude…, anthropic/… |
Anthropic |
gemini-…, gemini/…, google/… |
Google Gemini |
llama-…, mixtral-…, gemma-…, groq/…, meta-llama/… |
Groq |
Anything ending -us or -aus |
None — these are Azure-hosted and need no connection |
The Knowledge Store additionally requires OpenAI, since it uses OpenAI embeddings to index your files.
Part 3 — Adding an MCP Connector to a Graph
Open a Text Graph and add an MCP Connector node to the canvas.
Pick the app
Choose which tools to expose
Attach it to a step
If the app isn't connected yet
If you haven't linked the account, the node shows "No connected account yet" with a direct Connect link that opens the right connect flow. Follow it, then press Load Tools again.
Refreshing a catalogue
Tool catalogues are cached for an hour. If a provider ships a new action and you want it now, press Refresh on the node to force a fresh fetch.
How Tool Resolution Works
Understanding the read path explains most of the behaviour you'll see:
Three things follow from this:
- Opening the tool picker is fast. It's a cache read, not an upstream round trip.
- An upstream outage degrades rather than breaks. If the upstream fetch fails, Langoedge serves the last catalogue it successfully fetched, however old. A slightly stale schema is recoverable; a graph that compiles with zero tools just looks like a broken agent.
- A catalogue is shared, not per-graph. Tool names, descriptions, and schemas are properties of the app, not choices you made, so one entry is shared by every graph and every user. Only your decisions — which app, which tools withheld — are stored on your graph.
If an app's tools genuinely cannot be resolved from any layer, that connector is skipped and the step runs without it, with a warning in the logs rather than a hard failure.
What Is Not an MCP Connector
A handful of integrations are deliberately kept as hand-written modules rather than going through MCP, because they need behaviour beyond a generic tool call — retries, custom formatting, domain-specific aggregation, or a real-time voice path:
| Integration | Why it's hand-written |
|---|---|
| Cliniko | Healthcare scheduling with domain-specific aggregation across practitioners, appointment types, and availability. |
| ServiceM8 | Field-service job and client workflows. |
| Twilio / Telnyx | Telephony and SMS sit on the real-time voice path, not the tool-calling path. |
| Pinecone / Qdrant | Vector stores backing the Knowledge Base and Retriever tools. |
Native tools — the web crawler, web search, academic search, the SQL toolkit, the sandboxed code runner, and RAG retrievers — are unaffected by any of this and need no account connection beyond their own configuration.
Security
- Credentials are held by the connect layer and referenced by an opaque account id. Langoedge stores the link, not your password.
- The LLM never sees your credentials. Authentication is attached server-side, per request, at the moment a tool is invoked. The model sees only the tool's inputs and whatever the app returns.
- Tokens are minted fresh for each call rather than baked into a compiled graph, because graphs are compiled once and cached but invoked arbitrarily later.
- Every call is scoped to the graph owner's connected accounts. A graph cannot reach another user's linked apps.