Server has 5 tools with schemas and descriptions present, but quality is inconsistent. Tool names lack clear action verbs (createCatalogSearchTool, createExecuteTool use factory naming rather than verb_noun). Descriptions are present but generic, most lack actionable guidance on WHEN to use each tool vs alternatives. Parameter descriptions exist but are sparse (e.g., 'workspace' param has minimal context). Output schemas are not documented, LLMs cannot infer what these tools return. Error handling is absent from visible code. Security concerns: execute tools accept arbitrary JavaScript code, creating injection risk. No evidence of input validation, rate limiting, or permission gates.

• Rename tools to verb_noun format: search_catalog, execute_code, search_openapi, execute_graphql, execute_sparql. This lets LLMs infer intent from names alone.
• Document output schemas for all tools. Specify: {result: string, staged_data?: {uri, size}, error?: {code, message, recovery_hint}}. Include pagination/limit info if applicable.
• Add input validation: code length limits, allowed API methods, timeout constraints. Return actionable errors: 'Code exceeds 10KB limit. Reduce or split into multiple calls.'
• Expand parameter descriptions: 'workspace: Optional workspace ID for staging large results (>100KB). If omitted, results returned inline. Use workspace to enable SQL queries on staged data.'
• Add permission gates and audit logging. Log who executed what code, when, and what happened. Gate execute tools behind 'execute:code' scope.