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

With no annotations, the description carries the full behavioral burden. It helpfully discloses that data problems are reported separately and not treated as flags — a genuine output-semantics detail — but says nothing about permissions, cost, rate limits, or whether checks are exhaustive.

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 tight sentences, front-loading the core purpose before the flag list. The middle line is telegraphic to the point of being a fragment, but nothing is 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?

An output schema exists, so return values need not be explained, and the flag list plus the data-problems caveat cover the essentials. Missing are the parameter-interaction rules (both optional/none supplied) and any routing versus the sibling analysis tools, leaving gaps for a zero-coverage schema with no annotations.

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 two parameters, so the description must compensate. It does clarify the scope of each parameter (ocid = one tender, buyer = all of that buyer's awards), which adds meaning, but it never states whether both can be combined or what happens when neither or both are supplied (both are optional with null defaults).

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 concrete capability — integrity/red-flag checks — and enumerates the specific patterns detected (single bidder, direct method, signed before close, just-below-round amounts, repeat winners), which is well beyond a tautology. It distinguishes itself implicitly from siblings like price_benchmark or supplier_profile, but never explicitly routes against them.

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 'for one tender (ocid) or all awards of a buyer' implies the two operating modes, which is some usage context. However, there is no guidance on when to prefer this over price_benchmark or supplier_profile, no exclusions, and no statement about what triggers the buyer-wide mode.

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 no annotations, the description carries full burden and does reasonably well: the leading 'WRITE.' signals a side-effecting mutation, it states the concrete output artifact (report.md), it discloses the human-approval gate (an auth-like requirement), and it notes each finding cites its OCDS record. It omits overwrite/error behavior and permissions details, keeping 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?

Front-loads the operation type ('WRITE.'), then purpose, then prerequisites in three short lines with no filler. The fragmentary line breaks cost it a little readability, but nothing is wasted.

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-value explanation is unnecessary, and the write/approval prerequisites are covered. However, for a mutation tool with zero annotations and 0% parameter documentation, the description should say more about what happens on write (overwrite, failures) and what the remaining parameters mean.

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, and it only partially does: 'approved flags in a case' loosely implies case_id and 'needs a named human approver' maps to approved_by. The title and summary parameters are undocumented in both schema and description, and approved_by is optional in the schema despite being framed as a requirement.

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?

Specific verb+resource: 'Build the committee report (report.md) from the approved flags in a case' names both the artifact and its input source. This is clearly distinct from siblings like file_flag or check_red_flags, though it never explicitly contrasts itself with them.

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?

States two concrete preconditions for use: flags must already be approved and a named human approver is required. It gives no explicit when-not guidance or alternative (e.g. what to do if flags are not yet approved), so it stops short of a 5.

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 no annotations, the description carries the full load and does well: it flags the write nature, the human-approval requirement, and the exact content conditions that cause rejection. It does not cover idempotency, duplicate-flag behavior, or what happens to case state after writing, which are the remaining behavioral gaps.

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-loads the two most important facts (WRITE, needs approval) in the first clause, then adds the field guidance and refusal rules without padding. The fragmentary phrasing around finding/evidence is terse but 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?

An output schema exists, so return values needn't be described, and the description covers the mutation/approval profile and rejection rules. The unresolved gap is the four undocumented parameters, including flag_type, whose semantics and allowed values are unavailable anywhere in the definition.

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% across six parameters, so the description must supply meaning for all of them. It explains only two ('finding' = the pattern in one sentence, 'evidence' = the numbers behind it), leaving ocid, case_id, flag_type, and approved_by entirely undocumented in both places.

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: 'Add one flag to the case file,' which is concrete and tells the agent this creates an artifact rather than querying one. It does not explicitly distinguish itself from the sibling check_red_flags, but the write framing is clear enough to separate the two in most cases.

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 hard precondition ('needs human approval') and explicit refusal conditions (unknown ocid, wording that decides the award or declares wrongdoing), which functions as meaningful when-not guidance. It never names an alternative tool such as check_red_flags, so routing among siblings is left partly to inference.

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?

No annotations exist, so the description carries the full burden. It usefully discloses a data-sufficiency behavior ('says so when under 5 comparables'), but omits anything about read-only safety, permissions, or comparability constraints. Its enumeration of return fields is largely redundant given an output schema exists.

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 sentences with no filler, and the core action is front-loaded ahead of the return-value and caveat details. Every clause adds 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?

For a single-parameter, annotated-free tool with an output schema, the description covers purpose, output shape, and a meaningful edge-case behavior. The remaining gap is the unexplained 'ocid' parameter, which neither the schema nor the description clarifies.

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% and the single 'ocid' parameter is never explained in the description. The phrase 'one tender's award value' only loosely implies the identifier's role; format, requiredness, and lookup semantics are left entirely to inference.

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 ('compare one tender's award value with similar awards') and pins the comparison scope to 'same item group and category'. This is enough to separate it from siblings like search_awards or supplier_profile, though it never explicitly names which sibling to prefer over check_red_flags, whose outlier-detection role overlaps.

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 verb ('compare one tender's award value') but there is no explicit when-to-use, when-not-to-use, or named alternative among the sibling tools. The only conditional guidance is a data caveat, not a routing rule.

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?

No annotations are provided, so the description carries the full burden. It does disclose one genuinely useful trait: on no matches it 'explains why and suggests close buyer names,' which tells the agent how to interpret empty results. It says nothing about pagination behavior, the meaning of limit, or result-set size, which is a real gap for a search 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?

Front-loads the core statement and the optionality note, then gives a compact per-parameter glossary with no filler. Slightly clipped phrasing in the last sentence ('explains why') costs it a point but nothing is wasted.

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-value documentation is not required, and the description covers nearly every input including enum vocabularies. Missing annotation coverage and the undocumented 'limit' parameter are the only substantive holes for an 8-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 description coverage is 0%, so the description must compensate and largely does: it defines buyer ('part of the buyer name'), item ('word from the title or item group'), supplier, date format (YYYY-MM-DD signing date), and supplies enum values for category (goods|services|works) and method (open|selective|direct) that the schema does not contain. Only 'limit' is left undefined.

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 with scope: 'Find published awards.' An agent immediately knows this is a search over award records. However, it never distinguishes itself from siblings like price_benchmark or check_red_flags, so sibling routing must be inferred.

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?

'All filters optional' is the only usage hint, and it describes cardinality rather than when to reach for this tool over its siblings. There is no statement of when-not to use it or which alternative handles related questions.

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 no annotations, the description carries the full burden, and it does disclose two non-obvious traits: input is resolved by fuzzy matching (so the name need not be exact), and output is restricted to company records with no personal details. It stops short of confirming read-only status, coverage limits, or rate/cost behavior.

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 sentences with zero filler. The output contents are front-loaded and the two caveats (fuzzy matching, no personal data) follow immediately. Every clause 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?

An output schema exists, so return values needn't be explained, and input semantics are covered. The remaining gap is temporal scope — win rate, buyers, and single-bidder wins are period-dependent, and the description never states the time window covered.

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% for the single 'name' parameter, so the description must compensate — and it does, specifying that matching against the supplied name is fuzzy rather than exact. That is the key semantic an agent needs, though no example format or minimum-length guidance is given.

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 (Profile) and resource (supplier company), then enumerates exactly what the profile contains: bids listed, awards won, win rate, buyers, single-bidder wins. This distinguishes it implicitly from siblings like search_awards (raw award lookup) and check_red_flags (anomaly detection), though no sibling is named explicitly.

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 only implied — an agent can infer you call this to get an aggregate picture of one company, versus search_awards for individual records. There is no explicit when-to-use, when-not-to-use, or named alternative among the five siblings, and no stated prerequisites.

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