Ground Truth - Fresh Evidence for AI Agents

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds valuable context about the tool's limitations ('not proof of certification or legal sufficiency') and the types of signals it scans for, going beyond the structured fields.

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 concise sentences: the first states the action and purpose, the second lists specific signal types, and the third caveats limitations. Every sentence adds value with no waste, and the key information is 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?

For a simple one-parameter tool with a complete schema and output schema, the description provides thorough context: what it scans, what it looks for, and its limitations. No critical information is missing for an agent to select and invoke the tool 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 covers 100% of parameter descriptions, so the description doesn't need to elaborate on the 'url' parameter. The description mentions 'public' pages, which aligns with the schema description and adds minimal extra meaning, making a baseline 3 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 scans public security, trust, compliance, or legal pages for common enterprise buying signals, using a specific verb and resource. It distinguishes itself by specifying the compliance-posture-related use case and listing concrete signal types, standing out from sibling tools.

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 the tool ('before you claim a vendor supports a particular compliance posture') and notes it is a signal scanner, not proof. It does not explicitly name alternatives or exclusions, but the context is sufficient for an agent to infer appropriate usage.

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 description is exceptionally transparent: it discloses that exactly one live fetch is performed, enumerates precisely what is returned (HTTP status, content type, response time, redirect behavior, auth signals, rate-limit signals, sample), and explicitly undermines over-trust by stating that PASS only proves fetch success at check time. This goes well beyond the readOnlyHint, idempotentHint, and destructiveHint annotations and provides critical behavioral context.

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 concise and tightly structured: three sentences that front-load the purpose, list the return fields, and then state the limitations. Every sentence earns its place with no redundancy 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?

For a one-parameter tool with a rich output schema, the description is fully self-contained. It covers what the tool does, when to use it, what it returns, and its limitations. There is no notable gap that would confuse an agent invoking this 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?

The input schema fully documents the single 'url' parameter, including bare-domain normalization and http(s) requirement. The tool description adds no additional parameter-specific detail beyond what the schema already provides, 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 defines the tool's action ('Preflight an unfamiliar public URL or API') and what it returns (a PASS/WARN/FAIL verdict with HTTP status, content type, response time, etc.). However, it does not explicitly distinguish itself from the similarly-named sibling preflight_endpoint, which likely serves the same or nearly the same 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 gives clear usage context ('Preflight an unfamiliar public URL or API before an AI agent relies on it') and states important limitations (no validation of authenticated flows, POST side effects, JavaScript execution, or business logic). It does not explicitly name alternatives or exclusion criteria, but the context is strong enough for an agent to decide when to use 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?

Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds valuable behavioral context: results are cached for 5 minutes, and JavaScript-rendered, logged-in, or heavily obfuscated pricing details can be missed. This goes beyond the annotations without contradicting them.

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: purpose first, then usage context, then limitations and caching. Every sentence provides meaningful information with no fluff or repetition.

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's simple scope, the description fully covers what the tool does, its limitations, cache behavior, and return content. With annotations and output schema also present, this is complete for an agent to select and 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?

Schema coverage is 100% for the single url parameter, with a clear description. The tool description adds extra guidance: 'Prefer the specific pricing page, for example https://stripe.com/pricing, rather than a generic homepage.' This enriches the parameter semantics 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?

The description clearly states the verb and resource: 'Fetch a public pricing page and extract first-pass pricing signals.' This distinguishes it from siblings like compare_pricing_pages, which likely compares multiple pages, and check_endpoint, which is more generic. The purpose is immediately clear.

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 says 'Use this when you already have a likely pricing URL and need a quick live scan of visible page text.' It also lists exclusions: 'does not map prices to exact plans, normalize currencies, execute checkout flows, or guarantee that a price applies to a specific region or customer type.' This provides clear when-to-use and when-not-to-use 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?

