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

With no annotations, the description carries the burden of disclosing side effects. It discloses the persistence path (~/.qubic-mcp/networks.json) and implies the network is not activated immediately. However, it does not mention overwrite behavior, validation, or failure conditions, 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.

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

The description is two sentences, front-loaded with the primary purpose, and includes only essential information (storage location and activation follow-up). Every word earns its place with no redundancy.

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

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

For a simple tool with 3 parameters and no output schema, the description covers the core aspects: what it does, where it persists, and the required next step (activation). It does not mention duplicate handling or success/failure responses, but given the tool's simplicity, this is adequate and slightly above the minimum viable.

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

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

The schema provides 100% documentation of all three parameters, so the baseline is 3. The description adds minimal semantic value beyond the schema—it gives an example of a name and the storage purpose, but does not explain parameter relationships or constraints not already in the schema.

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

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

The description uses a specific verb ('Save') and resource ('custom Qubic network'), provides a concrete example ('local lite node'), and clearly distinguishes it from sibling tools by noting that activation is handled by switch_network. This leaves no ambiguity about 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.

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

The description states the storage location and explicitly directs the user to use switch_network to activate the saved network, providing clear context for when to use this tool. It does not include explicit exclusions (e.g., duplicate handling), but the guidance is sufficient for a simple add operation.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the use of 'current live price' but does not explain what happens if both qu and usd are provided, if neither is provided, or what the output format looks like. These are significant ambiguities for a conversion tool.

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

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

The description is two succinct sentences that front-load the primary action ('Convert between QU and USD') and then explain the two usage modes. There is no fluff or redundant repetition of schema details.

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

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

While the tool is simple, the description does not explicitly require exactly one parameter or describe the return value structure. Since there is no output schema, the description should compensate for these gaps. It provides a minimum viable explanation but lacks some important behavioral specifics.

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

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

The input schema already describes both parameters with 100% coverage, so the baseline is 3. The description adds value by indicating the 'either/or' exclusivity of the parameters, which is not expressed in the schema. This helps the agent understand that exactly one should be specified.

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

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

The description clearly states the tool converts between QU and USD using the current live price. The verb 'Convert' and the explicit resource pair distinguish it from sibling tools like get_token_price, which focuses on price data rather than conversion.

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

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

The description gives clear usage context by saying 'Specify either a QU amount... or a USD amount', which tells the agent how to structure the input. However, it does not explicitly mention alternatives or when not to use the tool, 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.

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

With no annotations provided, the description carries the burden of disclosing behavior. It adds useful context like 'current balance' and accepts two input forms, but it does not state potential side effects (none expected), network specificity, or error handling for invalid addresses. It is adequate but lacks depth.

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

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

The description is two sentences, front-loaded with the primary action, and every word earns its place. The example 'my-main' and the cross-reference to save_wallet are concise and useful without being verbose.

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

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

Given the simplicity of the tool, no output schema, and rich sibling context, the description is sufficiently complete. It informs the agent about input formats and a related workflow, though it could optionally mention the return format or error behavior.

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

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

The input schema already describes the 'address' parameter with 100% coverage, including the dual nature (address or wallet name). The description reinforces this and adds a practical tip about using save_wallet, providing extra value beyond the schema.

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

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

The description clearly states the tool's purpose: 'Get the current balance of a Qubic address or saved wallet.' It uses a specific verb ('Get') and resource ('balance'), and distinguishes it from sibling tools like get_transaction or get_transfer_history by focusing on balance retrieval.

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

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

The description explains when to use this tool by specifying acceptable inputs (60-character Qubic address or saved wallet name) and provides a cross-reference to save_wallet for setting up named wallets. It does not explicitly exclude scenarios, but the context is sufficient for an agent to decide.

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

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

No annotations are provided, so the description bears the full burden of behavioral disclosure. It clearly implies a read-only operation ('List') and adds useful context about the meaning and size of the computor set. It does not describe return format or error behavior, but for a simple list tool this is acceptable. The description effectively communicates the default epoch behavior, which is the key non-obvious trait.

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

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

The description is two concise sentences, front-loaded with the action and resource. The second sentence adds valuable context without redundancy. Every phrase earns its place, and the structure is optimal for quick comprehension.

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

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

The tool is simple: one optional parameter, no output schema, and a straightforward purpose. The description fully covers the domain context (what computors are, their count and role) and the default behavior. It is complete for an agent to invoke the tool correctly. No additional information is needed.

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

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

