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

With no annotations, the description carries the full burden, and it does disclose two useful traits: the call is 'Paid' and the response shape is recommendation/next_step/reasoning. However, it says nothing about latency, rate limits, auth requirements, or whether the recommendation is advisory-only — meaningful gaps for a zero-annotation 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?

Three short clauses, front-loaded with the input→output contract, then cost, then return fields. Every sentence carries information 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?

For a one-parameter tool with no output schema, the description usefully enumerates the return fields (recommendation, next_step, reasoning) and flags the paid nature, which is what an agent most needs. Minor gaps remain around cost magnitude and whether calls can be batched.

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% for the single 'question' parameter, so the schema already documents its meaning. The description's 'decision or set of options' restates the schema's 'The decision or options to weigh' without adding format, length, or phrasing guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource pair ('give a decision or set of options' → 'get a concrete recommendation') that is clearly distinct from siblings like verify_claim, summarize_url, or check_domain. It does not explicitly name or contrast a sibling, but the purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied — an agent can infer 'use this when you need a recommendation' from the purpose, but there is no statement of when to prefer it over alternatives such as verify_claim or grounding_line, nor any exclusions. 'Paid' hints at a cost tradeoff but is not framed as a selection criterion.

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

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

With no annotations and no output schema, the description carries the full burden and does reasonably well: it flags the tool as paid and names the returned fields (dns, tls_valid, cert_expiry). It omits failure behavior, error semantics when tls_valid is false, and rate/timeout limits, which keeps it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences: purpose, cost, returns. Purpose is front-loaded and every sentence earns its place with zero 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 one-parameter read tool with no annotations, the description supplies the two things structured data lacks: cost ('Paid') and the shape of the result (dns, tls_valid, cert_expiry). Only failure/error behavior and any rate constraints are 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?

One parameter with 100% schema description coverage, so the schema already documents 'domain' with an example. The description adds nothing on format (e.g., whether a scheme or subdomain is expected), so the 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?

States a specific verb (check) and resource (domain) and enumerates the three things verified: live DNS A records, valid TLS/SSL, and certificate expiry. This implicitly separates it from is_site_up (HTTP availability), but no sibling is named explicitly, so the differentiation is left to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the scope stated ('check any domain'), and 'Paid' gives useful cost context before invoking. However, it never says when to prefer this over the overlapping is_site_up sibling, nor are there exclusions or prerequisites.

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

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

With no annotations, the description carries the full burden and does notable work: it flags the tool as Paid (a critical operational trait) and states the return contains 'cleaned output plus what was fixed' despite there being no output schema. It stops short of disclosing auth requirements, size limits, or failure behavior, but the cost and output disclosures are substantive.

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 sentences, zero filler, and the core value proposition plus the paid flag are front-loaded before the mode breakdown. A model can parse it in one pass.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter tool with no output schema, the description explains both inputs' purpose and the shape of the return, including the per-mode behavior. Input size limits, error handling, and the cost amount are unstated, which is the only material 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?

Schema coverage is 100% and the enum already names the five modes, so baseline is 3. The description exceeds that by explaining what each mode does (json parse+pretty+validate, csv RFC4180 normalization, date ISO-8601), which tells the agent which mode to select rather than just the legal values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (clean messy data) and enumerates exactly what it does for each of the five modes. None of the siblings (check_domain, summarize_url, advise_decision, etc.) overlap in function, so no differentiation is needed.

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?

'Send messy data; get it back clean' implies the trigger condition, and 'Paid' signals a cost consideration, but there is no explicit when-not guidance or named alternative. The mode list helps an agent pick a mode, which is partial 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?

With no annotations, the description must carry the behavioral burden. It discloses that the operation is paid and names the return fields (keyphrases, theme), but omits details such as cost amount, input size limits, or processing constraints.

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 short and front-loaded, with no wasted sentences. The telegraphic style ('Paid. Returns keyphrases, theme.') is efficient but slightly fragmentary.

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 extraction tool with no output schema, the description adequately names the return fields and notes the paid nature. It is complete enough for invocation, though additional details on output structure or limits would strengthen 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?

