Bring your tool server onto the canvas
Attach a Model Context Protocol tool server to an AI Agent on the canvas. WEXTL shows the MCP node next to the model — approved tools only, every call in run history.
- GDPR
- Data Encryption
- 2FA
- Local Data Region
AI Agent running with a Slack MCP tool server — its tools in the run result
What MCPs helps you do
Bring your tool server onto the canvas
- 1
Point at the MCP endpoint
Add the server's URL (or local command) that you already trust. WEXTL calls tools/list against it and shows exactly the tools it advertises — nothing is available to the agent until you expose one.
- 2
Expose only the tools you approve
Check the tools the agent may call from that discovered list — e.g. list_issues and add_comment but not delete_repo. Anything left unchecked is invisible to the agent, not just unused.
- 3
Wire MCP under the AI Agent
The MCP capability hangs off the AI Agent node in the same slot as the model provider — the agent then decides, turn by turn, whether to call an MCP tool or act through Asana, Gmail, or CRM app nodes on the same canvas.
MCP beside the model, not instead of apps
MCP tools carry the same audit trail as app steps — not a side chat that forgets your CRM. When the AI Agent calls a tool, the call and its result ride inside the workflow run, never a separate chat log you have to reconcile later.
The MCP capability hangs off the AI Agent node in the same slot as the model provider. WEXTL calls tools/list against your server once you connect it, then shows exactly what it found — nothing implied, nothing added.
Reviewers see the MCP node sitting under the agent on the canvas — not a mystery function call routed through another product's dashboard.
Add a GitHub MCP server with list_issues, create_issue, and add_comment exposed. Ask the agent "any P0 bugs assigned to me" and it calls list_issues with a label filter — you never wired that as a fixed workflow step.
Change the request next run — "comment on issue 482 that I'm on it" — and the same agent calls add_comment instead. A workflow step always fires the same action every run; an MCP-backed agent tool call is chosen fresh at each turn based on what the conversation needs.
That's the actual tradeoff: you don't get a fixed sequence to point at in the canvas, but you also don't rebuild the workflow every time the request changes shape — the exposed tool list stays fixed, only the agent's choice among it varies.
MCP server picker — Slack, DeepWiki, GitHub, Linear and more
Policy before high-impact tool use
Pair MCP-backed agents with Filters and human review the same way you guard auto-send email — a delete_issue or refund_customer tool sits behind a review branch while add_comment or list_issues continue straight through.
Choose all tools, an allow-list of the ones you trust, or a deny-list to block just the destructive ones — the exposed tool set is decided before the agent ever runs, separately from which of those tools it actually calls during a given run.
Every call is logged either way, so a blocked high-impact call and an approved routine one both show up in run history with the same level of detail.
A WEXTL app in the catalog — Asana, Gmail, a CRM — is a first-party connector WEXTL builds, hosts the OAuth flow for, and maintains. An MCP server is one you bring: a vendor's hosted server, or one you run yourself against an internal system like a Postgres read-replica or an internal ticketing API.
WEXTL doesn't vet the servers you connect — you're pointing the AI Agent at an endpoint you already trust, the same way you'd trust an API key you typed into an HTTP step.
That's why the exposed-tools step matters: point at a server you don't fully trust and expose everything it offers, and the agent can call whatever that server advertises — scope it down to only what the workflow actually needs.
Tools to include — all tools, an allow-list, or a deny-list