The input schema has 100% coverage for the single parameter 'epoch', including its description 'Epoch number (defaults to current epoch)'. The tool description repeats this default behavior but adds no further parameter-level detail. Since the schema already documents the parameter well, 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.

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

The description states the tool's function clearly: 'List the computor identities for a given epoch.' It uses a specific verb ('list') and resource ('computor identities'), and adds context by explaining that computors are the 676 nodes that validate transactions on the Qubic network. This distinguishes it from sibling tools, none of which mention computors.

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

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

The description provides usage context by explaining the default behavior ('Defaults to the current epoch if none is specified') and the role of computors. It does not explicitly mention alternatives or exclusion cases, but for a unique getter tool, the context is sufficient. A score of 4 reflects clear context without explicit when-not guidance.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It adds the useful note that saved wallet names are accepted (which the schema also mentions), but it does not disclose other behaviors such as whether it makes external calls, what it returns, or how it handles missing parameters. The read-only nature is implicit from 'get', but not explicitly stated.

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

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

The description is extremely concise, consisting of two short sentences. The first sentence front-loads the core purpose, and the second sentence adds a minor detail about wallet name acceptance. No filler words or redundant information.

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

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

The tool is simple, and the schema covers parameter details. However, with no output schema, the description does not hint at the return format or structure beyond 'links'. It also does not clarify behavior when both parameters are omitted or both are provided, which could be ambiguous. Overall, it is minimally complete but leaves some usage details unspecified.

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

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

The input schema already provides full descriptions for both parameters, covering the 'saved wallet name' option in the address field. The description adds no additional parameter information beyond what the schema states, so it meets the baseline of 3 for adequate but not enhanced parameter semantics.

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

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

The description clearly states the tool's function with a specific verb ('Get links') and resource ('Qubic block explorers'), and specifies the two input types ('address or transaction ID'). It differentiates from sibling tools by focusing on explorer links, which none of the siblings explicitly provide.

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

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

Usage context is implied by the description: use when you need explorer links for an address or transaction. However, it does not explicitly mention when not to use this tool or suggest alternatives. There is no exclusionary guidance, but the purpose is straightforward enough that the intended use is clear.

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

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

No annotations are provided, so the description carries the full burden. It explains the return values (phase and marathon day) and the underlying schedule, which is helpful. However, it does not explicitly state that this is a read-only operation or mention potential error conditions or side effects. The description is adequate but lacks richer behavioral disclosure.

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

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

The description is two sentences long, front-loaded with the primary purpose, and every sentence adds value. It explains not only what the tool returns but also the context of the mining phases, all without unnecessary verbosity.

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

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

For a simple no-parameter getter with no output schema, the description is complete. It specifies the two pieces of information returned (mining phase and XMR marathon day) and provides the background needed to interpret them, satisfying the needs of an AI agent.

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

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

The tool has zero parameters and the schema description coverage is 100% (trivially). With no parameters to document, a baseline score of 4 is appropriate. The description adds no parameter information because none is needed.

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

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

The description clearly states the tool's purpose: 'Get the current Qubic mining phase (MINING or IDLE) and whether it's an XMR marathon day.' This is a specific verb+resource (get phase and flag), and the additional context about alternating phases distinguishes it from any sibling tool.

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

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

The description provides clear context for when to use the tool (whenever mining phase or marathon day status is needed) and explains the network's periodic behavior, making the usage obvious. However, it does not explicitly name alternative tools or state when not to use it, 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.

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

No annotations are provided, so the description carries the full burden. The verb 'Get' clearly indicates a read-only operation, but the description adds no further behavioral context such as authentication needs, caching behavior, or network-dependency caveats.

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

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

The description is a single, well-structured sentence that front-loads the main purpose and then lists the key data points. Every word earns its place with no redundancy.

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

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

With no parameters and no output schema, the description's enumeration of returned fields is largely sufficient for an agent to understand the tool's output. However, it omits minor contextual details like whether the data is from the currently selected network or how fresh the data is.

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

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

The tool has zero parameters, so parameter semantics are trivially satisfied; the baseline is 4. The description adds useful information about what data will be returned, compensating for the absence of schema parameter details.

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

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

The description uses a specific verb 'Get' and a specific resource 'Qubic network status', and enumerates distinct data categories (tick, epoch, supply, price, market cap). This clearly separates it from sibling tools like get_balance or get_tick_info.

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

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

