Four tools with basic schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. All tools are READ_ONLY, which is good for safety, but descriptions lack actionable guidance for LLM selection. Parameter descriptions are minimal (e.g., 'ID of the procedure' for procedureId). No output schemas documented. Tool names follow verb_noun pattern (list, get, search) which is correct, but descriptions don't explain WHEN to use each tool vs. alternatives or what fields are returned.

• Document output schemas for all four tools. Example: listProcedures returns {procedures: [{id: number, name: string, description: string}], total: number}. This enables LLMs to chain calls and extract IDs for getProcedureDetails.
• Expand parameter descriptions with format and constraint guidance. E.g., 'procedureId: Numeric ID of the procedure (integer, 1 - 999999). Use getProcedureDetails to fetch full details after listing.' and 'keyword: Search term (1 - 100 chars, alphanumeric + spaces). Searches use OR logic between words.'
• Add pagination to listProcedures and searchProcedures. Accept limit (1 - 100, default 20) and offset (default 0) parameters. Return total count so LLMs know if more results exist.
• Clarify tool selection in descriptions. E.g., listProcedures: 'Lists all available procedures. Use this for discovery or when you need all procedures. For targeted search, use searchProcedures.' searchProcedures: 'Searches procedures by keyword. Use this when you have a specific term or phrase. Returns matching procedures with relevance ranking.'
• Add error recovery hints. E.g., 'If procedureId is not found, call listProcedures or searchProcedures to find the correct ID.' This guides LLMs on next steps when a call fails.

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

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