Two tools with basic schemas and descriptions, but significant gaps in parameter documentation, output schema clarity, and error handling guidance. SearchMicroCMS and GetMicroCMSContent both have action verbs and non-empty descriptions (good), but descriptions are generic (avg 45 chars, well below 194-char baseline). Parameters lack constraints (no enums, ranges, or format specs). Output schemas are not documented, responses are raw JSON strings with no field-level guidance. Error handling returns plain text without recovery hints. No tool annotations (readOnlyHint, idempotentHint). Parameter descriptions are minimal (e.g., 'Search query' for 'q', 'API endpoint' for 'endpoint') and do not explain format, constraints, or dependencies.

• Document output schemas explicitly. Define the structure of response objects (e.g., SearchMicroCMS returns {contents: [{id, title, publishedAt, ...}], totalCount, offset}). Include field types and descriptions so LLMs know what to extract.
• Expand parameter descriptions to include format, range, and constraints. E.g., 'Search query (1-200 chars, alphanumeric + spaces)' and 'API endpoint name (e.g., blogs, articles, products, lowercase, no spaces)'.
• Add enum constraints for constrained parameters. Replace 'Sort order (e.g., -publishedAt)' with an enum of valid sort fields and directions. Replace 'Filters in the format field[operator]=value' with examples and a regex pattern in the schema.
• Enhance error messages with recovery guidance. Instead of 'Failed to search MicroCMS: <error>', return 'Invalid endpoint: got "blog", valid endpoints are: blogs, articles, products. Try again with a valid endpoint.' or 'API rate limit exceeded. Retry in 60 seconds.'
• Expand tool descriptions to 100-200 chars. Explain when to use SearchMicroCMS vs. GetMicroCMSContent (search for multiple items vs. fetch one by ID), what fields are returned, and any prerequisites (e.g., 'Requires MICROCMS_API_KEY environment variable').