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 describes the return data but does not explicitly state that the operation is read-only, nor does it mention error handling, rate limits, or authentication needs. The read-only nature is implied but not confirmed, leaving some gap for a tool with zero 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?

Two sentences, front-loaded with the core purpose, followed by usage context. No filler or repetition. Every word 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 simple single-parameter tool with no output schema, the description covers purpose, when to use, and what is returned. It does not mention edge cases like invalid slugs or partial data, but these are not critical given the simplicity. The explicit workflow context makes it sufficiently 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?

Schema coverage is 100%: the 'slugs' parameter is fully described in the schema (list of 2-5 slugs, type, examples). The description adds no new parameter semantics; it only restates the agent context already present in the schema. Baseline 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?

The description clearly states the tool's function: 'Head-to-head trust comparison of 2-5 Hlido-reviewed agents.' It specifies the exact outputs (Laddoo score, tier, dimension scores, claim verdicts) and distinguishes it from siblings like find_trusted or recommend by focusing on direct comparison after shortlisting.

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 explicitly tells when to use it: 'once you've shortlisted candidates (via find_trusted, find_similar_agents, or recommend) and need a direct comparison.' It names specific alternative tools and implies when not to use it (before shortlisting).

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 provided, the description carries the full burden. It discloses that it pulls from the published scorecard, returns per-claim verdicts, evidence snippets, and a synthesis, and explains dimension filtering behavior. It does not explicitly state read-only/no side effects, but the language implies a non-destructive read 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?

Three sentences, front-loaded with the core purpose in the first sentence. Each subsequent sentence adds useful detail (evidence source, parameter behavior, output format) without 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?

For a two-parameter tool with no output schema and no annotations, the description covers purpose, input semantics, and output format. It explains the dimension enum, the behavior when omitted, and the verdict values returned, making it complete enough for an agent to invoke 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?

The schema already documents slug and dimension (100% coverage), but the description adds the specific allowed dimension values (reliability, transparency, integration, security, evidence) and clarifies that omitting the dimension returns the full picture, going beyond the schema's generic 'optional dimension filter'.

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 provides a structured natural-language explanation of why a Hlido-reviewed agent has its current score, pulling claim-by-claim evidence from the scorecard. This specific verb+resource combination distinguishes it from siblings like get_scorecard (raw scorecard) and verify_claim (verify individual claims).

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 clear context on when to use: to obtain an explanation of an agent's score. It also provides specific guidance for the dimension parameter (list of valid values and omit for full picture), but it does not explicitly name alternative tools or state when not to use it, so it lacks explicit 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by explaining the semantic search mechanism, the ranking by embedding similarity, and the exact fields returned in each result. While it doesn't disclose potential rate limits or lack-of-results behavior, the core read-only nature and output structure are adequately covered.

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 yet comprehensive, containing only two sentences. The first sentence front-loads the purpose and output; the second gives a usage directive and a comparative alternative. Every sentence earns its place without redundancy.

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 there is no output schema, the description compensates by explicitly listing the return fields (Laddoo score, evidence_tier, review URL). It also provides a concrete task example. The main gap is not addressing edge cases like zero results or handling of min_score, but for a semantic search tool this is a minor omission, and the description is otherwise 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?

The input schema already covers all three parameters with descriptions (100% coverage), so the description adds little beyond what the schema provides. The example in parentheses ('I need an agent that can refactor TypeScript...') illustrates the description parameter but doesn't clarify top_k or min_score further. This meets the baseline for high schema coverage.

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 starts with a specific verb phrase 'Semantic search over Hlido's review corpus' and clearly states what it returns: top-N agents ranked by embedding similarity with Laddoo score, evidence_tier, and review URL. It also distinguishes itself from the sibling find_trusted by noting it is 'much better than substring matching', making the purpose unmistakable.

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 explicitly states when to use it: 'Use this when you have a task in mind and want Hlido's recommendation'. It also provides an alternative by comparing to find_trusted ('much better than substring matching via find_trusted'), which effectively advises when not to use the alternative. This satisfies the explicit when/when-not/alternatives criterion.

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 burden of behavioral disclosure. It reveals return contents ('each with its Laddoo score, tier, and review URL'), ranking by trust, and the minimum-tier filtering behavior, implying a read-only operation. It doesn't mention pagination or how trust is calculated, but the core behavior is transparent.

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 three sentences, each earning its place: purpose, return details, and usage alternatives. It is front-loaded with the main purpose and contains no filler.

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?