Adds substantial context beyond annotations: 'returns per-package registry metadata in input order, with field availability varying by registry. Missing or unpublished packages return found=false. Registry responses are cached for 5 minutes.' This enriches the readOnly/idempotent/openWorld hints with specific 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?

Four sentences, each packed with distinct value: core action, use cases, return/missing behavior, caching. No fluff or repetition; 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?

Covers all essential context: what it does, when to use, when not to use, output behavior, and caching. With a rich output schema and strong annotations, the description is fully complete for the tool's 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 100%: both packages and registry are already well-described in the schema. The description only reinforces 'exact package names' without adding meaningfully new parameter-level information, so 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?

Clearly states the verb and resource: 'Compare two or more exact package names side by side using live npm or PyPI metadata.' It also differentiates from siblings by explicitly saying 'Do not use it to discover unknown alternatives,' which distinguishes it from tools like estimate_market.

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?

Provides explicit positive conditions ('Use this when you already know the candidate packages and need evidence for claims...') and negative exclusions ('Do not use it to discover unknown alternatives, estimate market size, or compare packages across different registries'), effectively guiding tool selection without needing to read sibling names.

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 read-only, idempotent, non-destructive behavior. The description adds valuable context beyond that: the output is heuristic and page-level, does not map every price to every plan, and does not normalize regional billing differences. This discloses important output quality limitations that an agent needs to know before relying on results.

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, no fluff. The first sentence states the purpose and use case; the second states limitations. Information density is high and every word earns its place. The description is front-loaded with the primary action.

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 a single well-documented parameter, strong annotations, and an output schema (not shown but present), the description covers what the tool does, when to use it, and its limitations. There are no obvious gaps in the agent's ability to select and invoke the tool 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 fully documents the 'pages' parameter, its items, and required properties, so baseline is 3. The description adds semantic meaning about what the comparison focuses on (visible prices, free-plan signals, plan-name hints), which goes beyond the schema's structural definitions. It also clarifies that URLs must be public pricing pages.

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 action ('Compare two to five public pricing pages side by side') and its scope. It distinguishes itself from siblings by emphasizing a quick, live comparison of visible prices, free-plan signals, and plan-name hints, which is distinct from broader competitor analysis or single-page 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 want a quick, live comparison of visible prices, free-plan signals, and plan-name hints across vendors.' The description also implicitly states when not to use it by noting limitations (heuristic, page-level, no normalization), which serves as an exclusion 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?

Annotations are all false and provide no safety information, so the description carries the burden of explaining behavior. It discloses persistence, automatic scheduling via Cloudflare cron, on-demand triggering via run_monitor_now, storage in Durable Object SQLite, and the team API key requirement. This exceeds the minimum but could still mention side effects like name conflicts or validation, hence a 4.

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, front-loaded with the primary purpose, and every sentence provides necessary context: what the tool does, how it executes, where results are stored, and authentication requirements. No waste or 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 description covers the tool's role in the monitor lifecycle (create, schedule, on-demand, store), authentication, and persistence. With a full output schema and 100% parameter schema coverage, the description provides sufficient context for an agent to select and invoke the tool correctly. It is complete for a 6-parameter tool with an output schema.

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 all parameter meanings. The description provides a high-level overview of target types but does not add syntax details (e.g., 'npm:pkg-name') that are already in the schema. Therefore, the description adds no significant semantic value beyond the baseline.

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 and resource: 'Create a persistent monitor' and clearly enumerates what it tracks (URL, pricing page, package version, endpoint status, vendor claim, custom keyword pattern). This distinguishes it from sibling tools like check_endpoint or verify_claim, which perform immediate checks rather than creating persistent monitors.

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 states the tool creates a persistent monitor that runs on a schedule or on demand via run_monitor_now, giving clear context for when to use this tool. It also notes the requirement of a team API key, which is a prerequisite. However, it does not explicitly mention when to prefer alternative tools for one-off checks, 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?

