Two tools with well-structured schemas and descriptions. Both tools have clear names starting with action verbs (list_, escalate_to_), explicit parameter documentation, and defined input schemas. The escalate_to_expert tool has rich, context-aware descriptions that guide LLM decision-making. However, output schemas are not formally documented in the source, and error handling lacks recovery guidance. The server does not include tool annotations (readOnlyHint/destructiveHint) despite tool semantics being clear from descriptions.

• Add formal output schema documentation. For list_projects, document that it returns {available_projects: [{id, folder, conversation}], usage: string}. For escalate_to_expert, document the return structure from the backend (guidance, action_plan, etc.).
• Integrate tool annotations into tool definitions: add readOnlyHint: true to list_projects and destructiveHint: true to escalate_to_expert. This requires updating the tools array in ListToolsRequestSchema handler to include these fields.
• Enhance error messages with recovery guidance. Replace 'Unknown tool' with 'Tool not found. Available tools: list_projects, escalate_to_expert.' For validation errors, include the constraint: 'Invalid project ID: got "{value}", must match pattern ^[a-zA-Z0-9_-]+$ and be listed by list_projects().'
• Clarify optional parameters. For 'attempted', add to description: 'If omitted, the expert will assume this is your first attempt at the problem.' This makes the LLM aware of the consequence.
• Strengthen project discovery guidance. Update escalate_to_expert description to: 'Project ID must be discovered via list_projects() first, passing an invalid project will fail.' Make the dependency explicit, not implied.

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

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