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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses the return payload (inscription IDs, numbers, content types, sat rarity) which is useful, but does not state whether this is a read-only operation, explain pagination behavior, or note any rate limits or permission requirements. For a read tool without annotations, this is a moderate gap.

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 zero waste, front-loading the core action and resource before detailing the return fields. Efficient and clear.

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?

Covers the core purpose and return fields adequately for a simple retrieval tool with no output schema. However, with no annotations and no output schema, the description omits pagination behavior, read-only nature, and any usage caveats that would help an agent invoke it with full confidence.

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%, with the address and pagination parameters (limit, offset) fully documented in the schema. The description adds no parameter syntax or format details beyond what the schema provides, so the baseline of 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 (get) and resource (Ordinals inscriptions owned by a Bitcoin address) and explicitly names the return fields. Distinguishable from sibling tools like get_address_rare_sats and get_tx_inscriptions by the address-scoped inscription listing.

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

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

Usage is implied by the address-scoped nature of the tool, but there is no explicit when-to-use or when-not-to-use guidance, nor any reference to alternatives such as search_inscriptions or get_inscription_transfers. An agent must infer the appropriate context from the description alone.

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

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

No annotations are present, so the description carries the full behavioral burden. It discloses the return fields (ordinal number, rarity level, UTXO location), which is useful, but says nothing about pagination behavior, rate limits, permissions, or read-only safety. For a read tool with no annotations, this is partial coverage.

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 tight sentences, front-loaded with the action and resource, followed by the concrete return fields. 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 no annotations, no output schema, and no output_schema, the description partially compensates by enumerating return fields but omits pagination semantics and safety profile. Adequate but incomplete for a tool with zero structured behavioral coverage.

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 address, limit, and offset. The description adds no parameter-level detail beyond what the schema provides. 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?

States a specific verb ('Get') and resource ('rare satoshis held by a Bitcoin address') and names the distinguishing domain concept of rarity. It is clearly differentiated from siblings like get_sat_info or get_address_inscriptions.

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 versus get_sat_info or get_address_inscriptions, no mention of alternatives, prerequisites, or exclusions. The description says what it returns but never when an agent should select 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 exist, so the description carries the full behavioral burden; it implies read-only via 'Get' and lists the event types included, but omits pagination behavior, sorting, auth/rate-limit info, and output shape. The parenthetical even omits 'transfer_send', which the schema enum includes, so the event coverage statement is slightly incomplete.

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, purpose front-loaded, no filler. Every phrase contributes: the verb, resource, event scope, and filter dimensions.

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 is a straightforward read query, and the schema fully documents all five parameters. However, with no annotations and no output schema, the description does not explain return structure or pagination behavior, leaving a gap for an agent that needs to understand the response.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's 'Filter by ticker, address, or operation type' merely restates three filter parameters already documented in the schema and adds no format, syntax, or default 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?

States a specific verb ('Get'), resource ('BRC-20 token activity'), and event scope ('deploy, mint, transfer events'), which distinguishes it from siblings like get_brc20_token, get_brc20_holders, and get_brc20_balances. No sibling is named, but the resource label is distinct enough for an agent to identify the right 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?

Tells the agent how to filter (ticker, address, operation type) but not when to use this tool over alternatives such as get_brc20_token or get_rune_activity. There is no when-to-use, when-not-to-use, or alternative routing 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 usefully discloses the return shape (available, transferrable, overall balance), but says nothing about rate limits, pagination behavior, or auth requirements, so behavioral coverage is only partial.

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 tight sentences with zero waste; the core action is front-loaded and the return detail follows immediately. Every clause 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?

With no output schema, the description helpfully enumerates the returned balance fields and names the input resource, which is enough for a simple read tool. Minor gaps remain around pagination behavior implied by limit/offset.

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 address, limit, and offset are documented in the schema itself. The description adds no parameter syntax or format detail beyond what the schema 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 and resource ('Get BRC-20 token balances for a Bitcoin address'), which is clearly distinct from the rune/inscription siblings. It doesn't explicitly contrast with get_rune_balances or get_brc20_activity, but the resource naming makes the 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?

No when-to-use guidance, prerequisites, or alternatives are given. It doesn't say when to prefer this over get_rune_balances or get_brc20_holders, leaving the agent to infer selection 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the result ordering ('sorted by amount held'), which is useful, but says nothing about pagination behavior, rate limits, whether the list is cached/live, or what happens when a ticker is unknown.

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

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

