Temporal Cortex MCP exhibits significant definition quality gaps across all dimensions. Tool descriptions are present but severely lack detail and actionability for LLM selection. Input schemas are either completely absent or partially visible in examples only. No output schemas are documented. Parameter descriptions are missing or minimal. The server appears to expose calendar/scheduling tools but lacks the rigor required for production agentic use. Tools are inferred from example files rather than explicitly registered with full schemas, forcing a hard cap at 50 per tool. Critical issues: (1) No input schemas visible in source code for most tools, only examples show 'book_slot' has a schema, others are undocumented. (2) Descriptions are under 150 chars and lack actionable context (e.g., 'Get the current temporal context' does not explain WHEN to call it or what downstream tools it enables). (3) No output schemas documented anywhere. (4) Parameter descriptions completely absent for most tools. (5) No error handling guidance visible.

• Add formal JSON Schema definitions for all 13 tools with required/optional field distinctions, type declarations, and enum constraints. Move from examples to a schema registry (e.g., openapi.json or tools.json).
• Expand tool descriptions from current vague text (20-50 chars) to 80-150 chars following pattern:tool-description. Format: 'Describe WHAT the tool does, WHEN to use it (relationship to other tools), and WHAT it returns.' Example: 'Get current time, timezone, and DST status in the user's local context. Call this FIRST to orient the agent before any datetime reasoning. Returns: {timestamp_utc, timezone, dst_active, offset_minutes}.'
• Document output schemas for all tools. Include field names, types, and what downstream tools those fields feed into. Example: 'list_calendars returns [{calendar_id (string, passed to book_slot), provider (string), email (string), is_primary (boolean)}]. Do NOT return pagination metadata.'
• Add parameter descriptions to all input schemas. For 'resolve_datetime', document: 'A natural language datetime string (e.g. "next Tuesday at 2pm", "tomorrow 9am", "2024-01-15 14:00"). Format: free-form text understood by dateparser library. Required: yes.'
• Clarify overlapping tool names. 'get_availability', 'check_availability', 'find_free_slots' likely serve different purposes, rename to distinct, verb-noun patterns. E.g., 'check_time_conflict' for boolean checks, 'list_free_slots' for discovery, 'get_availability_summary' for aggregates.
• Add error handling guidance to write-operations ('book_slot', 'request_booking'). Document: 'Returns error if conflict detected. This is retriable, call find_free_slots again and retry with a different time. If two-phase lock times out, the operation is safely rolled back.' Include specific error codes or messages the LLM should interpret.