There is only one parameter, and the schema already documents it fully with 100% description coverage. The description's phrase 'Give any text' adds minor clarity but no syntax or format constraints 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 uses specific verbs and resources: extract key phrases and core theme from text. It is clear what the tool does, though it does not explicitly distinguish itself from siblings such as summarize_url or clean_data.

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?

'Give any text' implies the input expectation, and 'Paid' signals a cost consideration. However, there is no explicit guidance on when to choose this over alternatives or any exclusions.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the tool is paid, but it does not describe permissions, latency, rate limits, or what 'returns grounding' concretely means; the return behavior remains vague beyond the one-word phrase.

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 short and front-loaded, with no wasted preamble. 'Returns grounding' is somewhat redundant with the earlier sentence, but overall it is appropriately sized for a one-parameter 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?

For a tool with no output schema and no annotations, the description should clarify what a 'grounded line' actually is and what the agent receives. It only says 'Returns grounding,' which is too vague to fully inform correct invocation and interpretation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the single 'situation' parameter is already documented in the schema. The description adds the context that the situation should be stressed or stuck, but that largely echoes the schema's own description rather than adding new semantics.

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 input ('stressed or stuck situation') and output ('one grounded line to steady on'), so the purpose is clear enough to distinguish it from utility siblings like summarize_url or verify_claim. The metaphor 'grounded line' is slightly vague, but the core action is understandable.

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 implies usage for stressful or stuck situations, which gives some context, but it does not explicitly say when to use this tool versus alternatives or when not to use it. No sibling alternatives or exclusion conditions are named.

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

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

With no annotations, the description carries the full burden, and it does disclose two genuinely useful traits the schema cannot: that the result is a live/point-in-time check and that the call is Paid. It also names the return fields (http_status, reachable, latency_ms), which is helpful given there is no output schema. It does not disclose timeouts, redirect handling, or behavior on malformed URLs.

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 short sentences, front-loaded with the core question, then cost, then return shape. Every clause carries information and nothing is padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter read tool with no annotations and no output schema, the description covers purpose, cost, and the fields returned, which is most of what an agent needs. Minor gaps remain around timeout/error semantics and explicit contrast with check_domain, but the core affordances are present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single parameter with 100% schema description coverage ('Full URL to check'), so the schema already does the work. The description adds nothing about URL format, scheme requirements, or protocol support, making the 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 states a specific check verb and resource: whether a given URL is up or down right now. It is distinguishable from siblings like check_domain and summarize_url by being a real-time reachability probe. It stops short of explicitly naming the sibling it contrasts with, so it lands at 4 rather than 5.

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?

There is no guidance on when to use this instead of check_domain, summarize_url, or the other siblings, and no exclusions or prerequisites. The only implicit context is 'right now', which hints at live probing versus historical data, but that is inference rather than stated 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?

With no annotations, the description carries the full behavioral burden. It discloses the cost model ('Paid') and the returned fields, which is meaningful context, but says nothing about auth requirements, rate limits, latency, or failure behavior for unreachable pages.

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 short and front-loaded with the core action, and 'Paid' is surfaced early. There is mild redundancy between 'with its title and source' and 'Returns title, summary, source_url.'

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 tool with no output schema, the description covers the essential behavior and enumerates the returned fields, which compensates for the missing output schema. It is adequate, though cost/return details could be slightly clearer.

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?

There is a single parameter and schema description coverage is 100%, so the schema already documents the URL input. The description adds no format or constraint detail beyond the schema, which is the expected baseline when the schema does the work.

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 and resource: fetch a web page and return a short summary with title and source. It is clearly distinguishable from siblings like extract_keyphrases or verify_claim by virtue of being a summarizer, but it never names or contrasts those alternatives explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only usage signal is the terse 'Paid' flag, which usefully warns of a cost before invocation. There is no guidance on when to prefer this over sibling tools (extract_keyphrases, verify_claim) or any prerequisites, so usage is only implied.

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

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

