Agentic Swarm Marketplace (T54 x402 MCP)

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

Annotations indicate readOnlyHint=false, but the description does not disclose any side effects or state changes. It lists analysis capabilities but omits whether results are stored, if external APIs are called, or any limitations. The idempotentHint=true and destructiveHint=false provide some safety context, but the description adds no additional behavioral 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 two sentences, front-loaded with the core action, and uses a compact enumeration of outputs without extraneous words. Every sentence earns its place.

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

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

For a complex tool with no output schema, the description covers input constraints and provides a detailed list of return data. It doesn't mention execution time, prerequisites, or failure scenarios, but the enumerated outputs give a solid understanding of expected results.

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

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

The description clarifies that 'addresses' accepts up to 3 EVM addresses and specifically handles proxy/implementation pairs, supplementing the schema. The chain_id parameter is well-described in the schema, and the description's mention of EVM and Base helps contextualize it.

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

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

The description clearly states it runs a full 5-phase security audit on up to 3 EVM addresses, distinguishing it from lighter sibling audit tools. It also enumerates specific output components, 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.

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

The description explicitly frames the tool as a 'full' audit that handles EIP-1167 proxy pairs, indicating it is intended for comprehensive security reviews. It lacks explicit when-not-to-use or alternative tool mentions, but the context is clear enough for an agent to infer appropriate use cases.

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

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

Annotations provide readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds useful context by specifying exactly what triggers webhooks (admin key movement, liquidity drops, etc.) and the subscription duration, going beyond the bare hints. It does not contradict the annotations.

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

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

Two concise sentences: the first states the action and limits, the second lists alert triggers. Every word earns its place, no fluff or redundant repetition of the title or schema.

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

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

No output schema exists, so the description carries the burden for expected returns. It covers the core behavior (subscription, duration, alert types) and parameter limits. It omits cost implications (though the title mentions Base USDC x402) and cancellation details, but for an invocation-focused tool, it is reasonably complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description restates the purpose of parameters (addresses to watch, webhook URL for alerts) but adds no additional semantic detail beyond what the schema already provides. It does not clarify formatting, examples, or edge cases, so it stays at baseline.

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

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

The description names a specific verb ('Subscribe') and resource ('continuous monitoring of EVM contract addresses'), and clearly distinguishes itself from one-time audit/triage siblings by emphasizing the 30-day continuous nature and webhook alerts. The exact event types ('admin key movement, liquidity drops, claim condition changes, or new critical Slither findings') make the scope unmistakable.

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 context is clear: this is for ongoing monitoring, not a one-time audit. However, there is no explicit 'when not to use' or mention of alternatives like contract_audit or contract_triage. The implied differentiation is sufficient for an agent to select correctly, but lacks the explicit exclusion that would earn 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?

Annotations already provide idempotentHint=true and destructiveHint=false, and the description adds value by detailing the return contract (risk score 0-100, verdict SAFE/SUSPICIOUS/MALICIOUS, top threat flags) and a performance guarantee (<30s). It does not disclose whether external network calls or stored state are involved, but it does not contradict the annotations.

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

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

Two sentences deliver the action, threat scope, output format, and latency with zero filler. Every phrase contributes information, making it easy to scan and process.

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 compensates by explicitly listing the return values, and it names the EVM scope and default chain through the schema. However, it does not clarify how verdict thresholds are derived or how to interpret the risk score, which is a minor gap for a security-oriented tool.

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

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

Schema description coverage is 100%: contract_address is already described as '0x-prefixed EVM contract address to screen' and chain_id as a CAIP-2 chain id with a Base mainnet default. The tool description adds no additional parameter-level context, so it stays 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.

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

The description opens with a specific verb-resource pair: 'Screen an EVM smart contract address,' and enumerates concrete threat categories (malicious patterns, honeypots, rug mechanics, and known scam frameworks). It closes with clear outputs (risk score, verdict, threat flags) and a time bound that distinguishes it from deeper audit or monitoring tools in its sibling 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 phrase 'Completes in under 30 seconds' and the word 'triage' imply a quick pre-screening use case, but the description never explicitly states when to use this tool versus contract_audit or contract_monitor_subscribe, nor does it mention any exclusions. The guidance is present only by implication.

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

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

