MCP server for event-document vault search and timeline management. Provides read-only tools over an event-document vault (schedules, sign-on times, amendments, regulations, maps) so a chat assistant can answer trackside questions grounded in official documents with citations.
Startline AI has 8 well-named, read-only tools with clear descriptions (avg 120 chars, within baseline 194). All tools have input schemas with type definitions and parameter descriptions. However, output schemas are not documented, responses are inferred from code inspection. Error handling is minimal (only search() returns error objects; others return dicts with 'error' key inconsistently). No tool annotations (readOnlyHint, idempotentHint). Parameter descriptions are good but lack format constraints (e.g., event codes like 'AUS-GP-2026' are documented by example, not enum). The vault.find() fuzzy matching and synonym expansion show thoughtful design, but composition could be tighter, read_doc and search both require event disambiguation.
All amendment documents for an event and what they amend.
What an amendment actually changed vs the schedule it amends: moved/added/removed timeline rows plus a short summary. Cached.
Summarise one event: categories with doc counts, plus any amendments.
List documents, optionally filtered by event and/or category substring.
List all events in the vault with document counts.
Read a document's full text by slug or title (fuzzy matched).
Timeline for one event day, parsed from the current Minute-x-Minute.
Output schemas not documented. Code inspection reveals responses are dicts with fields like 'event', 'docs', 'categories', 'amendments', but LLMs cannot plan downstream calls without explicit schema declarations. search() returns list[dict] with 'doc', 'where', 'note', 'event', 'snippet', none declared in docstring.
Event codes (e.g. 'AUS-GP-2026') documented by example in descriptions, not as enum constraint. LLMs may hallucinate invalid codes. search() and read_doc accept optional event filter but no validation guidance.
Error handling inconsistent. read_doc() returns {'error': '...'} with candidates list on fuzzy match failure; search() returns [{'error': '...'}] on SQL error; event_overview() returns {'error': '...'} on missing event. No guidance on recovery actions (e.g., 'Try list_events() to see valid codes').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
Full-text search over every document chunk (FTS5 + BM25 + synonyms). Best first step for any factual question. Results cite note + page heading; follow up with read_doc for full context.
No tool annotations. All 8 tools are read-only (Risk: READ_ONLY declared in metadata), but readOnlyHint is not set in tool definitions. Agents cannot infer safety without explicit annotation.
read_doc() pages parameter accepts free-form string ('3-5' or '12') with regex validation inside. No enum or pattern constraint in schema, LLMs may pass invalid formats like 'pages 3 to 5' or 'all'. Description says 'use 3 or 3-5' but schema does not enforce it.