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 never states that this is a static, zero-argument read operation, nor what form the overview takes (text blurb, markdown, structured fields). Only the topical content is disclosed; no operational traits are.

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?

A single front-loaded sentence with no filler or redundancy. It is appropriately sized for a trivial zero-param informational tool, though it spends most of its words on marketing framing rather than tool guidance.

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 info endpoint with no output schema, the description is minimal but not broken: it establishes the tool returns a product overview. It is nonetheless thin on what the agent gets back and when to prefer it over the many sibling informational tools, leaving a real gap in routing.

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, which is the baseline-4 case. There is nothing for the description to disambiguate, and the schema correctly shows an empty properties object.

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 the resource ('Overview of Cryptbrew') and adds content scope ('business Bitcoin invoicing and tax-ready payment tracking for SMBs'), so an agent knows what the overview covers. However, 'Overview of Cryptbrew' largely restates the tool name 'cryptbrew_about', and there is no differentiation from near-neighbors like cryptbrew_how_it_works or cryptbrew_faq. Purpose is implied but not sharply distinguished from 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?

No when-to-use guidance is given, and the description does not contrast this tool with cryptbrew_how_it_works, cryptbrew_pricing, or cryptbrew_faq, all of which overlap in the 'about the product' space. An agent must guess which informational endpoint to call first.

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 disclosure burden. It does reveal the content categories returned (email, WhatsApp, setup visits, help pages), which is the primary behavioral trait for a static info tool, but it says nothing about the return shape or whether the content is static versus fetched live.

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?

A single short sentence with the resource named first and the contents enumerated. It is front-loaded and wastes no words, though the fragment style (a colon-list rather than a sentence) leaves it slightly bare.

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, no-output-schema informational tool, the description covers what the agent needs: it tells you the tool returns support/contact channels. Only the return format (structured list vs. prose) is unspecified, which is a minor gap at this complexity level.

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 there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4. The listing of content categories adds mild value but no parameter meaning is needed.

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 names a specific resource (Cryptbrew support and contact channels) and enumerates what it contains: email, WhatsApp, setup visits, help pages. That is clear enough for an agent to know it is an informational lookup. It does not, however, differentiate itself from close siblings such as cryptbrew_links or cryptbrew_faq, which could plausibly overlap.

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 this is the right tool when the user asks how to reach support or find help pages. There is no explicit 'use this when…' statement and no named alternative among the sibling tools, so the guidance is inferred rather than stated.

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 tells the agent this is a read-style Q&A tool and where its scope ends, but says nothing about answer format, sourcing, confidence, or rate limits. Adequate but thin 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?

One sentence for purpose plus one for routing — every clause earns its place and the core purpose 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 single-param, no-output-schema FAQ tool with no annotations, the description is nearly complete: purpose, scope, and the key sibling disambiguation. Only the absence of any behavioral note (answer format/sourcing) keeps it from a 5.

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 the single 'question' parameter. With zero undocumented parameters and no enum/nesting complexity, the description need not add syntax detail; baseline 4 for a fully-covered single parameter 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 a specific verb+resource: answer a Cryptbrew invoicing/product FAQ. It also names the sibling (cryptbrew_lock_info) it should defer to for Lock-only questions, letting an agent distinguish this from that tool without opening schemas.

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 routes Lock-only questions to cryptbrew_lock_info, giving a clear when-not-this-tool condition alongside the implied when-to-use (invoicing/product questions). Nothing is left to inference.

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 add value by disclosing the two underlying endpoints (/payments/health and /health), which hints at the check's scope. However it says nothing about auth requirements, rate limits, latency, or whether both endpoints must succeed, and 'fetch' only implies read-only 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?

A single front-loaded sentence that names the action, the resource, and the endpoints with zero filler. Every element 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 zero-parameter, no-output-schema health probe, the description covers what the agent needs: what it checks and where. Only the shape of the returned health data is left unstated, which is a minor gap for such a simple 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 tool takes zero parameters, so the baseline is 4. There is nothing for the description to clarify on the input side.

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') and resource ('Cryptbrew API health') and even names the exact endpoints queried. It is clearly distinct from the content-oriented siblings (pricing, faq, about), though it does not explicitly contrast itself with any of 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?

No explicit when-to-use or when-not-to-use statement, but the purpose (checking live API/service status) makes the usage context self-evident. No alternatives are named, so nothing is spelled out beyond implication.

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 supplied, so the description carries the burden, and it does imply a pure informational read with no side effects via the verb 'Explain'. However, it says nothing about the form or depth of the response (static doc text vs. generated summary), which would help an agent decide between this and cryptbrew_faq. A 3 reflects an implicit but adequate safety/behaviour signal.

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?

