PinWright exposes 3 Blueprint-related tools with significant definition gaps. Tool names lack clear action verbs (blueprint.build_api_index, blueprint.search_api, blueprint.search are somewhat descriptive but inconsistent). Descriptions are present but minimal (10-50 chars for most). Only blueprint.search has a visible input schema with typed parameters; the other two lack documented schemas entirely. No output schemas are documented. Error handling and recovery guidance are absent. The codebase shows HTTP transport and progress support, but tool definitions themselves are underdeveloped for LLM consumption.

• Add explicit input schemas to blueprint.search_api with typed parameters (e.g., query: string, limit: integer with min/max bounds)
• Expand descriptions to 100-200 chars each, stating WHAT the tool does, WHEN to use it, and what it returns. E.g., 'Search the cached Blueprint API index by keyword. Returns matching classes, functions, and properties with signatures. Use this to discover available APIs before calling build_api_index.'
• Document output schemas for all tools. E.g., blueprint.search should return {results: [{name, type, signature, location}], total_count, has_more}
• Add error handling guidance: 'If no results found, try a broader query or call build_api_index first to ensure the index is populated.'
• Mark blueprint.build_api_index with destructiveHint or idempotentHint in tool annotations to signal to LLMs whether it is safe to retry