The description adds value beyond annotations by disclosing the HTTP 402 behavior for unpaid routes. However, it does not clarify why readOnlyHint is false, what side effects may occur, or what happens after payment settles. Annotations already cover idempotency and non-destructiveness.

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

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

The description is short but redundant, repeating the title verbatim. The endpoint and operationId are useful for technical reference but not essential for an AI agent's selection. It could be more streamlined.

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 premium/payment aspect and the existence of sibling t54_x402_request, the description is incomplete. It does not explain the relationship between the tools, what to do upon receiving a 402 response, or what the returned bundle contains. Without an output schema, the description should compensate but does not.

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 depth parameter is fully described (enum, default, and description). The description does not add any meaning beyond the schema, such as how to choose between standard and full payloads.

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 identifies the resource as a 'verifiable swarm proof + x402 commerce bundle' and mentions HTTP GET, but lacks an explicit action verb like 'retrieves' or 'fetches'. It does not clearly differentiate from sibling t54_x402_request, which likely handles the payment flow.

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

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

No guidance is provided on when to use this tool versus alternatives such as t54_x402_request, nor any prerequisites like payment. The 402 note hints at a payment dependency but does not explain how to use the tool in that flow.

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

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

Annotations already declare non-destructive, open-world, and idempotent behavior. The description adds valuable behavioral context about paid routes potentially returning HTTP 402 until the x402 broker settles, and explicitly identifies the HTTP GET method. This goes beyond annotation-only information and helps the agent anticipate payment-related errors.

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

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

The description is brief and front-loaded with the core purpose, but the first sentence is a verbatim repetition of the title, which is slightly redundant. Still, the two sentences are efficient and avoid unnecessary fluff, earning a high conciseness score.

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

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

Since there is no output schema, the description must clarify what the tool returns, but it only mentions 'Farm Score, risk flags' without elaborating on the report format or content. It also lacks context on how the screening works or how it differs from sibling tools. The payment detail is useful but does not compensate for the incomplete picture.

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 all three parameters with 100% coverage (topic, context_note, contract_address). The description does not add further semantic detail 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 clearly states 'Airdrop / incentive screening (Farm Score, risk flags)' and provides the HTTP endpoint and operation ID, making the tool's purpose specific and distinct from general audit/research tools. However, it does not explicitly contrast it with sibling tools, though the unique focus on airdrops/incentives differentiates it.

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

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

The description provides no guidance on when to use this tool versus alternatives. It just repeats the title and gives endpoint/payment details, with no mention of appropriate scenarios, prerequisites, or exclusions. The agent is left to infer usage from the title alone.

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

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

The description adds the behavioral detail that paid routes may return HTTP 402 until the x402 broker settles, which complements the annotations (idempotent, non-destructive). However, it does not explain whether the tool has side effects (readOnlyHint is false) or what the response contains. Since annotations already cover safety profile, this extra context earns a mid score.

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 brief and front-loaded with the title, then the endpoint and payment note. However, the first sentence is redundant with the title, and the payment note, while relevant, is tangential to purpose. Minimal waste but repetition keeps it from a top score.

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

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

For a simple one-parameter tool with no output schema, the description still fails to mention what the response looks like or what 'audit' means operationally (e.g., heuristic pass/fail, scores, citations). The HTTP/402 note is niche and doesn't round out the tool's behavior, making the description incomplete for an agent deciding to invoke 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?

Input schema fully describes the single parameter prompt_snippet with its purpose and max length, so the schema carries the semantic load. The description adds no parameter-specific details, but with 100% coverage the baseline of 3 applies.

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

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

The description repeats the title 'Heuristic constitution / ethics review' and adds the HTTP endpoint and operationId, but does not explicitly state what action it performs (e.g., screens a prompt for violations) or what it returns. It is distinguishable from sibling tools like contract_audit by the 'constitution/ethics' domain, but the verb/resource combination is vague.

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

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