Even without an output schema, the description explains what the response includes (agents with score, tier, review URL) and how results are ranked. It could add a bit more about the trust ranking semantics, but for a read-only discovery tool, it covers the necessary context sufficiently.

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 the schema already documents all three parameters clearly. The description adds the nuance that 'need' is a free-text, keyword-based query and contrasts it with structured filters, but this is marginal beyond the schema. Baseline 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?

The description clearly states the tool discovers Hlido-reviewed agents matching a free-text need, ranked by trust. It explicitly distinguishes from siblings by naming alternatives (find_similar_agents and recommend), which sharpens purpose.

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 provides explicit usage guidance: 'Use this for keyword/need-based discovery' and specifies when to prefer other tools: 'for semantic task-matching prefer find_similar_agents, and for structured constraint filters prefer recommend.' This directly tells the agent when to choose this tool over 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?

With no annotations provided, the description carries the full transparency burden. It discloses that the tool can return statuses like 'not_yet_bench_tested' and 'not_testable', and describes the data contained in the trace. This gives meaningful insight into the tool's behavior and limitations.

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 two concise sentences, front-loaded with the core action and content. Every sentence contributes useful information without 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?

For a simple 2-parameter fetch tool with no output schema, the description covers the purpose, usage context, possible return statuses, and the key contents of the trace. It is comprehensive enough for an agent to decide when to invoke it and interpret basic responses, though a bit more detail on the signed link format could be added.

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 description adds no new parameter-specific meaning beyond the schema. The schema already documents 'slug' and 'spec_version' with examples and default behavior, so the description offers no additional semantic value for 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 clearly states the action ('Fetch') and the specific resource ('behavioral evaluation trace for a Hlido-reviewed agent'), and lists the trace contents (per-task pass/fail, adapter, tier, signed link). This distinguishes it from sibling tools like get_scorecard or get_incidents.

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 provides an explicit use case: 'Use this when you need evidence that an agent's coding/task behaviour has been independently verified beyond marketing claims.' It also mentions edge cases (not_yet_bench_tested, not_testable) but does not explicitly name alternatives or when-not conditions, so it falls slightly 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 burden. It discloses the kinds of incidents, that they are published, and importantly warns that an empty list is not a reliability guarantee. It doesn't mention pagination, sorting, or side effects, but for a read-only fetch it is reasonably transparent.

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 first sentence is dense and informative, and the usage sentence is valuable. However, the middle sentence 'Filter by agent slug, severity, or category' is redundant with the schema and adds no value, so it's not maximally 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?

The tool has 4 optional parameters and no output schema, but the description explains what the incidents include (severity, evidence, vendor-response status) and provides a key caveat about empty lists. It doesn't describe return ordering or pagination, but overall the picture is complete enough for this simple fetch 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 100%, so baseline is 3. The description restates the filter options ('Filter by agent slug, severity, or category') but adds no semantics beyond the schema. No extra meaning, examples, or format details are provided.

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 fetches published incidents from a failure registry, with specific verb and resource. It distinguishes from sibling tools by focusing on incidents/failures, not scores or trust checks, and adds detail about real observed failures and self-reported incidents.

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 gives explicit when-to-use guidance: 'Use this before delegating to an agent to check for known recent failures.' It also clarifies interpretation of empty results, but does not name alternative tools or state when not to use it, so not 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 does the heavy lifting. It discloses that the returned scorecard is 'sanitized' and details the exact contents, including captured command/exit_code/duration for CLI/API tests. This gives behavioral context beyond the schema, though it doesn't explicitly state read-only semantics or note any auth/rate-limit considerations.

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 three sentences: the first states the core function, the second enumerates return contents, and the third gives the use case. Every sentence earns its place with no fluff or redundancy, and it is front-loaded with the most important 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 no output schema, the description fully explains what the tool returns (every claim, verdict, evidence quote, source surface, and test details) and when to use it. It also notes the schema version. This is complete for a simple single-parameter fetch tool, leaving no critical gaps about return values or purpose.

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%, with the slug parameter already described with an example. The description adds minimal parameter-specific detail beyond 'one Hlido-reviewed agent,' which restates the schema. The bar is therefore baseline 3, and the description does not significantly elevate it.

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 opens with a specific verb+resource: 'Fetch the full sanitized claim-vs-evidence scorecard for one Hlido-reviewed agent.' It clearly states what the tool does and distinguishes it from siblings like get_behavioral_trace or verify_claim by focusing on the claim-vs-evidence scorecard.

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 ends with 'Use this for agent-to-agent pre-flight evaluation,' which provides a clear context for when to use the tool. However, it does not explicitly name alternatives or state when not to use it, so it lacks the explicit exclusion seen in top-tier examples.

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 burden of behavioral disclosure. It states the tool returns ranked candidates with a why_match line, implying a read-like operation. However, it does not explicitly mention safety, authentication, or error behavior, but the return format and ranking behavior are adequately disclosed.

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-loaded with purpose, followed by parameters and usage. It is not overly verbose, though the parameter list could benefit from mentioning the nested structure for clarity.

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 no output schema, the description provides a reasonable return format (why_match line). The tool is moderately complex, and the description covers purpose, usage, and output. It lacks details on edge cases like empty results or max_results defaults, but overall it is sufficiently complete for an agent to decide.

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 top-level constraints parameter, and the description only lists parameter names without explaining the wrapping constraints object. This could mislead an agent into passing them as top-level parameters. The nested schema properties have descriptions, but the description does not compensate for the structural ambiguity.

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 performs constraint-driven recommendation across Hlido's reviewed agents, with a specific verb and resource. It distinguishes itself from sibling tools like trust_check by offering a filtered shortlist rather than one-by-one checks.

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?

