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 and editing projects and the tasks inside them, building and questioning agents, and editing your Taskade Genesis app source. The catalog keeps growing with each release.
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 |
| 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 an MCP Client Works, Step by Step
The official MCP architecture overview defines three participants. The host is the AI application, such as Claude Code, Claude Desktop, or Visual Studio Code. The host creates one client for each server it connects to, and each client keeps a dedicated connection to its server. A server is any program that provides context to clients, and it can run locally or remotely.
- Discover. The client asks the server what it supports. In the current spec version (2026-07-28), this is the
server/discoverrequest. - List. The client calls
tools/list. Each tool arrives with a name, a description, and a JSON Schema for its input. - Call. When the model picks a tool, the client sends
tools/callwith the arguments and receives the result. - Refresh. A server can notify a client that its tool list changed. Change notifications are opt-in.
The messages use JSON-RPC 2.0. Two transports exist: stdio for local servers, and Streamable HTTP for remote servers, which supports bearer tokens and recommends OAuth. Servers expose three kinds of building block: tools (actions), resources (context data), and prompts (reusable templates). Protocol details change between spec versions, so read the current specification before you build your own client.
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. A personal access token works on the same endpoint for a client that cannot open a browser. Access is scope-enforced to the spaces your account can already reach, and the client acts within your role. It can create and edit projects, tasks, and agents, and edit a Taskade Genesis app's source. Authoring an automation is not exposed, and every source edit lands in your workspace activity feed. Full detail, including the tool-by-tool surface, is on Taskade as MCP Server.
Common Mistakes
- Expecting an agent to call a remote MCP server directly. The call lives in an automation step. Let the agent decide and the step act.
- Mixing up the two directions. The MCP Client step reaches out from Taskade. The hosted server at
https://www.taskade.com/mcplets outside clients reach in. - Skipping a simpler path. If a service has a Taskade integration, use it. Use the MCP Client step when the service publishes an MCP server and no integration exists.
- Granting more than you need. Give a connected client access only to the spaces and scopes it needs, and revoke tokens you no longer use.
Connection to Taskade
MCP is one of the outer connections in Workspace DNA. The /connect/dna map places integrations, MCP, webhooks, and HTTP APIs on the outer ring. Agents and Taskade EVE decide what to do, and automations do the work. For the setup steps, see MCP Server and Automation Actions in Learn.
What You Would Build in Taskade
Build a weekly digest. A schedule trigger starts an automation. An MCP Client step pulls open issues from a tracker that publishes an MCP server. An AI step summarizes them, and a final step writes the digest to a Taskade project that your team already reads. Then describe the dashboard you want on top of it.
Describe yours and build it free →
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
- Agent Orchestration - How agents and steps divide work
- Multi-Agent Teams - Teams that hand work to automations
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.
What is the difference between an MCP host, client, and server?
The host is the AI application. The client is the connection object the host creates for each server. The server is the program that provides tools, resources, and prompts. One host can run many clients at once.
Does Taskade MCP cost extra?
The MCP Client step is part of automations and works on every plan, within your automation run allowance. The hosted server needs a paid plan. See pricing.
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.