Loading ToolBench
MCP server for PracticePanther — legal practice management (matters, accounts, time entries, invoices)
Server has 8 tools with consistent naming (verb_noun pattern: find_*, get_*, create_*, update_*) and reasonable descriptions (100-200 chars). All tools have input schemas with typed parameters and descriptions. However, output schemas are not documented, responses are returned as JSON strings without declared structure. Parameter descriptions lack detail on constraints, formats, and dependencies. Error handling is present but generic. No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels. Missing pagination guidance in list tools despite OData support.
Create a new client account. ``account_json`` is a JSON object string. Minimum required: ``displayName``.
Open a new matter. ``matter_json`` is a JSON object string. Minimum required fields: ``displayName``, ``accountId``, ``practiceAreaId``, ``responsibleAttorneyId``, ``openDate``.
Search client accounts by name or email.
List contacts associated with accounts (e.g. co-counsel, witnesses).
Search matters (cases). Optional OData ``orderby``, ``filter``, ``select`` let you write rich queries (e.g. ``orderby="openDate desc"``, ``odata_filter="contains(displayName,'Smith')"``).
Fetch a single client account with full detail.
Output schemas not documented. Tools return JSON strings without declared field structure, forcing LLMs to parse unstructured text. Downstream tools cannot reliably extract IDs or references for chaining.
JSON string parameters (matter_json, account_json, updates_json) lack format guidance. No schema examples, required field lists, or validation rules. LLMs must guess valid JSON structure.
No tool annotations despite clear risk levels. create_matter and update_matter are destructive (WRITE risk) but lack destructiveHint annotation. find_* tools are read-only but lack readOnlyHint.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 68 | 2026-07-28+ | v2 |
Fetch a single matter with full detail (parties, practice area, status, etc.).
Patch fields on a matter. ``updates_json`` is a JSON object with only the fields you want to change (e.g. ``'{"status":"closed"}'``).
Pagination parameters (top, skip) present but no guidance on result limits or total count. Description does not state default behavior or maximum allowed values.
OData filter/orderby/select parameters documented only as 'OData clause' with no examples or constraints. LLMs cannot reliably construct valid OData syntax without examples.