No guidance is provided on when to use this tool versus alternatives such as contract_audit or contract_triage. The only practical note is the payment/402 behavior, which addresses failure conditions, not selection 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?

Annotations already flag idempotent and non-destructive, and the description adds useful context: the HTTP method, the free nature of the route, and the behavior of paid routes (402). It does not contradict annotations and provides enough extra detail to understand what the tool does beyond the structured fields.

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 long with no fluff: it states the title, return type, and key behavioral notes. Every sentence adds value (purpose, free status, HTTP method/path, 402 warning), making it appropriately concise and front-loaded.

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

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

For a health-check tool with no input schema and no output schema, the description covers the essential aspects: endpoint, HTTP method, return type, and payment requirements. It does not detail the exact structure of the health response, but the information provided is sufficient for an agent to select and invoke the tool correctly in most contexts.

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

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

The tool has zero parameters, so the description carries no parameter documentation burden. The baseline for no parameters is 4, and the description appropriately focuses on the return value and endpoint rather than 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 clearly states the tool returns JSON including an `llm` probe and specifies the HTTP GET `/health` endpoint. This distinguishes it from siblings like t54_hello_ping by explicitly mentioning the LLM probe and the HTTP path, making the tool's specific function 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 provides contextual guidance by noting that the route 'does not require payment' and that paid routes may return HTTP 402 until the broker settles, implying this is a low-cost health check. However, it does not explicitly state when to use this tool versus alternatives like t54_hello_ping or list operations.

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

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

Annotations already cover idempotency and destructive safety, but the description adds concrete behavioral context: the exact HTTP method and path, the operationId, the minimal JSON body, and the possibility of HTTP 402 until the broker settles. This goes beyond the annotations without contradicting them.

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

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

The description is very short and front-loaded, but the first sentence 'Micropayment ping (cheapest SKU)' is a direct repetition of the title and does not add new information. The remaining sentences are efficient and informative, but the redundancy prevents a higher score.

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

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

Given the tool's simplicity (zero parameters, no output schema), the description covers the essential contract: endpoint, operationId, and the 402 behavior. It does not detail the exact success response body, but 'minimal JSON body' plus the annotations provide enough context for a competent 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, so there is nothing for the description to elaborate on beyond the input schema. The description reasonably omits parameter details and instead focuses on the endpoint and behavior, which is sufficient for a no-argument tool.

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

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

The description clearly states that this tool is a micropayment ping confirming the HTTP 402 and T54 facilitator path, with a specific endpoint (HTTP GET /hello) and operationId. It is more specific than a generic ping and hints at differentiation via 'cheapest SKU', though it does not explicitly contrast with sibling tools like t54_get_health.

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 statement that paid routes may return HTTP 402 until the x402 broker settles implies this tool is useful for verifying the payment path before using paid routes. However, it does not explicitly state when to use this tool versus alternatives such as t54_x402_request or t54_get_health.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, so the bar for additional transparency is lower. The description adds valuable context beyond annotations: it is offline ('no network') and enumerates the specific return fields, helping the agent anticipate output despite no output schema. It does not contradict annotations.

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

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

Two concise sentences: the first states exact output and data source, the second gives usage context. Every word is purposeful, 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 zero-parameter, read-only list tool, the description plus annotations fully cover purpose, usage, and expected behavior. The explicit mention of t54_x402_request provides clear integration context, making the tool's role in the larger workflow obvious.

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

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

The tool has zero parameters, so schema coverage is trivially 100%. With no parameters, the description has no parameter semantics to add, and the baseline for zero-param tools is 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?

The description precisely states the tool returns operationIds, HTTP methods, paths, and query parameter names from the bundled OpenAPI spec. It distinguishes itself from sibling tools by explicitly framing this as a pre-request discovery tool and notes the offline nature ('no network'), which sets clear expectations.

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 explicit usage guidance: 'Use before t54_x402_request or per-SKU tools.' This tells the agent exactly when to invoke this tool relative to alternatives, giving clear sequencing and context for its role in the workflow.

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

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

