satoshidata — Bitcoin entity intelligence

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

No annotations are provided, so the description carries full burden. It mentions 'optional risk_check' and 'component statuses', but the input schema lacks a risk_check parameter, causing confusion. The description gives a reasonable overview but misses details like output format or rate limits, despite having an output schema.

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 concise sentences: first states the primary action, second lists contents and key constraint. No extraneous words, front-loaded with 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?

The description covers the report's contents and the evidence-only constraint, but fails to explain the 'optional risk_check' (not in schema) and lacks details on when to use this versus sibling tools. Despite an output schema existing, the description could be more 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 coverage is 100%, so baseline is 3. The description adds minimal additional meaning beyond schema descriptions (e.g., 'Flow-graph depth when include_graph=true' only paraphrases). No extra parameter semantics are provided.

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 states the tool returns a 'free sectioned evidence report for one Bitcoin address' and lists its contents, distinguishing it from scoring/verdict tools by explicitly stating 'Evidence only: no score, verdict, clearance, or compliance recommendation.' This effectively differentiates it from siblings like address_risk or address_intelligence.

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 context by emphasizing 'Evidence only' and listing what is included, implying when to use (raw evidence) vs. evaluation tools. However, it does not explicitly state when not to use or name alternatives, which would strengthen 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?

No annotations are provided, so the description carries the full burden. It mentions the output includes 'current best label, live wallet activity, cohort hints, and scanner signals,' but doesn't disclose potential rate limits, privacy implications, or whether the tool is read-only. This is adequate but could be more explicit.

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, well-structured sentence that front-loads the key action ('Return') and resource, then lists included elements. Every word adds value with no redundancy.

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?

The tool has one parameter and an output schema (not shown but indicated as present). The description covers the purpose and output contents sufficiently for an AI to understand what the tool does. Given the low complexity and rich sibling context, this is nearly 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% (one parameter with a clear description). The description adds minimal extra meaning by specifying 'single Bitcoin address,' which reinforces the schema. Since the schema already explains the parameter well, the baseline score 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?

The description clearly states the tool returns an 'address-intelligence card' for a single Bitcoin address, specifying the verb 'Return' and the resource. It lists included data types (label, activity, hints, signals), which distinguishes it from sibling tools like 'address_risk' or 'address_evidence_pack'.

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 no guidance on when to use this tool versus alternatives (e.g., batch_intelligence for multiple addresses). It only implies single-address usage via 'a single Bitcoin address' but doesn't explicitly state when not to use it.

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 provided. The description discloses that the output is factual and includes an informational-only disclaimer, implying non-authoritative status. However, it does not mention side effects, data freshness, authorization requirements, or whether the tool is read-only. More details would be beneficial.

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 extremely concise—two sentences that immediately state what the tool returns and add a disclaimer. Every sentence is essential and well-placed.

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 the presence of an output schema, the description does not need to detail return values. However, with only one parameter and many siblings, the description should cover parameter semantics and usage guidance. It partially meets completeness but has clear gaps.

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 only parameter 'address' has no description in the schema, and the tool description adds no semantics beyond its name. Schema description coverage is 0%. The description fails to explain what kind of address is expected (e.g., blockchain address).

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 states what the tool does: returns factual address risk signals including entity label/category, source count, behavioral flags, coarse risk indicator, and a disclaimer. It also clarifies what it is not (AML/KYT/compliance advice). However, it could further differentiate from siblings like address_evidence_pack or risk_check.

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 does not explicitly state when to use this tool versus alternatives. With many sibling tools like address_evidence_pack, address_intelligence, and risk_check, the lack of usage guidance is a notable gap.

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 provided, so description carries full burden. It mentions forwarding auth headers but does not disclose if the operation is read-only, any rate limits, or response format details beyond what output schema provides.

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 concise sentences that front-load the core purpose and add only essential information about auth forwarding.

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 output schema exists and tool is straightforward, description is fairly complete. However, could mention potential address limit or relationship to sibling tools.

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 parameter description is clear. The description does not add additional meaning beyond what the schema already provides.

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 states it returns 'address-intelligence cards for multiple Bitcoin addresses in one call', distinguishing it from single-address tools like 'address_intelligence'.

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 guidance on when to use this vs alternatives like 'address_intelligence' for single addresses or 'batch_risk_signals' for risk. Implied for batch use, but lacks 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?

No annotations are provided, so the description bears full weight. It discloses authentication forwarding ('Forwards X-WR-API-Key/Bearer auth') and labels the output as 'factual label-derived', but does not mention rate limits, idempotency, error behavior, or the fact that it is a read operation. With no annotations, more transparency would be beneficial.

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 concise sentences with no redundancy. The description is front-loaded with the main purpose, then adds the auth note. It earns its space without being verbose.

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?

Despite an output schema existing, the description remains minimal. It lacks details on the format of 'risk indicators', maximum batch size, or how this tool differs from closely related siblings like batch_trust_safety or risk_check_batch. An agent would need more context to decide when to use this 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?

