Confirm a URL is reachable and actually says what it is claimed to say, BEFORE you spend a long context reading or acting on it. Catches dead links, pages that changed, and pages that do not support the claim attached to them. One cheap call here replaces a full fetch-and-reason pass that ends in nothing. Costs $0.20 in USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | the URL to check | |
| contains | No | text the page must contain for the claim to hold |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses cost ($0.20), indicates it's a cheap check, and states what it catches (dead links, changes, unsupported claims). However, it omits details about failure handling, timeouts, or return semantics, which an agent might need.
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 four sentences, each contributing value: purpose, use case, benefit, and cost. No redundancy or filler; front-loaded with the core action and 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 simple 2-parameter tool with no output schema and no annotations, the description covers the key aspects: what it does, when to use it, and cost. It could mention return types, but given the low complexity, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters ('url' and 'contains') are already documented. The description adds no new info about parameter formats or edge cases, but it reinforces the purpose of 'contains' via the claim context. Baseline 3 is appropriate since schema does the heavy lifting.
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 ('Confirm') and resource ('URL') plus a clear outcome ('reachable and actually says what is claimed'), distinguishing it from siblings like verify_claim or check_provenance by focusing on URL/content validation. It is unambiguous about what the tool does.
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 using it BEFORE long-context reading and lists concrete scenarios (dead links, changed pages, unsupported claims). It doesn't explicitly name alternative tools, but the 'before you spend a long context' instruction provides sufficient context for when to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool serves a distinct purpose: verifying claims, sources, answers, checking provenance, tracking waste, querying pricing, and asking an AI assistant. No two tools overlap in their intended use, making it easy for an agent to select the right one.
Tool names follow mixed conventions: three verify_* tools share a prefix, but others use different verbs (check_, report_) or noun forms (pricing, waste_report) and one reverses the verb pattern (answer_share). While individual names are descriptive, the lack of a uniform verb_noun structure makes the set less predictable.
With 8 tools, the count is well within the ideal range for a focused verification service. Each tool addresses a distinct need—claim, source, and answer verification, provenance checking, waste tracking, and pricing—without redundancy.
The surface covers all advertised types of verification (claim, source, answer) plus provenance checking and waste tracking. Minor gaps exist like no dedicated tool for bulk or historical verification, but the core workflows are fully represented.