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

No annotations are provided, so the description carries the full behavioral burden. It discloses that the call is 'Free,' implying no credit consumption and no side effects, and 'Show' signals a read-only operation. It does not specify response format, but that is minor for a parameterless balance check.

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 short sentences deliver the cost, the purpose, and the usage guidance with no wasted words. The description is front-loaded and 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 zero-parameter tool with no output schema, the description covers what it does, that it is free, and when to call it. It even names the specific API key whose balance is checked, making the context complete enough for safe 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?

The tool has zero parameters and the input schema is empty, so there are no parameter semantics to explain. The baseline of 4 for a zero-parameter tool applies.

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

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

The description states a specific verb and resource: 'Show the remaining credit balance for FETCHER_API_KEY.' It also signals the tool is free, which distinguishes it from the paid fetch_data sibling and the credit-management topup_credits tool. This is a clear, unambiguous 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?

The phrase 'Call this before a long run of paid requests' gives explicit timing guidance and implies this is a preflight check. It does not explicitly name excluded alternatives, but the usage context is 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?

No annotations are present, so the description carries the burden. It discloses that the tool is free, and describes the contents of the returned signature including price and response shape. It doesn't discuss side effects or auth, but for a metadata endpoint the key behaviors are covered.

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, first gets directly to the point with 'Free' and the action, second provides usage guidance. No wasted 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?

For a one-parameter metadata tool, the description fully explains what the tool does, what information it returns, and when to call it relative to fetch_data. The absence of an output schema is acceptable because the tool's purpose is to describe that shape.

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 a clear example for the only parameter 'path'. The description only says 'one endpoint' and doesn't add extra semantics beyond the schema, 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?

Description states a specific action ('Show the full call signature') on a specific resource ('one endpoint'), enumerating what is included: required/optional parameters, allowed values, price, and response shape. It clearly differentiates from siblings by focusing on metadata rather than data fetching or searching.

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 tells the agent when to use it: 'Call this before fetch_data if you are unsure about parameters.' This names fetch_data as the alternative and gives a clear condition, satisfying the when/alternative requirement.

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. It discloses the monetary side effect (priced per call, spends prepaid credits from FETCHER_API_KEY) and the live-data behavior. It could say more about error handling or response shape, but the key behavioral costs are clear.

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?

Every sentence earns its place: cost warning, purpose, parameter-passing rule, follow-up guidance, and configuration alternative are all packed in without fluff. The essential 'Paid' warning 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 generic endpoint-fetching tool with only two parameters and no output schema, the description plus schema covers usage, cost, authentication, and the recommended describe_endpoint step. A more explicit statement about return format/errors would increase completeness, but the guidance to call describe_endpoint mitigates that 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 description coverage is 100%, so the schema already documents both parameters. The description reinforces that path and query parameters go together in `params`, which matches the schema, but it does not add substantial new semantic information beyond that.

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 ('Fetch'), a resource ('live data from any fetcher.sh endpoint'), and clearly differentiates from siblings like search_endpoints and describe_endpoint, which discover/describe endpoints rather than execute them.

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?

Gives clear context on when to call this tool, including the paid nature and a direct pointer to describe_endpoint when unsure. It also mentions the alternative of configuring FETCHER_SERVICE for named per-endpoint tools, though it does not explicitly enumerate all sibling comparisons.

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 burden, and it does well by disclosing cost ('Free'), return contents ('paths, descriptions and per-call prices'), and the searchable dimensions. It does not explicitly mention read-only behavior or rate limits, though 'search' strongly implies a safe read operation.

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?

One information-dense sentence with the most important signal ('START HERE. Free.') front-loaded. The list of services is useful, not padding, and the next-step routing 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 search tool with no output schema and no annotations, the description gives enough context: what it searches, what it returns, cost, and the recommended follow-up calls. Nothing essential 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?

The schema already covers both parameters thoroughly with examples, so the baseline is 3. The description adds value by clarifying they can be used together ('by keyword and/or service') and by naming the service categories, which helps the agent understand what values are meaningful.

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 action ('Search fetcher.sh's web-data endpoints'), names the resource domain, lists concrete services, and says what it returns. It also distinguishes itself from siblings by explicitly being the starting point before describe_endpoint and fetch_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?

It opens with 'START HERE', says it is free, and gives an explicit workflow: search first, then call describe_endpoint, then fetch_data. This directly tells the agent when to use this tool and how it relates to the obvious sibling alternatives.

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 disclosure burden. It reveals several key behaviors: the tool returns a URL rather than processing payment directly, enforces a $1 minimum, and instructs that the bby_live_… key should be placed in FETCHER_API_KEY after topping up. It does not disclose all potential side effects, but for a simple URL-returning tool this is sufficient.

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

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

The description is two sentences with no wasted words. It front-loads the crucial constraint ('bought on the web, not over stdio'), then identifies the return value, minimum amount, and follow-up action. Every sentence contributes unique 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 single-parameter tool with no output schema, the description provides adequate context to call it: what it returns, the minimum, and the post-payment step. Slight gaps remain around whether the optional amount parameter must be supplied or what the exact URL format looks like, but these are minor given the tool's simplicity.

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

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

The input schema already has 100% description coverage for the only parameter, amount, including its USD denomination, minimum value, and purpose ('Used only to confirm the floor'). The tool description repeats the $1 minimum but adds no new meaning beyond the schema, so the baseline of 3 applies.

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

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

The description states a clear action: 'Returns the top-up URL' for buying prepaid credits. It distinguishes itself from siblings like check_balance and fetch_data by focusing on purchasing credits rather than querying or retrieving data. However, the phrasing 'Prepaid credits are bought on the web, not over stdio' is slightly indirect and could be more explicitly framed as 'Use this tool to get a top-up link.'

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 when prepaid credits are needed and sets an important constraint that payment happens on the web, not through stdio. However, it does not explicitly mention alternatives like check_balance for checking credit status or explain when not to use this tool. The usage context is asserted but not differentiated against sibling tools.

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