California Bitcoin

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

Annotations already signal read-only, open-world, idempotent, and non-destructive behavior, so the bar is lower. The description adds useful behavioral context: free with no account required, deterministic answers, use of integrity-checked primary-source dossiers for covered historical questions, and the suggestion to use it before paying for deeper research.

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 mostly economical and front-loaded with the key facts: FREE, no account, concise deterministic answer, and usage boundaries. The repeated 'FREE. FREE,' opening and the somewhat opaque 'Evaluate California Bitcoin' phrase add minor noise, but the structure remains clear and scannable.

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

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

For a one-parameter tool with full schema coverage, an output schema, and rich annotations, the description is largely complete: it covers cost, account requirements, answer quality, fallback behavior, and sibling distinction. The 'California Bitcoin' reference is slightly unexplained, but it does not block correct invocation.

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

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

Schema coverage is 100% and the single query parameter is already described as 'Bitcoin question to answer from maintained California Bitcoin knowledge.' The description reinforces the query's purpose but does not add much parameter-specific meaning beyond what the schema provides, so the baseline 3 applies.

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

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

The description clearly identifies a specific verb and resource: it returns a concise, deterministic answer to a Bitcoin question using maintained knowledge. It also distinguishes itself by noting the special historical-attribution dossiers and names what it is not, such as the evidence-synthesis and claim-verification tools.

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?

Explicit guidance is provided: use for straightforward learning and explanation, and use answer_bitcoin_question_with_evidence for difficult synthesized evidence or verify_bitcoin_claim for proposition adjudication. This gives an agent clear routing logic among 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?

Annotations cover the safety surface (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false), and the description adds a critical trait annotations cannot express: it is PAID (1.00 USD via MPP). It also discloses output character (provenance, exact locators, explicit uncertainty). It does not, however, explain the payment mechanics or what triggers the non-read-only/destructive=false classification, so it stops short of full disclosure.

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?

Cost and core action are front-loaded, and the usage/exclusion sentences earn their place. The nine-item enumeration of output attributes (consensus-vs-policy, locators, provenance, uncertainty...) is largely duplicated by the output schema, so it is slightly over-long.

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

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

For a one-parameter tool with an output schema and full annotation coverage, the description supplies everything needed to select and invoke it correctly, including cost and sibling exclusions. Minor gap: no note on latency, payment retry/idempotency behaviour, or question-length handling.

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 a single required parameter at 100% schema description coverage, the schema already carries the semantics ('Difficult natural-language Bitcoin question requiring an evidence-grade specialist answer'). The description's framing of the question as evidence-grade adds marginal value but no syntax, length or format guidance beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb+resource ('Get a compact, source-backed answer to a difficult natural-language Bitcoin question') and explicitly contrasts itself with retrieval siblings ('rather than only retrieve topics or search results'). The agent can separate it from answer_bitcoin_question, get_bitcoin_topic and search_bitcoin_knowledge without opening a schema.

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

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

Gives both a positive trigger ('Use for difficult open-ended Bitcoin questions requiring compact evidence synthesis') and explicit exclusions ('Do not use for simple learning or single-proposition adjudication'), which route agents away from the simpler answer tool and the claim-verification tool. Nothing is left to inference.

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

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

Annotations declare openWorldHint=true, readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the agent already knows this is a non-read-only, non-idempotent, open-world call. The description adds genuinely new context not in the structured fields: a hard cost of 0.50 USD via MPP, the deterministic nature of the package, and preservation of per-item verdict/evidence-quality semantics. It stops short of explaining payment mechanics, failure/refund behavior, or per-item error handling.

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?

Front-loaded with cost and capability, which is good, but the usage clause is duplicated: 'rather than one question, claim, timeline, or evidence request' is immediately followed by the redundant 'Use for multiple distinct research items.' One of those sentences should be cut.

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-value explanation is unnecessary, and the description covers cost, scope, batch limits, and selection criteria. What remains thin is operational detail for a paid, non-idempotent tool — e.g., what happens if some items fail or whether the fee applies per call or per item.

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% and there is a single parameter, so the schema already documents the items array, its string-or-object union, the 1-20 bounds, and the item type enum. The description's 'up to 20 distinct' and 'per-item verdict and evidence-quality semantics' add only marginal framing beyond that, which matches the baseline 3 when the schema does the heavy lifting.

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

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