The description implies this is for a broad overview of network health, but it does not explicitly state when to use this tool over siblings such as get_tick_info or get_token_price. No alternatives or exclusions are mentioned.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It reveals a key dependency (must call get_token_list first) and a correctness constraint (never fabricate an issuer address). It also specifies the return content (ask/bid orders with price and quantity). It does not mention rate limits or response structure, but the important prerequisite behavior is well disclosed.

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

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

The description is concise and well structured. The main purpose is stated in one sentence, followed by an 'IMPORTANT' block that highlights the critical prerequisite. No wasted words or repetition of schema details.

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

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

The tool has plausible complexity (orderbook sides, pagination) and no output schema. The description explains the return type (ask/bid orders with price and quantity) and gives essential workflow context. It does not detail the exact response schema or pagination behavior, but the core usage and prerequisites are adequately covered 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.

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics for the issuer parameter by emphasizing that the exact address must come from get_token_list, and that guessing is prohibited. This goes beyond schema descriptions and helps agents use the parameter correctly.

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

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

The description clearly states the tool's function: 'Query the QX decentralized exchange orderbook for a Qubic token' and specifies the output: 'Returns current ask (sell) and bid (buy) orders with price and quantity.' It uses a specific verb ('Query'), names the resource (QX DEX orderbook), and differentiates itself from siblings like get_token_price and get_token_list.

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

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

The description provides explicit usage guidance: 'You MUST call get_token_list first to find the exact issuer address. NEVER guess or fabricate an issuer address.' This establishes a clear prerequisite workflow and error handling ('tell the user it was not found and ask them to provide the issuer address'). However, it does not explicitly contrast with alternative tools, so it stops short of a perfect score.

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

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

No annotations are provided, so the description carries the full burden. It discloses ranking by balance, current epoch, and pagination support, but omits aspects like authentication needs, response format, or potential rate limits. For a read-only getter, this is acceptable 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.

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

The description is a single sentence that front-loads the core purpose and ends with the pagination capability. Every word earns its place with no redundancy.

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

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

Given the tool's simplicity (2 optional params, no output schema), the description covers the essential behavior. It could mention what data is included per address (e.g., address, balance, rank) but the presence of an output schema would have reduced that burden. Sibling context is adequate to infer when to use it.

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

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

Schema description coverage is 100% for both page and pageSize, so baseline is 3. The description only mentions 'Supports pagination' generically, adding no syntax or behavior beyond the schema's own parameter descriptions.

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

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

The description uses a specific verb ('Get') and resource ('Qubic rich list'), and clearly qualifies the resource as 'top addresses ranked by balance for the current epoch.' This distinguishes it from sibling getters like get_balance (single address) and get_epoch_computors (different data).

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

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

The description implies usage context (rich list for current epoch) but provides no explicit when-to-use vs. alternatives or exclusions. The pagination note is a feature, not usage guidance. It is clear but not fully explicit.

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

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

No annotations are provided, so the description must handle behavioral disclosure. It clearly indicates a read-only operation ('Get', 'Returns') and details the three output fields. It also provides useful domain context (tick duration, epoch length). It does not discuss potential errors or explicitly confirm no side effects, but the read-only nature is well conveyed.

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

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

The description is three sentences: purpose, returned fields, and background context. Every sentence carries meaningful information without redundancy. It is front-loaded with the primary action and concise.

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

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

With no output schema, the description explains return values (tick number, epoch, tick duration) and provides context on tick/epoch structure. For a zero-parameter, read-only tool, this is sufficient and complete, requiring no further elaboration.

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

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

The tool has zero parameters, so the input schema fully covers all inputs. Baseline for 0 params is 4; the description adds no parameter information because none is required. The description's mention of return fields adds value beyond the schema.

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

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

Description clearly states the tool gets current Qubic network tick information, using specific verb 'Get' and resource 'tick information'. It lists returned fields (tick number, epoch, tick duration), which distinguishes it from other network tools like get_network_status or get_version.

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

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

The description provides context about ticks and epochs but does not explicitly state when to use this tool over siblings or when not to use it. Alternatives are not mentioned, so usage guidance is implied from the outlined purpose rather than explicitly stated.

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

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

No annotations are provided, so the description carries the full burden. It states the output fields and that it lists all registered tokens, but does not explicitly mention that the operation is read-only, has no side effects, or requires any auth. For a simple get/list operation, the description is adequate but lacks extra behavioral context beyond the basic function.

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

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

