Skip to main content
What the model is handed. 36 tools, five of which spend money. The server speaks MCP. Over a pipe it reads stdin; on the staging box it listens on an address inside the api’s network namespace and answers POST /rpc behind a bearer token. It holds no session and no database of its own: an owner is either pinned by the calling session or read off the chain. For every tool with its exact arguments and the description the model actually reads, see the tool reference.

​
The five that spend

Everything else reads, quotes, validates or saves. The list is short on purpose and each entry earned its place:
  • run_pipeline is the one verb. It starts, resumes or repeats: decided from the run rather than chosen, so there is one spending name for “make this plan run” instead of three. submit_pipeline and resume_run are gone, because a model holding several spending tools picks the wrong one, and on one measured day it picked wrong every single time it mattered.
  • start_chain and arm_schedule run a pipeline immediately, or make one fire unattended, for ever, with nobody present at the time.
  • place_order is arm_schedule with a price for a clock. It runs nothing when called and commits every fill after it, in bites, until the size is gone. That is spending on the only definition that matters: money moves later because of this call.
  • decide_firing can start a run that was refused. Its skip action does not spend, but one flag covers the tool, and erring towards withholding is the safe direction for a list whose whole job is to withhold.

​
What is deliberately not on that list

stop_run is absent, and so is cancel_order. Both end spending rather than start it, and this list is what withholds a tool until somebody presses Start. A person watching money move and unable to stop it from the conversation they are in is its own failure, and it happened: stopping was console-only, and the refusal they got told them to go there. The brake must not be behind the same gate as the accelerator. Ending a run is still governed: the owner is pinned by the session and cannot be named by the model, an author is required, and it refuses without a task id rather than guessing which run to end. What it is not is a spend. get_orders is absent for the same reason one level down: withholding it would leave somebody able to start an order and unable to see it.

​
Two locks, not one

Withheld at the server, not only at the client. Over a pipe, a client that did not ask for a spending tool could not be given it by anybody else: nothing else can reach the process. On a listening address that stops being true: the client’s request becomes a preference, and the guarantee has to live where the tool does. Gated on the way through. Every spending tool is wrapped by a spend gate that asks, before the call runs, whether this owner may make this move right now. It is a wrapper rather than a check in each handler because the check was in one handler, and the model walked past it three times, twice through a different tool and once by authoring a new task altogether. The gate is driven by the same list that does the withholding, swept over the registry the server actually serves. So a spending tool cannot be added without being gated: there is no line to forget to write, and a test fails the moment a tool the list names has no gate shape.

​
The list enumerates itself

The tool registry lives in one function so a test can read it. The names used to be written out in the tests as well, and that copy fell six tools behind the registry without anything noticing: including one spending tool, which meant the test meant to prove every spending tool is withheld was not checking the one that mattered most. A list that has to be updated in two places is a list that will not stay true. This is the repository’s standing rule, applied here to the one list where forgetting costs money.

​
The three tools to reach for first

The reference page has all 34; these three are the ones that change how a conversation goes. The first two answer whether a thing exists. The third answers what it does, what it costs, and what it does not do, and those are different questions that get asked as if they were one.

​
Why a plan is stated twice

validate_pipeline and save_pipeline both take the plan and a restatement of what each step moves, in decimal, with the symbol. A plan writes raw integer amounts and nothing in the document records what they were meant to be. So a plan whose every amount is a thousandfold too small is perfectly self-consistent and passes every other check there is. The second representation is the only thing that can catch it: two independent statements of the same intent, checked against each other, where a decimal-place error cannot be present in both. See Skills: writing-amounts is the skill that exists entirely because of this failure.

​
Where its answers come from

  • The same catalogue the api and the worker read. Without that, the tool server falls back to compiled tables while the api serves measured ones, and the two answer the same question two ways with nothing reporting it, which is how the model once confidently told a user there was no bridge, because one process was missing one environment variable.
  • The skill index, built before anything can ask a question, from Postgres where it can and from the files on disk where it cannot. The boot line says which, because “search got worse” and “search moved to the fallback” are the same symptom and only one of them is a database problem.
  • The chain, for anything about an account. There is nothing local to consult, and a cached owner would be wrong in exactly the way that matters; it would name whoever used to hold the account.

Related topics

Every toolSkillsFAQHow it worksDeFiLoops