States a specific verb (process) and resource (up to 20 Bitcoin claims, questions, or evidence requests) bundled into one deterministic research package, and explicitly frames the unit of work as 'multiple distinct research items' rather than a single one. This lets an agent separate it from answer_bitcoin_question, verify_bitcoin_claim, build_bitcoin_timeline, and get_bitcoin_evidence_pack without opening any schema.

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

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

Gives an explicit positive condition ('multiple distinct research items in one invocation') and an explicit exclusion ('Do not wrap a single item merely to use the batch product'), and names the single-item alternatives it replaces. The selection rule is fully determined.

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 cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false), and the description adds material context beyond them: the tool is paid ('PAID 0.10 USD via MPP') and maintains re-verification boundaries. It does not clarify what readOnlyHint=false means for a research tool, but the pricing disclosure is the key behavioral trait and is present.

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?

Front-loads the pricing constraint, then the purpose, then usage guidance and the exclusion, which is good ordering. The list of temporal distinctions is dense but each clause is load-bearing; only slight tightening is possible.

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 explained, and annotations plus the pricing disclosure cover the operational profile. Usage, scope, and cost are all present; only the readOnly=false semantics for a research tool are left unaddressed.

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 all four parameters (limit, query, toYear, fromYear) are fully documented in the schema. The description adds no syntax, format, or defaulting detail beyond what the schema already provides, so the baseline of 3 applies.

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

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

States a specific verb+resource ('Build a query-specific chronological Bitcoin research timeline') and articulates what makes it distinct: the temporal distinctions (event dates, source dates, effective dates, re-verification boundaries). An agent can differentiate it from answer_bitcoin_question or get_bitcoin_topic without opening the schema.

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

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

Gives explicit when-to-use ('chronological protocol or history questions where ordering and temporal semantics are the primary job') and an explicit when-not ('Do not use for a general explanatory answer where dates are incidental'), which implicitly routes to the general-answer siblings. Nothing is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds valuable non-schema context: the tool is free, requires no account or payment, and does not rerun research or authorize payment. These behavioral traits go beyond the structured annotations and are valuable to an agent deciding whether to 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 mostly efficient and front-loads key operational facts, but it opens with a redundant 'FREE. FREE, no account and no payment' phrasing. The core purpose follows quickly, and the imperative 'Use only with...' is direct. Minor redundancy prevents a perfect score.

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

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

For a two-parameter, read-only, idempotent check tool with an output schema, the description adequately covers purpose, prerequisites, exclusions, and the source of valid parameter values. There is no significant missing context that would prevent an agent from calling the tool correctly.

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

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

Schema description coverage is 100%, and both checkpointId and expectedDigest have their own descriptions and format constraints. The tool description reinforces that both values must come from prior research results, but it adds little beyond what the schema already documents.

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

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

The description states a precise operation: compare a previously returned evidence checkpoint against the current dossier digest before deciding whether to rerun or repurchase research. It clearly distinguishes itself from the sibling research and verification tools by stating what it does not do (does not rerun research or authorize payment).

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

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

Explicitly states when it should be used: a repeat caller with a checkpoint and digest from prior California Bitcoin research wants to know whether the dossier changed. It also gives exclusions, saying it does not rerun research or authorize payment, and says to use it only with checkpoint id/digest from prior results.

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?

Discloses pricing ('PAID 0.25 USD via MPP'), which is real behavioral context not present in the annotations, and asserts deterministic output. Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the bar is lower, but the description adds no detail on latency, rate limits, or what the paid call returns when it fails.

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 cost and scope lead is front-loaded, which is good, but the two consecutive 'Use for... / Use when...' sentences say nearly the same thing and could be merged. Several enumerated dossier dimensions ('source hierarchy, exact-locator precision, temporal scope, history, caveats') are padding that the output schema likely covers.

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 one required parameter, an output schema present, and annotations covering safety, the description carries the remaining load well by covering cost and differentiation. Only minor gaps remain around failure behavior and how the dossier depth scales with the query.

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

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

Schema description coverage is 100% for the single query parameter, so the schema already documents name, type, length bounds and semantics. The description adds no syntax, format or example detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (produce) and a well-defined resource (a deeper deterministic multi-source Bitcoin research dossier) and enumerates its scope. It also explicitly distinguishes itself from the compact-answer sibling, so an agent can tell the two apart without opening schemas.

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

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