The description is two sentences, front-loaded with the primary purpose and immediately adding a use-case context. Every word earns its place, with no redundancy or fluff.

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

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

For a simple zero-parameter read tool with no output schema, the description sufficiently explains what the tool returns and why it is useful. It does not explicitly state side effects or limitations, but none are expected for a get-list operation. The coverage is adequate but could be slightly more comprehensive by stating it is read-only.

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

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

The tool has zero parameters, so the baseline is 4. The description adds value by explaining the return fields, which helps the agent understand the output even without an output schema. No parameter-specific detail is needed.

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

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

The description clearly states the tool's action ('Get a list') and resource ('all registered Qubic tokens'), and specifies the return fields (name, issuer address, website). This distinguishes it from sibling tools like get_token_price or get_qx_orderbook, which have different purposes.

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

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

The description provides a clear use case: 'Useful for finding token issuers needed for QX orderbook queries.' This gives context for when to use the tool, but does not explicitly mention alternatives or when not to use it. Scoring 4 because clear context is present, but no exclusion criteria.

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

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

NO ANNOTATIONS ARE AVAILABLE, SO THE DESCRIPTION FULLY CARRIES THE BURDEN OF EXPLAINING BEHAVIORAL TRAITS. IT DISCLOSES THAT THE TOOL AGGREGATES DATA FROM COINGECKO, QUBIC OFFICIAL API, AND CRYPTOCOMPARE, AND LISTS THE OUTPUT FIELDS, WHICH IS HELPFUL. HOWEVER, IT DOES NOT ADDRESS POTENTIAL ISSUES LIKE SOURCE UNAVAILABILITY, DATA FRESHNESS, OR HOW DISAGREEMENT AMONG SOURCES IS RESOLVED.

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

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

THE DESCRIPTION IS A SINGLE, WELL-STRUCTURED SENTENCE THAT FRONT-LOADS THE PURPOSE AND IMMEDIATELY DETAILS THE OUTPUT FIELDS. EVERY PART OF THE SENTENCE ADDS VALUE, WITH NO EXTRANEOUS INFORMATION.

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

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

GIVEN THE TOOL'S SIMPLICITY (NO PARAMETERS) AND LACK OF AN OUTPUT SCHEMA, THE DESCRIPTION SUFFICIENTLY COMMUNICATES WHAT THE TOOL RETURNS: PRICE, 24H CHANGE, MARKET CAP, AND VOLUME, WITH A SOURCE-BY-SOURCE COMPARISON. IT COULD NOTE THE CURRENCY AND AGGREGATION METHOD, BUT THE ESSENTIALS ARE COVERED.

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

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

THE TOOL HAS ZERO PARAMETERS, AND THE INPUT SCHEMA CONFIRMS THIS. WITH NO PARAMETERS TO DOCUMENT, THE DESCRIPTION DOES NOT NEED TO ADD PARAMETER SEMANTICS BEYOND WHAT THE SCHEMA PROVIDES, EARNING THE BASELINE SCORE OF 4.

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

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

CLEARLY STATES A SPECIFIC ACTION (GET), A SPECIFIC RESOURCE (CURRENT QUBIC TOKEN PRICE), AND THE KEY DISTINGUISHING FEATURE (COMPARISON ACROSS MULTIPLE SOURCES). THIS DIFFERENTIATES IT FROM SIBLING PRICE-RELATED TOOLS LIKE CONVERT_QU_USD.

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

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

THE DESCRIPTION IMPLIES THAT THIS TOOL IS FOR RETRIEVING CURRENT PRICE DATA WITH CROSS-SOURCE COMPARISON, PROVIDING CLEAR CONTEXT FOR WHEN IT WOULD BE APPROPRIATE. HOWEVER, IT DOES NOT EXPLICITLY MENTION ALTERNATIVES OR CASES WHERE ANOTHER TOOL SHOULD BE USED INSTEAD, LEAVING NO EXCLUSIONS.

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

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

No annotations are provided, so the description carries the burden. It discloses the return fields (source, destination, amount, tick, execution status) and the ID format constraint. However, it does not describe error handling (e.g., transaction not found) or any side effects, which would be expected for full transparency.

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

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

The description is three short sentences, each adding value: purpose, return fields, and ID format. It is front-loaded with the primary action and has no unnecessary words.

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

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

For a single-parameter lookup tool, the description covers the return fields and the input format, which is sufficient for basic use. However, it omits behavior when the transaction is not found, and since there is no output schema, the return field types/structures are not described, leaving a minor gap.

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

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

