Three well-named, read-only tools with clear descriptions (avg 180 chars, within 10 - 1024 baseline). All tools have explicit input schemas using Zod with type constraints and descriptions. Parameters are well-documented with enums, ranges, and format guidance. Output is structured (text + structuredContent). Error handling returns actionable messages. Main gaps: no output schema documentation in code comments, no per-tool permission declarations, and list_opportunity_presets has empty input schema (though correct for a no-arg tool). Naming follows verb_noun pattern; descriptions explain WHAT, WHEN, and RETURN. Composition is clean, each tool has one responsibility.

• Document output schemas in JSDoc comments above each tool handler. Example: '@returns {Object} {data: Array<{preset: string, title: string, description: string}>}' for list_opportunity_presets.
• Add permission scope declarations to tool descriptions. Example: 'Requires: read:wordpress-directory. Scope: read-only.'
• Enhance error messages with recovery guidance. In api.js getJson(), catch 404 and suggest 'Plugin not found. Verify slug via find_plugin_opportunities().' For 429, include 'Retry-After' header value.
• Add range hints to numeric parameters. Example: 'min_installs: Minimum active installs (typical range: 0 - 10,000,000; omit for no lower bound).'
• If find_plugin_opportunities can return >10 results, add pagination support: return {data: [...], total_count: N, next_cursor: '...'} and accept a cursor parameter.