Schema coverage is 100% for the single parameter 'addresses', with a description. The tool description does not add any additional context or semantics beyond what the schema already provides, meeting the baseline for high 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 it returns 'factual label-derived risk indicators for multiple Bitcoin addresses in one call', specifying the verb and resource. It distinguishes from single-address tools like address_risk by indicating batch operation, but does not explicitly differentiate from sibling batch risk tools like batch_trust_safety or risk_check_batch.

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 guidance on when to use this tool versus alternatives. The description implies batch usage but does not mention prerequisites, limits, or situations where other tools might be preferred.

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, description carries full burden. It discloses auth forwarding behavior (X-WR-API-Key/Bearer), which is useful. However, it does not mention idempotency, rate limits, or data freshness. No contradictions with annotations since none exist.

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, 21 words, front-loaded with core function. No wasted words; every sentence provides essential 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?

Given simple structure (one parameter, output schema exists), description covers core purpose and auth forwarding. Lacks mention of batch size limits or behavior on invalid addresses, but overall adequate for a straightforward batch retrieval 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?

Schema coverage is 100% with the single parameter having a description in schema. Description adds no additional meaning beyond what schema provides (array of Bitcoin addresses). 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?

Description clearly states it returns wallet/entity summaries for multiple Bitcoin addresses in one call. Uses specific verb 'Return' and resource. However, it does not explicitly differentiate from sibling batch tools like batch_intelligence or batch_risk_signals, though the resource type differs.

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 guidance on when to use this tool versus alternatives. Implicitly suggests batch efficiency ('in one call') but lacks when-not-to use or comparisons to siblings like wallet_summary or other batch endpoints.

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 full burden. It mentions auth forwarding and returning a payload, but does not disclose whether the operation is read-only, idempotent, or has rate limits. The behavioral traits are minimally addressed.

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 front-loaded with the core purpose, followed by essential auth and return type info. 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?

Given a simple single-parameter tool with an output schema, the description covers the basic purpose and auth handling adequately. A little more detail on return structure could be added, but it is sufficient.

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 description merely repeats the schema's parameter description ('Bitcoin addresses to look up, in result order'), adding no additional meaning beyond what the schema already provides.

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 explicitly states the verb 'look up', the resource 'labels and trust-safety signals', and the scope 'multiple Bitcoin addresses in one call', clearly distinguishing it from sibling tools like wallet_trust_safety.

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 efficiency by saying 'in one call' and mentions auth forwarding, but does not explicitly state when to use this tool over alternatives like batch_intelligence or batch_risk_signals.

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 provided, so the description carries full burden. It states the return value (price and change) but does not disclose data source reliability, update frequency, API limits, or error conditions. Minimal transparency.

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 with no unnecessary words. It is appropriately front-loaded and efficient.

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 parameters and an output schema, the description is somewhat complete but lacks behavioral context such as latency, caching, or source. Adequate but could be improved.

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?

No parameters, so schema coverage is 100%. The description adds meaning by specifying 'current' and '24 hour change' beyond the empty schema. With 0 parameters, baseline is 4, and the description adds value.

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 states the tool returns the current Bitcoin price snapshot and 24-hour change from satoshidata.ai. The verb 'Return' and specific resource 'Bitcoin price snapshot' make it distinct from sibling tools which focus on addresses, blocks, transactions, etc.

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 guidance on when to use this tool vs alternatives. However, since there are no other price-related tools among siblings, usage is implicit. A score of 3 reflects the absence of explicit context or conditions.

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 provided, the description carries the full burden. It discloses the tool returns data (implying read-only), but does not explicitly state it is non-destructive, mention authentication needs, rate limits, or data freshness. The disclosure is adequate but minimal.

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, efficient sentence with no wasted words. It front-loads the action and resource, making it easy to parse.

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 the tool's simplicity (one parameter, no annotations, output schema exists), the description is mostly complete. It specifies the three main outputs (metadata, attribution, sample) and the input type. Minor omission: no indication of the sample size or format, but the output schema can cover that.

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 0% description coverage for the single parameter 'height_or_hash'. The description adds meaning by stating it accepts 'a height or block hash', clarifying the type of string value expected. This is a clear improvement over the bare 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 clearly states the tool returns Bitcoin block metadata, coinbase attribution, and a transaction sample, specifying the input as a height or block hash. It uses a specific verb ('Return') and resource, and distinguishes from sibling tools like pool_detail or wallet_detail.

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 no guidance on when to use this tool versus alternatives, such as when to use pool_detail for pools or other tools for different data. There is no mention of prerequisites or best contexts.

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 of behavioral disclosure. It mentions forwarding payment headers (useful for auth context) and implies read-only by 'Return', but does not explicitly state safety, mutability, or rate limits.

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 filler: the first states purpose, the second lists filters and auth forwarding. Every sentence earns its place and 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?

Given 8 parameters and the existence of an output schema, the description covers the main filters but omits pagination details (cursor) and does not explain what constitutes a 'dormant-coin awakening event'. It is adequate but not thorough.

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 baseline is 3. The description merely lists filter categories already documented in the schema, adding no new parameter-level meaning beyond what the schema descriptions provide.

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 states it returns 'dormant-coin awakening events over a bounded window', using a specific verb and resource. However, it does not differentiate from the sibling tool 'dormancy_flushes', which may cover similar events.

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 is provided on when to use this tool versus alternatives like 'dormancy_flushes'. The description only lists filters without indicating prerequisites or when not to use it.

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 are absent, so the description must carry the behavioral transparency burden. It mentions 'recent' but does not define recency, ordering, pagination, or any side effects. As a read operation, destructive hints are not needed, but data freshness and scope are unclear.

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, front-loading the key action. However, it omits essential details and lacks structure. It is concise but insufficient for completeness.

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 an output schema present, return values are covered. However, the description fails to explain parameters and behavioral expectations. The tool has three parameters and many siblings, so more context is needed.

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%, yet the description provides no explanation for any of the three parameters (limit, since, classification). The classification categories are mentioned in the description, but without mapping to the parameter. This is a critical gap.

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 states the action ('Return'), the resource ('recent CMCS dormancy awakenings'), and the classification categories. It conveys the core functionality, but does not differentiate from sibling tools like 'chain_awakenings' or 'pulse_dormant'.

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 use this tool versus alternatives. The description implies it's for retrieving classified dormancy flushes, but does not specify prerequisites, context, or exclude other tools.

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 provided, the description carries the full burden of behavioral disclosure. It only states what the tool returns but does not mention whether it is read-only, requires authentication, has rate limits, or any side effects. This is insufficient transparency for an agent to safely invoke the 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?

