A task attaches tools and MCP servers the same way an agent does — by id, or defined inline in the same write. What the model can reach while a run is in flight is exactly tools plus mcps, plus the generated submit_result tool that ends the run.
Everything about building a tool — the schema, the description, the operation tree — is in tools. This page is only about what changes when the thing calling it is a task.

Attaching a tool

Only published tools can be attached. A tool with no published version is refused when you save the task, naming the tool. Publish it first — see testing and publishing. You can also define a tool inline, in the same request that creates the task:
An inline tool is not kept inline. It is created as a real tool, published as v1, and the stored config carries {"tool_id": "…"} instead — so it gets an editor, a test panel, a ToolCoPilot, run_tool and version history like every other tool. A name that already exists in the workspace is a 409; reference the existing tool by id, or rename this one.

A task never pins a tool version

Republishing a tool changes every task that uses it, immediately, with no step in between. There is no publish on a task to freeze anything at, so each attached tool resolves to its current published version on every run. That is defensible for a bounded job that nobody is waiting on, and it would not be for a live call — which is exactly why agents pin a tool version when they publish and tasks do not. Two consequences worth planning for:
  • A tool edit you publish while an email batch is drafting changes every row generated after that moment.
  • Deleting a tool, or rolling it back to no published version, does not fail the save on tasks that already reference it — it fails those tasks at run time, as a configuration error. See errors and limits.
tool_version is part of the tool-selection shape, so a task config will accept one. It is ignored: the run always resolves the current published version. Do not set it on a task.

Attaching an MCP server

mcps names an integration that holds the server’s credential, or defines a server inline. Only an MCP-capable integration whose status is active can be attached; a disabled one or one that needs reconnecting is refused when you save. Defining a server inline creates a custom MCP integration and stores its id, the same way an inline tool becomes a real tool. Everything about approval and namespacing is shared with agents and documented once, in MCP servers. The two facts that bite most often:
  • allowed_tools is approved on the integration, not on the task. Null means every tool the server offers. Narrowing it reaches every task and every published agent on the next turn, because that approval is live.
  • The model never sees a server’s raw tool names. Each is prefixed with the integration’s tools_namespacecrm turns search into crm_search. Write your prompt against the exposed name; allowed_tools still approves the server’s own names. Two attached servers sharing a namespace is refused when you save.
Every approved tool is described to the model on every round, so a large server narrows the model’s attention and lengthens each round. On a task the cost of that is tokens and seconds rather than a caller waiting, but it is still the difference between a run that picks the right tool and one that does not.

What a tool call costs, and where it shows

Talqing charges nothing per tool call. What a call costs is whatever it spends on your side: your own endpoint, your own MCP provider’s credits, and the tokens the model spends reading the result back — reported on the run as provider_cost. Each call appears in the run’s trace as one entry, with the tool’s name as the model called it (namespaced, for an MCP tool), the arguments it sent, the result it got back and how long the call took:
Workspace secret values are masked before the trace is stored, and long fields are cut and marked. See running and runs.
A metered provider is metered per run. A task attached to an enrichment or data provider spends that provider’s credits every time it runs — and an email batch runs the task once per row, so a 5,000-row CSV spends them 5,000 times. Check what one run costs at the provider before you point a batch at it.

Next

Running and runs

Run a task and read what its tools actually did.

MCP servers

Approval, namespacing and the tools an integration exposes.