Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
ChronicleMCP has 8 tools with consistent naming patterns (verb_noun format: search_by_domain, get_bookmarks, etc.) and descriptions ranging from 30-50 characters, meeting basic documentation standards. However, schema completeness is mixed, some tools have detailed parameter definitions while others lack depth. Parameter descriptions are generally present but sparse (10-30 chars each, below the 72-char baseline). Output schemas are not documented in the visible code, which is a critical gap. No error handling guidance is visible. All tools are read-only (appropriate for a browser history reader), reducing security complexity but also limiting the need for confirmation/destructive patterns.
Output schemas completely undocumented. LLMs cannot plan downstream operations or know what fields to extract from responses. Critical for tool chaining and context window management.
Parameter descriptions are too sparse (average 15-20 chars vs. 72-char baseline). E.g., 'Browser to search' lacks context on which browsers are supported, format requirements, or behavior on unsupported browsers.
Document output schema for all 8 tools. For each tool, specify the JSON structure, field types, and required vs optional fields. Example: 'search_by_domain returns {results: [{url: string, title: string, visit_count: int, last_visit: ISO8601string}], total_count: int, has_more: boolean}'.
Expand parameter descriptions to 50-100 chars, including valid values, constraints, and consequences. Replace 'Browser to search' with 'Browser to search (chrome, firefox, safari, edge, brave). Chrome must be installed; returns error if browser not found.'
Convert 'browser' and 'format_type' parameters to enums in JSON Schema. Define: browser: {enum: [chrome, firefox, safari, edge, brave, opera, vivaldi]} and format_type: {enum: [markdown, json]}.
Add explicit error handling examples in tool descriptions. E.g., 'Returns error:browser_not_found if browser is not installed. Try get_browser_stats to list available browsers.' This guides LLM recovery.
Add tool annotations via fastmcp framework. Mark all 8 tools with readOnlyHint=true to signal clients they are idempotent and safe to cache/retry. Code: @app.tool(name=..., description=..., hints={'readOnlyHint': True})
For date parameters (compare_time_periods, analyze_productivity), add format specification: 'start_date (ISO 8601 format YYYY-MM-DD, required). Timezone is UTC. Dates must be in the past and start_date < end_date.'
For list-returning tools, add pagination: add 'offset' (default 0) and 'limit' (1-100, default 20) parameters. Document total_count in output schema. E.g., 'Limit defaults to 20. Use offset + limit to paginate large results.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Score history
Overall score trend
↑ 17 points across a rubric change (v1 → v2)
53/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
D
53
<=2025-11-25
v2
2026-03-09
F
36
-
v1
62/100
Suggest categories for uncategorized URLs.
No enumeration constraints on multi-value parameters. 'browser' and 'format_type' are free-form strings, LLMs may hallucinate invalid values like 'chrome-beta' or 'xml'. Enums should declare valid options: browser=[chrome, firefox, safari, edge], format_type=[markdown, json].
No error handling guidance visible. Tools should document: What if browser is not installed? What if no history exists? What if date range is invalid? Error responses must guide LLM on recovery actions (pattern:recovery-guide).
No tool annotations (readOnlyHint, idempotentHint) visible. While all 8 tools are indeed read-only, explicit annotation via tool metadata helps clients optimize caching and retry logic per MCP 2026-07-28 spec.
Date parameters (start_date, end_date in compare_time_periods, analyze_productivity) lack format specification. No mention of ISO 8601 requirement, timezone handling, or validation rules. LLMs frequently miscalculate date conversions, explicit format guidance is critical.
No pagination parameters visible in list-returning tools (get_bookmarks, get_downloads). Tools should accept 'limit' and 'offset' or 'cursor' and document max result size to prevent context window exhaustion.
Tool names are verb_noun but some are ambiguous. 'analyze_productivity', does it return a score, a report, or a recommendation? 'suggest_categories', does it save changes or just propose? Descriptions should clarify expected output and state-mutation.
analyze_productivitysuggest_categories
Clarify state mutation in tool descriptions. 'suggest_categories' should say: 'Proposes categories for uncategorized URLs. Does not save changes, categories must be applied via a separate update tool (if available).'
Test parameter constraints end-to-end. Ensure 'limit' bounds (1-100) are enforced and return actionable errors. E.g., 'Invalid limit: 500 exceeds maximum of 100. Use offset + limit=100 to paginate.'
Add dependency hints where appropriate. E.g., 'search_by_domain' description: 'If you need to see all visited domains first, call get_browser_stats to list domain breakdowns.'
Consider adding a discovery tool like 'list_available_browsers' that returns installed browsers and stats (total visits, date range covered). This eliminates guesswork and failures on unsupported browsers.