Server has 8 tools with basic schemas and descriptions, but significant gaps limit production readiness. Tool naming is inconsistent (query_*, mutation_* are template names, not concrete tools). Most descriptions are generic and under 100 chars. Parameter descriptions are minimal or missing. No output schemas documented. Error handling is absent from visible code.

• Document output schemas for all tools. E.g., list_available_queries should specify: returns {queries: [{name: string, description: string, args: object}], total: number}. This enables LLM planning.
• Add parameter descriptions to all tools. E.g., get_schema_info's 'type_name' should say: 'Optional. If provided, returns details for this specific GraphQL type (e.g., User, Post). Omit to get full schema overview.'
• Expand tool descriptions to 100-200 chars with WHEN/WHY context. E.g., 'List all available GraphQL queries. Call this first to discover what queries the API supports before using get_query_signature or execute_custom_query.'
• Add error handling and recovery guidance to execute_custom_query and mutation_* tools. E.g., 'If query fails, check syntax with get_query_signature first. If variables are invalid, the error will specify which field is wrong.'
• For dynamic query_*/mutation_* tools, generate explicit tool registrations at startup with concrete names and full parameter/output documentation, rather than relying on template inference. This enables static validation and clearer LLM reasoning.

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

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