Agentic Swarm Marketplace (T54 x402 MCP)

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

Annotations indicate idempotent and non-destructive behavior, and the description adds context about what the audit involves (5 phases, proxy handling, return components). It does not contradict annotations; however, it could clarify if any on-chain activity occurs during the audit.

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

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

Two sentences with no fluff: first sentence defines purpose and constraints, second lists outputs. Information is front-loaded and every sentence serves a clear purpose.

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

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

Given no output schema, the description thoroughly enumerates return components (Slither, Echidna, deployer profiling, etc.) and highlights proxy handling. Lacks mention of execution time, cost, or prerequisites, but overall is complete for a tool of this complexity.

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

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

Schema coverage is 100%, so baseline is 3. The description reinforces the schema's parameter details (max 3 addresses, comma-separated, default chain) but adds no new 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?

Clearly states the tool runs a full 5-phase security audit on up to 3 EVM contract addresses, with specific verb and resource. Distinguishes from siblings like contract_triage or contract_monitor_subscribe by emphasizing comprehensive analysis including Slither, Echidna, and deployer profiling.

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

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

Implies usage for deep security audit but lacks explicit guidance on when to use this tool versus alternatives like contract_triage for quick checks. No when-not or alternatives mentioned, though the scope and output details provide some implicit direction.

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 annotations already declaring idempotentHint=true and destructiveHint=false, the description adds valuable context: it creates a subscription that triggers alerts on specific events (admin key movement, liquidity drops, etc.) and has a default 30-day duration. No contradictions with annotations.

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

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

Two sentences, front-loaded with the core purpose, and every word earns its place. No unnecessary 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 no output schema, the description should explain the return value (e.g., subscription ID or confirmation). It omits this, leaving a gap. Otherwise, it covers the input parameters and behavior adequately.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The tool description does not add significant meaning beyond the schema's descriptions (e.g., 'addresses' is described as 'Up to 10 0x-prefixed EVM addresses to watch' in both). 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 (subscribe), resource (monitoring of up to 10 EVM contract addresses), and outcome (fires webhook alerts on specific risk events). It effectively distinguishes this from sibling tools like contract_audit and contract_triage by focusing on continuous monitoring.

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 does not provide explicit guidance on when to use this tool versus alternatives. It implies usage for monitoring contracts but offers no when-not or comparison with sibling tools like contract_audit or contract_triage.

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 indicate idempotentHint=true and destructiveHint=false, so the description adds value by specifying a 30-second completion time and the return format (risk score, verdict, flags). However, it does not disclose potential side effects, authentication requirements, or error handling for invalid addresses, leaving gaps beyond what annotations cover.

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 exceptionally concise: two sentences that front-load the action and outputs. Every word carries meaning with no fluff 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?

Given the low parameter count, full schema coverage, and presence of annotations, the description provides sufficient context for an agent to understand the tool's purpose and behavior. It lacks details on error scenarios or interpretation of the risk score, but for a straightforward screening tool this is 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?

The schema covers 100% of parameters with descriptions for both chain_id and contract_address. The description does not add additional meaning beyond what is already in the schema, 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 specifies the tool's action ('screen an EVM smart contract address'), its purpose ('malicious patterns, honeypots, rug mechanics, and known scam frameworks'), and its outputs ('risk score, verdict, top threat flags'). It effectively distinguishes itself from sibling tools like contract_audit by emphasizing speed ('under 30 seconds') and focus on quick triage.

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 quick screening ('under 30 seconds') but does not explicitly state when to use this tool versus alternatives like contract_audit for deeper analysis or contract_monitor_subscribe for ongoing monitoring. No when-not-to-use guidance 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?

Annotations already indicate idempotent and non-destructive behavior. The description adds value by disclosing the payment requirement and potential HTTP 402 response, which is critical for agent decision-making.

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

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

The description is short and front-loaded, with the endpoint and key behavior in the first sentence. Some redundancy (title repeated) slightly reduces conciseness.

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 low complexity (one optional parameter, no output schema), the description covers payment behavior and basic purpose. However, it omits explanation of domain-specific terms like 'verifiable swarm proof' and 'x402 commerce bundle', which may confuse agents unfamiliar with the system.

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 single parameter 'depth' is fully documented in the schema with enum and description. The description does not add any additional meaning or context for this 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 identifies the tool as returning a 'verifiable swarm proof + x402 commerce bundle' via an HTTP GET endpoint, but the phrasing is jargon-heavy and lacks a clear verb-resource structure. It does not distinguish this from sibling tools like t54_x402_request.

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

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

