Two tools with basic schemas and descriptions, but significant gaps in parameter documentation, output schema clarity, and error handling guidance. getDocumentation has a vague description (28 chars) and optional-only parameters with no type hints. queryDocumentation lacks output schema documentation and parameter constraints. Neither tool describes what data is returned or how to use results downstream. No error recovery guidance. Naming is acceptable (verb_noun pattern) but descriptions fall well below the 50-200 char LLM-optimized baseline. No tool annotations (readOnlyHint, etc.) despite both being read-only operations.

• Add explicit output schema documentation to both tools. Example: 'Returns: {type: object, properties: {documentation: {type: string}, endpoint: {type: string}, timestamp: {type: string}}}'. This lets LLMs know what fields to extract.
• Expand tool descriptions to 80-150 chars explaining WHEN to use each. E.g., 'getDocumentation: Fetch raw Paychex API docs for a specific endpoint. Use when you need complete reference material. queryDocumentation: Ask natural-language questions about Paychex APIs, faster for specific lookups.'
• Add constraints and format hints to 'endpoint' parameter. E.g., 'Optional endpoint path (e.g., /employees, /payroll). If omitted, returns base documentation. Must start with / if provided.'
• Implement error recovery guidance. Catch specific failures (network timeout, invalid endpoint, LLM service down) and return actionable messages: 'Endpoint not found. Available endpoints: /employees, /payroll, /benefits. Try one of these.'
• Add readOnlyHint: true to both tool definitions in the schema to signal they are safe for autonomous execution without confirmation.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry