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?

With no positive annotations to lean on, the description carries the behavioral burden and does so well: it discloses persistence, automatic scheduling via Cloudflare cron, durable per-account storage, and plan-based limits. It also notes on-demand execution and mentions that free tiers restrict hourly schedules, which is important operational 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 three sentences long, front-loaded with the core purpose, and every sentence adds meaningful context: scheduling, on-demand execution, durability, and plan limits. There is no filler or redundant restating of the title.

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 six parameters, a complete input schema, and an output schema, the description covers the essential behavioral and operational context an agent needs. It explains what is created, how it runs, where results are stored, and what constraints apply, leaving no critical gap.

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 covers 100% of parameters with detailed descriptions and enums, so the description does not need to repeat parameter-level detail. The tool description adds no extra parameter guidance beyond the schema, which is acceptable given the schema's completeness.

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 identifies the action ('create a persistent monitor') and the resource it operates on, covering the main target types and distinguishing itself from on-demand execution via run_monitor_now. It is far more specific than the title alone and differentiates from siblings like delete_monitor or list_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 explains how monitors run automatically or on demand, and it references run_monitor_now as the invocation path, which gives useful context. It does not explicitly contrast with one-off check tools like check_endpoint or verify_claim, but the persistent-monitor framing makes the primary usage scenario 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?

The description adds meaningful behavioral detail beyond the annotations: the link is read-only, contains monitor metadata and evidence but never the API key, and expires automatically. It also clarifies auth requirements. This is exactly the kind of non-obvious behavior an agent needs and the annotations do not 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?

Three dense, purposeful sentences with the core action front-loaded. Every sentence earns its place: what it creates, what it contains/doesn't contain, expiration, and the intended use plus auth requirement. 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?

Given an output schema exists and the input schema is fully documented, the description covers all critical context: read-only behavior, content safety, expiration, sharing purpose, and auth requirements. No important information is missing for an agent to invoke this 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?

Input schema coverage is 100% and each parameter already has clear descriptions. The tool description reinforces the monitor_id purpose by mentioning 'latest result for one of your monitors', but it does not add substantial meaning 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 states a specific verb ('Create'), a clear resource ('read-only public link'), and a precise target ('latest result for one of your monitors'). This makes it easily distinguishable from sibling tools like get_monitor_result or create_monitor.

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 explicitly names the intended use case: sharing a verified change with a teammate, customer, or agent. It also notes the auth prerequisite (free watch key or paid API key). It does not explicitly name alternative tools or exclusion criteria, but the use case and resource are clear enough for an agent to select it appropriately.

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 annotations (destructiveHint=true), the description discloses exactly what gets destroyed: the monitor and all its stored results. It also explicitly warns that the action cannot be undone and states the required credentials, adding meaningful behavioral context over the structured annotations. There is no contradiction with the idempotentHint annotation; the description simply does not address repeated-call 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 two compact sentences with no fluff. The core action and scope are front-loaded, followed by the critical irreversibility warning and authentication requirement. Every sentence contributes information an agent needs before calling the tool.

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 simple: one required parameter fully documented in the schema, destructive and idempotent behavior covered by annotations, and the description adds auth requirements and irreversible consequences. An output schema exists, so return-value documentation is not the description's job. Nothing essential 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 sole parameter monitor_id is already fully described in the schema as 'The monitor ID to delete.' With schema description coverage at 100%, the description does not need to add parameter details. It adds no new semantic information about the parameter, 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 states a specific verb ('delete'), a specific resource ('a monitor'), and the full scope ('and all its stored results'). It also clarifies permanence ('cannot be undone'), which distinguishes this from any non-destructive monitor tool. The purpose is unambiguous and clearly differentiated from siblings like create_monitor or list_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 clearly implies when to use this tool: when a monitor and its results should be permanently removed. It provides important usage context by warning about irreversibility and stating the authentication prerequisite ('Requires a free watch key or paid API key'). It does not explicitly name alternatives, but no sibling tool competes for this deletion 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, idempotentHint=true, destructiveHint=false, so the description doesn't need to restate these. The description adds context about auth requirements ('Requires a free watch key or paid API key') and what the report includes, but it doesn't disclose what happens if no monitors exist, whether the report is generated on-demand and returned or queued, or any rate limits. It doesn't contradict 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 sentences, all useful and no wasted words. The main action and scope are front-loaded, the inclusion list is concise, and the auth requirement is appended as a final note. Could perhaps integrate the auth note earlier, but it is not misleading 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?