The description is a single sentence that efficiently conveys the tool's purpose. No extraneous words, and the key output components are listed. It is front-loaded with the main action.

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 the tool's low complexity (zero parameters, no nested objects), and the presence of an output schema, the description is complete enough. It explains the main return elements, and the output schema covers the details. No additional context is necessary.

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 no parameters, so the schema coverage is 100%. Following the baseline rule for zero parameters, a score of 4 is appropriate. The description does not need to add parameter information, and it does not.

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 states the tool returns Bitcoin entity rollup categories, counts, and coverage_status distributions. It uses a specific verb and identifies the resource, but does not explicitly distinguish it from sibling tools like 'entity_list' or 'entity_lookup' which might also return entity-related 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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, contexts, or exclusions, which is a gap given the many sibling entity-related tools.

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 full burden. It clarifies that 'last_activity_at' is label-DB activity, not on-chain time, and explains 'coverage_status' values. This adds behavioral context beyond the schema.

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 long, with the main purpose in the first sentence and clarifying details in the second. No extraneous 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?

Given that an output schema exists (handling return values), the description adequately covers the key output fields. No auth or performance details are needed for a simple list 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?

Schema description coverage is 100%, so baseline is 3. The description does not add extra meaning for input parameters (sort, limit, category) beyond what the schema already provides.

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 ('Return named Bitcoin entity rollups') and clearly states the resource and optional filtering. It distinguishes the tool from siblings like 'entity_lookup' which returns a single entity, and 'entity_categories' which likely returns category metadata.

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 usage for listing entities with optional category filter but provides no explicit guidance on when to use this tool vs alternatives like 'entity_categories' or search tools. No when-not-to-use or prerequisite context is given.

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 adds value by explaining output fields (coverage_status values, last_activity_at meaning) and clarifying that last_activity_at is label-DB, not on-chain. However, it doesn't state read-only nature or potential costs.

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, no redundant words. First sentence captures core purpose, second adds critical context. Efficient and 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?

Adequate given output schema exists (so return format partially covered). But missing input behavior (e.g., invalid entity_name) and no annotation context. Leaves some gaps for a simple lookup 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?

Schema coverage is 0%, so description should compensate. It partially explains 'entity_name' implicitly but doesn't specify format or validity. 'member_limit' is hinted as 'bounded' but no explicit description of its effect or range.

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 states it returns 'one named Bitcoin entity rollup and a bounded member-address sample', specifying the verb, resource, and scope. It distinguishes from siblings like entity_list (which lists multiple entities) and entity_categories (categories).

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 use this tool vs alternatives like entity_list or entity_categories. It does not mention prerequisites, exclusions, or typical use cases.

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 exist, so the description must disclose behavioral traits. It mentions 'bounded' and 'small' but does not clarify auth needs, rate limits, data freshness, or whether the sample is deterministic.

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 with no waste, appropriate for a simple tool. However, it sacrifices critical information for brevity.

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 3 parameters, no annotations, and many sibling tools, the description lacks sufficient context. It does not explain the concept of 'small entity' or the meaning of 'bounded', making it inadequate for an agent.

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%, and the description adds no meaning to parameters like 'limit', 'since', or 'entity_name'. It fails to compensate for the lack of parameter documentation.

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 states the verb 'Return', the resource 'recent on-chain activity sample', and the target 'small named Bitcoin entity'. This distinguishes it from sibling tools like entity_list or entity_lookup.

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 guidance on when to use this tool versus alternatives. The description implies 'recent' and 'small' but does not define these terms or provide when-not use cases.

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 provided, the description carries the full burden. It indicates the tool returns fee estimates but does not disclose potential rate limits, side effects (unlikely), or that it is a read-only operation. This is minimally acceptable.

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 with no redundant words. It is front-loaded and efficiently conveys the tool's 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?

