score_output

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

No annotations are provided, so the description carries the full burden. It discloses that the tool uses a 'heuristic rubric' and returns a 'heuristic score and breakdown', and clarifies it is not definitive. However, it lacks details on side effects, authorization needs, or rate limits. The behavioral insight is partial but adequate for a non-destructive evaluation tool.

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, well-structured paragraph. It front-loads the core purpose, follows with usage guidance, provides technical input instructions, clarifies limitations, and mentions output. Every sentence earns its place with no redundancy or 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?

No output schema exists, so the description should explain the output format. It mentions 'Returns a heuristic score and breakdown' but does not detail the breakdown structure or where the rubric originates. Given the tool's role in evals/demos and many siblings, the description is adequate but lacks output specifics that would help an agent use the result effectively.

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 both parameters (before_text, after_text) as plain strings. The description restates this ('Pass before_text and after_text as plain strings') and adds minor context ('Revised analysis text...' and 'Original analysis text...'). This adds little beyond the schema, achieving the baseline of 3.

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 it 'Score a before/after pair of agenda-analysis text' and specifies the evaluation criteria (structure, evidence labeling, uncertainty handling, decision-readiness). The name and description align well. However, it does not explicitly differentiate from sibling tools like 'analyze' or 'validate', though the pair-input nature is distinctive.

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 says 'Use in evals or demos to compare whether an Agenda Intelligence rewrite improved...', providing clear context. It also explicitly states what it is not: 'not a factuality, legal, compliance, or investment judgment.' This helps an agent know when not to use it. It does not name specific alternatives among siblings, but the guidance is sufficient.

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