Schema description coverage is 100%, with the parameter described as 'The 60-character lowercase transaction ID'. The description adds the same constraint ('Transaction IDs are 60 lowercase letters') but no additional syntax or format details beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool's function with a specific verb ('Look up') and resource ('Qubic transaction') and specifies the lookup key (transaction ID). This distinguishes it from sibling tools like get_transfer_history, which lists transactions rather than retrieving a single one by ID.

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

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

The description implies when to use the tool: when you have a transaction ID and need its details. However, it does not explicitly state when not to use it or mention alternatives, such as get_transfer_history for broader transaction queries.

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

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

No annotations are provided, so the description carries the full transparency burden. It discloses the basic behavior: returns incoming and outgoing transfers with details, and is implicitly read-only via 'get'. However, it does not mention pagination behavior, ordering, or error handling. The description adds some behavioral context beyond the schema but lacks depth.

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

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

The description is three concise sentences, front-loaded with the main purpose and followed by a practical usage hint. Every sentence earns its place with no filler or redundancy.

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

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

The tool has 5 parameters and no output schema, and no annotations. The description explains the core purpose and a prerequisite, but it does not mention pagination (page/pageSize) behavior or the response structure beyond 'details'. This is adequate for basic use but leaves clear gaps about how to handle large result sets and what exactly is returned.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's phrase 'within a tick range' echoes the startTick/endTick schema descriptions, and 'Qubic address or saved wallet' mirrors the address parameter description. It does not add meaningful new parameter semantics beyond what the schema already provides.

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

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

The description clearly states the tool's function: 'Get the transfer history for a Qubic address or saved wallet within a tick range.' It specifies the resource (transfer history), the scope (address/wallet, tick range), and returns summary (incoming/outgoing transfers). This distinguishes it from siblings like get_transaction and get_balance, which handle different resources.

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

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

The description provides a clear usage prerequisite: 'Use get_tick_info first to find the current tick number.' This gives context on when to use this tool and how to obtain a needed input. However, it does not explicitly contrast with alternatives (e.g., get_transaction) or provide when-not-to-use guidance, 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.

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

With no annotations provided, the description carries full responsibility for disclosing behavior. It only states 'Get the current version' without mentioning that this is a read-only operation, whether it requires network access, potential errors, or the return format. This is a minimal behavioral disclosure.

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

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

The description is a single, short sentence that immediately states the tool's purpose. It is perfectly sized for the tool's simplicity with no unnecessary words or repetition.

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

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

Despite the absence of an output schema, the description effectively explains the tool's function for a trivial version-getter. The lack of edge cases or prerequisites keeps the tool simple, so the description is mostly complete, though a note about the return type would have made it fully complete.

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

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

The tool has zero parameters, so the baseline is 4 per the guidelines. The description correctly adds no parameter information since the schema already documents an empty properties object; there is nothing more needed.

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

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

The description uses a clear verb ('Get') and a specific resource ('qubic-mcp server version'), making its purpose unmistakable. It naturally distinguishes itself from all sibling tools, none of which relate to version retrieval.

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

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

The tool's intended use is implied by its name and description, but there is no explicit guidance on when to use it versus alternatives. Since no sibling performs a similar function, this is acceptable yet still lacks any contextual instruction.

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

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

With no annotations provided, the description carries the full burden. It clearly indicates a read-only operation ('List all') and specifies the return content (definitions with functions and field schemas). It does not mention any side effects or potential pagination, but for a parameterless list tool this is adequate.

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

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

The description is a single, front-loaded sentence with no filler. It states the action and scope efficiently.

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

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

For a parameterless tool with no output schema, the description fully informs the agent of what will be returned: all contract definitions with functions and field schemas. No further context is needed.

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

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

The tool has zero parameters and schema coverage is trivially 100%, so the baseline is 4. The description does not need to explain parameters and focuses on the output, which adds context beyond the empty schema.

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

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

The description clearly states the verb 'List' and the resource 'all registered custom smart contract definitions' with added detail about including functions and field schemas. This distinguishes it from siblings like register_contract or query_contract.

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

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

The usage is implied by the wording 'List all' but there is no explicit guidance on when to use this tool versus alternatives such as query_contract or query_smart_contract. No exclusions or alternative naming is provided.

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

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

No annotations are provided, so the description carries the full burden. It accurately describes a read-only listing operation, which is inherently non-destructive. However, it does not explicitly state that there are no side effects or that no special permissions are required. This is a minor gap for a simple list tool.

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

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

