A Model Context Protocol server for Clio Manage. Exposes the Clio Manage v4 REST API as MCP tools for Claude (or any MCP-compatible client) to read and write contacts, matters, and activities.
Two tools with clear action verbs and detailed descriptions. clio_who_am_i has excellent documentation including auth troubleshooting guidance. clio_create_company_contact has comprehensive parameter descriptions with enum guidance for address.name field. However, input schemas lack formal type constraints (enums not declared in JSON Schema), parameter descriptions are embedded in docstrings rather than schema, and no output schema is documented. Address parameter is object type without nested schema definition. Missing error classification guidance and recovery patterns.
Create a Company contact in Clio (type=Company). Use for entity clients — corporations, LLCs, sole proprietorships operating under a business name. For individual humans, use clio_create_person_contact. Args: name: Company legal name (required). email: Primary email address. phone: Primary phone number. website: Company website URL. address: Optional dict with keys: - name: must be one of "Work", "Home", "Billing", "Other". Defaults to "Work" if missing or invalid. ("Business" is a known 422 trigger; auto-coerced to "Work".) - street, city, province, postal_code, country. Returns: {"status_code": int, "body": <parsed JSON>}. On success (201), body["data"] contains the created contact incl. id. On failure, body contains Clio's error payload verbatim.
Return the authenticated Clio user's profile. Use this as the canonical "is auth working?" check before running any other tool. A 401 here means the refresh-token chain is broken — re-run the OAuth flow (docs/oauth-setup.md) and delete .clio_tokens.json. Returns: {"status_code": int, "body": <parsed JSON>}. body["data"] has id, name, email, and other Clio user fields.
Input schemas lack formal enum constraints. address.name field documents valid values ('Work', 'Home', 'Billing', 'Other') in description text only, not as JSON Schema enum. LLMs cannot parse constraints from descriptions alone.
No output schema documented for either tool. clio_who_am_i returns {status_code, body} but body structure is not formally defined. clio_create_company_contact returns created contact but field list is not specified. LLMs cannot plan downstream calls without knowing response structure.
address parameter is typed as 'object' with no nested schema. Callers cannot determine which keys are required vs optional, or their types. Should define as object with properties: {name: enum, street: string, city: string, ...}.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2026-07-28+ | v2 |
Error handling lacks recovery guidance. clio_who_am_i mentions 401 and refresh-token issues, but other tools do not document failure modes (422 on invalid address.name, 401 on expired token, network timeouts). No guidance on retryability or user-fixable vs fatal errors.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) declared. clio_who_am_i is read-only; clio_create_company_contact is destructive (creates contact). Annotations help agents reason about side effects and retry safety.