Skip to main content
Glama

tool_run

Triggers a specific command from a store-registered tool, passing the declared parameters so the store validates and runs the operation.

Instructions

Run one command of a tool of this store - the working way to do a job the owner already provided for. Say the unit from tool_list, the command, and its parameters as that tool declares them. Not the same as shop_run: that one runs a module YOU wrote, past the storefront, and returns what it printed; this one calls a function the shop wrote, and the store checks the registry before it runs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
intoNoName of a job to gather this call into. Every table of the answer is appended to <into>.<table>.jsonl beside the file it lands in anyway, so a walk of many pages ends in one file instead of overwriting itself - and that file feeds the next tool straight from disk, since any parameter takes {"file": ...}. Appending is all it does and nothing ever sweeps these files: they are yours, so delete one when a job begins and again when the work on it is done. A bare name, no path.
unitYesThe tool as tool_list names it - the first word of its line, MELBIS_AGENT_CURRENCY.
debugNoAdd the queries of the module to the timing line: how many it ran and how long they took together. Ask for it when a call was slow - a tool that is slow and one that is talkative are different troubles.
filesNoFiles for a command that takes them - tool_list says which does. Each entry names a local path and the element it belongs to; the store lays the file down and the tool then does its own work on it. One call is one request and holds as many files as the php of the store allows - it says the number when a pack is too long. The list itself may be the entries, or {"file": "path to a jsonl"} with one entry per line, written by a script and never retyped by you.
paramsNoThe fields of the command, and a command that declares none takes no params at all. A field it did not declare is refused, so take them from tool_list. A field of type jsonl - a stream of rows - takes the rows themselves, or {"file": "path on this machine"} with one json row per line: then the rows travel straight from the file past you, and a load of hundreds costs you nothing to say.
commandYesOne command of the tool - tool_list marks the granted ones and says what each takes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv6.5.1

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

There are no annotations, so the description carries the disclosure burden. It does add useful behavioral context: the store checks a registry before running, and it explains how this differs from shop_run. However, it does not disclose return semantics, side effects, failure behavior, or permission requirements, which are important for an execution-style tool with no annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The definition is compact and front-loaded: the first sentence states the core purpose, and the second immediately distinguishes it from shop_run. The phrase 'the working way to do a job the owner already provided for' is slightly vague, but there is no meaningful waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 6-parameter executable with no output schema and no annotations, the description explains how to name units, commands, and parameters and points to tool_list. But it omits the tool's return format, failure behavior, and any session or ordering prerequisites, leaving an agent with gaps for a fully confident invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3 and the description is not required to compensate. The prose mainly restates what the schema already says: units come from tool_list, commands must be declared, and parameters may be passed as filenames. It adds little beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and object—'Run one command of a tool of this store'—and names the exact inputs: unit, command, and parameters. It is clearly differentiated from the sibling shop_run, which runs user-written modules instead, so an agent can tell the two apart without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context: this is the way to invoke a tool the store owner already provided, and it explicitly contrasts with shop_run. It also directs the agent to tool_list for valid units, commands, and parameters. It does not state broader exclusions or alternative conditions beyond the shop_run distinction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.