Annotations provide no safety hints (all false), so the description carries the burden. It discloses that the link is read-only, never contains the API key, expires automatically, and requires a team API key. This adds meaningful behavioral context beyond annotations, though it doesn't cover every edge case like link revocation or idempotency.

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, each earning its place: purpose, key security/expiry traits, and use case/auth requirement. The most important information is front-loaded, and there is 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?

Given the output schema exists, return values are covered. The description includes purpose, use case, auth requirement, and key behavioral traits. It lacks explicit side-effect information (e.g., whether it creates a persistent record), but with the output schema and the simple nature of the tool, this is sufficient for an agent to invoke it 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?

Schema coverage is 100%, so all parameters already have descriptions. The description adds no new parameter-level detail beyond what the schema provides. It mentions expiration behavior, but the schema already documents expires_in_days with default and max.

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: 'Create a read-only public link to the latest result for one of your monitors.' This specific verb+resource combination distinguishes it from siblings like create_monitor or get_monitor_result. It also mentions the link contains evidence and metadata, 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 says 'Use it to share a verified change with a teammate, customer, or agent,' which gives a clear use case. It also notes 'Requires a team API key,' a prerequisite. However, it does not explicitly mention when not to use it or name alternative tools, so it falls 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?

The description goes beyond the annotations by explicitly stating the permanence ('cannot be undone'), the scope of destruction ('all its stored results'), and the authentication requirement ('team API key'). This adds valuable behavioral context not present in the annotations alone.

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 sentences, front-loaded with the action, and every sentence adds essential information: the irreversible delete, the stored results included, and the required API key. No extraneous 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?

For a simple one-parameter destructive action with an output schema present, the description covers the key aspects: permanent deletion, what is deleted, irreversibility, and auth requirements. No critical information is missing.

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 provides full coverage (100%) with a description for monitor_id ('The monitor ID to delete.'). The tool description does not add additional parameter-level meaning, so the baseline of 3 is appropriate given the 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 states a specific verb ('Permanently delete') and resource ('a monitor and all its stored results'), clearly distinguishing it from sibling tools like create_monitor, list_monitors, and get_monitor_result. The scope of deletion is explicit.

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 clearly implies the tool should be used when removing a monitor, and it gives a prerequisite ('Requires a team API key'). It does not explicitly mention when not to use it or compare to alternatives, but the context is clear for a destructive delete action.

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 read-only, idempotent, open-world, and non-destructive. The description adds valuable behavioral context: responses are cached for 5 minutes, and results reflect search relevance not market share, which complements the annotations without contradiction.

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 concise sentences deliver purpose, usage, exclusions, and caching behavior with no filler. The most important information is front-loaded in the first sentence.

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 read-only search tool with an output schema and rich annotations, the description covers key behaviors, limitations, and cache behavior. It is fully adequate for an agent to select and invoke the tool 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?

Schema coverage is 100% with descriptive text for both query and registry. The description itself adds only an example phrase ('edge orm') and reiterates the npm/PyPI choice, providing no additional semantic value beyond the schema, so baseline 3 applies.

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?

Clearly states the tool searches npm or PyPI to estimate package category crowdedness before making market claims. This is a specific verb-resource-purpose combination that distinguishes it from sibling tools focused on compliance, endpoints, pricing, and monitors.

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 when to use it ('when you have a category or search phrase') and what not to use it for ('Do not use it to compare exact known package names or to infer adoption from downloads'). However, it does not name a specific alternative tool, slightly reducing the guidance completeness.

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 and destructiveHint=false, so the safety profile is known. The description adds a team API key requirement, which is a meaningful behavioral constraint not covered by annotations, and it summarizes the output contents. No contradiction with 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?

The description is two sentences, front-loaded with the primary purpose, and contains no redundant or filler words. Every sentence adds value.

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 a rich output schema, complete schema parameter descriptions, and annotations covering safety, the description adds the needed overview and authentication requirement. The tool is fully contextualized for an agent.

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?

