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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, but the description adds important behavioral context: despite the 'write-back' framing, it clarifies that only text is built and nothing is sent. It also describes the exact note contents, helping the agent understand the output beyond the safety profile.

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 compact and front-loads the note's contents, with a short second sentence clarifying the no-send behavior. The first sentence is slightly indirect ('The note the CRM write-back would put'), but overall there is no wasted text.

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 rich annotations and the existence of an output schema, the description is largely complete: it explains what is generated, what it contains, and that no side effect occurs. The only notable gap is the absence of any parameter explanation for call_id, though the parameter name makes the intent obvious.

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?

The schema has one required parameter (call_id) with 0% description coverage, and the description does not mention call_id or explain its meaning. While the parameter name is self-explanatory, the description adds no semantic value beyond what the schema already provides.

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 states a specific action ('Builds the text only') and resource (the deal card note), and enumerates the note contents (verdict, flags, every score with quote, deal-field payload). It also implicitly distinguishes itself from the actual CRM write-back by clarifying that nothing is sent.

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 does not state when to use this tool versus alternatives such as submit_scores or score_call. It only implies preview usage through 'Builds the text only; nothing is sent,' but provides no explicit when-to-use guidance or alternatives.

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 destructiveHint=false, so the safety profile is covered. The description usefully adds the shape of the returned turns (n, speaker, text), but says nothing about auth, rate limits, or transcript completeness beyond what the output schema carries.

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 short, front-loaded clauses with no filler; the return shape and the usage hint both earn their place. It is terse rather than 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?

With an output schema present, return-value explanation is not strictly required, and the annotations cover safety, so the core need is met. Still, a retrieval tool with a 0%-documented key parameter and no routing guidance against list_calls or score_call leaves 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?

Schema description coverage is 0% for the single required call_id parameter, so the schema supplies no semantics. The description never mentions the identifier or its accepted form (ID vs name), leaving the agent to infer that the call's ID is the key, which is plausible but unconfirmed.

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 the resource (a single call) and its contents (numbered turns with n, speaker, text), which implicitly distinguishes it from the sibling list_calls. The retrieval verb itself is only implied by "get_call" and "One call," so it stops short of a full verb+resource statement.

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?

"Quote from these turns when scoring" gives an implied workflow context, linking this tool to scoring tasks. However, it never states when to use this versus list_calls or score_call, and offers no prerequisites or exclusions.

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?

The annotations already declare that this is a read-only, idempotent, non-destructive, closed-world operation, covering the safety profile. The description adds the default-version behavior and describes what the rules contain, but it does not add deeper behavioral traits such as error handling, pagination, or authentication requirements.

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 compact and front-loads the main purpose before listing the rule fields. It is efficient, though the field list could be slightly more structured for scanning.

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 simple read-only tool with rich annotations and an output schema, the description covers the core purpose, the default version behavior, and the key returned content. It is largely complete, with only minor gaps around version input semantics and explicit usage 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%, so the description must compensate. It explains that the version parameter defaults to the latest version, which adds useful meaning, but it does not clarify the expected integer format or what happens when an invalid version is supplied.

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 that the tool retrieves scoring rules for a version, and it enumerates the key fields returned (id, question, evidence, speaker, quote requirement). It does not explicitly differentiate from sibling tools, but none of the listed siblings overlap with this resource.

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 mentions that the latest version is used by default, which gives some context for the optional version parameter, but it does not say when to use this tool versus alternatives or under what conditions a specific version should be requested. There is no explicit when/when-not guidance.

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 and destructiveHint=false, so safety is fully covered. The description adds the useful fact that results carry scoring/verdict fields, but says nothing about ordering, pagination, or limits on a list operation.

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 compact sentences: the first declares what is returned, the second declares the filters. No filler and well front-loaded.

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?

An output schema exists, so return values need not be explained, yet the description lists them anyway and covers both filters despite 0% schema coverage. The only remaining gap is pagination/ordering behavior for a list tool.

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% – the parameters are bare 'Rep' and 'Scored' with no descriptions. The description compensates by clarifying that 'rep' is a name and 'scored' is a true/false selector, adding real meaning beyond the schema.

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+resource ('List calls') and enumerates the returned fields (date, rep, customer, turns, scored, verdict), so the agent knows exactly what it gets. It does not explicitly distinguish itself from the sibling get_call, so it stops short of a 5.

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 second sentence tells the agent which filters exist ('Filter by rep name and by scored=true/false'), implying when to reach for this tool versus an unfiltered pull. There is no explicit when-not guidance and no mention of the get_call sibling, so usage is only implied.

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 the read-only, idempotent, non-destructive profile, so the bar is lower; the description adds real behavioral rules beyond that: every rule and the total must reach min_agreement, and a rule without human labels cannot pass. It does not explain scoring cost, latency, or what a failing result looks like, so a 4 rather than 5.

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 dense clauses with no filler, front-loaded on what is measured before moving to the draft override and the pass constraint. It is slightly packed, but every sentence adds a distinct constraint.

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 describe return values, and the annotations cover safety. It covers the core evaluation semantics and the draft path; the only real gap is the meaning of scorer and rules_version for a 4-parameter tool.

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, but it only covers two of four parameters: rules_yaml (draft, unsaved evaluation) and min_agreement (the pass threshold). The scorer enum values and rules_version are given no meaning at all, leaving half the surface unexplained.

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 gives a specific verb and resource ('measure a rule set against the hand-graded calls') and enumerates the outputs (per-rule agreement, quote validity, pass/fail), which clearly separates it from read-only siblings like get_rules. It does not explicitly name an alternative tool, so it falls just short of the 5 bar.

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 the timing context ('before it ships') and a distinct mode of use ('Pass rules_yaml to test a draft rule set without saving it'), which is genuine when-to-use guidance. It stops short of naming alternatives or stating when NOT to call it.

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?

