Three tools with complete input schemas and descriptions, but descriptions are terse (40-80 chars, below the 194-char baseline). All tools are read-only discovery/analytics with no state mutation, which simplifies error handling but limits practical utility. Tool names follow verb_noun convention (barter_discover, barter_quote_curve, barter_arbitrage_book). Schemas are well-formed with proper types and constraints (enums, min/max). However, descriptions lack actionable context: no guidance on when to call each tool, no dependency hints, and no explanation of the 402 protocol or arbitrage mechanics that would help an LLM understand the domain. Parameter descriptions are minimal (e.g., 'Source registry to scrape' lacks explanation of what data is returned or why one registry might be preferred). Output schemas are not documented, responses are JSON text blobs with no declared structure.

• Expand tool descriptions to 150 - 250 chars. Include: what the tool does, when to call it, what it returns, and any prerequisites. Example: 'Discover 402-enabled MCP endpoints from a public registry. Call this first to find targets for arbitrage probing. Returns endpoint URLs, last-seen asking prices, and registry metadata. Supports glama, smithery, mcp.so.'
• Document output schemas explicitly. Define the structure of each response (e.g., barter_discover returns {registry, count, rows: [{url, price, last_seen}]}). This enables LLMs to extract fields and chain tools.
• Add parameter descriptions that explain constraints and context. E.g., 'limit: Max endpoints to return (1 - 200, default 50). Higher limits may timeout; start with 20 for fast discovery.'
• Add error handling guidance to tool descriptions. E.g., 'If target_url is unreachable, returns {error, reason}. Retry with a different target or check network connectivity.'
• For barter_arbitrage_book, clarify what 'today' means (UTC midnight, server local time?), what fields are in the P&L response, and how to interpret 'realized spread' (USDC amount, percentage, or both?).