Two read-only tools with clear naming (search_images, list_images) and proper Zod schemas. Descriptions are adequate (90-110 chars) but lack actionable context for LLM selection. Parameters are well-typed with enums and defaults, but descriptions are minimal (10-30 chars), below the 72-char baseline for A+ tools. Output is unstructured text rather than typed objects, forcing LLM parsing. No error recovery guidance. Tool annotations present (readOnlyHint=true) but no destructiveHint or idempotentHint usage.

• Expand parameter descriptions to 50-100 chars. E.g., 'limit: Maximum number of results to return (1-100, default 10). Larger limits may slow queries.' This sets expectations and constraints.
• Return structured JSON objects instead of formatted text. E.g., { images: [{ id, name, file_path, purpose, tags, description }], total: 42, offset: 0 }. This lets LLMs access fields directly and chain to downstream tools.
• Add error recovery hints. E.g., 'Error querying images: <message>. If this persists, check that SUPABASE_URL and SUPABASE_SERVICE_KEY are set correctly, or try list_images() to verify the connection.'
• Document the tags filter logic explicitly: 'Filter by tags, returns images that have ALL of these tags (AND logic). Pass empty array to ignore tag filtering.'
• Add a documented output schema to both tool descriptions. E.g., 'Returns: { images: [{ id: string, name: string, file_path: string, purpose: enum, tags: string[], description: string }], total: number, offset: number }'.