Assay provides four well-named, verb-prefixed tools (search, quote, score, call) with clear, detailed descriptions (150 - 250 chars each). All tools have input schemas with typed parameters and descriptions. However, output schemas are not formally documented, responses are returned as text blobs via a generic `text()` wrapper, making it impossible for LLMs to parse structured results reliably. Parameter descriptions are strong (e.g., 'Bazaar resource id from assay_search'), but the tool lacks pagination support for search results and does not document error recovery paths. Security is well-handled (no secrets in params, wallet-based payment), but error messages are not shown in the code.

• Document output schemas for all four tools. Define structured response objects (e.g., SearchResult with fields: resource, description, priceUsd, assayScore, grade) and return JSON objects instead of text blobs. This enables LLMs to extract IDs and chain tools reliably.
• Add pagination to assay_search: include 'total_count' and 'next_cursor' in response, accept 'cursor' parameter, and document the limit (currently 15 default, 50 max). Return all matching resources, not a silent truncation.
• Implement a dry-run or confirmation pattern for assay_call. Add optional 'dry_run' boolean parameter that returns estimated cost and provider response schema without charging. For real calls, require explicit confirmation or return a 'confirm_payment' tool that the agent must call separately.
• Add schema validation for assay_call's 'params' object. Either accept a 'schema' parameter describing the provider's input shape, or fetch and document the provider's schema from the Bazaar catalog. Provide LLM-readable guidance on what fields each resource expects.
• Enhance tool descriptions with explicit prerequisites and error recovery. E.g., 'Call assay_search() first to find a resource_id. If the resource is unrated, set allowUnverified=true (costs more). If the call fails validation, no charge is incurred, retry with different params.'