Two short sentences, zero filler, with the core action front-loaded and the return shape immediately after. Nothing could be trimmed without losing content.

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-annotation read tool with a fully documented 3-parameter schema and no output schema, the description covers both what it fetches and what comes back. It is nearly sufficient, lacking only edge-case and pagination behavior.

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 ticker, limit, and offset are already documented in the schema. The description adds no format detail (e.g., case sensitivity of ticker) or defaults, 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 and resource: 'Get top holders of a BRC-20 token', which clearly separates it from adjacent siblings like get_rune_holders and get_brc20_balances. It does not explicitly name a sibling to route against, so it stops short of a 5.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as get_brc20_balances when the agent wants one address's holdings rather than the top-holder leaderboard. Usage must be inferred entirely from the name.

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 enumerates return fields (max supply, minted supply, mint limit, decimals, deploy inscription, transaction count), which is useful, but says nothing about whether the ticker lookup is case-sensitive, what happens for unknown tickers, or rate limits. For a read lookup with zero annotation coverage, this is under-specified.

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 zero waste, front-loaded with the action and lookup key followed by the returned fields. Nothing extraneous.

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 single-param read tool with 100% schema coverage and no annotations, the description covers purpose and return fields adequately. However, with no annotations to carry the behavioral profile, the description should disclose a bit more about lookup behavior and edge cases; it is minimally viable but incomplete on behavior.

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

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

Schema description coverage is 100%, so the schema already documents the ticker parameter with examples (ordi, sats) and length constraints. The description only restates that the tool takes a ticker by saying 'by ticker,' adding no syntax or format meaning beyond 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?

States a specific verb (Get) and resource (BRC-20 token details) with the lookup key (ticker) and enumerates the returned fields. An agent can distinguish it from siblings like get_brc20_holders, get_brc20_balances, and get_brc20_activity 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?

Implies usage by naming the ticker as the lookup key, which naturally scopes it as a single-token lookup. However, it gives no explicit when-to-use or when-not-to-use guidance versus the sibling BRC-20 tools (holders, balances, activity). Adequate but with a clear 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 are provided, so the description carries the full burden. It does add value by naming the concrete return fields (name, description, inscription count, floor price, volume, owner count), making it clear this is a read-only aggregate lookup, but it says nothing about permissions, rate limits, or error behavior.

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

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

Two short sentences, purpose first and return contents second, with zero filler or 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?

For a single-parameter read tool with a fully documented schema, the description covers what the tool does and what comes back. The absence of any routing against the many sibling collection/inscription tools is the only meaningful gap.

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

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

Schema description coverage is 100% and the single slug parameter is documented in the schema with examples (bitcoin-puppets, nodemonkes). The description adds no parameter detail beyond that, 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 (Get) and resource (Ordinals collection details) and enumerates the returned fields, so the purpose is unambiguous. It does not, however, distinguish itself from close siblings like get_collection_inscriptions or get_collection_listings, which an agent could easily confuse for this 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?

There is no when-to-use guidance and no mention of alternatives, despite the sibling list containing several competing collection-scoped tools. Usage is only implied by the resource name.

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 usefully discloses the return shape (inscription IDs, numbers, content types, owners), but says nothing about whether this is a read-only operation, ordering of results, or how the 60-item page cap and offset pagination behave in practice. Adequate but with clear gaps for a zero-annotation tool.

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

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

Two sentences, zero waste. The purpose is front-loaded and the return-field summary follows immediately. Nothing is padded or repeated.

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 no output schema, the description correctly compensates by enumerating the returned fields, which is what an agent needs before calling. The remaining gap is pagination/ordering behavior, but for a simple list tool with a fully documented schema this is close to 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%, so slug, limit, and offset are already documented in the schema with defaults, bounds, and meanings. The description adds no semantics beyond that. Baseline 3 applies 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 and resource: 'List inscriptions in an Ordinals collection.' It is clearly distinguishable from sibling list tools like get_collection_listings or list_runes by naming the resource type. It stops short of explicitly differentiating from get_address_inscriptions or get_tx_inscriptions, but the collection scoping is stated.

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

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

There is no guidance on when to use this tool versus the many sibling inscription tools (get_inscription, search_inscriptions, get_address_inscriptions, get_tx_inscriptions). Usage is only implied by the scope word 'collection' and the required slug. No prerequisites, 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?

No annotations are provided, so the description carries the full burden. It says the tool returns active listings and prices, but does not disclose pagination behavior (limit default 20, max 60), the shape of results, rate limits, or what happens for an invalid collection_symbol. For a read-only listing endpoint this is thin behavioral context beyond the basic return description.

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

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

