8 read-only tools with mostly complete schemas and descriptions. Tool names lack action verbs (e.g., 'payability_verdict' instead of 'get_payability_verdict'), violating verb_noun convention. Descriptions are adequate (100-200 chars) but lack WHEN/WHY guidance. Parameters are typed and described, but no enums for constrained inputs (e.g., 'sort' accepts empty string or 'price', should be enum). Output schemas are not documented. Error handling is minimal, no recovery guidance or actionable error messages. Security is strong (read-only, no secrets in params). Composition is clean (single responsibility per tool). Baseline: avg tool description ~150 chars (within 10-1024 range), all params have descriptions, but naming and output documentation are gaps.

• Rename tools to start with action verbs: 'get_payability_verdict', 'list_endpoints', 'get_host_status', 'get_price_for_resource', 'get_manifest', 'get_payability_index', 'get_x401_adoption_state', 'get_model_claim_state'. This follows verb_noun convention and helps LLMs infer intent from the name alone.
• Document output schemas for all tools. For find_endpoints, specify: returns {endpoints: [{url, host, verdict, payable_networks, options}], total_count, limit}. For manifest and payability_index, document the structure of the returned JSON objects.
• Convert 'sort' parameter in find_endpoints to an enum: {type: 'string', enum: ['', 'price'], description: 'Sort order: empty string for default, or price to sort by cost'}.
• Add error recovery hints to tool descriptions. E.g., payability_verdict: 'If the URL is not found, call find_endpoints() first to locate it.' price_for_resource: 'Returns null if no price observed; check payability_verdict() to confirm the resource is payable.'
• Expand descriptions with WHEN/WHY context. E.g., find_endpoints: 'Use this first when you do not know the exact resource URL. Returns up to 25 endpoints matching your query. For a specific URL, use payability_verdict() instead.'