Given the lack of parameters and presence of an output schema (not shown), the description adequately states what the tool returns. It could mention fee tiers (low/medium/high), but the output schema likely covers that.

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 are zero parameters, so baseline is 4. The description does not need to add parameter information, and it provides no unnecessary detail.

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 states the verb 'Return', the specific resource 'current recommended Bitcoin fee estimates', and the source 'satoshidata.ai'. It is distinct from all sibling tools, none of which mention fee estimates.

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 guidance is provided on when to use this tool versus alternatives like mempool_stats or network_intelligence. However, its simplicity makes the use case obvious, so it is adequate but not excellent.

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 must carry the full burden. It discloses the tool returns 'current' data (implying real-time) but does not elaborate on data freshness, caching, side effects, or any rate limits. The brevity leaves behavioral gaps.

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 efficiently conveys the purpose and outputs without unnecessary words. It is well front-loaded and contains no redundant 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 simple no-parameter tool with an output schema, the description adequately covers the key return fields (size, fee floor, congestion summary). It could mention data freshness or that it is read-only, but it is near complete 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 tool has zero parameters, so the description does not need to document parameter details. The schema coverage is effectively 100% (empty schema), and the description adds no additional parameter context, which is acceptable given no parameters 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 clearly states the tool returns Bitcoin mempool data including size, fee floor, and congestion summary. The verb 'Return' and specific resource 'current Bitcoin mempool' make the purpose unambiguous and distinguish it from sibling tools like 'mempool_stress' or 'mempool_tx'.

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 is provided on when to use this tool versus alternatives. While the tool is simple and stateless, the description doesn't mention prerequisites, exclusions, or specific contexts where it's preferred over other mempool-related tools.

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 discloses that the tool forwards authentication headers and that parameters control a premium payload, but the premium payload behavior is undefined. Not contradictory.

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 with the purpose front-loaded. Concise without wasted words, though some details could be expanded.

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 the output schema exists, return values need not be explained. However, the description lacks context on when to use the tool, the nature of the premium payload, and does not fully cover parameter semantics.

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 0%, so the description must explain parameters. It adds a range hint for history_hours (1-168) and a boolean toggle for include_components, but the exact effect is vague ('Premium component/history payload') and the 'or' suggests mutual exclusivity not reflected in 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 clearly states it returns the current mempool-stress index, which is a specific verb and resource. However, it does not distinguish this tool from sibling tools like mempool_stats.

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 guidance on when to use this tool versus alternatives. It mentions premium payload options but does not contrast with other mempool-related tools.

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 indicates the tool is read-only ('inspect') and scoped to unconfirmed transactions. However, it does not disclose details like output format or potential errors.

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, short sentence that conveys the essential information without any unnecessary 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?

Given the single required parameter and the existence of an output schema, the description is complete enough for an AI agent to understand the tool's purpose and scope.

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 0% schema description coverage, the description should compensate. The only parameter 'txid' is self-explanatory, and the description adds context by specifying 'unconfirmed'. However, it does not explain the format or expected value beyond what the name implies.

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 'Inspect' and clearly identifies the resource: 'a single unconfirmed Bitcoin transaction currently in the mempool'. This distinguishes it from siblings like 'mempool_stats' or 'tx_status'.

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 is provided on when to use this tool versus alternatives such as 'tx_status' for confirmed transactions. The description does not mention 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?

No annotations are provided, so the description must carry the full burden. It explains endpoint routing but does not disclose behavior when multiple parameters are provided, rate limits, authentication needs, or error handling. The return value is implied as 'attribution', but no details about the output structure.

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 with no wasted words. The first sentence states the purpose and identifiers, the second maps them to endpoints. Highly efficient.

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 the tool's simplicity (4 optional params, output schema exists), the description covers the main usage patterns. It is complete enough for a lookup tool, though it could mention what happens with no parameters or prioritize between multiple provided identifiers.

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. It groups block_hash and block_height together and mentions address and pool_name, but does not explain constraints (e.g., exact format, or that they might be mutually exclusive). It adds basic meaning but lacks depth.

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 states it returns mining-pool attribution, specifies three distinct identifiers (block height/hash, pool name, address), and distinguishes itself from sibling tools like pool_detail and pool_list by specifying the endpoint resources.

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 explicitly maps parameters to different endpoints ('Block identifiers use /v1/blocks, pool names use /v1/pools/{pool_name}, and addresses use wallet trust-safety.'), providing clear context on when to use each parameter. However, it does not mention when not to use this tool or compare it directly to 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?

No annotations are provided, so the description bears the full burden. It discloses that the tool returns aggregated data and that include_charts controls chart arrays. It does not discuss side effects, permissions, rate limits, or data freshness, but the content is consistent with a read-only aggregate 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?

Two sentences effectively communicate purpose and parameter usage. No redundant information; front-loaded with the core function.

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 that an output schema exists (not shown), the description need not detail return values. It lists the main data areas covered. It is sufficiently complete for a summary tool, though could mention data latency or error conditions.

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. It adds meaning by specifying that include_charts should be set to true only when chart arrays are needed, clarifying the parameter's purpose 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?

Description clearly states it returns a combined Bitcoin network summary including price, fees, mempool, blocks, and chain-intelligence context. This distinguishes it from sibling tools that provide individual components.

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 gives context for when to use this tool (when a combined summary is needed) and provides guidance on the include_charts parameter. However, it does not explicitly state when not to use it or explicitly recommend alternatives for detailed data.

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 burden. It declares the tool returns a snapshot, implying a read-only, non-destructive operation. This is sufficient for a simple data retrieval tool, though it could mention that it does not modify any state.

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, concise sentence with no extraneous information. Every word earns its place, making it appropriately brief for a simple 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?

The tool has an output schema that presumably details the returned fields, so the description does not need to explain return values. The description is complete for a snapshot tool, though it could briefly mention what categories (e.g., price, hash rate) are included.

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, so schema coverage is trivially 100%. Per guidelines, baseline for 0 parameters is 4. The description adds no parameter-level details, which is acceptable since there are none to elaborate.

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 states it returns a 'current on-chain market and network snapshot' from satoshidata.ai. The verb 'Return' and resource 'snapshot' are specific. Among siblings like bitcoin_price or network_intelligence, this tool distinguishes itself as a broad overview, making its purpose 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?

