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

Beyond the annotations (which only declare non-read-only, non-idempotent, non-destructive), the description adds valuable behavior: an asynchronous ticket is returned, accepted shards are recomputed redundantly by the coordinator, and jobs may expire. It does not cover whether resubmission is safe given idempotentHint=false, nor what happens to expired or partially completed jobs, leaving gaps on a mutation tool with no output schema.

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?

Five short, front-loaded sentences: purpose first, then constraints, then return/polling behavior, then caveats. The telegraphic style packs a lot in, though the parenthetical and slash-heavy phrasing takes a second read.

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?

For a 5-parameter mutation tool with no output schema and no schema descriptions, the description covers the return contract (a ticket), the follow-up tool, expiry risk, and workload/backend coupling. The main hole is the undocumented seed parameter and the missing semantics of samples sizing.

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?

With 0% schema description coverage, the description has to carry parameter meaning, and it does explain backend (CPU/CUDA), workload (pi vs schedule probe), and scenario_id (three discrete scenarios). However seed is never mentioned and the samples bounds (100 to 5,000,000) and their interaction with workload choice are absent, so half the parameter surface remains 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 two concrete workload families (public synthetic pi on CPU/CUDA, or one of three schedule scenarios on CPU only), which lets an agent distinguish the two submission modes immediately. It stops short of differentiating itself from likely siblings such as simulate_pi, so the agent must infer why to use the network path at all.

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?

Gives real usage constraints: no private data or custom code, CPU-only for schedule scenarios, and the expectation-setting caveat that no net speedup is claimed. It also routes the agent forward to get_network_job for polling. There is no explicit statement of when to prefer this over a local simulation, which keeps it from a 5.

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