The server defines 1 tool ('chat') with a complete input schema and reasonable description. The tool schema is properly structured with required parameters, nested objects, and array types. However, there are significant gaps in parameter descriptions, missing output schema documentation, and no error handling guidance. The tool does one primary job (interact with Cube AI), but the definition lacks production-grade completeness expected at scores above 70.

• Define and document the output schema for the 'chat' tool. Specify whether it returns {text: string, toolCalls: array, visualizations: array} or another structure. Include field types and whether fields are optional.
• Clarify 'userAttributes' parameter: document valid attribute names (e.g., 'department', 'region', 'role'), whether they're case-sensitive, and example values. Consider using an enum or pattern constraint if only a known set is valid.
• Add error documentation to the tool description. List known errors (missing API key, misconfigured IDs, API failures) and what the LLM should do: 'If you get "Cube Chat API URL not configured", check that CUBE_CHAT_API_URL environment variable is set.'
• Use JSON Schema's oneOf or dependentSchemas to formalize mutual exclusivity between externalId/internalId. This enables tooling validation and guides LLM behavior without relying solely on runtime checks.
• Document whether the tool returns the response as a complete string, a stream of text chunks, or a structured object with multiple fields. Clarify how 'streaming' manifests in the tool's output (single response containing all chunks, or multiple partial responses).
• Add constraint descriptions for 'message' parameter: expected length, language, format (e.g., 'Plain text question, 5-1000 characters'). Current description is basic.
• Specify timeout behavior: does the chat API have a maximum response time? Will the tool timeout after N seconds, and how is this communicated to the LLM?