No explicit guidance is given on when to use this tool versus alternatives. However, as a parameterless snapshot, its use is implicitly understood for getting a quick overview. Lacking exclusions or references to siblings, it scores minimally adequate.

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 must fully disclose behavioral traits. It only states the action but does not mention side effects (e.g., read-only), failure modes (e.g., no OP_RETURN), or dependencies such as transaction availability.

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?

Single sentence with no redundant words, front-loading the action and resources. It is concise and to the point.

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 the output schema exists, return values need not be described. However, the description omits any context about supported protocols, error conditions, or behavior when no OP_RETURN is present. It is borderline adequate 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?

Schema description coverage is 0% and the description adds no detail about the 'txid' parameter beyond its name. While the purpose implies it's a Bitcoin transaction ID, format or validation expectations are not clarified.

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 states the tool's action ('Decode') and specific resources ('OP_RETURN protocol markers and ordinals inscription envelopes') for a particular input type ('Bitcoin transaction'). This is distinct from sibling tools that focus on addresses, blocks, mempool, etc.

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 is provided on when to use this tool versus alternatives, or prerequisites (e.g., the transaction must contain OP_RETURN data). The description lacks usage context entirely.

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 are absent, so description carries full burden. Only mentions 'free' but does not disclose read-only nature, error behavior, or permissions. Lacks critical behavioral details.

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?

Single sentence is concise, but so brief that it sacrifices clarity. Could be expanded to include key details without becoming verbose.

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?

Despite having an output schema, the description fails to explain what 'detail' includes or how to use the output. Lacks overview of functionality and edge cases.

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?

Parameter 'pool_name' has 0% schema description coverage; description only says 'named pool' which adds no meaning beyond the schema. No format or constraints explained.

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 it returns mining-pool detail for a named pool, which is a specific verb and resource. However, it does not differentiate from sibling tools like 'pool_list' or 'mining_pool_info'.

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 use this tool versus alternatives. No context about prerequisites or typical use cases.

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, and the description only mentions 'free' and 'recent block-share windows'. It does not disclose rate limits, caching behavior, or whether the data is real-time. This is minimal transparency for an unannotated 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?

The description is a single, clear sentence with no unnecessary words. It is front-loaded with the action and object.

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 the tool has no parameters and an output schema exists (implied), the description adequately covers what the tool returns. It could mention whether the roster is a snapshot or live, but overall it is complete enough for a simple list 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?

There are no parameters (0 params, 100% schema coverage), so the bar is lower. The description adds value by specifying the data source ('free satoshidata.ai') and the window context ('recent block-share windows'), going beyond the empty 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 clearly states the tool returns a 'mining-pool roster' with 'recent block-share windows'. The verb 'Return' and the specific resource 'roster' distinguish it from sibling tools like mining_pool_info and pool_detail, which likely focus on individual pool details.

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 usage when a list of mining pools is needed, but it does not explicitly state when to use this tool over siblings like mining_pool_info or pool_detail. No exclusions or alternatives are mentioned.

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 disclose behavioral traits but only states the tool returns data. It omits details like read-only nature, rate limits, or what happens to the data.

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, making it concise, but it sacrifices completeness by not including parameter or usage details.

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 4 parameters and no schema descriptions, the description is incomplete. It does not explain what consolidation candidates are, what the output contains (despite having an output schema), or how to use the parameters effectively.

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%, yet the description does not explain any parameters (limit, since, min_btc, min_inputs) or their meanings, adding no value beyond the bare 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 clearly states the tool returns recent consolidation candidates from a specific live feed, using a specific verb and resource. It implicitly differentiates from sibling tools like pulse_whales or pulse_dormant by topic, though it does not explicitly call out alternatives.

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 is provided on when to use this tool versus alternatives, nor any prerequisites or context for its use.

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 full burden for behavioral traits, but it only states the tool returns data. It does not mention data freshness, pagination, rate limits, or any side effects. The output schema exists but its content is absent, limiting transparency.

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 short sentence, which is concise and front-loaded. However, it could include essential parameter or usage information without losing conciseness, so it earns a 4 rather than a 5.

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 the tool has 4 parameters with no schema descriptions and an output schema not explained, the description is insufficient. It does not clarify what constitutes a dormant-coin reactivation, how filtering works, or what the output looks like, leaving the agent under-informed.

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 0%, meaning parameters have no descriptions in the schema, and the description does not mention any of the 4 parameters (limit, since, min_btc, min_age_years). The description adds no meaning beyond the schema, which itself provides no explanations.

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 states the tool returns 'recent dormant-coin reactivations' from a named feed. The verb 'return' is vague but acceptable, and it distinguishes from siblings by specifying the focus on dormant coin reactivations rather than consolidations or whales.

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 is given on when to use this tool versus alternatives like pulse_whales or pulse_summary. Usage context is implied but not explicit; there are no when-to-use or when-not-to-use instructions.

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 must carry behavioral transparency. It accurately describes the tool as returning health and event totals, implying a read-only operation, but does not explicitly mention safety, rate limits, or side effects. Adequate for a simple query 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?

The description is a single sentence with no wasted words, effectively communicating the tool's 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?

Given no parameters and the presence of an output schema (not detailed here but indicated), the description is sufficient for understanding the tool's function. It does not explain return values, but the output schema covers that. Brief but complete for a simple health summary 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?