Adds real behavior beyond the annotations: 'claude' requires ANTHROPIC_API_KEY in the server environment, and the result goes through the same evidence guard as submit_scores and 'is saved only if it passes' — so a call may silently not persist. It does not address the idempotentHint=false implication (re-scoring the same call), which keeps it from a 5.

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 action and scope, then modes, then side effects, then routing. Dense and waste-free, though the quoted-keyword phrasing is slightly packed.

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?

An output schema exists, so return values need no explanation, and the description covers auth, persistence guard, and routing. The only gap is the unexplained rules_version parameter, a minor omission.

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%, so the description must carry the load. It explains the two scorer enum values and their differing auth/behavior requirements, which is the most important parameter, but says nothing about call_id or rules_version.

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+resource ('Score a call on the server') and immediately scopes it to headless/'nobody in the loop' runs, which separates it from the interactive submit_scores path. An agent can distinguish it from all siblings without opening a 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 an explicit usage condition (runs with nobody in the loop) and an explicit alternative for the other case: 'In a chat, prefer get_call plus submit_scores.' This is exactly the when-to-use vs when-not-to-use routing the dimension asks for.

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?

With annotations only covering the generic safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), the description carries rich extra context: validation is all-or-nothing ('the server checks every score before saving anything'), the exact failure contract (accepted=false with rejected[{rule_id, reason, hint}] and missing[]), quote matching semantics (case/spaces ignored, speaker must match, quote_required coupling), and the success payload (verdict flagged computed). This is exactly the beyond-annotations 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?

Front-loaded with the core action, then dense with genuinely load-bearing contract details; almost no filler. It is longer than average but the length is justified by atomic-validation and error-shape disclosure, and the single paragraph stays readable.

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 3-required-param mutation tool with annotations and an output schema, the description covers the failure contract, retry path, quote rules, and success signal, so return values need not be re-explained. The omission of what call_id/rules_version refer to and the lack of contrast with score_call keep it just short of complete.

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?

Top-level schema coverage is 0% for call_id, rules_version, and scores, but the description compensates heavily for the nested Score fields: quote must be verbatim from the named turn, turn must be spoken by the rule's speaker, true requires a quote and false requires an empty one, and rule_id corresponds to rules from get_rules. call_id and rules_version themselves are only implied (via get_call / 'the version'), leaving a small gap.

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 sentence states a specific verb+resource ('Submit one score per rule for a call') and the 'every rule of the version has to be present' requirement implies batch semantics that distinguish it from the near-twin sibling score_call. However, it never names or contrasts with that sibling explicitly, so the agent must infer the distinction from the sibling's name alone.

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 gives strong operational context: all rules of the version must be sent, a false score takes an empty quote, and on failure you 'fix those rules and send the full set again.' What's missing is any explicit routing guidance against the sibling score_call, so the agent is not told when this tool is preferred over a single-score alternative.

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 the full safety profile (readOnly, idempotent, non-destructive), so the description is free to add behavioral context instead. It does: every count lists the call ids it counts, and the report is scoped to scored calls plus unscored-call visibility. This is meaningful disclosure beyond annotations, though pagination/size behavior is unaddressed.

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?

Content summary is front-loaded in the first sentence, with the filter detail last. Two sentences, no filler, dense but readable. Slightly list-heavy, but every clause describes actual report content.

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, return structure needn't be spelled out, annotations cover safety, and a 2-param read-only report is low-complexity. The only real gap is the semantics of the 'rep' parameter, so completeness is high but not perfect.

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%, so the description carries the burden. It compensates for 'since' by giving the format (since=YYYY-MM-DD) and states both params act as filters, but it says nothing about what 'rep' accepts (name, email, id), leaving one of two params underspecified.

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 resource (a team-level report over scored calls) and enumerates its exact contents: rate per rule, per-rep table, at-risk calls with quotes, follow-ups, unscored calls. This distinguishes it well from list_calls, get_call, and score_call. It stops short of naming a sibling directly, so it lands at 4 rather than 5.

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?

Usage is implied by the enumerated contents (an agent can infer this is the aggregate 'team overview' tool rather than a single-call or write tool). However, no explicit when-to-use/when-not guidance or named alternatives are given, and the sibling tools are never referenced.

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