Two short sentences, front-loaded with the core purpose and then the return content. No redundancy, though it could be slightly more information-dense given the lack of annotations.

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 annotations, no output schema, and three parameters, the description is adequate but not complete. It covers the what and the return unit (BTC) but omits pagination behavior, error cases, and how it differs from sibling inscription-listing tools, leaving gaps an agent must infer.

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 the schema already documents limit, offset, and collection_symbol semantics including defaults and bounds. The description adds only that prices are in BTC, which is about output rather than parameters, so the 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 (Get) and resource (active marketplace listings for an Ordinals collection on Magic Eden), and clarifies the return (listed inscriptions with prices in BTC). It is clear, but does not explicitly differentiate from siblings like get_collection_inscriptions, which could be confusing since both concern inscriptions for a collection.

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 usage by specifying 'active marketplace listings' and 'prices in BTC', so an agent can infer this is for marketplace/pricing data versus raw inscription data. However, it gives no explicit when-to-use or when-not-to-use guidance and does not name alternatives like get_collection_inscriptions.

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. 'Get' plus the enumerated return fields makes the read-only nature and output content reasonably clear, but there is no mention of authentication needs, rate limits, or behavior on a missing/invalid inscription ID.

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 tight sentences with zero waste; the core action and scope lead, and the return-value summary follows compactly.

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

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

For a single-parameter read tool with no output schema, listing the returned fields compensates well for the absent return contract. Only the lack of usage/alternative guidance and any failure-mode behavior leaves a minor gap.

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

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

Schema description coverage is 100%, and the schema already documents the single 'id' parameter including its {txid}i{index} or number format. The description only restates 'by its ID or number', adding no syntax detail beyond the schema, so 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 and resource ('Get detailed metadata for a Bitcoin Ordinals inscription') and scopes it by ID or number. Enumerating the returned fields (owner address, content type, sat rarity, genesis) implicitly distinguishes it from siblings like get_inscription_content, get_inscription_traits, and get_inscription_transfers, though no sibling is named explicitly.

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

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

There is no explicit guidance on when to use this tool versus alternatives such as get_inscription_traits, get_inscription_content, or search_inscriptions. The reader must infer the distinction from the field list alone.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the return shapes (direct text vs base64-encoded binary plus content type), which is real value, but says nothing about behavior for missing/invalid IDs, size limits, or whether the call is a safe read.

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 tight sentences with zero filler, and the core purpose is front-loaded ahead of the return-format detail. Every sentence earns its place.

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

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

For a single-parameter read-only getter with no output schema, the description adequately covers what it does and what comes back. A note on error/missing-ID behavior would make it fully complete, but nothing essential 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?

There is only one parameter and schema description coverage is 100%, so the schema already documents the id format. The description adds nothing about the id beyond what the schema states, making the 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?

States a specific verb and resource ('Get the raw content of a Bitcoin Ordinals inscription') and even clarifies the return format. It implicitly distinguishes itself from metadata-oriented siblings like get_inscription and get_inscription_traits by emphasizing 'raw content', though it never names them explicitly.

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

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

Usage is only implied by the phrase 'raw content' – an agent can infer this is for retrieving the actual inscription payload rather than metadata. There is no explicit when-to-use, when-not-to-use, or named alternative among the many sibling 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 does disclose the return content (trait types and values with examples), which is meaningful since there is no output schema, but it says nothing about error behavior, whether unindexed/inscriptions without traits return empty results, or whether the lookup is read-only/cached.

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

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

Two short sentences, front-loaded with the action and followed by the return summary. No filler, though the second sentence is largely a restatement of the first with examples rather than new information.

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

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

For a single-parameter read tool with no output schema and no annotations, the description covers what the tool returns and gives illustrative trait categories, which is the key missing piece. It stops short of explaining behavior on inscriptions with no traits or any distinguishing context versus sibling lookups.

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

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

Schema description coverage is 100%; the single 'id' parameter is already documented in the schema as an inscription ID in {txid}i{index} format. The description adds no format, validation, or interpretation 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 (Get) and resource (trait information for a collection inscription), and the parenthetical examples (background, body, eyes) make the output concrete. It is distinguishable from get_inscription or get_collection_inscriptions, though it never explicitly says how it relates to those 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives despite many closely related siblings (get_inscription, get_collection_inscriptions, get_collection_info). The phrase 'collection inscription' only implies the input domain, not when this tool should be chosen.

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 says the tool is a read operation and lists returned fields, but does not disclose pagination behavior, rate limits, data ordering, or freshness. For a history retrieval tool with zero annotation coverage, this is a notable gap.

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

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