No parameters exist, and schema coverage is 100%. The description does not need to add parameter information. Baseline for 0 parameters is 4, and the description meets that without issues.

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 states the verb 'return' and the resource 'satoshidata.ai on-chain Pulse scanner health and 24-hour event totals'. It distinguishes from sibling tools that focus on specific event types like pulse_consolidations or pulse_dormant.

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 use this tool versus siblings or alternatives. The description does not specify context or exclusions; it only states what the tool returns.

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 exist, so the description carries full burden. It only states it 'returns' data, implying a read operation, but fails to disclose how 'recent' or 'large' is defined, data freshness, rate limits, or idempotency. Minimal behavioral context.

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 very short and front-loaded with the main purpose. However, it is too brief, sacrificing essential details for brevity. It earns its place but lacks completeness.

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 3 parameters, no schema descriptions, and an output schema, the description omits parameter context and behavioral traits. It does not describe what constitutes a 'movement' or how parameters filter results, making it incomplete for effective use.

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%, yet the description adds no meaning to the parameters (limit, since, min_btc). It does not explain their roles or how they affect results, leaving the agent to infer from defaults only.

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 states the tool returns 'recent large Bitcoin movements' from a specific source (satoshidata.ai's Pulse feed), which is a specific verb and resource. However, it does not differentiate from sibling tools like whale_alerts or pulse_consolidations.

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 use this tool versus alternatives. With many sibling tools such as whale_alerts and pulse_consolidations, the agent would benefit from context on when to prefer this over others, but none is provided.

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 cover behavioral traits. It mentions 'free' and 'not a recommendation', but does not disclose whether the tool is read-only, requires authentication, or has rate limits. It implies a safe screening operation but lacks explicit transparency.

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, well-structured sentence that immediately conveys the core purpose and key nuance. No extraneous 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?

Given the presence of an output schema, the description can be concise. It provides essential context for a simple tool, but could benefit from briefly explaining what 'evidence + confidence' means.

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 has no description and 0% schema coverage. The description only mentions 'one address' but does not clarify format, constraints, or usage of the single parameter. This is insufficient for an agent to correctly invoke the tool.

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 specifies the tool returns a 'free evidence + confidence BTC screening bundle for one address', which clearly states the verb and resource. However, it does not explicitly differentiate from siblings like 'address_risk' or 'risk_check_batch'.

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 disclaimer 'not a recommendation; you decide whether to transact' provides some usage context, but no guidance on when to use this tool versus alternative sibling tools like 'address_risk' or 'batch_risk_signals'.

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 provided. Description adds 'free' (cost), 'up to 100' (limit), and 'bundles' (structure). Lacks details on idempotency, side effects, auth requirements, or error handling. Moderate transparency.

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?

Single sentence, 16 words. Front-loaded with purpose and clear delimiter. No unnecessary 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?

Output schema exists, so return values are covered. Description could mention address validation or required format, but overall sufficient for a simple batch 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?

Schema has 100% coverage; description adds the constraint 'up to 100 addresses', which is not in the schema. Adds value beyond the basic parameter 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?

Description clearly states it returns 'free evidence + confidence BTC screening bundles for up to 100 addresses'. It explicitly says what it does NOT do ('not recommendations'), distinguishing it from risk_check (single address) and other batch tools by scope and intent.

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?

Implies use for screening multiple addresses but does not contrast with sibling batch tools like batch_risk_signals or batch_intelligence. No explicit when-to-use or when-not-to-use 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?

No annotations are provided, so the description carries the full burden. It discloses that feedback is submitted but fails to mention side effects (e.g., whether feedback is stored, rate limits, authentication needs, or confirmation). The output schema exists but is not referenced.

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, front-loading the core purpose. It is efficient, though it could include more detail without becoming verbose.

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 the tool's complexity (14 parameters, no schema descriptions, no annotations), the description is insufficient. It does not explain parameter usage, feedback format, or expected outcomes. The presence of an output schema helps but is not integrated.

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 14 parameters and 0% schema description coverage, the description should compensate but does not. It only lists some feedback types in general terms; individual parameter meanings (e.g., 'asks', 'reason', 'address') are not explained, leaving the agent unclear on how to populate them for different feedback types.

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 states the tool's purpose: submitting various types of feedback (label corrections, missing-label suggestions, data-quality reports, general feedback). It uses specific verbs and resources, and is easily distinguished from sibling tools which are all blockchain data queries.

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 usage for feedback submission but does not explicitly state when to use this tool vs. alternatives. Given that siblings are unrelated (blockchain data), the context is clear, but there is no guidance on when not to use it or any 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?

No annotations provided, so description carries full burden. States 'submit' implying mutation, but does not disclose side effects, idempotency, or what happens to the submitted digest. Lacks behavioral details.

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?

Description is a single, direct sentence with no extraneous words. Efficiently conveys core 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?

Tool has output schema but no description of return values. For a batch submission tool, missing info on success/failure, errors, and limits. Incomplete for the complexity.

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 0% and description only says 'SHA-256 digest' for hash_hex. Does not specify expected hex format, length, leading zeroes, or encoding. Minimal value added beyond 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?

Description clearly states the action (submit), resource (SHA-256 digest), and target (satoshidata.ai's Bitcoin timestamping batch). It is specific and distinguishes from siblings like timestamp_quote or verify_timestamp.

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 use this tool versus alternatives. Context on prerequisites, such as needing a quote or when batching is appropriate, is absent.

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 provided, so description carries the burden. It clearly states 'return' and describes the output as a quote, implying non-destructive read operation. Safe to assume no side effects.

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 sentence that is front-loaded with the key verb 'return' and immediately provides the object type and what it contains. 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?

With zero parameters and an output schema present, the description adequately summarizes the return value. However, it could mention that this is used before calling timestamp_hash or similar.

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?

No parameters exist (0 params, 100% schema coverage from empty schema). Baseline score of 4 applies, but description adds value by specifying the output components.

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?

Clearly states it returns a 'Bitcoin timestamping preflight quote' with specific components (fixed service fee and anchor-fee share). This verb+resource is unique among 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?

Implied usage: when you need a preflight quote before submitting a timestamp. No explicit when-not-to-use or alternative tools mentioned, despite sibling tools like timestamp_hash.

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 must disclose behavioral traits. It does not mention side effects (e.g., irreversible broadcast, network fees), required authentication, or failure modes. The description is minimal and lacks transparency.

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 concise sentence, but it lacks essential details. While it is not verbose, it sacrifices completeness for brevity, making it only minimally adequate.

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 the complexity of broadcasting a transaction (critical action, irreversible), the description should explain return values (output schema exists but not described), error handling, idempotency, or network requirements. It fails to provide sufficient context for correct use.

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 0% schema description coverage, the description must add meaning to the 'hex' parameter. It adds value by specifying it is a 'fully signed raw Bitcoin transaction hex', but does not provide format details, length constraints, or examples, which are critical for correct invocation.

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 states the action (broadcast) and the specific resource (fully signed raw Bitcoin transaction hex). It distinguishes from sibling tools like tx_status and tx_verify, which are for checking status or verifying, not broadcasting.

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 is provided on when to use this tool versus alternatives. For example, it does not mention prerequisites (e.g., transaction must be signed) or post-conditions (e.g., use tx_status for confirmation).

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 provided, the description carries full burden. It discloses the exact output (four statuses) and implies a read-only operation. Could mention non-destructiveness or no side effects, but current text is adequate.

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?

Single sentence, front-loaded with action and output. 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?

Given the tool's simplicity (one parameter, output schema exists), the description is mostly adequate but lacks explanation of the input parameter and does not hint at the output schema structure.

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%, yet the description does not explain the txid parameter beyond its existence. It does not state that txid is a Bitcoin transaction hash, leaving agents to infer.

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 states the tool returns a Bitcoin transaction state check, listing four possible statuses: unknown, mempool, conflicted, confirmed. The word 'narrow' distinguishes it from more comprehensive transaction tools like mempool_tx or tx_verify.

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 usage for quick status checks but does not explicitly state when to use this tool versus alternatives or when not to use it.

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 should disclose behavioral traits like error handling, return format, or side effects. It only states the verification intent but not what happens on failure (e.g., insufficient confirmations, address mismatch) or whether it throws exceptions.

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 conveys the core purpose efficiently, with no filler. However, it could be slightly more structured (e.g., list parameters) without losing conciseness, but it remains appropriate.

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 4 required parameters and no schema descriptions, the description is insufficient for an agent to use correctly without ambiguity. The existence of an output schema slightly reduces the need to describe return values, but behavioral and parameter gaps remain.

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 0%, so the description must compensate. It vaguely maps 'enough sats' to min_amount_sats and 'enough confirmations' to min_confirmations, but offers no details on the other parameters (txid, expected_address) or their types/constraints, leaving ambiguity.

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 states it verifies that a transaction paid enough sats to the expected address with enough confirmations. This distinguishes it from siblings like tx_status (status only) and block_detail (block-level info), making the purpose specific and 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?

No usage guidance is provided; the description does not specify when to use this tool versus alternatives like address_risk or risk_check. The context hints at verification for payment confirmation, but explicit when/not-to-use information is absent.

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 not disclose outcomes (e.g., success/failure indicators), side effects, or requirements (e.g., network access).

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 and front-loaded with the core action. However, slightly more detail could improve clarity without sacrificing conciseness.

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?

The tool has a single parameter and an output schema, but the description omits important context such as input format, expected output, and potential failure modes. Some gaps remain for effective agent use.

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%, and the description does not explain the 'proof_base64' parameter beyond its name. No format, constraints, or examples are given.

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 states the action ('Verify') and the resource ('detached OpenTimestamps proof against the Bitcoin blockchain'), distinguishing it from sibling tools like 'timestamp_hash' and 'tx_verify'.

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 use this tool versus alternatives. Sibling tools exist (e.g., 'timestamp_hash', 'timestamp_quote', 'tx_verify') but no context is provided for selection.

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 full burden. It only says 'returns' (implying read-only) but lacks details on auth, rate limits, data freshness, or performance costs.

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?

Single sentence with no extraneous words. Front-loaded with verb and object. Fully 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?

An output schema exists, so return values need not be described. However, the term 'contributor depth and category distribution' is undefined. Given the many sibling tools, more context would help, but the description is minimally adequate.

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 0%, and the description does not add meaning beyond stating that the address is for a single Bitcoin address. It does not specify required format, network (mainnet/testnet), or any 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?

Description clearly states the action ('Return'), the resource ('contributor depth and category distribution'), and the scope ('for a single Bitcoin address'). It distinguishes from sibling tools like wallet_detail or wallet_summary by specifying what it returns.

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 use this tool versus alternatives like wallet_detail, wallet_summary, or wallet_flow_graph. The description does not provide use cases or 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?

No annotations exist, so the description should disclose behavioral traits. It implies a read-only operation but does not explicitly state safety, permissions, rate limits, or side effects. For a data retrieval tool, this is insufficient.

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, concise sentence that conveys the core purpose. It could be more structured but avoids verbosity.

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?

An output schema exists, reducing the need to explain return values. However, the description omits explanation of 'grouped ... label evidence' and how the output is organized, which is critical for agent understanding.

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 0% description coverage, yet the description only adds that the parameter is a Bitcoin address. No format guidance, validation rules, or relationship to the output are provided. Meaning is minimal.

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 specifies the action ('return'), the resource ('grouped satoshidata.ai label evidence and detail'), and the scope ('single Bitcoin address'). It is specific but does not differentiate from similar tools like address_evidence_pack.

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 is provided on when to use this tool versus its many siblings, such as address_intelligence or address_risk. No context on prerequisites or appropriate scenarios.

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 full burden. It mentions 'render-ready' but doesn't disclose behavioral traits like auth needs, rate limits, or output format. Adequate but minimal.

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 clear sentence with no wasted words, front-loading the core function.

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 8 parameters, full schema descriptions, and an output schema, the description is reasonably complete. It could add context on what 'render-ready' entails, but overall sufficient.

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 description adds little beyond the parameter descriptions. The baseline of 3 is appropriate as the description doesn't enhance parameter meaning.

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 'Return' and resource 'transaction-flow graph' for a Bitcoin wallet address. It clearly distinguishes from sibling tools like wallet_summary by focusing on graph visualization.

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 usage for obtaining a graph but offers no explicit when-to-use or alternatives guidance. With many sibling tools, this leaves the agent to infer context.

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 full burden for behavioral disclosure. It states 'Return' and 'summary,' suggesting a read operation, but does not disclose if there are rate limits, costs, or any side effects. For a tool with no annotations, more context about behavior (e.g., whether it is expensive or if the summary is cached) is needed.

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 of 13 words, front-loaded with the key information. It is efficiently written with no wasted words, earning 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?

The tool has an output schema (context says true), so return values are not needed in the description. The description is adequate for a simple 1-parameter tool, but given the many sibling tools, it could provide more context on when this summary is preferable over alternatives. Overall, it is minimally complete but not rich.

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 one parameter 'address' with 0% schema description coverage. The description confirms it is 'for a single Bitcoin address,' but adds no detail about expected format (e.g., legacy, bech32) or constraints. With such low coverage, the description should compensate more, but it only provides minimal confirmation.

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 states the action ('Return') and the resource ('premium satoshidata.ai chain intelligence summary for a single Bitcoin address'). It distinguishes from siblings by specifying 'premium chain intelligence summary' and limiting to a single address, which is unique among sibling tools like batch_summary or address_intelligence.

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 usage for a single Bitcoin address when a premium summary is needed, but it does not explicitly mention when not to use it or suggest alternatives (e.g., batch_summary for multiple addresses, address_intelligence for a simpler version). The context is clear but lacks exclusion or alternative 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?

The description adds minimal behavioral context beyond the 'free' and 'teaser' nature. With no annotations, it fails to disclose read-only status, authorization needs, or side effects. The only unique behavioral detail is the inclusion of an 'examined marker' when no category matches.

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 with no wasted words. It efficiently states the tool's action and a key output feature. It could be improved by adding structured sections, but it is appropriately sized for a simple 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?

Despite the presence of an output schema, the description leaves gaps: no explanation of what a 'teaser' entails, no input format details, and no context on when to use this tool. A more complete description would include prerequisites and example use cases.

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 description mentions a 'single address' but does not specify the expected format (e.g., legacy, segwit) or validation constraints. With 0% schema description coverage, the description partially compensates by naming the input, but lacks crucial format 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 uses a specific verb ('Return') and identifies the resource ('Bitcoin wallet trust and safety teaser for a single address'). However, it does not distinguish this tool from siblings like address_risk or address_intelligence, which likely serve similar purposes.

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 is provided on when to use this tool versus alternatives. The description mentions 'free' but does not clarify if it is for quick previews or when to prefer batch_trust_safety or other address tools.

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 full burden. It clearly states the tool returns recent large transfers with classification, and explains the range alias. It does not mention any destructive effects or authentication needs, but as a query 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 consists of three concise sentences. The first states the main purpose, the second explains the range parameter, and the third describes flow_direction (output classification). It is well-structured and front-loaded, though flow_direction explanation could be clarified as output.

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 the complexity of 5 parameters and an existing output schema, the description is mostly complete. It explains the classification output and the range alias. However, it does not discuss pagination or the meaning of flow_type filter beyond what schema provides.

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 descriptions for all parameters. The description adds minimal extra information beyond the schema: it clarifies the range alias (already in schema) and introduces flow_direction as output classification (not a parameter). This provides some value but does not significantly enhance parameter understanding.

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 ('Return') and resource ('recent large Bitcoin transfers with label-DB flow_type and flow_direction classification'). It clearly distinguishes from sibling tools like pulse_whales by emphasizing the classification aspect.

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 explains allowed values for range and flow_direction but does not provide explicit guidance on when to use this tool versus alternatives (e.g., pulse_whales). Usage context is implied but not explicitly stated.

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