The description is a single, well-structured sentence that front-loads the verb 'List' and conveys all key information without any wasted words or redundancy.

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

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

For a zero-parameter tool with no output schema, the description sufficiently covers the core functionality: listing all networks and indicating the active one. It could potentially mention the output format, but this is not necessary given the simplicity of the tool.

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

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

The tool has zero parameters, and the schema confirms this. The baseline for 0-parameter tools is 4, and there are no parameter semantics to explain. The description adds no parameter info but none is needed.

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

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

The description clearly states the action (List), the resource (all available Qubic networks), and adds specificity ('built-in and custom') and the key feature of showing the active one. This distinguishes it from sibling tools like switch_network or add_network.

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

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

The description implies the primary use case: viewing networks and identifying the active one. It does not explicitly state when not to use this tool or mention alternatives, but the context is clear given the sibling tools. A score of 4 reflects the clear context without explicit exclusions.

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

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

With no annotations provided, the description carries the full burden and does add meaningful behavioral context: addresses are public and private keys are never stored. It also indicates the operation lists all saved wallets, implying no filtering. However, it does not describe the return format or edge cases like an empty list.

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

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

Two short, front-loaded sentences with no redundancy. The first sentence states the action and resource, the second adds a security clarifier, and every word earns its place.

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

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

For a zero-parameter tool with no annotations and no output schema, the description is nearly complete: it specifies the action, resource, and a key security property. It falls short only in explaining the exact response structure, but that is largely inferable from the described purpose.

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

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

The tool has zero parameters, which warrants a baseline score of 4. The description reinforces that all wallets are listed without any filtering, aligning perfectly with the absence of parameters.

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

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

The description uses a specific verb ('List') and a clear resource ('all saved Qubic wallet addresses'), which immediately distinguishes it from sibling tools like save_wallet and remove_wallet. The inclusion of 'Qubic' and 'saved' clarifies the exact scope.

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

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

The description implies usage by stating the action but provides no explicit guidance on when to use this tool versus alternatives like save_wallet or remove_wallet. There is no mention of prerequisites or scenarios where this tool is preferred.

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

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

Despite no annotations, the description discloses key behaviors: automatic binary encoding/decoding, input as JSON object with named fields, and response decoded to human-readable fields. This goes beyond the schema and helps the agent anticipate input/output transformations.

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

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

Four short sentences efficiently cover purpose, prerequisite, input format, and output behavior without redundancy. Each sentence contributes value.

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

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

The description covers the full workflow: registration prerequisite, invocation method, input format, and decoded output. It lacks an explicit comparison to query_smart_contract, but the registered-contract scope and automatic decoding are sufficient for the agent.

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

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

Schema covers 100% of parameters with descriptions, and the description repeats the input format without adding new details. It reinforces the example but doesn't add meaning beyond what the schema already provides, so baseline 3.

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

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

The description clearly states the tool 'Quer[ies] a registered smart contract function' with specific encoding/decoding behavior. It is distinct from raw queries by requiring registration, though it doesn't explicitly differentiate from the sibling query_smart_contract.

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

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

It explicitly instructs to 'Use register_contract first' and then call by contract/function name, providing a clear usage sequence. It does not list alternatives or when-not-to-use scenarios, so it misses explicit exclusions.

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

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

The description explicitly states 'read-only' and that it returns base64-encoded bytes, which is useful given there are no annotations. However, it introduces an inconsistency by mentioning 'inputHex' while the schema's parameter is 'requestData' (base64), which could confuse an agent about the actual input format.

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

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

The description is well-structured with a numbered list of known contracts, but that list largely duplicates the schema's contractIndex descriptions. The mention of 'inputHex' adds unnecessary confusion, so it is not fully concise or waste-free.

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

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

It covers the return format (base64 bytes), known contract indexes, and provides a starter tip. However, it lacks explanation of inputSize, and the encoding inconsistency (hex vs base64) creates a clear gap. Given no output schema, it's moderately complete but not fully self-sufficient.

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

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

Schema coverage is 100% with descriptions for all four parameters, so the baseline is 3. The description adds a helpful tip about inputType=0, but it also mentions a nonexistent parameter 'inputHex', conflicting with the schema's 'requestData' and potentially misleading the agent. This reduces the score.

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

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