Explicit usage guidance is provided: 'Use this when you have buyer constraints (budget, category, capability) and want Hlido's filtered shortlist instead of one-by-one trust_check calls.' This clearly indicates when to use this tool versus 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context about what happens after reporting: 'Hlido's R1 maintenance routine processes reports daily and fires re-tests via dispute-retest sub-agent.' This goes beyond the schema and gives the agent an understanding of the tool's side effects. It does not mention auth, rate limits, or response format, but for a reporting tool this is reasonably transparent.

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 three sentences, each earning its place: the first states the purpose, the second gives the usage trigger, and the third explains the post-submission behavior. It is front-loaded with the most critical information and contains no fluff or redundant details.

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 that there is no output schema and no annotations, the description adequately covers the tool's purpose, usage context, and what happens after a report is submitted. It does not describe the response the agent will receive, but for a simple reporting tool, the explanation of the daily maintenance routine and re-test workflow is sufficient to set expectations. A slight gap is the lack of any note about confirmation or idempotency, but overall it is complete enough.

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 input schema provides 100% coverage of all four parameters, including descriptions for each. The tool description does not add any additional parameter-level semantics beyond what the schema already states; it merely echoes the enum values. With full schema coverage, 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?

The description starts with a specific verb+resource: 'Report an issue with a Hlido review', and enumerates concrete issue categories (stale info, wrong verdict, missing claim, broken link) that align with the enum. This clearly distinguishes the tool from sibling tools like get_scorecard or verify_claim, which are about retrieving or verifying data, not reporting problems.

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 explicitly states when to use the tool: 'Use when calling get_scorecard or trust_check returns data you can prove is incorrect.' This names two specific sibling tools as triggers, providing clear context. It does not explicitly state when not to use it, but the condition is sufficiently scoped, so it earns a 4 rather than 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 fully discloses behavior: it returns a future scorecard URL + ETA, has rate limits (5/day anonymous, 50/day identified), and produces signed evidence + claim verification within ~24h (sooner if founder triggers manually). This gives the agent a thorough understanding of expected service 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?

The description is compact and well-structured: purpose is stated first, followed by usage trigger, return value, rate limits, and timeline. Each sentence provides high-value information without redundancy.

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 well-documented: it covers what it does, when to use it, what returns (URL+ETA), limitations (rate limits), and process (signed evidence, timeline). Given no output schema, the description adequately explains the return expectations. All necessary context is present.

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%, as every parameter (url, why, name, requester) has a description. The tool description does not add additional parameter semantics beyond the schema, 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?

The description clearly states the action ('Request that Hlido audit'), the resource ('a NEW AI agent that has no review yet'), and the context (no_review_found from trust_check or get_scorecard). It distinguishes itself from sibling tools by targeting new agents without existing reviews.

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 when to use: 'Use this when trust_check or get_scorecard returns no_review_found and you need a verdict before delegating to the unknown agent.' This provides a clear trigger and purpose, differentiating from alternatives without needing to name them.

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?

Describes outcome (confirmation with tracking, queued review, public scorecard). No annotations exist, so description carries full burden; it's transparent but doesn't mention potential queue times or rate limits.

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 efficient sentences. First sentence covers purpose and condition; second provides alternative. 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?

