Queue fixed public synthetic pi (CPU/CUDA) or one of three discrete schedule scenarios (CPU only). No private data/custom code. Returns a ticket; poll get_network_job. Coordinator recomputes every accepted shard; no net speedup claim. Jobs may expire.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | ||
| backend | No | auto | |
| samples | Yes | ||
| workload | No | pi_chunk_v1 | |
| scenario_id | No |
Changes observed during successful MCP inspections.
Input schema / properties / scenario_idAdded value: +{
+ "enum": [
+ "single_80_deadline_90",
+ "pair_60_40_deadline_100",
+ "pair_60_40_deadline_110"
+ ],
+ "type": "string"
+}Input schema / properties / workloadAdded value: +{
+ "default": "pi_chunk_v1",
+ "enum": [
+ "pi_chunk_v1",
+ "schedule_probe_v1"
+ ],
+ "type": "string"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond annotations by disclosing the async ticket model, the required polling flow, job expiration ('Jobs may expire'), and the important caveat that the coordinator recomputes every accepted shard with no net speedup claim. These are non-obvious traits an agent must know before invoking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences, front-loaded with purpose and scope, then return/polling, then caveats. Some clauses are telegraphic ('no net speedup claim') but each carries information and nothing is padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description explains the return value (ticket) and the polling mechanism, plus lifecycle caveats and scope limits. It is largely complete for a 5-parameter submit tool, with the main gap being the semantics of seed and samples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must carry the load. It maps the workload enum to the pi vs schedule modes and notes schedule scenarios are CPU only, which clarifies backend/workload/scenario_id relationships, but seed and samples are never explained, leaving some parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Queue') and resource ('fixed public synthetic pi ... or one of three discrete schedule scenarios'), and discriminates the two workload modes. It names get_network_job as the polling sibling, but does not differentiate itself from the broader set of siblings (e.g. simulate_pi).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'No private data/custom code' implies a when-not-to-use boundary, and 'poll get_network_job' implies the follow-up flow. However there is no explicit guidance on when to pick the pi workload versus the schedule scenarios, nor which sibling to choose for private/custom workloads.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.