Both parameters (period and include_unchanged) have detailed descriptions in the schema, covering their meaning, defaults, and effects. The description adds no additional parameter-specific semantics, so the baseline of 3 applies.

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 a specific verb ('Generate') and resource ('summary report of monitor activity'), clearly distinguishing from sibling tools like list_monitors (which lists monitors) and get_monitor_result (which fetches a single result).

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 clearly implies usage for time-window summaries by stating 'for a time window' and enumerating the report's contents, but it does not explicitly provide when-not-to-use guidance or name alternatives. This is clear context without exclusions, so it earns a 4.

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 read-only and idempotent behavior; the description adds value by specifying the 'team API key' auth requirement and listing the exact data elements returned (change details, confidence score, evidence URLs, error info). It does not contradict the 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?

The description is two sentences and front-loaded with the primary action. Every clause adds relevant information: what is retrieved, what is included, and the auth requirement. No fluff or redundant wording.

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 an output schema present, the description is complete: it explains the main operation, mentions key output fields, and notes the auth requirement. The schema covers parameter details, and annotations cover safety profile, so nothing critical is missing.

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?

Both parameters (monitor_id, limit) have descriptions in the schema, providing 100% coverage. The description does not add any additional semantic details about the parameters themselves; it only mentions the resource and output contents, so the baseline score 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 tool's purpose: 'Retrieve the most recent run results for a monitor' – a specific verb and resource. It enumerates key output components (change details, confidence score, evidence URLs, error information), which distinguishes it from related tools like list_monitors or generate_change_report.

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 intended usage is implicit: call this after a monitor has been run when you need the results for a specific monitor_id. It doesn't explicitly name alternatives or exclusions, but the context makes it clear. The 'Requires a team API key' adds a prerequisite, not a usage scenario.

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, openWorldHint, idempotentHint, and destructiveHint=false, covering basic safety. The description adds meaningful context by noting it 'reports observable configuration only and does not prove that a site is secure or vulnerability-free', which sets expectations for result interpretation. It also enumerates header types checked.

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 that are tightly scoped: purpose, usage context, and a crucial caveat. Each sentence adds distinct value with zero redundancy or filler, and the most important information is 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?

With annotations covering safety and an output schema present, the description adequately covers purpose, usage timing, limitations, and parameter handling. A minor gap is that it does not explicitly state that a live network request is made, but openWorldHint already implies external resource access.

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 description already fully covers the single parameter: 'Public http(s) URL or bare domain to inspect. Bare domains are normalized to https:// automatically.' Since schema coverage is 100%, the description adds no additional parameter meaning, warranting the baseline score 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 states a specific verb ('Inspect') with a clear resource ('security-related HTTP response headers') and a specific context ('for an unfamiliar public URL before an agent trusts or recommends it'). The focus on security headers and trust/recommendation clearly distinguishes it from sibling tools like check_endpoint or verify_claim.

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 a clear usage context by specifying 'before an agent trusts or recommends it' and cautions that it 'does not prove that a site is secure or vulnerability-free', which helps agents decide when to rely on results. However, it does not explicitly name alternative tools or state when not to use 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is known. The description adds valuable context beyond annotations: the resource is scoped to 'this API key' and there is an authentication requirement ('Requires a team API key'), which informs whether the agent can invoke the 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 two short sentences (24 words) that front-load the core action ('List all monitors') and add essential constraints. Every word earns its place, with no redundancy 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?

For a simple list operation with one optional parameter, an output schema, and strong annotations, the description fully covers purpose, scope, and authentication. It does not need to describe return values or pagination since the output schema exists.

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 100% coverage for the single parameter (active_only), so the baseline is 3. The description does not add any information about the parameter or clarify the active_only filter, so it provides no additional semantic value.

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 verb 'List' and the resource 'monitors', specifies scope ('owned by this API key'), and adds useful detail (last run status and schedule). This distinguishes it from sibling tools like create_monitor, delete_monitor, and get_monitor_result.

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: if you need to view monitors, use this tool. It also notes a prerequisite ('Requires a team API key'), but it does not explicitly mention alternatives or conditions for when not to use it. The purpose is clear enough that an agent could infer, but there is no direct comparison to 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 readOnly, openWorld, idempotent, non-destructive. Description adds non-obvious behaviors: 'Zero-cost schema discovery', 'No quota consumption, no API key required.' This gives operational context beyond annotations. No contradiction.

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 concise sentences, each informative: function, usage guidance, cost/auth. No fluff, front-loaded with the main purpose.

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 zero-parameter discovery tool with rich annotations and an output schema, the description fully covers purpose, when to use, and cost implications. No gaps apparent.

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?

