Definition: In the Model Context Protocol, the client is the software that reaches outward — it discovers the tools an external MCP server publishes and calls them mid-task. Claude Desktop, Cursor, and VS Code all act as MCP clients. Taskade fills the role too, and it fills it from your automations: the MCP Client step points at any remote MCP server, lists the tools that server publishes, and calls any of them. It works on every plan, including Free, with your plan's automation run allowance as the only ceiling. What an AI agent cannot do is reach a remote server on its own — it hands that call to an automation step instead.
Taskade fills the other role as well. Taskade as MCP Server publishes your workspace — projects, tasks, documents, agents, automations — at https://www.taskade.com/mcp, and any external MCP client can sign in over OAuth2 + PKCE and call it. That side needs a paid plan. Alongside both directions, the 100+ integrations and the built-in tools every AI agent carries reach the services that do not speak MCP at all.
Why the Two Roles Get Confused
MCP is a two-sided protocol, and both sides are usually described in the same breath. Every connection pairs exactly one server — which publishes a tool catalog and waits to be called — with exactly one client, which discovers those tools and invokes them. Read quickly, "Taskade supports MCP" sounds like it covers both. It covers one.
The confusion has a real cost when you are planning a stack. Product lives in Taskade, specs live in Notion, issues live in Linear, code lives in GitHub. Knowing which side of MCP a product implements tells you which of those hops it can make for you and which you still have to wire yourself.
The protocol's appeal is genuine: pre-MCP, connecting M agents to N tools meant building and maintaining M-times-N bespoke integrations. MCP replaces M-times-N with M-plus-N — each tool exposes one server, each agent platform ships one client, and they plug together. Taskade contributes both halves of that equation, with a different piece of the product behind each one.
The Two Roles, and How Taskade Fills Each
On the server side, direction of travel is external → Taskade. The external client holds the tokens, and the tools on offer are Taskade's: reading your projects, tasks, agents, and automations, creating projects and agents, and editing your Taskade Genesis app source. The catalog stood at 18 tools in July 2026 and keeps growing.
On the client side, direction of travel is Taskade → external, and the piece that travels is an automation step rather than the agent itself. Register a server once, list its tools, call the one you want, and pipe the result into the rest of the flow. An agent contributes the judgment — read the project, decide what to do — and hands the call to the step.
What Reaches Your Other Systems Today
| Path | What it does | Where it lives |
|---|---|---|
| MCP Client step | Lists and calls tools on any remote MCP server | Automation steps, every plan |
| 100+ integrations | Bidirectional — triggers pull events in, actions push data out | Automations and agent steps |
| 34 built-in agent tools | Web search, code execution, file analysis, persistent memory | Every AI agent |
| Custom slash commands | Your own repeatable prompts and procedures, per agent | Agent settings |
| HTTP request and webhooks | Call any REST endpoint, receive any callback | Automation steps and triggers |
| Taskade as MCP Server | Lets Claude Desktop, Cursor, or VS Code read your workspace | Every paid plan |
Between them, these cover the jobs teams reach for MCP to solve: getting a Notion page into a Taskade project, opening a Linear issue from a triaged ticket, pulling GitHub status into a dashboard. If the service publishes an MCP server, the MCP Client step calls it directly. If it does not, the integration catalog and HTTP steps get you there anyway.
One boundary worth stating plainly: an agent cannot reach a remote MCP server by itself. The call lives in an automation, and the agent feeds it or reads its result. That is a difference in where the connection is held, not in whether you can make it.
What the Client Role Means
Worth understanding as a protocol concept, because it is the same shape whether Taskade is the client or Claude Desktop is.
A client registers a server endpoint, authenticates, and reads the manifest that server publishes. Each tool arrives as a name, a description, and a JSON Schema for its arguments — the same shape as a native function call. From the model's side there is no distinction between a local tool and a remote one: it reads the description, decides to call it, and folds the observation back into its reasoning. That uniformity is the whole point of the standard, and it is why tool use generalizes so cleanly across products.
When you connect Claude Desktop to Taskade, you are watching exactly this happen — with Claude Desktop as the client and Taskade as the server. When an automation's MCP Client step lists a remote server's tools, you are watching it happen with the roles swapped. The mechanics are the same in either direction. Only the endpoints change.
How the Inbound Direction Is Secured
The hosted MCP server authenticates external clients over OAuth2 + PKCE — no password sharing, a Bearer token scoped to mcp, revocable per-session from your Taskade settings. Browsing is read-only and scope-enforced to the spaces your account can already reach; the only write surface is a Taskade Genesis app's source directory, and every source edit lands in your workspace activity feed. Full detail, including the tool-by-tool surface, is on Taskade as MCP Server.
Related Concepts
- Model Context Protocol — The standard
- MCP Client — What an MCP client is, in general
- Taskade as MCP Server — The inbound direction
- Tool Use — The pattern MCP tools plug into
- Function Calling — The wire format
- AI Agents v2 — What the built-in tools belong to
- Automations — Where integrations and HTTP steps run
- Integration Orchestration — How the working paths fit together
Frequently Asked Questions About the MCP Client Role
What is an MCP client?
An MCP client is the AI app side of the Model Context Protocol — the piece that connects to an external MCP server, reads the tools it publishes, and calls them during a task. Claude Desktop, Cursor, and VS Code act as MCP clients.
Can Taskade connect to external MCP servers?
Yes, from your automations. The MCP Client step registers a remote server, lists the tools it publishes, and calls any of them — on every plan, including Free, with your automation run allowance as the only ceiling. An agent cannot reach a remote server on its own, so let it hand the work to the step. The 100+ integrations, HTTP request steps, and the built-in agent tools cover everything that does not speak MCP.
Which direction of MCP does Taskade support?
Both. Taskade publishes your workspace at https://www.taskade.com/mcp so external MCP clients can browse projects, agents, and automations and edit Taskade Genesis app source — that side needs a paid plan, and Taskade as MCP Server has the setup. In the other direction, an automation's MCP Client step calls tools on servers you point it at, on every plan.
Is this the same as Taskade integrations?
They overlap. Integrations are connections Taskade builds and maintains — 100+ of them, bidirectional, with triggers that pull events in and actions that push data out. The MCP Client step is the generic version: instead of a connector Taskade wrote, you point at any server that speaks the protocol. Reach for an integration when one exists, and the MCP step when the service publishes an MCP server instead.
How do I connect Notion or Linear to a Taskade agent?
Two paths, both through automations. Notion and Linear have direct Taskade integrations — connect the account once and the actions become available as steps. If you would rather use their MCP servers, the MCP Client step points at either one and calls its tools. In both cases the agent works alongside the automation rather than making the call itself. For a service with neither, the HTTP request step calls its REST API directly.