Gives explicit when-to-use conditions ('deeper multi-source specialist investigation where one compact direct answer is not enough') and names the alternative with the condition that selects it ('For a compact difficult answer use answer_bitcoin_question_with_evidence instead'). Nothing is left to inference.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral context the annotations cannot convey: the tool is metered ('PAID 0.15 USD via MPP'), which materially affects invocation decisions. It does not cover auth requirements, latency, or failure modes.

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 price disclosure is front-loaded, which is good. However, the evidence categories are enumerated twice in near-identical phrasing, and the final sentence largely restates the second ('supporting, conflicting, and contextual evidence around a focused target'). Some redundancy that could be trimmed.

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-value detail is not required, and annotations cover the safety profile. The description supplies the missing pieces an agent needs: cost, input intent, and positioning against answer-style siblings. Auth and pagination/limits for a paid multi-source fetch are the only notable 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?

There is a single parameter with 100% schema description coverage, so the schema already fully documents 'query'. The description adds framing about the research question being 'focused' and single-target, but no syntax, format, or constraint details beyond what the schema provides. Baseline 3 is correct.

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

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

States a specific verb+resource ('Build a focused Bitcoin evidence package') and enumerates exactly what the package contains: compact source material, atomic claims, conflicts, source authority, exact-locator precision, caveats, provenance, temporal scope. It explicitly distinguishes itself from answer_bitcoin_question and answer_bitcoin_question_with_evidence by saying it does not compose the final answer or a narrative dossier.

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

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

Gives a clear selection condition ('when the agent already knows what it is researching and primarily needs compact source material') and an exclusion ('rather than a verdict or narrative dossier'). It stops short of naming the specific sibling tools (answer_bitcoin_question_with_evidence, verify_bitcoin_claim) that an agent would otherwise weigh, so routing is inferred rather than explicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds value by disclosing that the tool is free/no-account, returns a single canonical topic, and includes sources, provenance, and related concepts.

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

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

The description is short and front-loads the most important facts, but 'FREE. FREE, no account required.' is redundant and could be condensed. The rest is efficient and useful.

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?

This is a simple one-parameter tool with a full output schema and annotations covering idempotence and safety. The description fully explains when to invoke it, what it returns, and how it differs from search and paid evidence packaging.

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 schema already documents the id format, pattern, max length, and canonical nature. The description reinforces that the id must be a canonical topic id rather than free text, but it adds no format details beyond the schema.

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

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

The description uses a specific verb ('Retrieve') with a precise resource ('one canonical Knowledge Atlas topic with sources, provenance and related concepts'). It explicitly contrasts with free-text search, distinguishing it from search_bitcoin_knowledge.

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 clearly states when to use it: 'Use only when the canonical topic id is already known.' It also gives the decision context ('before deciding whether paid evidence packaging is necessary') and an explicit exclusion: 'Do not use this as free-text search.'

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: it is free, requires no account, returns ranked matches, and is a first-pass evaluation tool rather than a final answer tool. It doesn't describe pagination or exact return format, but the output schema exists and the annotations cover the safety profile, so a 4 is appropriate.

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 three sentences with zero waste. It front-loads the most important behavioral facts (FREE, no account), states the purpose, and then gives explicit usage guidance. Every sentence earns its place.

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

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

Complete for a search tool with a rich output schema, full schema coverage, and annotations covering the safety profile. The description tells the agent when to use it, what it returns (ranked matches), and what it is not for. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents both parameters (query and limit) with descriptions, defaults, and constraints. The description adds the context that the query is a 'Bitcoin topic, concept, event, person, protocol feature, or research phrase' and that limit is the 'Maximum number of ranked knowledge matches to return', but this largely mirrors the schema. Baseline 3 is correct when the schema does the heavy lifting.

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

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