Input schema has zero parameters, so baseline is 4. Description adds no parameter semantics but doesn't need to; the empty schema is self-documenting. Mention of 'all available tools' and 'access tiers' clarifies the scope of results, not 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?

Clearly states 'List all available Ground Truth tools and their access tiers' – specific verb (List), resource (tools), and scope (access tiers). Distinguishes from sibling tools by being the discovery meta-tool.

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 advises to call this 'before making a tool call' to explore available verification tools. Adds that it's zero-cost, no quota, no API key, implying it's safe to call anytime. Does not explicitly list alternatives but the tool's unique role makes usage clear.

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 readOnly, openWorld, idempotent, and non-destructive. The description adds behavioral details about the return value (one combined PASS/WARN/FAIL verdict with evidence) and a clear caveat that it does not guarantee safety, authentication, or correctness. No contradiction with 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?

Three concise sentences with front-loaded action, followed by output and limitation. No redundancy or filler; each 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?

Given a one-parameter tool with rich annotations and an output schema, the description covers the purpose, usage scenario, output format, and limitations. It is complete enough for an agent to decide when and how to invoke it 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?

Schema coverage is 100% for the single url parameter, and the schema already describes it as a public http(s) URL or bare domain. The description reinforces the 'unfamiliar URL' context but doesn't add new parameter-specific details 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 uses specific verbs ('Run', 'Returns') and clearly states the scope (reachability/response and security-header checks combined). It distinguishes from siblings by emphasizing the combined verdict and the preflight use case, which separates it from check_endpoint and inspect_security_headers.

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 specifies the intended use case ('for an unfamiliar URL or API before an AI agent trusts or acts on it') and provides limitations ('It does not prove that a service is safe, authenticated, or correct'). It doesn't explicitly name alternatives, but it implies when the combined check is appropriate versus individual checks.

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. The description adds valuable behavioral context: it is 'free live', requires 'no account', and does not create a 'persistent monitor'. It does not explicitly mention potential limitations or return details, but the core behavior is well disclosed beyond the 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?

The description is three sentences long, with the main purpose front-loaded in the first sentence. Every sentence earns its place: the first states what it does, the second when to use it, and the third how to transition to an alternative. No filler words.

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 description provides complete workflow context: why to use this tool (proves what would be monitored), when to use it (before checkout), and what to do after (offer create_monitor only when needed). An output schema exists, so return values don't need explanation. The sibling context is sufficiently addressed by the explicit comparison to create_monitor.

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%, with detailed descriptions for each parameter including enums and usage notes (e.g., pricing_page, vendor_claim). The tool description itself doesn't add parameter-level meaning, which is acceptable since the schema already fully documents them.

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 with a specific verb ('Capture') and resource ('free live baseline for a source'). It distinguishes itself from 'create_monitor' by explicitly noting it works 'without creating an account or persistent monitor', and its placement before checkout is made clear.

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 explicit when-to-use guidance: 'Call this before recommending checkout'. It also states the alternative: 'offer create_monitor only when the user wants scheduled checks, history, or change alerts', which advises when not to use create_monitor and implies preview is for initial validation.

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 description goes beyond annotations by disclosing specific behavioral traits: it 'Records the result' (side effect), returns a comparison of changed values (behavior), consumes quota (cost), and requires a team API key (auth). These add valuable context beyond the raw annotations (readOnlyHint=false, openWorldHint=true, etc.).

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 concise sentences, front-loaded with the primary action, followed by key behavioral and prerequisite information. Every sentence contributes meaningful detail with 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?

