t2000_agent_sell

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

Since annotations are absent, the description carries full burden. It discloses live-probing behavior, specific conditions (must answer 402 with valid Sui challenge), per-route failure reporting, gasless signature, immediate visibility, and explicitly states 'This does NOT spend funds.' This is excellent behavioral transparency with no annotation 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?

The description is information-dense and front-loaded with the main purpose. It includes extra context like CLI mirror, no-spend, and visibility. However, some redundancy exists with schema descriptions (endpoint behavior, remove flag), and a few sentences could be tightened. Still, each sentence contributes overall 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?

Despite having no output schema and no annotations, the description covers the full workflow: prerequisites, input handling, server-side probing, on-chain signature, immediate availability, removal, and a non-monetary side-effect note. It tells the agent exactly what to expect and what to state to the user, making it complete for a 3-parameter tool with complex 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?

Input schema already provides detailed descriptions for all three parameters (100% coverage), including endpoint behavior and primary default. The description adds little beyond the schema; it repeats endpoint semantics and mentions 'primary route' in the process, but no new parameter-specific meaning is introduced. Baseline 3 applies because schema does the heavy lifting.

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

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

Description starts with a specific verb+resource: 'Sell this agent's x402 API as Services on its public Agent ID.' It clearly states the purpose and includes concrete outcomes (buyers pay per call in USDC, routes appear on t2000.ai). It distinguishes itself from sibling tools like t2000_service_create by focusing on agent API selling and mentioning t2000_services for buyers.

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 context on how to invoke (origin vs. single route URL, remove flag, primary route default) and prerequisites (requires on-chain Agent ID). However, it does not explicitly contrast with alternatives like t2000_service_create or t2000_service_retire, nor when NOT to use this tool, so it misses the 'when-not/alternative' bar for a 5.

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