Teppi

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and open-world assumptions. The description adds value by explicitly stating the reporting philosophy: 'Unknown is reported as unknown, never as bad.' It also hints at the categories of results (which returned nothing, which list exclusions), which gives the agent a preview of the output semantics. 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?

Two sentences total with zero filler. The first sentence front-loads the primary action and the breakdown categories, and the second adds a critical nuance ('Unknown is reported as unknown'). Every part earns its place; no redundancy or vague phrasing.

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 read-only lookup with no output schema, the description covers the key output categories (unknown, paid-but-empty, non-serving, monthly spend). It does not describe the exact return format or pagination, but given the moderate complexity and the strong parameter schema, the description is sufficient for an agent to call it correctly. The openWorldHint annotation also sets expectations about unknown items.

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% — the 'dependencies' array and its item properties (url, method, pay_to, calls_per_month) all carry descriptions. The tool description does not add any parameter-level detail beyond what the schema provides, so it rides on the schema. This meets the baseline for full schema coverage.

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

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

The description states a specific verb ('look up'), a clear resource ('every paid endpoint your agents call'), and the aggregation dimension ('added up by the address each one pays'). It also lists the specific outcomes (unknown, paid-but-no-response, non-serving, monthly spend). This clearly differentiates it from sibling tools like check_grade or plan_route, which are unrelated to paid endpoint exposure.

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 purpose is so specific that the usage context is obvious: use it when you need a consolidated view of paid endpoints across a fleet. However, there is no explicit statement of when not to use it or mention of alternatives, though siblings are clearly different. The description implies a batch/aggregation scenario without explicitly saying so.

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 readOnly/openWorld hints, it discloses meaningful behavior: 'Answers unrated rather than guessing when the evidence is thin' and 'a url never seen is put in line for a free handshake' reveal non-immediate and abstention semantics. This is exactly the kind of context an agent needs and 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 sentences, front-loaded with the return purpose, followed by edge-case behavior and retry guidance. Every sentence adds information; 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 read-only check with no output schema, it covers the main return content, unknown-URL handling, and coverage scope. The remaining gap is that the method parameter is left semantically unexplained, and no sibling is named as an alternative, though the description is otherwise sufficient for invocation.

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 only 33%, so the description must compensate. It clarifies id_or_url ('x402 endpoint or its url') and indirectly relates pay_to via the payTo/charges semantics, but it never explains what the optional method GET/POST means or when to supply pay_to beyond the schema's own description.

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: 'Return what has been verified about an x402 endpoint or its url...' and enumerates concrete facts (whether it answers, what it charges, whether the price moved), which clearly distinguishes this from planning/capability siblings. The 'Works for endpoints Teppi does not operate' sentence adds a meaningful coverage distinction.

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

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

It provides clear usage context: works even for endpoints Teppi does not operate, and unseen URLs are queued for a free handshake, so 'ask again in an hour' is explicit retry guidance. It does not name sibling tools or give when-not-to-use exclusions, so it stops short of a 5.

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

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

Annotations already indicate read-only and open-world behavior. The description adds useful behavioral context by specifying exactly what will be returned: schemas, pricing, networks, seller details, and all recorded observations. This is consistent with the annotations and adds value beyond 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 a single, front-loaded sentence that immediately states the scope ('Full detail for one capability') followed by a compact, informative list. There is no filler, repetition, or unnecessary prose.

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

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

For a simple read-only get-by-id tool, the description explains the return content well enough, and the annotations cover safety. It could be more complete by explicitly linking the id parameter to the capability being fetched, but the overall definition is sufficient for an agent to select and invoke the tool.

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

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

The schema has one required parameter, id, with 0% description coverage, yet the description never mentions the id parameter or how to supply it. The pattern in the schema provides format information, but the description itself adds no parameter semantics; the connection to 'one capability' is only indirect.

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: retrieve full detail for one capability, and enumerates the included content areas (schemas, pricing, networks, seller, observations). It implicitly distinguishes itself from search_capabilities by emphasizing a single entity, but it does not explicitly contrast with any sibling.

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

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

The intended usage is implied: use this tool when you need comprehensive information about a specific capability, presumably after identifying it through a search. No explicit when-to-use or when-not-to-use guidance is given, and no alternatives 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?

Annotations already declare readOnlyHint=true, and the description reinforces this by saying it 'Moves no money and buys nothing.' It adds meaningful behavioral context about what the tool returns: ordered list, cost estimate, and verification state per step. This goes beyond the annotations and helps the agent set expectations.

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

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

The description is only two sentences, front-loaded with the core function and output, followed by a necessary clarification about non-execution. There is no filler or redundancy; 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?

Given there is no output schema, the description does a good job enumerating what the return value contains: ordered paid endpoints, cost estimate, and verified-step details. It also clarifies side-effect behavior. Minor gaps remain around parameter meaning, but the overall tool behavior is sufficiently described for an agent to use 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 0%, so the description must compensate, but it only mentions 'goal' and 'budget' at a high level. It does not explain the min_grade parameter at all, nor the budget_usd decimal-string format, nor how goal language or grade filtering affects the plan. This leaves a required and an optional parameter underspecified.

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 ('Turn') and resource ('a goal and a budget' into a route), and clearly defines the result as an ordered list of paid endpoints with cost estimate and verification details. It also explicitly distinguishes planning from executing by saying 'returns the plan for you to run yourself.' This is clear and differentiates from the sibling tools around capabilities and grades.

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

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

The description provides clear context: use this when you have a goal and budget and need an ordered plan of paid endpoints. It also implicitly excludes execution by stating 'Moves no money and buys nothing: it returns the plan for you to run yourself.' However, it does not explicitly name alternatives or state when not to use it versus siblings.

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 annotations already declare readOnlyHint=true, lowering the burden on the description. The description adds valuable behavioral context by specifying the returned fields (price, schemas, networks, verification) and the verified-first sort behavior. It does not contradict the annotations, though it omits details like pagination or open-world result semantics.

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 with no filler: purpose, return payload, sort guidance, and usage trigger each occupy one sentence. It is front-loaded and every clause adds 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?

For a read-only search tool with no output schema, the description covers the primary use case and return behavior well. However, with five parameters and zero schema-level documentation, the missing explanations for max_usd, network, and limit leave notable gaps for an agent trying 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?

With schema description coverage at 0%, the description must compensate for parameter meaning. It hints at query through 'by task description' and at sort through 'Sort by verified', but leaves limit, max_usd, and network unexplained, including their format constraints.

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 ('Search') with a concrete resource ('paid agent capabilities') and a clear search criterion ('by task description'). It also lists what is returned and the scenario where it should be used, making its purpose unambiguous and distinguishable from siblings like get_capability.

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 an explicit trigger: 'Use before paying an x402 endpoint you have not used.' However, it does not name alternatives or state when not to use it, so it stops short of a perfect 5.

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