Two short sentences, front-loaded with the main action and followed by the returned fields. No filler or repetition.

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 core purpose and return fields, but with no annotations and no output schema it omits behavioral details like pagination behavior (limit/offset semantics are in schema but not described) and data ordering. Adequate but leaves some practical 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?

Schema coverage is 100% and each parameter includes a detailed description, including accepted ID formats. The description adds no parameter detail beyond what the schema already provides, so it meets 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?

States a specific verb+resource: 'Get the transfer history for a Bitcoin Ordinals inscription.' Clear what it returns. It is distinguishable from siblings like get_inscription (metadata) and get_inscription_traits, though it does not explicitly name 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 on when to use this tool versus related siblings such as get_inscription or get_tx_inscriptions. The description implies the tool is for transfer history but offers no conditions, exclusions, or 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses that this is a read-style operation and lists the activity types and returned fields, but it omits pagination behavior, ordering, the meaning of 'recent', and any auth or rate-limit 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?

Two tightly written sentences with no wasted words. The purpose is front-loaded, and the return-value summary follows immediately without 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?

With no output schema and no annotations, the description does useful work by listing returned fields and operation types. It is nearly complete for a simple paginated read tool, though it could better define the 'recent' time window and pagination ordering.

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 three parameters are already fully documented in the schema, including name format, limit bounds, and offset semantics. The description adds no parameter-level meaning beyond that baseline.

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 ('Get') and a clearly scoped resource ('recent activity ... for a Bitcoin Rune'), and it enumerates the activity categories (mints, transfers, burns). This distinguishes it from siblings such as get_rune_info, get_rune_holders, and get_brc20_activity without needing to name 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?

The description states what the tool returns but gives no guidance on when to choose it over related tools like get_rune_info, get_rune_market_info, or get_rune_holders. Usage is only weakly implied by the phrase 'Get recent activity'.

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, and it does disclose the return payload shape (rune name, symbol, balance). However, it says nothing about pagination behavior despite limit/offset params, nor about auth needs or result limits, so behavioral coverage is partial for a tool with zero annotation support.

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 tight sentences with zero filler. The core action is front-loaded and the return contents are appended efficiently.

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 no output schema, the description usefully enumerates the returned fields, and all three params are fully documented in the schema. It is close to complete for a simple read tool, with only pagination semantics left implicit.

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%, with limit, offset, and address all documented including bounds and defaults, so the schema does the heavy lifting. The description adds no parameter detail beyond identifying that address is a Bitcoin address, which is the baseline 3 case.

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 and resource ('Get Rune token balances for a Bitcoin address') and lists what is returned (rune name, symbol, balance). The resource is precise enough to separate it from the near-twin get_brc20_balances, but it never explicitly names siblings like get_rune_holders or get_rune_info, so differentiation is inferred rather than stated.

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 no when-to-use guidance and no alternatives. An agent gets no help deciding between this and get_rune_holders, get_tx_runes, or get_brc20_balances; usage must be inferred entirely from the tool name.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the return shape (addresses + balances) and ordering (descending by amount held), which is genuinely useful, but says nothing about pagination defaults, rate limits, or permissions.

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

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

Two short sentences, front-loaded with the action and resource, then the return content. No filler or 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?

No output schema exists, so the description usefully states the returned fields and sort order. Pagination is covered by schema. Minor gaps remain around what 'top' defaults to and how results are ordered for ties, but overall it is complete enough to call 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%: name (with format example), limit, and offset are all documented in the schema. The description adds no additional meaning beyond confirming the resource being queried, 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 (Get) and resource (top holders of a Bitcoin Rune), plus what is returned (addresses and balances sorted by amount held). The qualifier 'Bitcoin Rune' implicitly separates it from the BRC-20 sibling get_brc20_holders, though no sibling is named explicitly.

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

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

There is no when-to-use guidance, prerequisites, or mention of alternatives. An agent must infer from the name alone that this is the holder-listing tool versus get_rune_balances (per-address) or get_rune_info (token metadata).

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 the full burden. It does disclose the payload contents (symbol, divisibility, supply, premine, mint terms, etching tx), which frames this as a static metadata read, but it says nothing about permissions, errors for unknown names, or caching/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?

Two sentences, no filler, and the identity of the tool comes first with the return payload second. Every clause 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?

