Six tools with clear verb-noun naming and comprehensive descriptions (avg 180 chars). All tools have input schemas with type definitions and parameter descriptions. Tool names follow action-verb convention (list_, get_, search_). Schemas use Zod with proper type constraints and enums. However, output schemas are not formally documented in the code, responses are text-based content blocks without structured field definitions. Error handling is minimal (e.g., 'No reference found' but no recovery guidance). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being read-only. Parameter descriptions are good but could be more prescriptive about constraints and formats.

• Add formal output schema documentation for all tools. Define the structure of returned content (e.g., 'Returns: { content: [{ type: "text", text: string }] }') so LLMs know what fields to expect.
• Annotate all tools with readOnlyHint: true in the tool definition. This signals to clients that these tools are safe to cache and retry without side effects.
• Enhance error messages with actionable recovery steps. E.g., 'No reference found for "xyz". Available types: pie, bar, line. Call list_chart_types() to see all options.'
• Remove references to non-existent tools (search_all, get_api_reference) from search_docs description, or implement them. If they are planned, document them as 'coming soon'.
• Add explicit enum constraints or examples to get_section 'file' parameter to clarify preferred format (e.g., prefer bare names like 'xy' over 'skill/xy').