No guidance on when to use this tool versus alternatives. The description mentions a paid route and HTTP 402 but does not explain contexts where this is preferred over other tools.

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

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

Annotations already declare idempotency and non-destructiveness. The description adds that it is an HTTP GET, discloses that paid routes may return HTTP 402 (payment via x402), and mentions the outputs (Farm Score, risk flags). This provides valuable behavioral context beyond annotations.

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

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

The description is very short and front-loaded with the tool title. It efficiently includes the endpoint and payment behavior note. However, it could be slightly more concise by removing the redundant title 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?

Given the tool has three optional parameters and no output schema, the description covers the core outputs (Farm Score, risk flags) and payment behavior, but lacks details on default behavior, cost, or how parameters affect results.

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

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

Schema coverage is 100%, so baseline is 3. The description adds no new information about parameters beyond their existence; the schema descriptions already cover the meaning of 'topic', 'context_note', and 'contract_address' adequately.

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 performs 'Airdrop / incentive screening' and mentions 'Farm Score, risk flags', which clearly indicates its purpose. It distinguishes from sibling tools like contract_audit (which audits contracts) and research_brief (general research). However, it lacks an explicit verb like 'evaluate' or 'score'.

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

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

No guidance on when to use this tool versus alternatives. The description does not specify scenarios (e.g., 'use this when assessing airdrop risks') or exclude cases where contract_triage might be more appropriate.

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 indicate idempotentHint=true and destructiveHint=false. The description adds that it's a GET endpoint and mentions HTTP 402 payment failures, which is useful context beyond annotations. However, it does not disclose other behaviors like rate limits or error handling.

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

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

The description is two sentences long, which is concise, but it front-loads technical details (HTTP method, operationId) rather than a plain-language summary. It could be restructured to state the purpose first.

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 low complexity (1 optional param, no output schema), the description should explain what the heuristic audit returns or how the results are presented. The payment note alone is insufficient; the user needs to know what constitutes a 'constitution/ethics review'.

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 coverage is 100% with a single optional parameter (prompt_snippet) that has a description. The description adds no extra detail about the parameter's usage, meaning it meets the baseline but does not enhance understanding.

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 title 'Heuristic constitution / ethics review' suggests a clear purpose, but the description only provides the HTTP endpoint and a payment note. It lacks a direct statement of what the tool does (e.g., 'Screens text for constitutional violations'). The purpose is inferable but not explicitly stated.

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

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

No guidance on when to use this tool vs. sibling tools like contract_audit or t54_research_brief. The only usage hint is the HTTP 402 payment note, which implies it may be for paid users but does not clarify conditions or alternatives.

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

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

Annotations are provided (readOnlyHint=false, idempotentHint=true) and the description adds important behavioral details: it's an HTTP GET, no payment required, and paid routes may return 402. This goes beyond what annotations alone convey.

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 fairly concise but contains redundancy (title repeated in first line) and could be streamlined. Still, it is effective and front-loaded with key info.

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 health probe, the description is complete: it states the output includes 'llm' probe, the HTTP method, and a note about payment status. No output schema is needed for such a simple endpoint.

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?

No parameters exist, and schema coverage is 100% (empty). The description correctly indicates the endpoint is a simple GET without inputs, so no additional parameter information 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 it returns JSON with an 'llm' probe and that it requires no payment, distinguishing it from sibling tools that deal with contracts, commerce, or other operations.

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 indicates this tool is for health checking without payment and mentions potential HTTP 402 for paid routes, but does not explicitly enumerate when to use versus alternatives. However, the sibling tools are quite different in function, so context 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?

Annotations indicate non-read-only (readOnlyHint=false), idempotent, and non-destructive (destructiveHint=false). The description adds that the tool may trigger payment settlement and return 402 until settlement, clarifying behavioral traits beyond annotations.

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

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

The description is short, with two sentences and minimal waste. The first line repeats the title, which slightly reduces efficiency, but overall it's 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?

No output schema is provided. The description mentions HTTP 402 and minimal JSON body but does not specify the success response format or JSON structure, leaving some ambiguity for a tool that would benefit from such 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?

The tool has zero parameters with 100% schema coverage. With no parameters to describe, the description need not add parameter details, and the baseline score of 4 applies.

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

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