This is a simple single-parameter read tool with full schema coverage, and since no output schema exists, the description usefully enumerates what is returned. What is missing is the routing information an agent needs against the many nearby rune 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 single 'name' parameter already documents format and the example with the bullet separator. The description only repeats 'by name', adding no syntax or normalization guidance beyond the schema. 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 and resource ('Get details for a Bitcoin Rune by name') and enumerates the returned fields, which separates it from sibling metadata tools like get_rune_market_info or get_rune_holders. It stops short of naming the sibling it is not, so it is clear but not fully differentiated.

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 only usage signal is 'by name', which implies a lookup keyed on rune name. Nothing tells the agent when to pick this over list_runes, get_rune_market_info, or get_rune_unlock_date, and there are no stated preconditions.

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 the return fields and does not mention read-only nature, data freshness, rate limits, authentication needs, or any other behavioral traits. The verb 'Get' implies a read, but that is not made 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?

Two short sentences with zero waste. The purpose is front-loaded, followed by the key return values, making it easy to scan and 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?

For a simple read tool with one parameter and no output schema, the description adequately explains the return fields, which compensates for the missing output schema. However, it lacks usage guidance relative to related tools and any behavioral context, leaving clear gaps for an agent trying to select it confidently.

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 single 'name' parameter is already fully documented with an example. The description adds no additional meaning about the parameter format or constraints, so the baseline of 3 applies.

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

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

The description states a specific verb and resource: 'Get market data for a Bitcoin Rune.' It also lists the exact output fields (price in USD, market cap, 24h volume), making the purpose clear. However, it does not explicitly differentiate from sibling tools like get_rune_info, which could also return rune data, so it stops short of a 5.

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 about when to use this tool versus alternatives such as get_rune_info or get_rune_activity. It only states what the tool does, leaving the agent to infer context and 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 carries the full burden. It does disclose the return shape ('unlock block height and estimated date') and implies a read-only query, but says nothing about permissions, rate limits, or what happens when the name is already etched. Partial behavioral disclosure only.

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 tight sentences with the core action front-loaded and the return values appended. No filler or 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?

With no output schema, the description appropriately covers return values (unlock block height and estimated date). For a one-param read tool this is nearly complete; only edge-case behavior (already-etched names, invalid names) is 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% (name: 'Rune name to check availability for'), so the single parameter is fully documented in the schema. The description restates 'rune name' without adding format, constraint, or lookup semantics beyond what the schema already provides; 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 ('Check') and resource ('rune name' + availability for etching) with clear scope. It distinguishes itself from siblings like get_rune_info and list_runes by focusing on unlock timing, though it does not explicitly name an alternative to route against.

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

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

The description implies the use case (checking rune name availability/unlock timing) but gives no explicit when-to-use, when-not-to-use, or alternative-tool guidance. An agent must infer that this is the right call versus get_rune_info or list_runes.

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

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

With no annotations, the description carries the full burden, and it does disclose the return payload shape (rarity level, epoch, cycle, period, name, inscription), which implies a read-only lookup. However, it says nothing about behavior for invalid/nonexistent ordinals, rate limits, or whether the ordinal must reference a mined satoshi.

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, both load-bearing: the first states the action and key, the second enumerates the output. Front-loaded and free of filler.

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

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

For a single-parameter lookup with no output schema and no nested objects, the description is nearly sufficient because it lists the returned fields, compensating for the missing output schema. The remaining gap is guidance on alternatives and failure behavior, which is minor at this 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 description coverage is 100%, so the ordinal parameter (format, min/max length, example) is already fully documented in the schema. The description's phrase 'by its ordinal number' adds no syntax or format detail beyond that, so the baseline of 3 applies.

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

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

The description names a specific verb ('Get information about') and a precise resource ('a specific satoshi by its ordinal number'), then enumerates the returned attributes (rarity, epoch, cycle, period, name, inscription). No sibling tool covers per-satoshi lookups, so ambiguity is low, though it never explicitly differentiates itself from the adjacent get_address_rare_sats.

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

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

There is no when-to-use guidance, no prerequisites, and no named alternative. The mention of 'any inscription on it' loosely hints at overlap with get_inscription, but the agent is left to infer whether to call this or that sibling.

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 the full behavioral burden. It usefully declares what is returned (inscription IDs, numbers, content types), but is silent on read-only assurance, ordering of results, empty-result behavior for a transaction with no inscriptions, and behavior on an unknown txid.

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, zero filler, with the action and scope front-loaded before the return summary. Every clause 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?

