Temporal Cortex presents a significant quality challenge: tool definitions exist only in SKILL.md documentation (skills/temporal-cortex/SKILL.md), not as code. No Rust source code is visible showing actual tool registration, input schemas, or output type definitions. The evaluation is based entirely on inferred tool existence from markdown documentation. Per HARD SCORING RULES, when tool definitions cannot be seen in actual source code (only inferred from markdown), per-tool scores are capped at 50. Additionally, the source code provided shows only shell scripts and configuration setup, no Rust implementation, no schema definitions, no error handling. Descriptions in SKILL.md are present but brief (10-50 chars typically), below the baseline median of 194 chars. No parameter type definitions, ranges, or constraints are visible. No output schemas documented. This is a documentation-only evaluation with critical gaps in implementational evidence.
Tools (15)
adjust_timestampread only28/100
Adjust a timestamp by a duration
book_slotwriteauth25/100
Book/create a calendar event
check_availabilityread onlyauth30/100
Check if specific times are available across calendars
compute_durationread only25/100
Calculate duration between two times
convert_timezoneread only28/100
Convert times between timezones
expand_rruleread only28/100
Expand recurrence rules (iCalendar RRULE) into specific event instances
find_free_slotsread onlyauth25/100
Find available time slots across calendars
get_availabilityread onlyauth30/100
Get personal availability windows (user-readable availability summary)
CRITICAL: No input schemas visible in source code. All 15 tools show schema score of 0. Tool definitions exist only in SKILL.md markdown documentation, not as code. Per HARD SCORING RULE: 'If a tool has NO input schema at all: its schema score MUST be 0.' No JSON Schema definitions, parameter types, ranges, enums, or constraints documented anywhere in provided source.
CRITICAL: Tool definitions inferred, not directly visible in provided source code. Only SKILL.md and shell scripts provided; no Rust implementation shown. Per HARD SCORING RULE: 'If you cannot see the actual tool definition in the source (only inferred): cap that tool's overall at 50.' Caps all tools at 50 maximum; actual scores lower due to schema absence.
Recommendations
URGENT: Provide Rust source code showing actual tool registration, input schemas, and output type definitions. Markdown SKILL.md alone is insufficient for MCP validation. Code must use a typed schema format (JSON Schema or similar) with explicit name, description, input parameters with types/constraints, and return type.
URGENT: Define input schemas for all 15 tools using JSON Schema. Every parameter must have: type (string, number, boolean, array, object), description (50+ chars explaining what it controls), and where applicable: enum (valid values), minimum/maximum (numeric ranges), minLength/maxLength (string lengths), pattern (regex for format).
URGENT: Document output schemas. For each tool, define the return type: object with named fields and their types. For list tools (list_calendars, list_events, get_availability), document the array structure, pagination fields (limit, offset/cursor, total), and per-item fields.
Add parameter descriptions to tool descriptions. E.g., resolve_datetime should explain: 'Parameters: expression (string, natural language date/time like "tomorrow at 3pm" or "2024-01-15T14:30"), reference_tz (optional IANA timezone for ambiguous expressions). Returns: DateTime object with ISO 8601 timestamp and resolved_tz.'
Expand tool descriptions to 100-200 characters with context. Current: 'Parse and resolve natural language datetime expressions to specific dates/times'. Better: 'Parse natural language datetime (e.g. "tomorrow at 3pm", "next Monday") and return ISO 8601 timestamp. Resolves ambiguity using current_tz or user timezone. Call when user provides relative/natural time rather than specific date.'
Score history
Overall score trend
First recorded score · v2 rubric
35/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
35
2026-07-28+
v2
read only25/100
Get current date, time, timezone, and week start configuration
list_calendarsread onlyauth30/100
List all available calendars for the authenticated user
list_eventsread onlyauth30/100
List events from a calendar within a time range
query_public_availabilityread onlyauth28/100
Platform Mode only - query public availability of other users
request_bookingwriteauth25/100
Platform Mode only - request a booking with another user
resolve_datetimeread only28/100
Parse and resolve natural language datetime expressions to specific dates/times
resolve_identityread onlyauth25/100
Platform Mode only - resolve identity of the authenticated user
Missing parameter documentation. No descriptions of parameter types, constraints, ranges, or valid values visible. Tool descriptions like 'Parse and resolve natural language datetime expressions to specific dates/times' (resolve_datetime) lack specifics on what parameters are accepted, what formats are valid, what errors are possible.
No error handling or recovery guidance. Tool descriptions do not indicate what errors are possible, how to recover, or what to do if a call fails. Per pattern:recovery-guide, error responses should guide the LLM on next steps.
Descriptions below baseline length. Average tool description ~40 chars; baseline median is 194 chars. Descriptions like 'Get current date, time, timezone, and week start configuration' (get_temporal_context, 63 chars) lack context on when/why to use, what to expect, how output is structured.
write_booking and request_booking marked WRITE but no idempotency or confirmation guidance. Per pattern:command-tool, state-modifying tools must indicate idempotency and whether they support dry-run or confirmation.
No pagination/limit guidance for list tools. list_calendars, list_events, get_availability return unspecified structures. Per pattern:paginated-result, list tools must accept limit and offset/cursor, and document result cap.
Ambiguous parameter handling in datetime tools. resolve_datetime, convert_timezone, adjust_timestamp, and compute_duration descriptions do not specify parameter names, types (ISO 8601? Unix timestamp? Natural language?), or whether timezone-aware handling is automatic.
No documentation of identity resolution dependencies. resolve_identity marked 'Platform Mode only', but no indication in description whether other tools require identity, or what context is available in local mode vs Platform Mode.
Add error handling guidance to write tools (book_slot, request_booking). Specify: What errors are possible (calendar full, permission denied, invalid time range)? Are they retryable? Should the user be asked to choose a different time? Is there a dry-run mode?
Document pagination for list tools. Specify: Does list_calendars return all calendars or paginated? If paginated, what are limit/offset parameters? Does it return a total_count? What's the max limit per request?
Clarify timezone handling. All timezone-aware tools must specify: Does input accept 'UTC offset' or only IANA timezones? Does output include timezone? Are daylight-saving transitions handled? Can convert_timezone accept UTC offsets like '+05:30' or only 'Asia/Kolkata'?
Add mutual exclusivity notes. If resolve_datetime accepts either 'expression' (natural language) or 'iso_date' (structured), document in both parameters: 'Mutually exclusive with iso_date. Provide one or the other.'
Specify RRULE expansion constraints. expand_rrule description lacks: What's the max number of instances returned (capped to prevent infinite series)? Do all recurrence rules parse, or are some unsupported? What does the output structure look like (array of DateTime)?
Add Platform Mode vs. Local Mode context. resolve_identity, query_public_availability, request_booking marked 'Platform Mode only', clarify in description: What happens in local mode? Are these tools unavailable, or do they fall back to local user? Can setup.sh configure both modes?
Document availability window structure. get_availability and check_availability lack return format specification. Are availability windows time slots (start/end pairs)? Are they daily summaries? What fields (start, end, duration, day_of_week)?
Add examples to parameter descriptions (in description text, not as separate examples field). E.g., resolve_datetime: 'expression: "next Monday at 2pm" or "tomorrow" or "2024-03-15T14:30Z". Reference timezone defaults to current system timezone unless overridden.'
Validate input early and return actionable errors. If convert_timezone receives an invalid IANA timezone like 'New York' instead of 'America/New_York', return: 'Invalid timezone: "New York". Did you mean America/New_York? Run get_temporal_context() to see available zones.' not a 400 error.
Implement dry-run or confirmation for state changes. book_slot should support a 'dry_run' parameter (true/false, defaults false) to preview conflicts without committing. request_booking should indicate whether it requires user confirmation.
Define chaining IDs in responses. If book_slot creates an event, return the calendar_id and event_id so downstream tools (if they exist) can operate on that event without lookup.
Strip unnecessary API metadata from responses. list_events should return [{ id, summary, start, end, calendar_id }, ...], not verbose API responses with audit fields, etags, or raw JSON.