tools plus mcps, plus the generated submit_result tool that ends the run.
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:{"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
configurationerror. 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_toolsis 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_namespace—crmturnssearchintocrm_search. Write your prompt against the exposed name;allowed_toolsstill approves the server’s own names. Two attached servers sharing a namespace is refused when you save.
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 asprovider_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:
Next
Running and runs
Run a task and read what its tools actually did.
MCP servers
Approval, namespacing and the tools an integration exposes.