Model Context Protocol (MCP) server for the CallRail REST API v3
CallRail MCP has well-structured tool definitions with consistent naming (verb_noun pattern), clear descriptions (avg 80-120 chars), and complete JSON schemas for all 15 tools. All parameters are typed and described. However, output schemas are not documented in the source code, error handling lacks recovery guidance, and some parameter descriptions could be more prescriptive about constraints. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications. Composition is sound, tools are single-responsibility and chainable via IDs.
Compare call metrics between two date periods
Create a new tag with specified name and color
Create a new call tracker
Delete a call tracker
Get details of a specific call by ID
Get details of a specific company by ID
Get details of a specific tracker by ID
Output schemas not documented. Tool descriptions state what is returned (e.g., 'Get details of a specific call') but do not specify the response structure, field names, or types. LLMs cannot plan downstream tool calls or extract specific fields without knowing the response schema.
Missing tool annotations. Tools are classified by risk (READ_ONLY, WRITE, DESTRUCTIVE) but do not use MCP tool annotations (readOnlyHint, destructiveHint, idempotentHint). This prevents clients from applying appropriate safety guardrails or UI affordances.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | <=2025-11-25 | v2 |
List calls with optional filtering by date range, tags, company, and pagination
List all companies in the account
List all tags in the account
List all call trackers in the account
Add one or more tags to a call
Remove one or more tags from a call
Update an existing tracker
Get call usage summary statistics for a date range
Error handling lacks recovery guidance. No evidence in source that error responses include actionable next steps (e.g., 'Try search_companies() first' or 'Invalid color, must be one of: red, blue, green'). Errors should categorize as retryable, user-fixable, or fatal.
Parameter constraints not fully specified in descriptions. 'color' parameter in create_tag references 'valid CallRail colors' but does not enumerate them in the description. 'phone_number' format is not specified (E.164? Domestic? Validation rules?). Descriptions should include format, range, and allowed values inline.
Pagination not fully documented. list_calls and list_trackers accept 'page' parameter but descriptions do not specify page size, total count return, or whether results are capped. Per pattern:paginated-result, tools returning lists should document limit, offset/cursor, and total count.