The description states a specific verb ('search'), a specific resource ('canonical Bitcoin Knowledge Atlas topics and related history'), and a clear purpose ('evaluate coverage on the caller's real question'). It also distinguishes itself from siblings by noting it is a no-cost evaluation tool for discovering maintained topic coverage, not a final evidence-grade answer tool.

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 explicitly says when to use it ('Run the first no-cost evaluation when you need to see which maintained Bitcoin topics and evidence match a query') and when not to use it ('Do not use when a canonical topic id is already known or when a final evidence-grade answer is required'). It also mentions the FREE/no-account aspect, which is a clear usage condition.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior Domestication. The description adds valuable non-obvious context: the tool is free, requires no account, does not authorize payment, and is meant only for product selection. This complements rather than contradicts the annotations.

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 compact and front-loaded with the most important constraint (FREE, no account). The repetition of 'FREE' is a minor redundancy, and every other sentence carries meaningful usage or behavioral guidance, so only a small deduction applies.

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 enum parameter, an output schema, and rich annotations. The description fills the remaining gaps: pricing/contract inspection, no payment authorization, and the precise moment to use it. Nothing an agent needs to call it correctly is missing.

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

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

With 100% schema_description_coverage and a well-described enum for the single required parameter, the description does not need to add much. It does restate the task enum values and frames them as research intent, but this is largely redundant with the schema's own 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?

The description states a specific action—'Select a research product'—and clarifies it is an inspection/selection step for price, evaluation path, and contract. It explicitly distinguishes itself from executing research or authorizing payment, which separates it from sibling research-execution tools like answer_bitcoin_question or verify_bitcoin_claim.

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 gives explicit when-to-use guidance: 'Use after free evaluation when the correct specialist product is unclear.' It also gives explicit when-not-to-use guidance: 'Do not use it to execute research or authorize payment,' and directs choosing the smallest appropriate product before paid requests.

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

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

The annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds valuable behavioral context beyond these: it states the tool 'never authorizes or initiates payment' and returns a 'source-backed deterministic answer' with 'compact maintained-coverage matches.' This extra detail is useful for agent decision-making without contradicting the annotations.

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 front-loaded with 'FREE' and 'START HERE,' but it contains unnecessary repetition: 'Default first call for an unfamiliar agent' appears twice, and 'FREE' is also repeated. While the content is useful, the redundancy makes it less concise than it could be. A more streamlined version would earn a higher score.

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 tool's purpose, usage timing, behavioral constraints, and what it returns (source-backed answer, matches, next action). It also addresses payment concerns and directs the agent to evaluate coverage. Since an output schema exists, the lack of explicit return format details is acceptable. The only minor gap is the slight redundancy, but all essential context is present.

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

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

The schema already documents the single parameter 'query' with a clear description ('Bitcoin question or research task to answer using maintained California Bitcoin knowledge.') and provides an example. The tool description adds minimal extra parameter semantics—it only restates that it handles 'any Bitcoin question or research task,' which is already implicit in the schema. Since schema coverage is 100%, the baseline of 3 applies.

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

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

The description clearly states this is a free entry point for any Bitcoin question or research task, returning a source-backed deterministic answer and a smallest safe next action. It distinguishes itself from siblings by explicitly labeling itself as the default first call for unfamiliar agents and the tool to use before any paid option, making its purpose and scope 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?

The description gives explicit when-to-use instructions: 'Default first call for an unfamiliar agent,' 'Use it before any paid tool when coverage has not yet been evaluated,' and 'Do not use it to authorize payment.' It also tells the agent to evaluate coverage before choosing another tool, which is clear guidance on when to use this tool versus alternatives.

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

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

Annotations already declare the safety profile (non-destructive but not read-only, open-world), so the description's job is to add context beyond them — and it does by disclosing the price ("PAID 0.10 USD via MPP") and the conservative, source-backed nature of the verdict. It does not, however, explain billing semantics (per-call charge, failure charging) or what happens if the claim is not verdict-eligible, both relevant for a paid non-idempotent 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?

Front-loads the critical operational fact (paid, 0.10 USD) and then the behavior, keeping it to a few sentences. There is mild redundancy: sentence two and sentence three both restate that the tool adjudicates concrete claims, and the described verdict sets overlap without matching (partially verified/insufficient-evidence vs uncertain).

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 need not be explained, and the description covers cost, input shape, verdict philosophy, and exclusions. The remaining gap is the inconsistent verdict taxonomy and undefined jargon ("verdict-eligible maintained atomic claims"), which an agent cannot map onto expected outputs.

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

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

Schema coverage is 100% with a single well-documented param, so the baseline is 3. The description adds meaningful constraint the schema does not: the input must be one concrete proposition, not an open-ended question, which directly shapes how the agent must formulate the string it passes.

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

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

The description states a specific verb and resource — evaluate one specific Bitcoin factual proposition and return a verdict — plus the exact verdict vocabulary and evidence metadata returned. It explicitly contrasts itself with siblings that compose answers to broader questions (answer_bitcoin_question, deep_ground_bitcoin), so an agent can route correctly without opening a schema.

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 gives an explicit inclusion rule ("Use only for a concrete proposition that needs supported, contradicted, mixed, or uncertain adjudication") and an explicit exclusion rule ("Do not use for open-ended explanation or general evidence collection"). It also frames the calling context ("upstream agent already has a concrete factual Bitcoin claim and needs adjudication" rather than a composed answer), which is exactly the decision an agent must make.

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