Plith Rigor

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

Annotations cover only the safety profile (readOnly=false, idempotent=false, openWorld=true, destructive=false); the description goes well beyond by disclosing the credit/billing model (prior_workflow_id 'is charged as a new run at the normal quote'), the 402 max_budget_exceeded refusal that fires before anything runs or is charged, delivery semantics (SSE/webhook/polling, with polling the MCP default), and the execution-mode fallbacks. These are the operational traits an agent most needs and none are in the annotations.

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?

Front-loaded with the action, then the rigor_plan prerequisite, then the direct-execution branch — a sensible ordering. However, the execution-mode sentence is a very long run-on packing several edge cases, and the direct/output_contract guidance largely duplicates what the schema fields already say, so a bit of it does not earn its place.

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?

With an output schema present the description needn't explain return values, and it correctly spends its length on routing, cost, delivery, and refusal behavior instead. Annotations, a fully documented 7-param schema, and this description together leave nothing an agent needs missing before invocation.

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 description coverage is 100%, so the schema already documents all 7 parameters, including the nested output_contract and delivery objects. The description restates the same guidance (direct execution, output_contract validation, delivery methods) rather than adding syntax, formats, or defaults the schema lacks. Baseline 3 applies when the schema does the heavy lifting.

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?

The opening states a specific verb+resource ('Execute a structured workflow end-to-end') and immediately scopes what the tool produces (solution designs, competitive analyses, governance documents) and how it routes work (classifies the task, selects a tool sequence, executes each step). It also distinguishes itself from the sibling rigor_plan by naming it as the free preview step. An agent can separate this from rigor_status/rigor_workflows without opening any schema.

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?

Explicitly instructs to call rigor_plan first to preview sequence and cost before committing credits, and gives an explicit branch: for atomic work set preferences.execution='direct' with an output_contract. It also states fallback conditions (attachments or prior_workflow_id force standard execution). This is when-to-use, when-not, and alternative-selection guidance all in one.

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

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

Annotations already establish readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond that: it explicitly does not execute, it is free with no credits charged, and allowed_modes in the response signals execution eligibility — cost and side-effect behavior an agent needs.

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 short sentences, front-loaded with the core action and scope, then the classification/selection behavior, then the eligibility signal, then cost. Every sentence earns its place with no padding.

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 planning tool with an output schema, the description covers the essentials: what it produces, that it does not execute, cost, and how to read execution eligibility. It stops short of explaining the follow-up path to rigor_execute, a minor gap given the rich schema.

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 description coverage is 100% and the nested parameters (task_type, preferences, output_contract, prior_workflow_id) are thoroughly self-documented in the schema. The description adds no parameter-level detail beyond the response field allowed_modes, so the baseline 3 applies.

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 and resource ('get a structured workflow plan with per-step cost estimates') and delineates scope precisely: classifies, selects a framework sequence, and returns the plan 'without executing anything' — which cleanly separates it from the rigor_execute sibling.

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?

The opening phrase 'Before executing a complex task' gives clear temporal context for when to call it, and the non-execution clause implies the plan-then-execute handoff. However, it never names rigor_execute (or rigor_status/rigor_workflows) as the alternative, so the routing is implied rather than explicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety bar is low. The description adds real value beyond that by disclosing what the call surfaces (progress, step results, full deliverable once complete) and that it is the retrieval half of a polling pattern.

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?

Three short sentences, zero filler, with the purpose front-loaded and the usage rule last. Every sentence earns its place.

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 single-parameter, read-only status tool with an output schema and full schema coverage, nothing an agent needs is missing. The polling-lifecycle context is supplied and return values are covered by the output schema.

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 100% and the single workflow_id parameter already documents its origin and 'wr_xxx' format. The description adds no parameter-level detail, so the baseline of 3 is appropriate.

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 ('Check') and resource ('status of a running or completed Rigor workflow'), and names the sibling it depends on (rigor_execute). An agent can distinguish this polling/status tool from rigor_plan, rigor_workflows, and rigor_execute without opening any schema.

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 a clear triggering condition: 'Use after rigor_execute with polling delivery to retrieve results.' That is enough to route correctly, though it does not state when NOT to use it (e.g. synchronous delivery, or if the workflow ID is unknown).

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description goes beyond annotations by disclosing that it lists and searches workflows, returns per-workflow status/progress/capacity usage/available actions, and supports filtering/pagination. It also reveals the tool surfaces data that could be used to infer concurrency limits and find prior work, which is useful context. It does not claim any side effects and does not contradict annotations.

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?

The description is a compact paragraph that front-loads the core function, then lists returned data, then gives use cases, then a sibling-routing tip. Every sentence contributes either scope, use-case, or navigation guidance. There is no repetition of schema details and no fluff.

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?

The tool is a read-only list/search operation with an output schema, full parameter docs, and strong annotations. The description covers why the tool exists, what it returns, and how to route to rigor_status. There is no missing information needed for an agent to select and invoke it safely and correctly.

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 100%, so all nine parameters are already documented well, especially q which has a detailed substring-matching explanation. The description adds meaning by framing the q parameter's practical purpose (find prior work on a subject before commissioning it again) and framing the tool's overall filtering/pagination behavior. It also highlights status as a filter relevant to identifying stuck workflows, which complements the schema's parameter list.

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?

The description names a specific verb (list/search), a specific resource (Rigor workflows), and enumerates the returned fields (status, progress, capacity usage, available actions) plus pagination and filtering. It clearly distinguishes itself from siblings like rigor_status by positioning itself as the workflow-level discovery tool and telling the agent to pair a q hit with rigor_status for deliverable reads, and differs from rigor_execute/rigor_plan which create/run workflows.

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?

It states explicit use cases: monitor workflow state, understand concurrent limit usage, identify stuck/completed workflows, and find prior work via q before commissioning it again. It gives a concrete routing rule: pair a q hit with rigor_status to read the deliverable. It does not explicitly say when not to use it, but the openWorldHint:false and the clear scope make the guidance strong and actionable.

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