The Ultimate Critic

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

Annotations indicate modification (readOnlyHint false) and potential side effects (openWorldHint true). Description adds context on credit consumption, routing behavior, and policy-based release, complementing annotations without contradiction. No contradictions found.

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?

Two sentences with clear front-loading: first explains purpose, second adds behavioral notes. No fluff, but the second sentence could be more structured. Overall concise and well-organized.

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?

Despite complex nested schema and no output schema, description misses key details: how to specify evaluation criteria (intent, rubric), output format details, evidence policy, and what happens on insufficient_evidence. Incomplete for a tool with such complexity.

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 0%, yet the description provides minimal parameter details. Only mentions artifact field briefly ('Use content for text/JSON and files for evidence or image payloads'). Does not explain domain, intent, rubric, output_format, evidence_policy, etc. Insufficient compensation for lack of schema descriptions.

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?

Description clearly states 'Evaluate an AI-produced artifact against its task, requirements, constraints, and evidence.' Uses specific verb 'evaluate' and resource 'artifact', and distinguishes from siblings (preview, quote, usage) by focusing on evaluation.

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?

Description mentions credit usage and routing of findings (fail to repair, insufficient evidence collection, pass release), but does not explicitly state when to use this tool versus alternatives or provide exclusions. Usage is implied but not comprehensively guided.

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 indicate read-only, idempotent, and non-destructive behavior. The description adds important context: the preview is not retained, makes no external model call, and does not consume paid entitlement. This goes beyond the annotations by specifying resource usage and retention policy.

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 single sentence of 20 words, front-loaded with the verb 'Run'. Every word serves a purpose, no redundancy or fluff. It is highly concise and easy to parse.

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?

Given the tool has 4 parameters with 0% schema description coverage and no output schema, the description is incomplete. It does not explain what the 'task' parameter does, how 'requirements' are used, or what the return value looks like. The agent is left with insufficient information to correctly invoke the tool without additional context.

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 0% with no parameter descriptions. The description mentions 'text, code, or JSON artifact' and 'narrow no-key deterministic preview', but does not explain what 'task' or 'requirements' parameters mean. It adds minimal semantic value beyond the parameter names themselves.

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 clearly states the tool runs a 'narrow no-key deterministic preview' on non-sensitive artifacts of type text, code, or JSON. It distinguishes from sibling tools by noting it makes no external model call and does not consume paid entitlement, implying it is a limited free preview compared to tuc.evaluate or tuc.quote.

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 description implies usage for quick, non-sensitive previews without cost or retention, but it does not explicitly specify when to use this tool versus siblings like tuc.evaluate. No exclusions or explicit alternatives are given, leaving the agent to infer usage context.

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 indicate readOnlyHint, idempotentHint, and non-destructive behavior. The description adds that it returns tier and charge, which is useful beyond annotations. No contradictions.

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?

Single sentence that directly states purpose and differentiation. No filler or redundant information.

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?

Given the complex nested input schema and no output schema, the description is too brief. It omits how to structure the request, what fields are required, or expected return format. Adequate only for the simplest use cases.

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 0% (based on context signals) yet the description provides no details about the input parameters. The agent must rely solely on the schema, which lacks top-level descriptions. The description should compensate but does not.

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?

Description clearly states the tool returns package tier and credit charge, distinguishing it from an actual evaluation. The verb 'Return' is specific and the mention of 'standard, extended, or full package tier' adds precision.

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 phrase 'without running an evaluation' implies when to use this tool versus alternatives like tuc.evaluate. It provides clear context but does not explicitly list when not to use or name sibling tools.

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; description adds specificity by naming the data returned ('review-credit usage and entitlement limits') and reinforces read-only nature.

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?

Single sentence, no wasted words, front-loaded with action and resource. Perfectly concise.

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 parameterless, read-only tool with extensive annotations, the description fully covers what it does and returns, with no gaps.

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?

No parameters exist, so baseline 4 applies. Description adds no parameter information, which is unnecessary given 100% schema coverage and zero parameters.

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 uses specific verb 'Return' and resource 'review-credit usage and entitlement limits', clearly distinguishing from siblings like tuc.evaluate or tuc.quote that imply submission or action.

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 states 'without submitting work', indicating this is a read-only check for monitoring usage before proceeding with other tools. No explicit alternatives given, but the clear distinction suffices for most agents.

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