Clearly states it queries a Qubic smart contract (read-only) and lists known contracts, providing a specific verb and resource. However, it does not explicitly differentiate from the sibling tool 'query_contract', so it loses the fifth point.

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

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

Provides clear usage guidance: it labels the tool as low-level, instructs to use inputType for function selection, and suggests starting with inputType=0 and empty input to get contract info. This gives practical direction, though it does not discuss alternatives or exclusions.

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

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

No annotations are present, so the description carries the full burden. It discloses supported field types, array count, enum mapping, and post-registration behavior, but omits side effects such as overwrite semantics, validation errors, or required permissions. This is a clear gap for a mutation tool.

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

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

The description is front-loaded with the core purpose, followed by usage summary, type details, and an example. It is longer than a one-liner but every sentence earns its place; the example is essential for understanding the expected JSON structure.

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

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

For a tool with 5 parameters and no output schema, the input side is well covered, but the description does not mention what the tool returns or how failures are reported. A brief note on return value and error handling would make it more complete, especially since there is no output schema.

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

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

Schema coverage is 100%, but the schema's description of the 'functions' parameter is generic. The description adds substantial meaning by detailing the JSON structure, supported field types, count/enum syntax, and providing a complete example. This goes well beyond the structured field descriptions.

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

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

The description opens with "Register a custom smart contract definition for use with query_contract," clearly identifying the verb, resource, and intended downstream use. It distinguishes the tool from siblings like list_contracts and remove_contract by explicitly naming query_contract as the consumer.

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

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

The description explains that registration enables querying by name with automatic encoding/decoding, giving a clear context for when to use it. It does not explicitly exclude alternatives (e.g., query_smart_contract for built-in contracts), but the term 'custom' and the link to query_contract imply the scope.

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

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

With no annotations, the description must carry the full burden of behavioral disclosure. It only states the removal action and does not mention side effects, irreversibility, error handling for non-existent names, or permission requirements. Minimal information beyond the core operation.

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

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

The description is a single, concise sentence with no unnecessary words. It efficiently communicates the essential purpose without filler.

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

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

The tool is a mutation with no annotations and no output schema, so the description must explain more about expected behavior. It lacks information about return values, error cases, or side effects, making it incomplete for an agent to fully anticipate outcomes.

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

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

Schema description coverage is 100% for the single 'name' parameter, and the schema provides a clear description. The tool description only repeats 'by name', adding no additional meaning. Baseline 3 is appropriate.

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

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

The description clearly states the action ('Remove'), the resource ('registered smart contract definition'), and the method ('by name'). It effectively distinguishes this tool from siblings like register_contract, list_contracts, and query_contract.

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

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

The description implies usage when one wants to remove a contract, but it does not provide explicit context such as prerequisites (e.g., contract must exist) or when to prefer alternatives. No exclusions or alternative tool references are given, making it a basic implied usage.

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

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

With no annotations provided, the description carries the full burden of disclosing behavior. It clearly states two key behaviors: built-in networks cannot be removed, and if the removed network was active, the tool switches back to mainnet. This goes beyond the basic 'delete' action and helps the agent anticipate side effects.

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

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

Two sentences, front-loaded with the action, and no wasted words. The description efficiently covers purpose, a key restriction, and a behavioral consequence in a compact form.

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

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

For a simple tool with a single parameter and no output schema, the description is complete. It addresses the main action, the critical edge case (built-in networks), and a relevant fallback behavior (switching to mainnet), covering all necessary context.

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

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

The schema fully documents the 'name' parameter (100% coverage), so the baseline is 3. The description adds value by clarifying that the name refers to a 'saved custom network' and that built-in names are invalid, which helps the agent select an appropriate value for the parameter.

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

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

The description uses a specific verb ('Remove') and resource ('saved custom network'), clearly distinguishing it from sibling tools like add_network, switch_network, and list_networks. It also states what it cannot do (removing built-in networks), further clarifying its scope.

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

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

The description implicitly guides usage by restricting to custom networks and explicitly noting that built-in networks cannot be removed. While it doesn't name alternative tools, the context signals and siblings make it clear when to use this tool. The built-in network exclusion is a useful usage constraint.

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

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

The description clearly discloses a crucial behavioral trait: it only removes the local reference and does not affect the blockchain address. This is particularly important for a deletion operation, though it does not mention potential errors or side effects like wallet-not-found behavior.

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

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

The description is two sentences long, directly states the action and the key caveat, and contains no extraneous information. It is front-loaded with the verb and resource.

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

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