Given the tool has only one simple parameter, an output schema, and annotations, the description covers all essential aspects: purpose, usage context, behavioral consequences, and prerequisites. The return behavior is even described, which complements the output schema. The description is complete for an agent to correctly select and invoke the 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?

The input schema already provides 100% coverage for the single parameter monitor_id with the description 'The monitor ID returned by create_monitor.' The tool description does not add further parameter-specific guidance, so the baseline of 3 applies.

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 with a specific action ('Immediately run a monitor's verification check') and scope ('outside its normal schedule'). It distinguishes itself from sibling tools like get_monitor_result (which retrieves results) and create_monitor (which creates monitors).

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 clear context for when to use the tool: when an immediate, out-of-schedule verification is needed. It also includes important usage constraints: 'Counts against your monthly quota' and 'Requires a team API key.' It does not explicitly exclude alternatives, but the context strongly implies the use case.

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, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds substantial behavioral context beyond annotations: tests run in order with no branching or early exit, the verdict mapping is fully mechanical (all passing => SUPPORTED, zero passing => REFUTED, otherwise PARTIALLY SUPPORTED), and the tool is not an open-ended research agent. This goes well beyond what annotations provide.

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-organized: first sentence defines the action, second covers typical use cases, third imposes constraints, fourth explains the verdict algorithm, fifth names alternatives. Every sentence earns its place, and there is no redundant or filler content. It is appropriately sized for a tool of this complexity.

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's moderate-to-high complexity (multiple test types, ordered execution, verdict logic), the description covers all key aspects: what it does, when to use it, behavioral constraints, verdict determination, and sibling alternatives. An output schema exists for return values, and the description already explains the verdict mapping, so nothing critical is missing.

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 baseline is 3. The description adds some context by listing example check types (endpoint reachability, npm search counts, substring presence) and emphasizing that tests must be explicitly defined, but this largely restates information already in the schema. The hypothesis parameter is self-explanatory. No additional syntax or format details beyond the schema are provided, so a 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 'Run a small verification plan made of concrete live checks and summarize whether a hypothesis is supported' with a specific verb and resource. It also distinguishes itself from siblings by explicitly naming alternatives (verify_claim, estimate_market, compare_competitors) and framing itself as a coordination tool, not an open-ended research agent.

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 explicit when-to-use guidance ('Use this when one conclusion depends on multiple simple checks...') and when-not-to-use guidance with named alternatives ('Use verify_claim when you already have evidence URLs...'). It also restricts usage by stating 'every test must be explicitly defined in advance' and 'no branching or early exit', which clarifies the boundary versus more flexible research 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?

Beyond the readOnlyHint and idempotentHint annotations, the description discloses the 5-minute caching behavior, case-insensitive substring matching, and the fact that it does not prove a claim true when a page is silent. These details add meaningful context.

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 concise yet information-dense, front-loading the purpose and covering mechanism, limitations, and caching in a few sentences. No filler or 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 the rich annotations, output schema, and fully documented parameters, the description covers the tool's behavior, limitations, and usage context comprehensively. It explains what the tool returns (per-source evidence) and how to interpret it.

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 baseline is 3. The description does not add significant parameter-specific semantics beyond what the schema already provides; it reinforces purpose but doesn't explain parameter formats or edge cases.

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 and resource: 'Verify a factual claim against specific public evidence URLs.' It clearly states the tool's mechanism (checks keyword appearance) and explicitly contrasts with open-ended search or semantic analysis, distinguishing it from sibling tools like test_hypothesis.

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 explains when to use the tool: 'before an agent repeats it or acts on it.' It explicitly states limitations ('does not perform open-ended search, semantic contradiction analysis') and provides guidance on choosing direct evidence URLs and interpreting results as support signals.

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