For a tool with 3 params and no output schema, the description adequately covers usage context, result, and alternative. Complete for agent decision-making.

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 baseline is 3. The description adds minimal extra meaning beyond the schema's parameter descriptions; it doesn't elaborate on usage or syntax.

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's purpose: 'Nominate a new AI agent for Hlido to review.' It specifies the exact scenario (when agent not in corpus) and distinguishes from sibling request_quick_audit.

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 tells when to use this tool: after trust_check returns no_review_found, and contrasts with request_quick_audit for immediate verdicts. Clear and actionable.

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. It explicitly discloses that this is a 'Preview' and that persistent subscriptions won't come until 'Wave 3.' It clearly states the current behavior: returns current state plus advisory polling instructions, and gives concrete URLs (RSS at /changelog/feed.xml or polling /data/attestations/{slug}.json). This is excellent transparency—the agent knows it's not a real subscription and what to actually expect.

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 only two sentences but packs important info: preview status, current behavior, specific endpoints, and usage intent. It is front-loaded with the key caveat, then gives actionable details. Every phrase adds value without redundancy.

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?

This is a somewhat unusual tool (a placeholder for future functionality). The description covers what it returns, how to act on it, and the limitation. It lacks detail about the exact shape of the 'current state' but given there's no output schema, it's still fairly complete. The preview nature is fully explained, and the provided URLs are enough for an agent to proceed.

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 baseline is 3. The description adds value by explaining the 'channel' parameter in terms of the actual polling options (RSS feed and JSON polling URL) and by noting that 'webhook is advisory only until Wave 3 ships.' This goes beyond the schema, which only lists the enum values, and helps the agent understand what each channel will return. Thus a 4 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?

The description clearly states what the tool does: 'returns the agent's current state plus advisory polling instructions' and indicates its purpose: 'register interest in being notified when a slug's verdict changes.' It is specific about the verb (returns, register) and resource (state, notifications), but the name 'subscribe' is somewhat misleading because it actually doesn't create a subscription yet. It does distinguish from siblings by focusing on interest registration rather than verification or scoring.

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 exactly when to use it: 'Use this to register interest in being notified when a slug's verdict changes.' This is clear context. It also mentions the preview limitation and tells users what they'll get instead of a persistent subscription. However, it doesn't provide explicit alternatives or when-not-to-use guidance, which would have pushed it to 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 burden and does well: it details return values (score, tier, verdict, summary, incidents), the no_review_found error case, and the quick nature of the query. It lacks explicit read-only confirmation or rate limits but provides substantial behavioral context beyond the schema.

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 sentences, front-loaded with purpose, then usage guidance, then error handling and follow-up. Every sentence earns its place with no repetition or filler.

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 no output schema or annotations, the description covers core functionality, expected outputs, error condition, and alternatives. The tool is simple (2 params, no nested objects), and the description provides all needed invocation 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 coverage is 100%, so baseline is 3, but the description adds meaning: it clarifies agent_or_url accepts a Hlido slug or product URL and that URLs are matched to the closest reviewed agent. It also explains that use_case tailors the verdict, enriching the schema definitions.

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 verb ('returns') and resource ('the independent Laddoo trust score, tier, verdict, claim-verification summary, incidents'), and clearly distinguishes itself from siblings by positioning as 'the core Hlido trust query' and naming alternatives like get_scorecard and request_quick_audit for follow-up use 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?

Explicitly instructs when to call: 'Call this FIRST — before delegating to, installing, or relying on another agent'. It also provides exclusions and alternatives: if no_review_found, 'then call request_quick_audit', and for full evidence, 'follow up with get_scorecard'.

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 does well: it discloses the verdict values (PASS/FAIL/PARTIAL/UNKNOWN), the evidence snippet with source, and the honest null case with its meaning. It stops short of discussing permissions or side effects, but for a read-only fact-check this is adequate.

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 dense sentences: the first states purpose, the second explains return behavior and when to use. 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?

Since there is no output schema, the description must explain return values, and it does: verdict values, quoted evidence, source surface, and the null case. For a two-parameter tool, this is fully 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?

The schema already covers both parameters 100%, so the description adds little beyond the claim should be specific and in plain language—which the schema also says. Baseline 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?

The description uses the specific verb 'fact-check' and identifies the resource: one marketing/capability claim about an agent, tested against Hlido's independent testing. This clearly distinguishes it from broader tools like verify_transparency or trust_check.

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 provides clear context: 'Use this to validate a vendor's specific promise before you rely on it.' However, it does not explicitly name alternative tools or state when not to use it, so it is not a full 5.

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