No annotations are provided, so the description carries the full burden. It does disclose useful behavioral context — that calling it is free and that listed items are priced per call in USDC over x402 — which is real information beyond the schema. However, it never states that the operation is read-only, that no auth is required, or what the response looks like, leaving notable gaps for a no-annotation 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?

It is short and front-loaded, but the fragment "Free." is awkwardly placed and the closing sentence ("TEOS is a catalog of small paid utilities for agents, priced per call in USDC over x402") partially restates the pricing already given in the first sentence. Some words are spent on redundancy rather than new information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description must convey what comes back, and it does reasonably well: free discovery files plus paid tools with prices. For a zero-parameter listing tool this is close to complete, though it omits any hint of response format or size.

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 tool takes zero parameters, so per the rubric the baseline is 4. There are no parameter semantics to explain, and the description correctly spends no effort on arguments.

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 ("List") and resource ("everything TEOS offers") and enumerates the contents: free discovery files plus paid per-call tools with prices. This clearly separates it from the sibling utilities (check_domain, summarize_url, etc.), which are individual functions rather than a catalog. It stops short of a 5 only because it never states the catalog's role as a discovery step relative to its siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: an agent can infer this is the discovery/listing entry point, but the description gives no explicit when-to-use guidance, no exclusions, and never mentions the sibling teos_how_to_buy, which is the obvious complementary tool for acting on the catalog. This is minimum-viable implied 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?

With no annotations, the description must carry the behavioral burden. It usefully discloses that the call is "Free" and that the output is plain-language instructions, but says nothing about permissions, rate limits, or what the instructions actually cover. For a zero-parameter informational tool this is adequate but thin.

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 short sentences, front-loaded with the deliverable before the cost note and the trigger condition. No filler, though "Free." as a standalone fragment is slightly clipped.

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 no output schema, the description does at least characterize the return value as plain-language payment instructions covering x402/USDC. For a simple no-param help tool this is nearly sufficient, though it could briefly indicate what topics the instructions span.

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 tool takes zero parameters, so the schema imposes no semantic burden and the baseline of 4 applies. The description adds no parameter detail, which is correct since none exist.

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 deliverable: plain-language instructions for paying a TEOS tool via x402 with USDC. The agent can tell this is an informational/how-to tool rather than an action tool. It does not explicitly contrast itself with the sibling teos_catalog, which also relates to TEOS tools, so it stops short of a 5.

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?

"Use when your agent needs to know how to buy and call a TEOS tool" gives an explicit trigger condition for invoking it. There are no stated exclusions or named alternatives (e.g., teos_catalog for discovery), so it is clear context without routing 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?

With no annotations at all, the description carries the full burden and does well: it discloses that the tool is paid, that verification runs against the live web, and that results include a three-valued verdict, evidence, and sources checked. It omits latency, rate limits, failure/error behavior, and repeat-call cost implications, which keeps it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the core action and cost warning, with output shape following. The closing line ('Grounds an agent's statements in reality') is motivational rather than operational and is the only low-value 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 tool with no output schema and no annotations, the description does the essential work: it names the return fields and the verdict enumeration, and flags the paid nature. Remaining gaps are secondary (rate limits, failure modes, what 'unverifiable' typically means), so it is close to complete but not exhaustive.

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% for both parameters, so the baseline is 3. The description reinforces that url is optional and gives a concrete claim example ('example.com uses Cloudflare') that hints at expected claim phrasing, but adds no format or constraint detail the schema doesn't already supply.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Check a claim against the live web') and adds a concrete claim example plus the output shape (verdict, evidence, sources), so an agent knows exactly what comes back. It doesn't explicitly name or contrast with siblings like check_domain or is_site_up, so differentiation is inferable rather than stated.

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?

'Grounds an agent's statements in reality' implies the usage context (verify a factual assertion before asserting it) and 'Paid' flags a cost consideration. However, there is no explicit when-not-to-use guidance, no mention of alternatives, and no statement of prerequisites or limits — the agent must infer the boundary from sibling names.

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