With no output schema, the description correctly carries the return-value summary (IDs, numbers, content types). For a simple one-required-parameter read this is nearly sufficient, with only minor gaps around ordering and empty results.

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 txid parameter is documented as 'Bitcoin transaction ID', so the schema does the work. The description adds no format, network, or length guidance beyond it, making the 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?

Specific verb ('Get') plus resource and scope ('all Ordinals inscriptions contained in a Bitcoin transaction'), which reads clearly as a transaction-scoped bulk fetch. It implicitly distinguishes itself from single-inscription siblings like get_inscription and address-scoped ones like get_address_inscriptions, though it never names an alternative.

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 framing ('contained in a Bitcoin transaction') implies the use case when you have a txid and want its inscriptions, but there is no explicit when-to-use, when-not-to-use, or routing to get_inscription / get_address_inscriptions. Usage is inferred rather than stated.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the return shape (rune names, amounts, addresses, operation types), which is real value given there is no output schema, but it says nothing about behavior for invalid txids, Rune-less transactions, rate limits, or whether the RPC may need an indexer.

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, zero filler, with the core purpose front-loaded and the return contents second. Nothing could be trimmed without losing 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 single-parameter read tool, covering purpose plus return fields is nearly sufficient, and it compensates for the absent output schema. Missing only edge-case behavior (no-runed tx, invalid txid).

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?

Only one parameter (txid) at 100% schema description coverage, so the schema already documents it. The description adds no format or validation context beyond what the schema supplies, making the baseline of 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?

States a specific verb and resource: 'Get all Rune transfers in a Bitcoin transaction,' which an agent can distinguish from inscription- or balance-oriented siblings by resource alone. It stops short of naming the closest sibling (get_tx_inscriptions) or otherwise drawing the boundary explicitly.

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

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

Usage is implied by the resource scope — call this when you need Rune transfers for a given txid — but there is no explicit when-to-use statement, no mention of the parallel get_tx_inscriptions tool, and no guidance for transactions that contain no Runes.

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 pagination behavior and the shape of returned data (name, symbol, supply, divisibility, mint terms, etching info), which is genuinely useful, but says nothing about ordering, auth requirements, rate limits, or whether the list is exhaustive.

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 tight sentences with no waste; the core purpose is front-loaded and the return-value detail follows efficiently. Slightly more could be said but nothing is padding.

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 no output schema, the description usefully enumerates the returned fields so the agent knows what to expect. For a simple two-parameter read tool with full schema coverage, this is nearly complete, only missing usage guidance relative to siblings.

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 parameters (limit, offset) are fully documented in the schema, including defaults, min, and max. The description only alludes to pagination without adding syntax or meaning beyond what the schema already 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?

States a specific verb and resource ('List Bitcoin Runes') and names the scope (pagination) plus the returned fields. It is distinguishable from sibling per-rune tools like get_rune_info or get_rune_holders, though it never explicitly contrasts itself with them.

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

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

There is no when-to-use guidance, no exclusions, and no naming of alternatives among the many sibling rune tools (get_rune_info, get_rune_holders, get_rune_market_info). The agent must infer that this is the bulk-listing tool rather than a per-rune detail tool.

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 implies a read operation via 'search and list' but never states read-only semantics, does not describe result ordering, default page size, the 60-cap behavior, or total-count/next-page signals. It only restates the filter set already visible in 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?

Two tight sentences, front-loaded with the core action followed by the filter taxonomy. No filler, though the second sentence is largely a restatement of the schema's property list rather than new 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 an 11-parameter, all-optional query tool with no annotations and no output schema, the description covers what can be filtered but not how results come back, how paging should be driven, or when to prefer a scoped sibling. Adequate but with clear gaps given the schema richness and zero annotation support.

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 11 parameters (limit, offset, rarity enum, block/number ranges, cursed, recursive) are already documented in the schema. The description's filter list mirrors the schema without adding syntax, default, or range-combination semantics, so 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+resource ('Search and list Bitcoin Ordinals inscriptions') and enumerates the filter dimensions, which is enough for an agent to identify the tool. However, it does not differentiate from close siblings like get_address_inscriptions or get_collection_inscriptions, which also return inscription sets with filtering.

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

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

No when-to-use guidance is given. Nothing tells the agent whether this is the general-purpose discovery endpoint versus the address-, collection-, or tx-scoped siblings, nor what happens with zero filters (a global list?) or how it relates to get_inscription for single lookups.

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