A single front-loaded sentence with no filler, listing the covered topics immediately. Every word earns its place and nothing is buried.

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, zero-annotation conceptual explainer with no output schema, the description names the exact subject matter an agent needs to route correctly. The only missing piece is the boundary against the similar about/faq siblings, which keeps it from a 5.

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 there are no parameter semantics to explain and the baseline of 4 applies. The description correctly avoids inventing arguments the schema does not support.

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 (Explain) and enumerates the three concrete topics covered: invoicing, payment forwarding, and the non-custody model. It is clearer than a bare name restatement, but it does not distinguish itself from near-neighbour siblings such as cryptbrew_about and cryptbrew_faq, which plausibly cover overlapping conceptual ground.

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?

No guidance on when to call this versus cryptbrew_about, cryptbrew_faq, or cryptbrew_pricing, all of which are plausible alternatives for a conceptual question. The agent must infer routing from topic names alone, with no exclusions or prerequisites stated.

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 the exact contents returned (website, help, support, downloads, llms.txt, API, App Store, health). For a zero-side-effect static link resource there is little further behavior to reveal, though it does not state the return shape (structured list vs. markdown).

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?

A single dense sentence that front-loads the resource type and then lists every entry; nothing is wasted. The lead-in phrase 'Official Cryptbrew invoicing URLs' is slightly garbled, since the listed links are not invoicing-specific.

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?

No output schema and no parameters exist, so the description is largely complete for such a simple static-links tool, enumerating the payload contents. It misses the response format and does not resolve the overlap with cryptbrew_health/cryptbrew_contact.

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 baseline of 4 applies; there is nothing for the description to clarify beyond what the schema already shows.

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 names a specific resource set (official Cryptbrew URLs) and enumerates the concrete links returned, so an agent knows exactly what it gets. It offers no differentiation from siblings, and the 'health' link overlaps confusingly with the sibling tool cryptbrew_health.

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 when-to-use statement, no condition that selects this tool over cryptbrew_health or cryptbrew_contact, and no mention of when a raw link list is preferable to those dedicated tools. Usage is only implied by the content list.

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 of behavioral disclosure. It lists product features but does not state that the tool is a read-only information source, describe the return format, or mention any side effects, permissions, or network 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 a single sentence that front-loads the product name and packs the key distinguishing details (separate Mac app, features, price, exclusion of invoicing). It is efficient, though the colon-separated list is dense and the tool action remains implicit.

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 parameterless info tool with no output schema, the description provides useful product content and disambiguation. However, it does not state what the tool returns or how it relates to the many sibling info tools, leaving meaningful gaps for an agent deciding whether to call 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?

The tool takes zero parameters, so there is no parameter semantics to document. By the baseline rule for 0 params, a score of 4 is appropriate because the description does not need to compensate for missing parameter details.

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 names the subject (CryptBrew Lock) and lists specific product attributes, but it never states what the tool actually does, such as returning information about CryptBrew Lock. It disambiguates from the 'invoicing 1% fee' product but does not differentiate from sibling tools like cryptbrew_about or cryptbrew_pricing.

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 'CryptBrew Lock only' and 'Not the invoicing 1% fee' imply a scope constraint, but there is no explicit guidance on when to use this tool versus the sibling tools (e.g., cryptbrew_pricing, cryptbrew_faq, cryptbrew_about). The agent is left to infer 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?

No annotations are provided, so the description carries the disclosure burden, and it does so by revealing the actual payload (fee rate, minimum, free iOS app) rather than just naming the topic. It is a static informational lookup with no implied mutation, so the risk surface is minimal; only return-shape details are absent.

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, zero padding. The subject is front-loaded ('Cryptbrew invoicing fees only') and the disambiguation clause follows immediately.

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 no-param, no-output-schema info tool, the description supplies the substantive answer content (the fee schedule) while disambiguating from Lock. An agent has enough to call it and describe the result; nothing essential is missing, though it says nothing about the fuller structure of the pricing response.

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?

Zero parameters, so the baseline is 4. The description correctly implies a parameterless informational call and adds no misleading parameter expectations.

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 precise scope: 'Cryptbrew invoicing fees only', and immediately enumerates the content (payment fee 1% min 10 sats, free iOS app). It also names the sibling it is NOT (CryptBrew Lock), so an agent can distinguish it from cryptbrew_lock_info without inspecting schemas.

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 when-not and the correct alternative: 'Not CryptBrew Lock — use cryptbrew_lock_info for Lock.' That routes the agent away from the most likely confusion. It does not, however, differentiate from the other six informational siblings (faq, about, how_it_works), so it falls short of full 5-level coverage.

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