DocMonitor has three well-named, read-only tools with clear descriptions (avg 180 chars, within baseline 194). All tools have input schemas with type and description. However, output schemas are not formally documented in the code, return types are inferred from implementation (dict/list). Parameter descriptions are present but minimal (e.g., 'days' lacks range/constraint guidance). No error handling guidance, no tool annotations (readOnlyHint present in metadata but not declared), and no pagination support for potentially large result sets. The resource endpoint is well-designed but adds no tool-level complexity.

• Add formal output schema documentation to each tool. Use JSON Schema to declare response structure (e.g., check_drift returns {summary: {total: int, by_status: {string: int}}, claims: [{claim_text, status, evidence, ...}]}). This enables LLMs to plan downstream operations.
• Add range constraints to numeric parameters. E.g., 'days: integer, 1 - 365 (default 30)' in get_changelog description. Prevents LLMs from passing absurd values.
• Document error cases and recovery paths. E.g., 'If doc fetch fails, try search_docs() with a specific keyword instead.' This guides LLM behavior on failure.
• Add limit and cursor parameters to search_docs and get_changelog to support pagination. Cap default results at 20 - 50 and document the limit in descriptions.
• Expose tool annotations (readOnlyHint, idempotentHint) in the tool definition metadata so clients can render safety hints and prevent unnecessary confirmation dialogs.

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

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