The description states 'Confirms HTTP 402 + T54 facilitator path; minimal JSON body' and specifies the HTTP GET endpoint, clearly indicating the tool tests micropayment routing. However, the phrase 'confirms' is somewhat vague and could be more precise about the verification 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?

The description mentions that paid routes may return HTTP 402 until settlement, implying use for checking payment readiness. No explicit guidance on when not to use or alternatives among sibling tools is provided, leaving context implied.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds 'no network', indicating no external calls. This is consistent and provides useful behavioral context beyond annotations.

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

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

The description is two sentences long. The first sentence states the output; the second provides usage guidance. Every sentence is essential and well-structured.

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 having no output schema, the description lists the exact data returned (operationIds, methods, paths, param names). Annotations cover safety. For a parameterless tool, this is 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?

There are zero parameters, so the description does not need to add param meaning. Schema coverage is 100%. Baseline score 4 applies as the description adds no unnecessary detail.

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 operationIds, HTTP methods, paths, and query parameter names from the bundled OpenAPI spec. The title 'List T54 OpenAPI operations' and the mention of using it before specific sibling tools distinguish its purpose and 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 explicitly says 'Use before t54_x402_request or per-SKU tools', providing clear context for when to use this tool. While it doesn't list alternatives in detail, the positive guidance is sufficient for correct selection given the sibling tool names.

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 indicate idempotentHint=true and destructiveHint=false. The description adds a note about HTTP 402 for paid routes, which is additional behavioral context, but does not explain output format or other behaviors.

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 includes unnecessary HTTP method and operationId details for an AI agent. It could be more concise by focusing on the tool's function and removing technical implementation specifics.

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 (2 optional params, no output schema), the description is too vague. It lacks explanation of what a 'multi-section research brief' is, how the parameters shape it, and what the agent can expect in return.

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?

Both parameters (topic, context_note) are fully described in the input schema with length limits. The description adds no further semantic value beyond what the schema 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 title and description mention 'Multi-section research brief' and HTTP GET, but do not explain what a research brief is or its sections. The purpose is vaguely stated, relying on the tool name for meaning.

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 its siblings (e.g., t54_structured_query, t54_agent_commerce_data). There is no mention of use cases 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?

Annotations already disclose idempotent and non-destructive nature. The description adds value by mentioning potential HTTP 402 error due to x402 broker payment requirements. However, it does not describe side effects, success behavior, or return format beyond what annotations imply.

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

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

The description is short but contains a redundant first sentence that repeats the title. The structure is somewhat organized with technical details, but the most important functional information is not 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?

Given the tool's simplicity (one parameter, no output schema), the description provides basic context: endpoint, operationId, and payment note. However, it lacks explanation of 'constitution-safe', what the success response looks like, and how it differs from siblings, leaving gaps for 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 input schema has 100% coverage with a clear description for the only parameter 'q'. The tool description adds no additional information about the parameter (e.g., formatting, examples, or constraints), so it provides marginal extra value.

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 tool's purpose is clear when combining the title 'Constitution-safe short LLM answer' and the schema parameter description 'Natural-language question for a short constitution-safe answer'. However, the description itself is fragmented and does not explicitly state the verb-resource relationship, nor does it differentiate from sibling tools like 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?

The description provides no guidance on when to use this tool versus alternatives such as t54_research_brief or t54_airdrop_intelligence. It only gives technical details (HTTP GET, endpoint, possible 402 error) without context for selection.

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?

Description adds context beyond annotations: mentions the HTTP 402 payment and retry mechanism. Annotations already indicate non-read-only, non-destructive, idempotent; no contradiction.

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 sentences with no waste. First sentence gives core purpose, second provides usage guidance, third explains error handling. Front-loaded with essential 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 generic nature of the tool (2 params, no output schema), the description adequately covers how to obtain operation_id, use query, and handle 402 errors. Complete for its role.

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 baseline is 3. Description adds value by listing known operationIds and explaining query keys must match OpenAPI query names, with a reference to the resource.

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 'Execute any T54 seller operation by operationId with an optional query map.' It distinguishes from siblings by advising to prefer per-operation t54_* tools when available.

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

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

Explicitly says 'Prefer per-operation t54_* tools when available' giving when-not guidance. Also instructs to call t54_list_operations first and describes HTTP 402 retry behavior.

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