The tool has an output schema, so the description need not explain return values. The description covers purpose, scope, and auth requirements. Given the tool is a read-only report generator with clear params and an output schema, the only missing context is subtle: what the report format is (though output schema covers it) and what happens in edge cases like no monitor activity. But overall it's adequate for an agent to select and 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 description coverage is 100%, so the schema already documents both parameters. The description mentions 'time window' but doesn't explicitly map it to the 'period' parameter beyond what the schema says. The description doesn't add details like whether include_unchanged only affects the report's visibility or also affects processing. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

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 ('Generate') and resource ('summary report of monitor activity'), clearly distinguishing it from sibling tools like list_monitors or get_monitor_result. The title reinforces the action. The scope of the output (monitors run, changes detected, failures, risk levels, recommended follow-up actions) also clarifies what this report contains, and it is distinct from other tools like assess_compliance_posture or 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 gives clear context regarding when to use this tool: when a summary report of monitor activity is desired, with a specific time window. It implies the difference between this and get_monitor_result or list_monitors by focusing on an aggregated report rather than a single result or simple list, but it does not explicitly exclude alternatives or state conditions like 'use this instead of list_monitors when you need an aggregated summary.'

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, and non-destructive behavior. The description adds meaningful context by disclosing the exact result contents and the authentication requirement (free watch key or paid API key), which is not present in annotations. It does not contradict 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 tight sentences with no filler. The result contents are front-loaded, and the authentication caveat is appended as a compact, necessary qualifier. 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?

For a simple two-parameter read-only tool with a full input schema and an output schema, the description covers the essential call context: what is returned, recency semantics, and required credentials. Nothing critical for invoking it correctly 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 input schema already fully documents both parameters. The description adds no parameter-specific detail beyond confirming the tool returns the most recent results, which the schema's 'newest first' description already conveys. 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 states a specific verb ('retrieve'), a clear resource ('most recent run results for a monitor'), and enumerates the result contents (change details, confidence score, evidence URLs, error information). This clearly distinguishes it from siblings like run_monitor_now or list_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 implies the tool is used after a monitor has run and for retrieving result details, but it does not explicitly state when to prefer it over alternatives such as run_monitor_now, list_monitors, or generate_change_report. The authentication requirement is a useful precondition but not usage guidance.

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

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

Annotations already declare readOnlyHint, 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?

The description adds an authentication requirement ('free watch key or paid API key') that is not present in the annotations, and clarifies the resource scope. It does not contradict the readOnlyHint/idempotentHint/destructiveHint annotations, so credit is given for this extra 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 entire description is one sentence that front-loads the action and resource, then appends the auth requirement. There is zero waste.

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 says 'all monitors' but the schema default active_only=true means only active monitors are returned unless the flag is set to false. This creates a subtle mismatch that could lead an agent to omit the parameter and get a narrower result than expected; the description should note the default filter.

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 single parameter active_only is fully described in the input schema. The description adds no additional meaning about the parameter, 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?

States a specific verb ('list'), resource ('monitors'), scope ('owned by this API key'), and returned data ('last run status and schedule'). This clearly distinguishes it from siblings 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 gives clear context for the tool's purpose but does not explicitly state when to use it over alternatives such as get_monitor_result or run_monitor_now. The use case must be inferred from the phrase 'List all monitors' rather than spelled out.

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?

Adds substantial behavioral context beyond annotations: records the result, returns a change indicator, counts against monthly quota, and requires a free watch key or paid API key. These side effects, cost, and auth requirements are not visible in the annotations, so the description carries the burden well.

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 with a distinct purpose: the action, the result/behavior, and the quota/auth requirements. No unnecessary words 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?

For a single-parameter triggering tool with an output schema present, the description covers the trigger semantics, side effects, quota, and authentication. Nothing essential is missing 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?

The schema already documents monitor_id with 100% coverage, including a helpful reference to create_monitor. The description adds no extra parameter-level detail, 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?

States the specific action 'Immediately run a monitor's verification check outside its normal schedule', clearly distinguishing it from read/monitoring tools like get_monitor_result. It also describes the outcome: records the result and returns whether the observed value changed since the last run.

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?

Clear context for when to use: for an immediate, out-of-schedule verification check. It also states prerequisites (quota and authentication). It does not explicitly name alternative tools or exclusions, but the intended usage is unambiguous.

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.