The description adds the HTTP 402 payment behavior and endpoint details, which are useful beyond the annotations. Annotations already indicate idempotent, non-destructive, and non-read-only, and the description does not contradict them. However, it does not disclose what the tool returns or any side effects, so transparency is limited.

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

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

The description is short but starts with a redundant restatement of the title. The useful endpoint and payment information is buried after the redundant first line. It is not waste-free, but it is compact.

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 should explain what the tool returns, but it only mentions the HTTP endpoint and payment behavior. The purpose is implied by the title and parameter descriptions, but the description leaves the agent uncertain about the actual output format or structure of the 'multi-section research brief'. This is incomplete for a tool with 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?

The input schema provides 100% coverage with descriptions for both 'topic' and 'context_note', so the description need not add param details. It does not add any additional meaning beyond the schema, matching the baseline of 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 repeats the title 'Multi-section research brief' without an explicit verb or action. It provides the HTTP GET endpoint and operationId, but does not state what the tool does (e.g., generates/retrieves a research brief) in actionable terms. This fails to distinguish it from sibling tools like t54_structured_query or t54_agent_commerce_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?

No guidance is given on when to use this tool vs alternatives. The only conditional note is about HTTP 402 payments, which is a prerequisite/error condition, not a use-case guideline. There is no mention of competing tools or scenarios.

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

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

The annotations already indicate idempotent and non-destructive behavior. The description adds beyond that by specifying the HTTP GET method, the listing-friendly nature, and the paid-route behavior that may return HTTP 402 until the x402 broker settles. This is valuable context consistent with the `readOnlyHint: false` annotation, though it could disclose more about auth or rate limits.

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

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

The description is compact and front-loaded with the endpoint and method. The only minor flaw is that the opening sentence repeats the title verbatim, adding little value, but otherwise every sentence contributes useful information.

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

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

For a simple single-parameter GET tool with no output schema, the description covers the route, method, payment-related behavior, and the nature of the answer. It does not spell out the exact response payload, but the title and parameter description provide enough 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.

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

The schema has 100% coverage for the single parameter `q`, including a descriptive explanation and a max length. The tool description adds no semantic detail 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.

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

The description identifies a GET endpoint that accepts a natural-language `q` parameter and returns a short, constitution-safe LLM answer. It includes the route, operationId, and enough context to distinguish it from sibling tools like `t54_research_brief` or `t54_constitution_audit_lite`, though it lacks an explicit verb such as 'retrieves' or 'returns'.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives. It mentions 'listing-friendly' and a payment/402 caveat, but does not state when to prefer this over related tools or when not to use it.

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

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

The description adds a specific behavioral detail beyond annotations: 'On HTTP 402, x402_broker_client pays then retries.' This informs the agent of payment/retry behavior. Annotations (readOnlyHint false, idempotentHint true, destructiveHint false) are not contradicted, but the description could disclose more about side effects of arbitrary operations.

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, then usage guidance and a note on 402 handling. Every sentence contributes value, with no waste.

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 generic tool with an open-world hint and idempotency flag, the description is fairly complete: it states the operation, suggests alternatives, points to t54_list_operations for discovery, and notes 402 handling. It lacks explicit return-value documentation, but no output schema is provided, and the generic nature makes that acceptable.

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

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

Schema coverage is 100% for both parameters, with detailed descriptions for operation_id and query, including known operation IDs and a link to the OpenAPI spec. The description itself only repeats 'optional query map', adding no new semantic meaning 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 executes any T54 seller operation by operationId, with an optional query map. It explicitly distinguishes from dedicated per-operation tools by advising to prefer them when available, making it a generic fallback.

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 guidance: 'Prefer per-operation t54_* tools when available', which tells the agent to use dedicated tools when possible and this generic one otherwise. It also mentions behavior on HTTP 402, adding operational context, though it doesn't fully enumerate all when-not-to-use scenarios.

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