Counterparty MCP Server

by XCP

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.5
Disambiguation4/5
Most tools are clearly distinct by resource and action, but there are many similar get_* tools that differ only by filter (by_asset, by_address, by_pair), which could cause confusion. The descriptions help, but the sheer number of similar patterns creates some ambiguity.
Naming Consistency4/5
Uses a consistent verb_noun snake_case pattern (get_ for reads, compose_ for transaction building). Some deviations like api_request, compose_mpma, compose_movetoutxo, and unpack_transaction vs decode_transaction slightly break the pattern, but it's mostly predictable.
Tool Count2/5
48 tools is far beyond the typical range. Even though the Counterparty protocol is complex, this many tools creates a heavy surface that agents must navigate. The api_request catch-all further suggests the count could have been trimmed.
Completeness4/5
The tool set covers most core Counterparty operations: assets, orders, dispensers, dividends, sends, issuance, and various compose actions. The api_request tool provides a fallback for missing endpoints. Minor gaps exist (e.g., no specific query for fairminters), but it's generally complete.
Average 3.8/5 across 48 of 48 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on February 11, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint=false) and not destructive. The description adds no further behavioral details, such as whether it returns an unsigned transaction, requires specific permissions, or may fail if the fairminter is inactive. With no output schema, this lack of context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action ('Compose a transaction') and resource ('mint tokens from an active fair minter'). It is concise with no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and does not explain the return value, potential errors, or how 'active fair minter' is determined. Given the absence of an output schema and the low complexity guidance, the tool is under-specified for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for all 5 parameters, giving 100% coverage. The tool description itself adds no additional parameter meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool composes a transaction to mint tokens from an active fair minter. It uses a specific verb and resource, but does not explicitly distinguish from the sibling tool compose_xcp420_fairminter, which also involves fairminter functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites like needing an active fairminter, fee rate considerations, or when not to use it. The intended usage is only implied by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description merely restates the tool's purpose without disclosing behavioral traits beyond the annotations. It does not mention that composing a transaction does not broadcast it, that the result must be signed and broadcast separately via broadcast_transaction, or any side effects or requirements. The annotations already signal a non-read-only operation, so the description adds little value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the core purpose. Every word contributes, with no filler or redundancy. It is appropriately front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no output schema) and the presence of sibling tools like broadcast_transaction, the description is too thin. It does not explain the compose-then-broadcast workflow, what the return value looks like, or the context for using this tool in a larger transaction-building process. This leaves the agent without essential operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage with detailed parameter explanations (e.g., quantity divisibility, sat_per_vbyte). The tool description adds no additional parameter semantics, but the schema already provides the necessary meaning, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool composes a transaction to send Counterparty tokens to an address, using a specific verb ('compose') and resource (transaction). It implicitly distinguishes from sibling tools like compose_dispense or compose_order, but does not explicitly differentiate from compose_mpma which also sends tokens (multi-asset).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention that this is for single-asset sends, nor does it reference compose_mpma for multi-asset sends. There is no mention of prerequisites like address ownership or balance checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the description is consistent. However, it adds no behavioral context beyond the name, such as pagination, filtering behavior, or return format. It simply restates the function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no unnecessary words. It is concise but also somewhat under-specified, though conciseness is about brevity, not completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and minimal description, the tool lacks context about what it returns, how pagination works, and how it differs from closely related asset tools. The description is insufficient for an agent to fully understand the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with each parameter (limit, named, cursor, offset) clearly described. The description adds no parameter-level meaning, but per rubric, baseline is 3 when coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs 'search or list' and identifies the resource as 'Counterparty assets,' making the core function clear. However, it does not differentiate from sibling tools like get_asset_info or get_owned_assets, so it lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention that this is for broad listing/searching while other tools are for specific asset details or owned assets. Thus, an agent has no basis to choose this over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond the parameter default (which is also in the schema). It does not describe pagination, return format, or other runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is easy to parse. It front-loads the core action and resource, with a useful parenthetical default. No words are wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large number of sibling order-related tools, the description lacks necessary context to disambiguate this general listing from filtered variants. It does not mention scope (e.g., all orders vs. per-asset), which is essential for correct tool selection. No output schema exists, so the description should carry more weight, but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are described in the schema. The description merely repeats the default for 'status' ('open'), adding no new meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'orders on the Counterparty DEX', including a useful default status. However, it does not differentiate this general order listing from sibling tools like get_asset_orders or get_address_orders, which filter by specific criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus more specific order tools. The 'default: open' note is a parameter-related detail, not usage context. There are no exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond what annotations already provide (readOnlyHint=true, openWorldHint=true). It does not mention pagination, return format, or any side effects. Since annotations already cover safety, this is acceptable but lacks additional context like rate limits or data shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no fluff or redundancy. Every word adds meaning, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should help explain what is returned, but it does not. It also lacks context about pagination or how the parameters interact. The presence of annotations and complete schema slightly mitigates this, but the description itself is too minimal for a 4-parameter tool in a large sibling family.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear parameter descriptions for address, limit, cursor, and offset. The tool description itself does not add parameter semantics, but baseline 3 applies because the schema fully documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('all assets issued/owned by a specific address'), clearly stating what the tool does. It distinguishes from vague generic names like get_assets by scoping to a specific address and ownership/issuance relationship.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool instead of alternatives. Sibling tools like get_asset_balances and get_assets could overlap in purpose, but the description does not mention exclusions or alternatives, leaving the agent to infer based on name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds the default status ('open'), but this is also present in the schema (status default '0'). It does not elaborate on pagination behavior, potential large result sets (despite openWorldHint), or return format, leaving some behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence with a parenthetical. It is front-loaded with the key action and resource, and contains zero filler words. This level of conciseness is appropriate for a simple, well-named read-only tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 optional but self-explanatory parameters and annotations cover safety, the description is minimally adequate. However, it lacks context about the tool's scope: does it return all dispensers globally or is it filtered by something? It also does not mention pagination behavior or describe the response structure (no output schema). For a list endpoint, the description could provide more guidance on when to use this vs. the more specific sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (limit, cursor, offset, status) having a description. The description adds no new meaning beyond the schema; the '(default: open)' note duplicates the schema's status default. Since the schema fully documents the parameters, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Counterparty dispensers, with the verb 'Get' and resource 'dispensers'. It distinguishes from singular 'get_dispenser' by using plural and notes the default status of 'open'. However, it does not explicitly mention listing all dispensers or differentiate from other dispenser-related list tools like get_address_dispensers or get_dispensers_by_asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus the many sibling tools. The parenthetical '(default: open)' hints at status filtering but does not clarify whether this is the general list endpoint for all dispensers or when to prefer the more specific variants. There is no mention of alternatives, prerequisites, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds no further behavioral details, such as that composing does not broadcast, whether it returns an unsigned transaction, or any prerequisites like UTXO availability or fee estimation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the verb and resource. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, no output schema, and complex sibling context, the description is insufficient. It does not explain the composition workflow, return value, or special cases like inscription support or fee requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover 100% of parameters, so the baseline is met. The description's mention of 'text message or numeric value' aligns with the text and value parameters, but adds no extra semantic clarity beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'Compose' and the resource 'a transaction to broadcast a text message or numeric value to the Counterparty network', which distinguishes it from sibling compose_* tools like compose_send or compose_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided. The sibling tool broadcast_transaction implies a two-step process, but the description does not mention it. Usage must be inferred from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description adds no behavioral context. It does not state whether the transaction is signed, broadcast, or merely prepared, nor does it mention potential side effects like balance checks or fee requirements. The word 'compose' is standard but not elaborated on, leaving significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and front-loaded with the core purpose. Every word earns its place; there is no fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 6 parameters and no output schema, the description is minimal and does not explain the resulting transaction structure, whether the operation is reversible, or what happens after composition. It lacks essential context for an agent to understand the full behavior and expected outcome, making it insufficient for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter already well-described (e.g., 'Asset whose holders will receive dividends'). The description itself adds no additional meaning to the parameters, so it meets the baseline of 3 without exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'compose' and the resource 'a transaction to distribute dividends to all holders of an asset', which is specific and distinguishes it from other compose_* siblings. It conveys exactly what the tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when distributing dividends) but does not provide explicit alternatives, exclusions, or prerequisites. It doesn't mention that other compose tools exist for different transaction types, so guidance is limited to inferred context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, providing the safety profile. The description adds no further behavioral context such as pagination requirements or potential need for multiple calls. It does not contradict annotations, but also adds no operational detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise, front-loaded, and contains no irrelevant details. It effectively communicates the tool's purpose in the least possible words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple read-only nature, the schema covers all parameters, and annotations provide safety info, the description is mostly complete for a basic query tool. However, it lacks explicit mention of pagination to retrieve 'all' holders and does not differentiate from similar balance tools, which would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters have descriptions in the schema, so the schema fully covers their meaning. The description adds no extra semantics beyond the term 'specific asset' aligning with the asset parameter, which is already documented. Per the baseline, this is adequate but not enhanced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves balances for a specific asset across all holders, using a specific verb and resource. However, it does not explicitly distinguish this from sibling tools like get_balances or get_utxo_balances, so it misses the full 5 score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool compared to alternatives. It simply states what it does, without mentioning exclusions, prerequisites, or alternative tools, leaving the agent to infer its usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations declare readOnlyHint=true, the description's 'Get all DEX orders' is misleading because the schema's status parameter defaults to 'open', meaning not all statuses are returned by default. The description adds no context about this default behavior, pagination, or other nuances, so it fails to disclose an important behavioral trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It clearly states the action and resource, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 5 parameters, pagination, and a status filter, the description provides no guidance on these features. It omits that results are paginated, that a status filter exists with a default of 'open', and gives no hint about return structure. The 'all' phrasing also overpromises, making the description incomplete for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not add semantic information beyond the schema, but it also doesn't need to since every parameter has a description. No extra value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('DEX orders') with a clear scope ('involving a specific asset'). This distinguishes it from sibling tools like get_orders (all orders) and get_address_orders (by address), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need DEX orders filtered by asset, but it does not explicitly state when to use this tool versus alternatives like get_orders or get_orders_by_pair. There is no when-not or alternative guidance, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds no behavioral details beyond a restatement of the read-only nature, such as pagination behavior, return format, or data scope. It does not contradict annotations, but it provides no additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. It gets straight to the point and earns its place with zero filler, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a straightforward read operation with solid annotations and a fully documented schema. However, there is no output schema and the description does not mention pagination, return shape, or any additional constraints. This is adequate for a simple getter but leaves some gaps for an agent unfamiliar with the API.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for all four parameters (address, limit, cursor, offset), achieving 100% coverage. The description adds no parameter-level information, so the baseline score of 3 applies, as the schema carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly identifies the resource ('transaction history for a Bitcoin address on Counterparty'). It distinguishes this from sibling tools like get_address_orders and get_sends, which target different data types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving transaction history for an address, which is straightforward. However, it offers no explicit guidance on when to choose this tool over alternatives, such as get_address_orders or get_sends, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only behavior (readOnlyHint=false) and open-world effects (openWorldHint=true). The description adds the useful 'specific UTXO' target constraint, but does not disclose return values, whether the transaction is unsigned, or other side effects beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no wasted words. It states the verb and resource immediately and is appropriately concise for the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters and no output schema, yet the description only states the high-level purpose. It omits important context such as how destination_vout relates to attachment, what the composed transaction returns, and how this differs from sibling compose tools (e.g., compose_detach).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 6 parameters, so the structured schema already provides meaning for each parameter. The description does not add parameter-level context, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Compose') and clearly identifies the resource/action: attaching Counterparty tokens to a specific UTXO. This distinguishes it from sibling tools such as compose_detach and compose_send.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when attaching tokens to a UTXO) but provides no explicit alternatives, exclusions, or guidance relative to sibling compose tools. For example, it does not mention compose_detach as the inverse operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal behavioral information beyond the annotations. It does not clarify whether 'compose' means building a transaction for later broadcast or actually sending it, nor does it mention side effects (e.g., marking the order match as paid). The openWorldHint and readOnlyHint already indicate action, but the description does not explain what the action entails or its consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, front-loaded with the core purpose, and contains no redundant or filler wording. Every word contributes to understanding the tool's role.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, yet the description does not mention what the function returns (e.g., a transaction hex or a signed payment). It also lacks workflow context, such as needing a prior matched order or how to obtain the order_match_id, leaving the agent to infer these from the parameter names alone. For a DEX-related compose operation, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter already has a meaningful description. The tool's description does not add any extra parameter semantics, so it meets the baseline of 3 but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Compose') and a clear resource ('BTC payment for a matched DEX order'), making the tool's function immediately obvious. It also distinguishes from sibling compose_* tools by specifying the DEX order context, which is unique among the provided siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states this tool is used to complete BTC trades on the DEX, giving strong context for when to invoke it. However, it does not explicitly mention alternatives or exclusions (e.g., 'use compose_send for general BTC transfers'), so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, and the description adds that it 'Compose a transaction' and that dispensers automatically sell tokens for BTC. However, it does not disclose return format, broadcasting requirements, or side effects beyond composition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose and a contextual note. Every word earns its place; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters and no output schema, the description lacks guidance on how to compose for different statuses (open vs close), return value expectations, or prerequisites. The schema covers parameter meanings, but overall contextual completeness is limited.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each of the 9 parameters having a description. The tool description does not add parameter-specific semantics but the schema provides sufficient detail, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Compose a transaction to create, open, or close a dispenser,' which clearly identifies the tool's function and scope. It distinguishes itself from sibling composition tools by specifically targeting dispensers and listing the three operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating, opening, or closing dispensers but does not explicitly compare with alternatives like compose_dispense or mention when not to use it. No exclusion or alternative guidance is provided, so the agent must infer 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, and the description adds 'compose a transaction' implying a non-read-only operation. It does not disclose what the tool returns, whether broadcasting is required, or other behavioral nuances, so it adds limited value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and resource, and includes a useful pointer to an alternative. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 21 parameters, no output schema, and no explanation of what a fairminter launch entails or what the returned transaction looks like, the description is too sparse. It also fails to clarify the relationship with compose_fairmint, leaving a significant completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters. The description itself offers no additional parameter guidance, staying at the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool composes a transaction to create a fair minting launch for a new asset. It distinguishes from compose_xcp420_fairminter, but does not differentiate from the similarly named sibling compose_fairmint, leaving potential confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly names an alternative for XCP-420 compliant launches, providing a clear when-not-to-use condition. However, it does not address the closely related compose_fairmint sibling or other compose_* alternatives, leaving some usage context implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds the scope 'issuance history' but does not disclose pagination behavior or response format. Since annotations carry the safety profile, the description provides some but limited additional behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the essential purpose. There is zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with rich annotations (readOnlyHint, openWorldHint, destructiveHint) and a fully described schema, the description is nearly sufficient. It clearly states the resource ('issuance history'), and pagination is implied by the schema's cursor/offset/limit parameters. A minor gap is not explicitly stating the return is a list, but 'history' strongly implies this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all four parameters with descriptions (100% coverage). The description adds no additional semantics beyond what the schema already provides. Baseline 3 is appropriate 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and resource 'issuance history' scoped to 'a Counterparty asset', clearly distinguishing it from siblings like compose_issuance (creating issuances) and get_asset_info (asset metadata). It unambiguously states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention alternatives, exclusions, or typical use cases. The agent is left to infer from the name alone, which is insufficient given many similar getter tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, covering the irreversible/submitting nature. The description adds minor context ('via the Counterparty node') and notes the transaction must be signed, but does not disclose failure behavior or return value expectations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant wording. Every word contributes to the meaning, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, annotations present), the description is adequate but lacks some context. There is no mention of expected output (e.g., transaction hash) or any post-broadcast behavior, which would be useful given no output schema. The destructive nature is covered by annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so a baseline of 3 applies. The description does not add significant detail beyond the schema—it only restates that the transaction is signed, which aligns with the parameter description 'Signed raw transaction hex'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Broadcast'), the resource ('a signed Bitcoin transaction'), and the destination network ('via the Counterparty node'). It is specific and distinguishes from sibling compose_* tools which create transactions, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied but not explicit: the description suggests broadcast after signing, and the sibling tools include compose_* functions that produce raw transactions. However, there is no direct statement of when to use this tool vs alternatives, nor any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds the address scoping constraint. However, it does not disclose pagination behavior or the possibility of limited results, which would be valuable since the tool has pagination parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no wasted words. It is concise and immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list endpoint with five parameters and no output schema, the description is adequate but minimal. It could mention pagination or filtering options, though the schema covers parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well-documented. The description does not add additional meaning beyond what the schema provides, keeping it at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('dispensers'), and the specific scope ('created by a specific address'), distinguishing it from sibling tools like get_dispenser or get_dispensers_by_asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description—use this when you want dispensers for a particular address—but there is no explicit guidance on when to prefer this over alternatives like get_dispensers or get_dispensers_by_asset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a safe read operation (readOnlyHint=true, destructiveHint=false). The description adds the clarification that 'dispense records' are 'purchases', which is useful domain context, but it does not describe pagination behavior, return format, or other operational details beyond what annotations and schema provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose. It contains no unnecessary words and is front-loaded with the action and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with good annotations and full schema coverage, the description is minimally adequate. It explains what is returned (dispense records/purchases) but does not mention pagination or how it differs from other dispenser-related tools. There is no output schema, so some return detail could be expected, but the description is sufficient for an agent to select the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented. The description does not add meaning beyond the schema, except to associate 'specific dispenser' with the 'hash' parameter. Baseline 3 is appropriate as the schema carries the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets dispense records (purchases) for a specific dispenser, using a specific verb ('Get') and resource ('dispense records'). It differentiates from the similar sibling get_dispenser by clarifying this is about purchase records, not dispenser details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a specific dispenser' implies the tool requires a dispenser identifier and is distinct from listing all dispensers, but it does not explicitly mention alternative tools like get_dispensers or when not to use this tool. The usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description does not contradict them. It adds the specific scoping to a DEX order but does not disclose pagination behavior, result ordering, or the implications of openWorldHint (e.g., match statuses changing over time).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundancy. It immediately communicates the core function, earning a top score for conciseness and front-loaded structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters and no output schema, the description is somewhat underspecified. It does not mention the return structure or pagination behavior, though the schema hints at pagination via limit/cursor/offset. It is adequate for a simple query tool but lacks comprehensive context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for all 5 parameters (100% coverage), including limit, cursor, offset, status, and order_hash. The description adds no additional semantic meaning beyond what the schema already documents, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'get' and identifies a distinct resource ('matches') scoped to 'a specific DEX order'. This clearly distinguishes it from sibling tools like get_orders (which lists orders) and get_order (which retrieves a single order).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool over alternatives, though the phrase 'for a specific DEX order' implies it is for order-specific match retrieval. There are no exclusions or references to alternative tools, relying on the agent to infer context from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare the tool as read-only and non-destructive. The description adds no further behavioral context, such as potential errors, rate limits, or what happens if the transaction lacks Counterparty data. It simply reinforces the read-only nature by using verbs like 'decode' and 'unpack.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and purpose. No extraneous words; it is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a clear purpose and the schema covers parameters, but the absence of an output schema and lack of guidance about edge cases or alternative tools leaves some gaps. For example, it doesn't describe the format of the decoded data or what to do if the transaction is not a Counterparty transaction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the schema (raw_transaction as 'Hex data to unpack (raw transaction hex or Counterparty data hex)' and block_index as optional context). The description itself adds no additional parameter-level information, so it relies entirely on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('decode and unpack') and its target resource ('raw transaction'), specifying that it exposes 'embedded Counterparty data.' This identifies the tool's purpose distinctly from generic decoders, though it doesn't explicitly reference sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: when you have a raw transaction and want to extract Counterparty data. It provides a clear context for invocation, but does not mention any exclusions or alternatives, such as when to use decode_transaction instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint true and destructiveHint false, so the agent knows this is a safe read operation. The description adds the scope (raw Bitcoin hex, components) but does not mention what happens on invalid hex, return format, or any edge cases. Without annotations, this would be insufficient, but with them it is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential purpose in 10 words. Every word earns its place, with no redundancy or unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one well-documented parameter and clear annotations, the description provides sufficient context. It could mention the exact return format or error handling, but the lack of an output schema is mitigated by the 'inputs, outputs, etc.' phrasing. The complexity is low, so the description is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single raw_transaction parameter, so the schema already provides full meaning. The description does not add any parameter-specific detail beyond what the schema states, keeping this at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool decodes a raw Bitcoin transaction hex into its components, naming inputs and outputs. It uses a specific verb and resource, distinguishing it from general compose/send tools. While unpack_transaction may appear similar, the explicit focus on raw Bitcoin transaction hex makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (whenever raw transaction hex needs decoding) but does not explicitly state when not to use it or mention alternatives like unpack_transaction. Given the sibling list includes unpack_transaction, some usage guidance would be valuable, but the intent is still inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds 'DEX orders' domain context but does not disclose additional behavioral traits like default ordering, pagination behavior, or handling of invalid addresses. It neither contradicts nor enriches annotations significantly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. It front-loads the core purpose and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 5 parameters, no output schema, and full annotations/schema coverage, the description is mostly complete. It provides the essential context (address-specific DEX orders) and relies on the schema for parameter details. The lack of explicit return-format information is acceptable given the 'Get' verb and typical list semantics, but a note on pagination could have made it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all five parameters have explicit descriptions. The tool description adds no extra meaning beyond the schema, but the schema already fully documents the parameters, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Get', the resource 'all DEX orders', and the scope 'placed by a specific address'. This distinguishes it from sibling tools like get_orders (all orders) and get_asset_orders (by asset), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need orders for a specific address, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. Usage is inferred from the address scope rather than directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with annotations (readOnlyHint=true), but adds no extra context about behavior beyond the schema. It doesn't disclose what happens for invalid addresses or unknown assets, but given the annotations already indicate a safe read operation, a score of 3 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler, front-loading the action and resource immediately. Every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two well-documented parameters and safety annotations, the description is adequately complete. It lacks explicit alternatives and return format, but those are not critical for such a straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters already described. The description does not add any new semantic detail beyond what the schema provides, so it earns the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and identifies the exact resource ('balance of a specific asset for a Bitcoin address'), clearly distinguishing it from sibling tools like get_balances which would return multiple balances. This leaves no ambiguity about the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a single asset-address pair but does not explicitly exclude alternatives or mention when to prefer this over get_balances or get_asset_balances. Since siblings include similar balance tools, explicit guidance would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds minimal behavioral context beyond the lookup key, such as return format or error handling. It does not contradict annotations, but it also does not enrich them significantly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no extraneous content. It perfectly balances brevity with the essential information needed to identify the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter getter with strong annotations, the description is largely complete. It clearly identifies the resource and lookup key. While it doesn't explicitly state that the return value is the dispenser object, this is implied by 'Get details' and is not a critical gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter 'hash' with a description ('Dispenser transaction hash'), and the tool description repeats this information ('by its transaction hash'). With 100% schema coverage, the description adds no extra semantic value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets details of a specific dispenser by transaction hash. It specifies the verb ('Get'), the resource ('details of a specific dispenser'), and the key ('by its transaction hash'), which distinguishes it from sibling tools like get_dispensers or get_dispensers_by_asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when you have a transaction hash and need a single dispenser's details. However, it does not explicitly state alternatives or exclusion scenarios (e.g., 'use get_dispensers to list all'), leaving the guidance implicit rather than overt.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, covering safety. The description adds '(default: open)', which clarifies the default status behavior, but does not disclose other aspects like pagination or response format. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core function and the most important default. It is concise and free of unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, with rich schema annotations and full parameter descriptions. The description covers the primary use case and default status. While there is no output schema, the return type ('dispensers') is inferable, and the annotations cover safety. Slightly more context about response behavior could be added, but it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented. The description adds the default status ('open') which is also in the schema, providing no additional meaningful meaning beyond what the schema already offers. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('dispensers') with a clear scope ('for a specific asset'). The tool name 'get_dispensers_by_asset' reinforces this, and the description distinguishes it from sibling tools like 'get_dispensers' and 'get_address_dispensers'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving dispensers tied to a specific asset, but it does not explicitly state when to use this tool versus alternatives (e.g., 'get_dispensers' for all or 'get_address_dispensers' for an address). No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. The description adds the 'order book' concept and pair-specific scope, but does not disclose additional behaviors like default status filtering or pagination (though these are visible in the schema). This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the tool's purpose. It is front-loaded and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, list-style tool with a full parameter schema and safe annotations, the description is largely sufficient. It conveys the core functionality and scope, though it omits explicit details about the response shape (since there is no output schema). Given the tool's simplicity, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not add any parameter-specific meaning beyond what the schema already provides; it only loosely references the pair via 'specific trading pair', which maps to asset1/asset2 already described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('order book'), and the scope ('specific trading pair on the DEX'). This distinguishes it from sibling tools like get_asset_orders (single asset) or get_orders (general) by emphasizing pair-specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need the order book for a specific trading pair) but does not explicitly mention alternatives or exclusions. No guidance is given for when to prefer another order-related tool such as get_asset_orders or get_address_orders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, which the description does not contradict. The description does not add behavioral details like pagination behavior, return format, or rate limits. With the safety profile covered by annotations, the minimal description is acceptable but not enriching.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence: 'Get all sends (token transfers) from a specific address.' It is front-loaded with the primary verb and object, and every word adds meaning. There is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool is a read-only query with full schema coverage and safety annotations, the description is nearly complete. It could benefit from a hint about pagination (since 'all sends' might imply a single bulk response), but the schema's limit/cursor/offset parameters already signal this. Overall, the blank is adequately filled for a simple list-fetching tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all four parameters (limit, cursor, offset, address) are already documented. The description only restates the address scope ('from a specific address'), adding no deeper semantics beyond the schema. This aligns with the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 clear resource ('sends' with clarification 'token transfers') scoped to 'a specific address'. It effectively distinguishes from sibling tools like get_address_transactions by narrowing to token transfers, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when wanting token transfers from a given address, but offers no explicit guidance on when to choose this over sibling tools (e.g., get_address_transactions or get_asset_balances). There are no exclusions or alternatives mentioned, leaving the context only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations: it clarifies that the tool only composes a transaction (not executes it), and highlights the permanence of the action ('permanently destroy'). This is useful behavioral context that the annotations (readOnlyHint=false, destructiveHint=false) do not fully convey. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core purpose without any redundant words. It is exactly as concise as needed and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description and annotations provide adequate context for the tool's purpose and parameters, there is no mention of the return value or workflow (e.g., that the composed transaction should be passed to broadcast_transaction). Since there is no output schema, this missing workflow detail leaves a gap in completeness, though the sibling tool name implies it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 tool description itself does not add additional parameter semantics beyond the overall purpose, but the schema already provides detailed descriptions for all six parameters, so the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Compose a transaction to permanently destroy (burn) Counterparty tokens'. It identifies the specific verb (compose), resource (transaction), and action (destroy/burn), which distinguishes it from sibling compose tools like compose_send or compose_dispense.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the burning purpose, but it does not explicitly mention when to use this tool over alternatives (e.g., when to use compose_send instead) or any exclusions. The intent is clear enough from the wording, but no direct alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds 'Compose a transaction' which clarifies this is not broadcasting, and 'detach ... back to an address' describes the effect. This goes beyond the annotations (readOnlyHint=false, openWorldHint=true) by indicating a state-changing but non-executing action. However, it does not mention return format or side effects on the UTXO, so not a full 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and includes only necessary information. It is concise and free of filler or redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description does not state what the composed transaction looks like or that it returns an unsigned transaction. Given the complexity of compose tools and the many sibling compose_* tools, more detail (e.g., return value, typical workflow) would be helpful. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% — all three parameters already have descriptions. The description does not add any additional meaning beyond what the schema provides; 'back to an address' merely echoes the 'destination' parameter. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Compose' and the specific resource 'a transaction to detach Counterparty tokens from a UTXO back to an address'. This distinguishes it from siblings like compose_attach (which attaches tokens) and compose_send, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the verb 'detach' — use when you want to remove Counterparty tokens from a UTXO. However, there is no explicit when-to-use vs alternatives, no mention of prerequisites (e.g., UTXO must have attached tokens), and no comparison with compose_attach or compose_movetoutxo. The only guideline is the fee rate note in the schema, not in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as non-read-only and non-destructive. The description adds useful context that attached tokens move with the UTXO, but does not clarify whether the composed transaction is broadcast or returned unsigned, or what side effects occur beyond 'composing'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource. Every word contributes to understanding the tool's core purpose, with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple compose operation, especially with full schema coverage and annotations. However, the lack of an output schema and the description's silence on what the tool returns (e.g., hex transaction, signed tx) leaves a notable gap for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema itself. The description does not add meaningful parameter details beyond what is already in the schema, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Compose a transaction') and a precise resource ('move a UTXO (and any attached tokens) to a new output'). It clearly distinguishes this from sibling tools like compose_send by focusing on moving an entire UTXO, not sending a specific asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly conveys when to use the tool: when you need to move a UTXO and its attached tokens to a new output. It stops short of explicitly naming alternatives or exclusions, but the intended use case is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the agent knows it is not a read-only operation. The description adds that it composes a transaction (not broadcasting) and sweeps all assets/BTC, but does not disclose behavioral details such as automatic UTXO selection or ownership transfer implications. This is acceptable but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with a clear verb and object. It contains no unnecessary words and is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a moderately complex parameter set (bitfield, fee rate, UTXO inputs), but the description is minimal. It does not mention expected output or preconditions, though annotations and schema fill some gaps. For a compose operation, this is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all six parameters including flags bitfield and fee rate described. The description adds no extra meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'compose' and the resource 'transaction', with the specific scope of 'sweep all assets and/or BTC from one address to another'. This distinguishes it from sibling compose tools like compose_send and compose_mpma, which target specific assets or transfers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies use when one wants to move all assets and/or BTC from an address, which differentiates it from more granular compose tools. However, it does not explicitly state exclusions or name alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the lookup-by-hash behavior, which is consistent with the parameter schema, but does not disclose additional behavioral details such as return format or potential error cases. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence. Every word contributes to clarity, with no filler or redundant statements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only lookup with one well-documented parameter, full schema coverage, and strong annotations (readOnlyHint, openWorldHint, destructiveHint), the description is complete enough. It names the resource, the action, and the identifier, which is sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the only parameter ('order_hash' described as 'Order transaction hash'). The description's 'by its transaction hash' aligns with the schema but does not add any new semantic information beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get details'), the specific resource ('a specific DEX order'), and the identifying mechanism ('by its transaction hash'). This distinguishes it from sibling tools like get_orders (plural list) and get_order_matches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching a single order given a transaction hash, but does not explicitly state when to use it versus alternatives like get_orders or get_orders_by_pair. The context is clear but no exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the safety profile is known. The description adds no behavioral details beyond the verb 'compose' implying it creates a transaction without broadcasting. This is adequate but not especially informative beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that effectively communicates the tool's purpose without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, no output schema), the description is adequate. It identifies the purpose and relies on the detailed schema for parameter guidance. Missing some context like broadcasting flow, but 'compose' implies the natural workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter is well-described (e.g., quantity in satoshis, fee rate examples). The description itself does not add parameter details, so it relies on the schema, which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool composes a transaction to buy from a dispenser by sending BTC. It uses specific verbs and resources, distinguishing it from sibling compose tools like compose_dispenser, which likely creates or updates a dispenser.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when buying from a dispenser. It does not explicitly name alternatives or exclusions, but the purpose is distinct enough among siblings that an agent can infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a useful behavioral constraint—'All three arrays must be the same length'—which is not covered by the schema. However, it does not disclose other behavioral traits like return format, side effects, or dependencies (e.g., UTXO selection). Annotations are present (readOnlyHint=false, destructiveHint=false) and not contradicted, but the description adds only limited context beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary purpose, and includes only essential information. Every sentence earns its place with no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters and no output schema, the description is reasonably complete: it covers core functionality and the key array-length constraint. However, it does not explain what the tool returns or how the composed transaction is used downstream, which could be useful but is not critical given the tool's straightforward compose role and sufficient schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 adds meaningful cross-parameter semantics by stating that assets, destinations, and quantities must have equal lengths, clarifying a relationship not explicitly stated in the schema. This goes beyond the schema's individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool composes a multi-party multi-asset send transaction, distinguishing it from single-send compose_send and other compose_* siblings. The verb 'compose' plus the specific 'multi-party multi-asset' scope makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool—when sending multiple assets to multiple recipients in a single transaction—but it does not explicitly mention alternatives or when not to use it. The context of sibling tools (e.g., compose_send) provides contrast, but the description itself lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds context by enumerating metadata fields but does not disclose any behavior beyond that (e.g., error handling for non-existent assets, rate limits, or response format). With annotations present, this is adequate, though not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear, focused sentence that front-loads the purpose and lists examples of metadata. No filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 with good schema coverage and annotations, the description is sufficient. There is no output schema, so the description compensates reasonably by listing common metadata fields. It could be more exhaustive, but it adequately sets expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single parameter 'asset' with examples (XCP, PEPECASH, A12345). The description does not add additional parameter semantics, but the schema already does the heavy lifting. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and a specific resource ('metadata for a Counterparty asset'), and lists concrete metadata fields (supply, divisibility, issuer, description). This distinguishes it from sibling asset-related tools like get_asset_orders or get_asset_balances, which focus on different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when you need asset metadata such as supply, divisibility, or issuer. It does not explicitly mention alternatives or exclusions, but the context of sibling tools makes the use case clear. A brief note distinguishing it from get_assets (which lists assets) would strengthen it, but it is still clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds minimal behavioral context beyond 'all' (indicating a list) and does not contradict annotations. With annotations covering the safety profile, a 3 is appropriate—the description adds slight context but no significant behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the tool's purpose directly. It contains no filler or redundant information, making it exceptionally concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with rich annotations and fully documented parameters, the description is sufficient. Though there is no output schema, the description accurately conveys the tool's purpose and scope. Pagination behavior is implied by the schema parameters, so the description does not need to repeat it. Slightly more detail about return format would be helpful, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all four parameters, so the schema already documents each parameter. The description's mention of 'Bitcoin address' mirrors the address parameter description and adds no meaning beyond what the schema provides. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a clear resource ('all Counterparty token balances'), and the scope ('for a Bitcoin address'). It distinguishes itself from sibling tools like get_balance (singular) and get_asset_balances (balances for an asset) by specifying 'all' and 'for a Bitcoin address'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: to retrieve all token balances for a given address. It provides clear context but does not explicitly mention alternatives or exclusions. However, the specificity of 'all' and 'for a Bitcoin address' makes the appropriate use case clear without needing to name sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is well-covered. The description adds the asset-specific scope but does not disclose additional behaviors such as pagination, result ordering, or rate limits. This is acceptable but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately conveys the action and target. Every word earns its place; there is no fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only query tool with well-documented parameters and safety annotations, the one-sentence description is mostly sufficient. However, it could mention pagination or the typical return shape, especially since there is no output schema, but the schema and annotations already cover the essential invocation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 all four parameters. The description only reinforces the 'asset' parameter in prose and adds no extra meaning for limit, cursor, or offset beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get dividend distributions for a specific asset' clearly states the verb (Get), the resource (dividend distributions), and the scope (specific asset). It distinguishes this read tool from compose_dividend and other query tools by emphasizing asset-specific filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear use case: retrieving dividends for a particular asset. It does not explicitly name alternatives or state when not to use it, but 'for a specific asset' provides enough context to separate it from broader or mutation-focused tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds no further behavioral context (e.g., response format, potential timeout), but for a trivial no-parameter getter, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy. Every word contributes to the purpose, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no parameters and no output schema, the description adequately conveys its function. It could optionally mention what the block information contains, but this is not necessary for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema carries all necessary information. Per the rubric, a 0-parameter tool gets a baseline of 4; the description doesn't need to elaborate on parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the latest block information from the Counterparty node, using a specific verb ('Get') and resource ('latest block'). It is distinct from sibling tools, none of which focus on blocks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use when you need the latest block from the Counterparty node. However, there is no explicit guidance on when to prefer this over alternatives or any exclusions, though no sibling tool directly overlaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds little beyond 'Get details', but given the low bar set by strong annotations, this is acceptable. No extra behavioral context (e.g., error cases, response format) is provided, but none is contradicted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that uses the active verb 'Get' and specifies the resource and lookup key. Zero wasted words, perfectly sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 parameter, no output schema, no nested objects), and the description clarifies its purpose completely. It doesn't mention the return format, but for a 'get details' operation this is generally self-evident. Given the low complexity, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: tx_hash is described as 'Transaction hash'. The description's phrase 'by its hash' adds no new meaning beyond the schema. Baseline of 3 is appropriate when the schema already fully documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'details of a specific Counterparty transaction', and the scope 'by its hash'. This distinguishes it from sibling tools like get_address_transactions or get_sends, which cover different scopes or transaction types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: when you have a transaction hash and need details for a single transaction. It does not explicitly exclude alternatives or name when-not-to-use, but the specificity ('specific transaction by its hash') provides clear context without being ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds the UTXO-scoping context, but doesn't disclose additional behaviors like what happens if the UTXO doesn't exist or whether zero balances are returned. With annotations covering the main safety traits, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb and resource. Every word earns its place, and there is no fluff or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, one-parameter, read-only balance lookup, the description is sufficient. It states the core purpose and scope. While there is no output schema or mention of return format, the tool's nature (token balances for a UTXO) makes the return predictable. Given the low complexity, this is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single 'utxo' parameter with format (txid:vout), so schema coverage is 100%. The description adds no new syntactic or semantic details beyond saying 'specific UTXO', which is redundant. Baseline 3 is appropriate given the schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a clear resource 'Counterparty token balances' and a precise scope 'attached to a specific UTXO'. It distinguishes from sibling tools like get_balances (address-level) and get_asset_balances (asset-level) by focusing on the UTXO attachment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the appropriate context: use when you need balances tied to a UTXO rather than an address or asset. It doesn't explicitly name alternatives or exclusions, but the scope is clear enough to guide selection among the many sibling balance tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds key behavioral context beyond the annotations by indicating that the tool composes (builds) a transaction rather than directly cancelling the order, and it specifies the 'open' precondition. This is useful information not conveyed by readOnlyHint=false, destructiveHint=false, or openWorldHint=true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently communicates the action and target, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a compose tool with four fully-described parameters and no output schema, the description gives the core purpose but omits details about the return value and the need to broadcast the composed transaction via broadcast_transaction. It is functional but leaves gaps for an agent to infer the full workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already fully explains all four parameters (e.g., 'must be order creator' for address, fee rate guidance for sat_per_vbyte). The description does not add any parameter-specific meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'compose' and clearly identifies the resource as 'a transaction to cancel an open DEX order.' This distinctively differentiates it from sibling tools like compose_order (which creates orders) and other compose_* tools, leaving no ambiguity about its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the context for use: when an open DEX order needs to be cancelled. It provides clear context without the need to infer. However, it does not explicitly mention alternatives or when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows it may not be read-only. The description adds the 'raw API request' concept and a link to the API reference, but does not elaborate on potential side effects, rate limits, or return format variability. It neither contradicts annotations nor adds substantial behavioral detail beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and includes a link and example without excess. Every element earns its place; it is concise, structured, and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given it is a generic raw-request tool with no output schema, the description adequately sets expectations by indicating it covers endpoints not in sibling tools, providing the API reference for details, and giving an example. It could mention that return values vary by endpoint, but the link covers that. Overall it is sufficiently complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are individually described in the input schema. The description adds an example (endpoint="/v2/blocks/last", method="GET") which helps illustrate usage, but does not explain parameter semantics beyond what the schema already provides. Thus it adds minimal incremental value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Make a raw API request') and the resource ('any Counterparty REST endpoint'), and explicitly distinguishes it from the other tools by saying 'not covered by the other tools'. This makes its purpose unambiguous and differentiates it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool: 'any Counterparty REST endpoint not covered by the other tools'. It also provides a full API reference link and a concrete example, giving clear context for when this fallback tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly notes that it 'composes a transaction,' signaling this is a transaction-building operation rather than a broadcast, which adds value beyond the annotations (readOnlyHint=false, openWorldHint=true). It does not contradict the annotations and provides useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the essential action and scope. It contains no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 12 parameters, the description is minimal but sufficient because the schema provides detailed parameter semantics. It clearly states the tool's role (compose issuance) and introduces the create/update distinction, which is essential context. However, it does not mention prerequisites or post-compose steps, but these are not required given the schema richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for all 12 parameters, so the description is not required to explain them. The description adds no additional parameter meaning beyond what the schema already provides, hence the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'compose a transaction to issue (create) a new Counterparty asset, or update an existing one,' identifying the specific verb (compose), resource (Counterparty asset), and scope (create or update). This differentiates it from sibling compose_* tools, which target different operations like sending or dispensing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool (issuing or updating assets) but does not explicitly state exclusions or alternatives. Since the purpose is unambiguous, it earns a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read. The description adds the specific information categories returned (status, version, network), but does not describe return format or any edge-case behavior, which is acceptable for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that conveys the action and target without unnecessary words. It is concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters, no output schema, and low complexity. The description fully captures what the tool returns and is sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description correctly indicates that no inputs are needed and focuses entirely on the output, which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with a clear resource ('Counterparty node status, version, and network information'). It clearly distinguishes this tool from sibling tools like get_latest_block or get_transaction, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: whenever the agent needs Counterparty node status, version, or network info. It does not explicitly mention alternatives or exclusion criteria, but the context is straightforward given the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the exact fixed parameters and which fields are configurable, adding significant context beyond the basic annotations. It does not contradict the readOnlyHint=false or destructiveHint=false annotations, and correctly implies this produces a transaction without destructive side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The two-sentence description is compact and informative, with the first sentence stating purpose and the second detailing constraints without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is self-contained about the XCP-420 standard and configurable fields, and the schema provides all parameter details. The absence of an output schema is acceptable for a compose tool where the result is typically an unsigned transaction, though the description could explicitly state the return type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all six parameters with descriptions, so baseline is 3. The description adds value by clarifying that only asset, start_block, and description are true fair launch configuration parameters, while others are transaction mechanics (address, inputs, fee rate). This helps the agent understand the distinction.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool composes an XCP-420 compliant fair launch, with a specific verb and resource. It also enumerates the standard's fixed parameters, distinguishing it from generic compose_fairminter sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly conveys that this tool enforces a specific community standard with fixed parameters, implying it should be used when an XCP-420 launch is desired. However, it does not explicitly name alternative tools for non-compliant launches, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and non-destructive. The description adds useful behavioral detail: it queries the Counterparty node first and falls back to mempool.space, clarifying the data source and fallback logic. This goes beyond the annotation flags and helps set expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no filler. The first sentence states the core function, the second covers fallback and usage. Well-structured and immediate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and clear annotations, the description covers the necessary context: purpose, fallback behavior, and how values should be consumed. Without an output schema, a bit more detail about the return shape might help, but for its simplicity this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, conf_target, is fully described in the schema (100% coverage). The description adds a crucial qualifier that this parameter is 'Only used for Counterparty node estimate', which informs the agent when the fallback is active. This enriches the schema's default-3 description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get current Bitcoin fee rates in sat/vB', a clear verb-object statement. This distinguishes it from all sibling tools, none of which focus on fee estimation. The wording is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs the agent to 'Use the returned values directly as sat_per_vbyte in compose tools', providing a clear when-to-use context. It does not name alternative tools, but no sibling serves a similar purpose, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only (readOnlyHint=false) and not destructive, but the description adds a crucial behavioral nuance: give_quantity and get_quantity are TOTAL amounts, not per-unit prices, with the price being their ratio. This is a common misuse trap and the examples clearly illustrate the correct interpretation, going far beyond 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat long but every sentence is purposeful, front-loading the critical warning about total amounts before providing examples. The two examples are redundant in some ways but helpfully cover both buy and sell directions, making the length justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter compose tool, the description thoroughly covers the most error-prone aspect (total vs. per-unit amounts) and the schema documents all other parameters. It doesn't mention the return format, but the 'compose' naming convention and the sibling broadcast_transaction tool imply the output, so this is a minor gap given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all 9 parameters, but the description adds significant value by clarifying the semantics of give_quantity and get_quantity, including the 10^8 multiplier for divisible assets, satoshis for BTC, and how to interpret the price ratio. The two concrete examples (buying TOKENA and selling XCP) make the parameter usage unambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Compose a DEX order to trade Counterparty assets,' using a specific verb (compose) and resource (DEX order). It distinguishes from sibling compose tools like compose_send and compose_issuance by focusing specifically on orders, with examples for both buying and selling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates usage by providing buy and sell examples, making it clear this tool is for creating DEX orders. However, it does not explicitly mention when not to use it or name alternatives (e.g., compose_cancel for cancelling), leaving room for slightly more explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-server MCP server](https://glama.ai/mcp/servers/XCP/mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/XCP/mcp-server)

Score Badge

Copy to your README.md:

[![mcp-server MCP server](https://glama.ai/mcp/servers/XCP/mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/XCP/mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/XCP/mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server