For a simple tool with one parameter, the description adequately covers purpose and the most important behavioral nuance. It lacks details about return values or error handling, but since there is no output schema and the operation is straightforward, this is a minor gap.

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

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

The input schema already fully describes the single parameter ('name' with 'The name of the wallet to remove'), and the description reinforces this with 'by name'. With 100% schema description coverage, the description adds no extra parameter context, 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.

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

The description uses a specific verb ('Remove') and resource ('a saved wallet by name'), making the tool's function immediately clear. It also implicitly distinguishes itself from sibling tools like 'save_wallet' and 'list_wallets' by focusing on removal.

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

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

No explicit guidance is given on when to use this tool versus alternatives. It does not name alternatives or provide context for specific scenarios, leaving the agent to infer usage solely from the tool's name.

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

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

With no annotations provided, the description fully carries the burden of disclosure. It explicitly states that only public addresses are saved, never seeds/private keys, and that data is stored locally in ~/.qubic-mcp/wallets.json. This is critical behavioral context for an agent handling wallet information.

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

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

The description is two sentences, front-loaded with the primary action, and each sentence contributes unique value: purpose and security/storage detail. There is no redundancy or fluff.

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

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

For a simple 2-parameter save tool with no output schema, the description covers the core purpose, the privacy implications, and the storage location. This is sufficient for an agent to understand what the tool does and what side effects to expect, without needing additional return-value details.

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

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

Schema description coverage is 100%, so the schema already provides full parameter meaning. The description adds a small reinforcement ('friendly name' aligns with the name parameter) but does not add any extra constraints or format details beyond the schema, matching the baseline expectation.

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

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

The description clearly states the verb+resource: 'Save a Qubic wallet address with a friendly name for quick access.' It distinguishes from sibling tools (list_wallets, remove_wallet) by explicitly focusing on the save action, and adds a specific safety clarification that only the public address is stored, never seeds/private keys.

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

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

The description conveys clear context: use when you want to store a wallet for quick access. It does not explicitly mention alternatives or when not to use, but the sibling tool names ('list_wallets', 'remove_wallet') implicitly provide the decision boundary, and the phrase 'for quick access' gives a concrete use case.

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

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

No annotations are provided, so the description carries the full burden. It discloses the key behavioral trait that all subsequent tool calls use the new endpoint, which is essential. It doesn't mention failure modes or permissions, but for a simple switch tool this is adequate.

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

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

Three short sentences, front-loaded with the core action, and every sentence adds value. No redundant or artificial detail.

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

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

For a single-parameter tool with no output schema, the description covers purpose, effect, built-in options, and the alternative for custom networks. It is fully sufficient for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100% and the schema already describes the 'name' parameter with examples. The description adds little beyond that, only noting built-in networks, so it meets the baseline without adding extra parameter semantics.

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

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

The description uses a specific verb ('switch') and resource ('active Qubic network'), clearly distinguishing it from sibling tools like add_network, list_networks, and remove_network. It also states the consequence of the switching action.

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

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

It explicitly names the alternative tool for custom networks ('Use add_network to save custom networks'), and implies this tool is for switching to built-in networks. It also notes that the switch affects all subsequent calls, providing clear context.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly explains that validity is determined by format plus on-chain existence with balance or transfer activity, which is transparent about the validation criteria. It does not state side effects, but as a validation tool it is implicitly read-only, and the description adds meaningful context beyond the tool name.

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

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

The description is a single, front-loaded sentence that conveys the complete purpose and validation criteria without any filler. It is concise and efficient, earning the highest score for structure.

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

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

For a tool with one required parameter and no output schema, the description covers the core function well: it defines what 'validate' means (format + on-chain existence). It does not describe the return format, which would be helpful but is not strictly necessary given the tool's simplicity. The description is reasonably complete for an agent to invoke correctly.

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

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

The input schema already documents the single parameter with a clear description ('Qubic address to validate (should be 60 uppercase letters)'), and schema_description_coverage is 100%. The tool description does not add any extra 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.

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

The description uses a specific verb ('validate') and identifies the resource ('Qubic address'), then clearly distinguishes itself from siblings by specifying the two-part check: format and on-chain existence with balance or transfer activity. No other sibling tool performs validation, so this tool is unambiguous.

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

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

The description implies usage for validating an address before operations, but it does not explicitly state when to use this tool versus alternatives (e.g., get_balance or get_transfer_history for checking activity). It provides no when-not-to-use guidance or references to sibling tools.

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