clio-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct resource and action. Find/get/create/update/delete pairs are perfectly separated, and specialized actions like log_time, move_document, or complete_task do not overlap with anything else.
Naming Consistency5/5
All tools follow the clio_verb_noun pattern. List/find use plural nouns while get/create/update/delete use singular, creating a predictable and consistent convention throughout.
Tool Count2/5
46 tools is well above the typical 3-15 range and even exceeds the 25+ threshold for 'too many'. Though each tool is purposeful, the large number makes the server heavy and potentially overwhelming for agents.
Completeness3/5
The server covers many modules (matters, contacts, documents, tasks, activities, bills, calendar, communications, custom fields), but notable gaps exist: contacts have no update/delete, communications lack update/delete, tasks have no delete, and contact notes cannot be added via the available tools.
Average 3.4/5 across 46 of 46 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 48 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read operation but does not state that it is read-only, nor does it disclose any side effects, permission requirements, or additional behavior like potential pagination of version history.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (five words) but is a noun phrase rather than a complete sentence. While there is no wasted wording, it is under-specified and lacks structure, making it less helpful than an efficient sentence would be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is inadequate. It does not explain what 'version history' includes, any ordering, pagination, or error conditions. A simple get operation still benefits from clarifying what the response contains beyond the two broad categories.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate for the undocumented 'id' parameter. It does not explicitly state that 'id' refers to a document identifier, relying instead on the tool name for context. This is a marginal improvement over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Document metadata plus version history' clearly identifies the resource (document) and the specific content returned (metadata and version history). It distinguishes from sibling tools like clio_download_document (which retrieves the file itself) and clio_update_document (which modifies).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention that this is for metadata/history rather than file content, nor does it reference any conditions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only says 'full detail' without disclosing error behavior, permissions, or what happens if the entry does not exist. There is no behavioral context beyond the basic read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single, front-loaded sentence with no wasted words, but it is under-specified: 'full detail' is vague and does not convey what fields or behaviors are involved. Conciseness is good, but the brevity sacrifices needed information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description provides only minimal context. It does not explain what 'full detail' includes, how to handle missing IDs, or what the response structure is, making it insufficient for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'id' with no description and 0% coverage. The description does not explicitly connect the parameter to the calendar entry or explain its format. The parameter name is self-evident, but the description adds no additional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (calendar entry) and indicates it returns the complete object, distinguishing it from 'find' operations that search. It is specific about scope ('one') but does not explicitly restate the verb from the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like clio_find_calendar_entries. No context about prerequisites or typical use cases is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states the action without mentioning side effects, permissions, reversibility, or what happens after logging the expense. This is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy, making it concise. However, given the complexity of 6 parameters and no other documentation, it is under-specified rather than efficiently concise, so a middle score is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only a one-line description, no annotations, no output schema, and incomplete parameter documentation, the description is highly incomplete. An agent lacks essential context to invoke the tool correctly, especially considering the number of required parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for 3 of 6 parameters (date, price, quantity), but the tool description adds no parameter information. The remaining parameters (matter_id, note, activity_description_id) are undocumented in both the schema and the description, requiring the agent to guess their meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool logs an expense entry on a matter, using a specific verb and resource. However, it doesn't explicitly distinguish it from sibling tools like clio_log_time or clio_log_communication.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as clio_log_time. The description only states what it does, without any contextual or exclusionary information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of disclosing behavior. It implies a read-only operation by saying 'detail', but it does not explicitly state that it retrieves a task without side effects, nor does it mention possible errors (e.g., if the task ID does not exist) or response format. The description is too terse to provide meaningful behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (six words) and front-loaded with the key phrase 'Full detail'. It is concise, but it borders on under-specification. Every word earns its place, but the structure is a fragment rather than a complete sentence, and it lacks context that could be provided without being verbose. A score of 3 reflects that it is concise yet minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description should clarify what 'full detail' means and how it differs from other list/retrieval tools. It does not mention that the task ID is required, nor does it describe the returned object. The description is inadequate for an agent to fully understand the tool's context and expected behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% because the schema has no descriptions for the single required parameter 'id'. The description does not compensate by explaining that the id identifies the task to retrieve. While the parameter name 'id' is self-explanatory, the description still adds no semantic value, and the rubric requires the description to compensate when schema coverage is low.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves full detail for a single task, which distinguishes it from list/find tools like clio_find_tasks and from getters for other resources. The verb 'get' is implicit in the tool name and the description's 'Full detail' conveys retrieval. It is specific and unambiguous, though it does not explicitly mention the resource type beyond 'task'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention that it should be used when a task ID is known and complete details are needed, nor does it reference sibling tools like clio_find_tasks for listing or search scenarios. The context of sibling tools implies some usage, but the description itself carries no such information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden. 'Full detail' suggests a read operation and return of comprehensive data, but it does not explicitly state that it is read-only, what fields are included, whether authorization is required, or how errors are handled. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler words. It front-loads the key concept 'full detail' and specifies the resource. It is appropriately sized for a tool with one parameter, though it sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and no output schema or annotations, the description should explain what 'full detail' means and what the response contains. It does not specify what fields or data are returned, nor does it clarify the need for an existing activity entry. This leaves significant gaps for a simple but still non-trivial retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'id' with no description coverage. The tool description does not mention 'id' at all, leaving the agent to infer that the parameter identifies the activity. This is insufficient for a single-parameter tool with zero schema-level description; the description should explicitly state that 'id' is the activity identifier.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Full detail for one time/expense entry' clearly indicates the tool fetches a single activity record and returns comprehensive information. It distinguishes itself from sibling clio_find_activities by emphasizing 'one' entry, though it lacks an explicit verb like 'get' or 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that clio_find_activities should be used for searching, nor does it state prerequisites like needing an existing activity ID. The phrasing 'one entry' implies a single-item retrieval, but no explicit usage instructions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It only says 'full detail' without disclosing read-only nature, error behavior, pagination, or response structure. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, it is so brief that it borders on under-specification, which prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the minimal complexity (one parameter, no output schema), the description still leaves gaps: it does not explain what 'full detail' includes, any limitations, or usage context. Not complete enough for a tool with no annotations or output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema lists a single required 'id' number parameter with 0% schema description coverage. The description does not explain what 'id' refers to (e.g., bill ID) or how to obtain it, failing to add meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Full detail for one bill,' indicating a retrieval operation for a single bill. It implicitly distinguishes from sibling 'clio_find_bills' which lists bills, though it does not explicitly name the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus clio_find_bills or other bill-related tools. The description does not mention prerequisites such as obtaining a bill ID or alternative tools for listing bills.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Full detail' but does not clarify side effects (though the name implies read-only), potential errors (e.g., 404 if not found), required permissions, or what 'full detail' actually includes. The description adds minimal behavioral context beyond what the tool name itself implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no wasted words. It is front-loaded and easy to parse. However, its extreme brevity borders on under-specification, so it does not earn a 5, but it is appropriately concise for a simple get-by-id tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is still incomplete. It does not explain what 'full detail' includes, any error behaviors, or how this relates to the broader workflow (e.g., using clio_find_contacts to obtain an ID first). The description provides only the bare minimum, leaving significant gaps for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (id, a number) and schema description coverage is 0%, so the description must compensate. The phrase 'one contact' hints that the id identifies a contact, but it does not explain the id format, how to obtain it, or any constraints. The description adds almost no value beyond the bare schema, leaving the parameter semantically underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Full detail for one contact' clearly identifies the tool as a retrieval operation for a single contact, using the verb 'get' implied by the tool name and specifying the resource. It distinguishes itself from siblings like clio_find_contacts (which suggests searching/listing multiple contacts) and clio_create_contact (which creates) by focusing on a single existing contact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this should be used when you already have a contact ID, or that clio_find_contacts should be used for searching. There is no context about prerequisites or excluded scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Record' which implies creation but doesn't mention side effects, required permissions, immutability, or what happens with invalid input. This is insufficient for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 13-word sentence that is front-loaded with the core action and scope. Every word is meaningful, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, no output schema, and no annotations, a one-sentence description is inadequate. It lacks details on parameter formats, relationship rules, and expected return values, making the tool under-specified for an agent to invoke with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, and the description adds minimal parameter meaning. It maps 'phone call or email' to the type enum and 'matter or contact' to matter_id/contact_id, but leaves subject, body, and received_at semantics unexplained. The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool records a phone call or email communication, which distinguishes it from sibling tools that find or get communications. However, it does not explicitly differentiate from other logging tools like clio_log_time or clio_add_matter_note, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as clio_find_communications for querying or clio_add_matter_note for internal notes. It only implies the core use case without any exclusions or prerequisite context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It merely says 'Append a note to a matter's timeline' without explaining side effects, return values, idempotency, or permissions. The non-destructive nature of 'append' is inferred but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is immediately clear and front-loaded, stating the core action without extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and zero parameter documentation, the description is too thin. It does not explain the required inputs, expected result, or any behavioral nuance, leaving the agent with significant gaps for successful invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the tool description does not mention any parameter (matter_id, detail, subject) or their meanings. The description fails to compensate for the lack of schema documentation, leaving parameters ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Append') and identifies the resource ('a note to a matter's timeline'), which clearly distinguishes this from sibling tools like clio_find_notes or clio_get_note. It succinctly states the action and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states the action, leaving usage context implicit. There is no mention of scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It only states that a calendar entry is created and may be tied to a matter, but it does not describe side effects, return behavior, required permissions, or how all_day or timezone values are treated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It conveys the core action and key optional relationship efficiently, though it sacrifices detail that might be expected for an 8-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create endpoint with 8 parameters, no annotations, and no output schema, the description is underspecified. It omits return value information, field-level semantics beyond the schema's meager coverage, and behavioral details such as how all_day interacts with start_at/end_at.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 38% (3 of 8 parameters described in the schema). The description adds minimal value by clarifying calendar_id's role and noting matter_id is optional, but it does not explain summary, start_at, end_at, all_day, location, or description, which are essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Create') on a specific resource ('calendar entry'), and adds scope by noting it occurs 'on a calendar' and may be optionally linked to a matter. This distinguishes it from sibling tools like clio_get_calendar_entry, clio_update_calendar_entry, and clio_delete_calendar_entry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as clio_create_task or clio_log_time. It does not mention prerequisites, exclusions, or typical scenarios, leaving the agent to infer usage solely from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It implies a read-only operation via 'Read notes' but leaves ambiguity: it does not clarify whether the corresponding ID is required conditionally, how limit affects results, or what the return format is. The phrase 'with matter_id' may suggest it is required, yet the schema marks it optional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. It front-loads the purpose and immediately states the key parameter requirement, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is incomplete. It does not explain that this is a find/list operation (vs clio_get_note for a single note), nor does it mention pagination, limits, or behavior when no notes are found. The conditional dependency between type and ID is hinted at but not fully specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining that type='Matter' pairs with matter_id and type='Contact' with contact_id, which goes beyond the schema's enum. However, it does not describe the limit parameter or the optional/required nature of the IDs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Read notes' and clarifies the required type parameter with its mapping to matter_id or contact_id. This distinguishes it from sibling clio_get_note by indicating a type-based retrieval, but the phrase 'Read notes' is somewhat generic and could more explicitly say 'list' or 'find'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives like clio_get_note. The description only explains the type requirement but does not state the use case (e.g., finding notes for a matter/contact) or mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses filtering capabilities but omits critical behavioral details such as default limit, pagination, ordering, the effect of omitting all filters (likely returns all accessible tasks), and whether results are scoped to the authenticated user. The description adds little beyond what the schema already names.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that immediately states the action and resource, then lists filter dimensions. There is zero redundant phrasing, and the structure makes it easy to parse. It could be longer, but for what it says, it is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 optional parameters, no output schema, and no annotations. The description only covers high-level purpose and filter categories. It does not explain return format, pagination/limit behavior, whether filters are combinable, or what a successful response looks like. Given the absence of other structured context, this is insufficiently complete for an agent to invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, so the description must compensate. It adds group-level meaning by summarizing filters and explicitly naming 'due-date range' for due_from/due_to. However, it does not elaborate on the 'limit' parameter, and it largely restates property names rather than adding deeper semantics like format constraints or behavior when multiple filters are combined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'tasks', with a concise list of filter dimensions (matter, assignee, status, due-date range). It does not explicitly distinguish itself from sibling find tools like clio_find_matters or clio_get_task, but the resource name and filter context make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or alternative guidance is provided. The description only says 'List tasks...' without explaining when to prefer this over clio_get_task, clio_complete_task, or other find tools. There are no exclusions or context cues about optional filters or combinations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It states 'Update' but does not mention whether fields are partially updated, if any permissions are required, or whether the operation is reversible. The examples hint at field semantics but omit broader behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no extraneous information. It front-loads the verb and resource and uses parenthetical examples efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 6 parameters and no output schema or annotations, the description is too sparse. It lacks details on return values, partial update behavior, authorization requirements, and how to identify the entry, making it incomplete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, forcing the description to add meaning. The examples 'reschedule', 'rename', and 'relocate' map to start_at/end_at, summary, and location respectively, providing some semantic value. However, the required 'id' parameter and 'description' are not addressed, leaving gaps in compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Update' and clearly identifies the resource as 'calendar entry', adding examples (reschedule, rename, relocate) that clarify the scope of modifications. It implicitly distinguishes from sibling tools like create/delete/find by focusing on modification, though it does not explicitly name alternative tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs. alternatives such as create or delete. The description merely states what the tool does without context on prerequisites, exclusions, or scenarios where it is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It only states the action without disclosing side effects, required permissions, or response behavior. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that clearly states the purpose. It wastes no words and is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, no output schema, and many sibling tools, this description is severely inadequate. It provides no information about return values, required fields beyond implication, or how it relates to other matter-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, with only client_id described in the schema. The tool description adds no parameter details, only 'for a client' which merely restates client_id. Other parameters like status, practice_area_id, and description are entirely unaddressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Create' and clearly identifies the resource 'matter' for 'a client'. This distinguishes it from sibling tools like clio_update_matter or clio_find_matters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for creating matters but provides no explicit guidance on when to use it versus alternatives like clio_update_matter or clio_find_matters. There is no context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the burden of disclosing behavior. It mentions 'Returns concise fields, paginated,' which offers some insight into the response shape and pagination, but does not detail read-only nature, pagination controls, or potential omissions. The practice area mismatch also reduces transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. However, the inclusion of 'practice area' without schema support makes it slightly inaccurate, which detracts from its otherwise efficient structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with four parameters, no output schema, and no annotations, the description is too minimal. It does not explain how pagination is controlled (e.g., limit param), what 'concise fields' include, or how filters interact. The phantom practice area filter further weakens completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description partially covers parameter meaning by listing search criteria, but it fails to map criteria to specific params (e.g., practice area is not a param). It does not elaborate on limit, status enum values, or query syntax. Schema coverage is only 50%, and the description does not fully compensate for the undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Search matters' and lists criteria (client, status, practice area, free text), distinguishing it from get_matter or find_contacts. However, 'practice area' is mentioned as a filter but no corresponding schema parameter exists, creating ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when searching matters but does not explicitly compare with alternatives like clio_get_matter or clio_find_contacts. No when-to-use or when-not-to-use guidance is provided, so usage context is only implied by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read operation and promises 'full detail,' but it does not specify which fields are included, error behavior, or any special edge cases. This is basic but not comprehensive transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase with no wasted words. It is appropriately minimal for a simple getter tool and front-loads the core purpose effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter, the description covers the essential action but omits parameter clarification and any details about the return format. Since there is no output schema, the description should at least state what 'full detail' includes, which it does not. Overall, it is minimally viable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'id' parameter with 0% description coverage, and the description does not compensate by explaining what 'id' refers to or how to obtain it. The agent must infer from the tool name that it is the note ID, which is not explicitly stated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Full detail for one note' clearly indicates a retrieval of a single note, and it is distinct from the sibling 'clio_find_notes' which likely searches. However, the verb is implicit, relying on the tool name 'get' to convey the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus 'clio_find_notes' or other fetching tools. The description does not mention that it requires a known note ID or that it should be used when a specific note is already identified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action and gives no details about idempotency, permissions, what happens if the task is already complete, or the response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise, front-loaded sentence with no wasted words. It effectively communicates the core action in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one simple parameter and no output schema, this is nearly sufficient for basic invocation. However, it lacks the usage and behavioral context needed to fully distinguish it from closely related task-management tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no explicit meaning to the 'id' parameter beyond what the tool name implies. The parameter is simple and inferable, but the description does not compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Mark a task complete' uses a specific verb and resource, clearly distinguishing it from sibling tools like clio_update_task or clio_create_task. It is unambiguous and directly states the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as clio_update_task, which might also be used to modify task state. It does not mention prerequisites or exclusions, leaving the agent to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. 'List' clearly implies a read-only, non-destructive operation, which is safe. However, the description does not mention pagination behavior, the default limit of 25, or that it returns a list of bills. The schema provides the limit details, but the description adds no extra behavioral context beyond the obvious read nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It front-loads the core purpose ('List bills') and immediately specifies the filtering criteria. Every word earns its place, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no annotations and no output schema, the description is too sparse to be fully complete. It covers the main filtering parameters but omits the limit parameter, does not describe the return format (a list of bills), and does not address edge cases like no filters being provided. The tool is simple, but missing these details leaves gaps for an agent relying solely on the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly names three filtering dimensions (matter, client, state) which map to the schema properties matter_id, client_id, and state, providing meaning beyond the bare property names. However, it omits the limit parameter entirely, and with 0% schema description coverage, the description only partially compensates for the lack of parameter documentation. It does not explain how filters combine or the purpose of limit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'List' and the resource 'bills', with the scope of filtering by matter, client, or state. This differentiates it from the sibling tool clio_get_bill, which retrieves a single bill. However, it does not explicitly mention that it can return multiple bills or that it is the 'find' counterpart to 'get'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but provides no guidance on when to use it versus alternatives. It does not mention that clio_get_bill should be used for retrieving a single bill, nor does it specify conditions like 'use when you need to search by filters' vs. 'use in all cases for listing bills'. No exclusions or alternative clarifications are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It implies mutation but does not state whether updates are partial or full replacements, whether existing fields are overwritten, what permissions are required, or what the response contains. The examples (fix hours, note, date) hint at capabilities but do not detail behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It states the core purpose and provides illustrative examples efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and a 5-parameter schema at 0% description coverage, the description is too sparse to fully inform an agent. It lacks details on return values, partial update semantics, validation rules, and preconditions, leaving significant gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It maps 'hours' to quantity, 'note', and 'date', but omits price and id. This provides partial semantic value for three of five parameters, but the missing parameters and lack of field-level detail prevent a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('a time/expense entry'), with concrete examples (fix hours, note, or date). This distinguishes it from siblings like clio_log_time/clio_log_expense (create), clio_get_activity (read), and clio_delete_activity (delete).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It does not mention that it is for modifying existing entries rather than creating new ones, nor does it reference any prerequisites or exclusions. The examples imply usage but do not provide clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and domain, omitting any details about required permissions, return values, side effects, or prerequisites (e.g., matter must exist). This lack of transparency is similar to under-disclosed mutation tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently communicates the tool's purpose and scope, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no annotations, and no output schema, the description should provide more context about return values, requirements, or parameter usage. The description only covers the basic purpose, leaving significant gaps for a creation operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only due_at has a description), yet the description does not compensate by explaining parameters. It merely hints that a matter is involved, which is already evident from the parameter name matter_id. The semantics of name, description, and due_at remain unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Create'), the resource ('task'), and the scope ('tied to a matter'). This distinguishes it from sibling tools like clio_create_matter or clio_create_contact, and there is no ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage—this is for creating a task related to a matter—but it does not provide explicit when-to-use guidance or mention alternatives like clio_create_calendar_entry or clio_update_task. There is no exclusionary or comparative information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states that it searches contacts by name or free text, without disclosing details like result ordering, pagination, or whether both clients and parties are included by default. This is minimal context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, front-loaded with the verb, resource, and method. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description fails to describe return values, result structure, or behavioral limits. The type and limit parameters are unexplained, making the tool underspecified for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines three parameters (type, limit, query) with zero description coverage. The description's 'by name or free text' maps to the query parameter but provides no guidance on the type filter or limit behavior. The type enum and limit's default/max are undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search contacts (clients and parties) by name or free text.' This is a specific verb (search) on a resource (contacts) with a clear scope (clients and parties) and method (name/free text). It distinguishes from siblings like clio_get_contact, which retrieves a single contact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching contacts by name or free text, but does not explicitly state when to use this over alternatives like clio_get_contact or clio_browse. There are no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry behavioral disclosure. It clarifies that the tool returns 'full detail' for a single communication, implying a read-only, single-record operation. Yet it omits permissions, error behavior, or rate limits, providing only minimal context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundancy or filler. It effectively conveys the core purpose without unnecessary words, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter get tool, the description is minimally adequate, stating it fetches full details for one communication. However, without an output schema, it does not specify what 'full detail' entails, and it offers no guidance on when to use this over the find tool, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only an 'id' field with no description (0% coverage). The description adds no meaning about the id parameter—it does not explain the id format, how to obtain it, or that it refers to a unique communication. This fails to compensate for the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the resource ('communication') and scope ('one'), with 'full detail' indicating comprehensive retrieval. It distinguishes from siblings like clio_find_communications (search) and clio_log_communication (log), though it lacks an explicit verb like 'get'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'one communication' implies this tool is for retrieving a specific communication by ID, as opposed to searching via clio_find_communications. However, it does not explicitly state when to use it or name alternatives, leaving the guidance implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states the basic function and filters, but does not mention whether the operation is read-only, any required permissions, pagination behavior, or the structure of the response. This is a significant gap for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb 'List', and contains no redundant information. It is appropriately concise for the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and a 0% schema description coverage. The description does not explain the return format, pagination limits beyond the schema, or any operational caveats. It is insufficient for an agent to fully understand the tool's behavior in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to some parameters by mentioning 'matter, contact, or date range', which maps to matter_id, contact_id, and to/from. However, it does not explain the exact nature of to/from (likely dates) or provide details for limit. Since the schema has no property descriptions, this partial compensation earns a midpoint score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'logged communications', and specifies filters (matter, contact, date range). This distinguishes it from sibling tools like clio_get_communication (single item retrieval) and clio_log_communication (creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies using this tool when a list of communications is needed with filtering options. However, it does not explicitly mention when to use alternatives like clio_get_communication for individual communications, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions a list operation but lacks details on pagination, output structure, or any potential side effects. Minimal insight beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is concise and free of filler. Every word contributes meaning, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema. The description explains the purpose and timing, but omits guidance on the limit parameter and return format, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'limit' parameter. The schema itself provides defaults and constraints, but the description adds no explanation of how the parameter affects results, so it fails to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('activity descriptions') with a clarifying parenthetical ('preset rates/descriptions') that differentiates it from activity-related siblings like clio_find_activities. It clearly states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'to use when logging time/expenses' gives implied context but does not explicitly compare to alternatives or state when not to use this tool. No exclusionary guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the basic read action. It does not mention return format, pagination behavior, whether both firm and user calendars are returned, or any other side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately states the core action and scope. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description gives the essential purpose, but it lacks details about the output structure (e.g., what fields are returned, how to use the calendar IDs) and pagination. With no output schema and no annotations, the agent has to infer these details, which is a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes a single optional 'limit' parameter with clear constraints (default 50, min 1, max 50), so the schema is self-explanatory. However, with 0% schema description coverage, the description does not mention this parameter at all, providing no added value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'List' and the resource 'calendars', and clarifies the scope as 'firm/user'. This clearly distinguishes it from sibling tools like find_calendar_entries, which deal with calendar entries rather than calendars.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'available to schedule on' implies this tool should be used before scheduling, but there is no explicit guidance on when to use it versus alternatives, nor any mention of what to do with the results (e.g., use calendar IDs for create_calendar_entry).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not explain partial update semantics, whether unspecified fields are preserved, permission requirements, or return behavior. The agent is left uninformed about side effects beyond the simple update action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no redundancy, front-loaded with the verb and resource. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no annotations, and no output schema, the description is too sparse. It omits critical details like partial vs. full update behavior, response format, or error conditions, making it incomplete for safe and confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description maps several schema parameters to natural-language actions (rename→name, reschedule→due_at, reassign→assignee_id, priority, description), adding meaning beyond the bare schema. Since schema description coverage is 0%, this compensation is valuable, though id and format details are not covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update a task' and enumerates the specific actions (rename, reschedule, reassign, change priority/description), which distinguishes it from sibling tools like clio_create_task or clio_complete_task. The verb and resource are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as clio_complete_task for status changes or clio_get_task for reading. The usage is implied by the name but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the basic action. It does not disclose behavior for edge cases such as missing parameters, precedence between matter_id and parent_folder_id, pagination via limit, or output format. This leaves significant ambiguity for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and front-loaded, with no wasted words. It is appropriately concise for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits essential context such as what happens when no parameters are supplied, whether listing is recursive, and what the response structure looks like. With no output schema or annotations, this is insufficient for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description references 'matter' and 'parent folder', adding context to matter_id and parent_folder_id. However, it does not explain the 'limit' parameter, and since schema description coverage is 0%, the description fails to fully compensate for the missing documentation of all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'List' and specifies the resources 'folders and documents' with a clear scope 'under a matter (or a parent folder)'. This distinguishes it from sibling tools like clio_get_document or clio_find_matters, making the purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the context of use: browsing the contents of a matter or folder. However, it does not explicitly mention when to use alternatives or any exclusions, so it falls short of a 5 but has clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely states 'create' without mentioning prerequisites, permission requirements, or side effects. This leaves significant ambiguity for an agent invoking the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently communicates the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, yet the description fails to explain expected outcomes, error conditions, or the relationship between matter_id and parent_folder_id. This is insufficient for an agent to invoke it with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The phrase 'under a matter or parent folder' gives partial meaning to matter_id and parent_folder_id, but the description does not elaborate on the name parameter or clarify whether a parent context is required. With 0% schema description coverage, it adds some but not sufficient semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and resource 'a folder' with a specific location 'under a matter or parent folder.' This distinguishes it from sibling tools like clio_delete_folder and clio_create_matter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: creating a folder within a matter or under a parent folder. It provides clear context but does not explicitly name alternatives or exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It lacks any mention of pagination (limit, defaults), read-only nature, or response format, leaving critical expectations unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy, directly states purpose and filtering options.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description is too sparse for a 6-parameter list tool. It omits pagination details, default behaviors, and response structure, making it insufficient for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists the filter dimensions (matter, user, type, date range) which maps to the schema parameters, but only to/from are described in the schema. The description adds some grouping but does not elaborate on parameter value formats or combinations beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (List) and identifies the resource (time/expense entries) with filter criteria, distinguishing it from sibling retrieval or creation tools like clio_get_activity or clio_log_time.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for listing/finding activities with optional filters, but does not explicitly state when to prefer it over alternatives like clio_get_activity for single record retrieval or clio_find_notes for notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds context about the output (field IDs and value formats) and implies a read-only listing operation. However, it does not mention pagination limits, response structure, or any potential side effects, leaving significant behavioral details undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It front-loads the verb and resource, and every word contributes meaning. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only 2 parameters, no output schema, and no annotations, the description conveys the core purpose and indicates the type of returned data (field IDs and value formats). However, it omits any mention of the limit parameter's behavior or pagination, making it adequate but not fully complete for a self-contained tool description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains 'parent type' implicitly (matching the parent_type parameter) but does not mention the 'limit' parameter at all. The schema provides min/max/default for limit, but the description adds no extra meaning for that parameter, resulting in incomplete parameter explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('custom field definitions for a parent type') and explains the intended outcome ('so you know the field ids and value formats'). This distinguishes it from sibling tools like clio_set_custom_field_values and other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case—when you need field IDs and value formats—but does not explicitly state when to use this tool vs alternatives, nor does it provide exclusions or a direct pointer to related tools (e.g., 'use before setting custom fields'). The guidance is reasonable but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavioral traits. It only says 'set' without explaining whether this overwrites all existing custom fields, how invalid IDs are handled, or what the response looks like. This is insufficient for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action. The related tool hint is concise and directly useful. No superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 required parameters, a nested array, and no output schema, yet the description does not mention request mechanics (e.g., multiple fields, parent_id role, error cases). The single dependency hint is not enough to fully use the tool correctly without inferring from the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, but the description adds meaning by specifying that parent_type allows 'matter or contact' and that field IDs come from clio_list_custom_fields. However, it does not explain parent_id semantics or the expected structure of the values array beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (set) and the resource (custom field values), and specifies the allowed target objects (matter or contact). This distinguishes it from sibling tools, none of which perform the same operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (to set custom field values) and gives a direct pointer to a prerequisite sibling tool (clio_list_custom_fields) for obtaining field IDs. It does not explicitly state when not to use it, but the usage context is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. The verb 'List' implies a read-only operation, and the filter criteria are disclosed. However, it does not mention pagination, the significance of the limit parameter, or the response format, which are important behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that avoids redundancy. Every word contributes to the core purpose and filter capabilities.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic list-with-filters functionality, but it does not address pagination/limit behavior, how to retrieve a single entry, or what the response contains. Given the lack of annotations and output schema, more contextual detail would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only 40% description coverage. The description adds meaning by tying 'calendar', 'matter', and 'date range' to the corresponding parameters, but it does not mention the 'limit' parameter or clarify that all filters are optional. It partially compensates for the schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists calendar entries and specifies the filter dimensions (calendar, matter, date range). This distinguishes it from siblings like clio_get_calendar_entry (singular retrieval) and clio_list_calendars (lists calendars, not entries).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing/filtering calendar entries, but it does not explicitly mention when to use this tool versus alternatives such as clio_get_calendar_entry for a single entry. No exclusions or alternative tool names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value by clarifying that closing is a status update to 'closed', a nuance not in the schema. However, with no annotations, it does not disclose whether updates are partial/full, permission requirements, or reversibility of changes, leaving some behavioral uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It clearly states the operation and then adds a useful clarifying example, making it exceptionally concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with three parameters and no output schema, the description covers the core purpose and a key behavioral detail. It does not mention available fields (schema covers that) or return behavior, but it is sufficiently complete for the tool's low complexity, though some contextual info like partial updates is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It gives meaning to the status parameter by linking closing to 'closed' and implicitly identifies that the id selects the matter. However, it does not explain the description parameter or all possible status transitions, so compensation is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'update' and resource 'matter', distinguishing it from sibling tools like create/get/find. The parenthetical adds specificity about status changes, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating an existing matter but does not explicitly state when to use it over alternatives (e.g., create for new matters). No prerequisites or exclusions are provided, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states what is returned ('full detail...including linked client and recent documents') but does not mention safety (read-only), potential errors, or response format. It adds some value but lacks richer behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the main purpose ('Full detail for one matter') and includes specific, useful details without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), and the description adequately covers the core purpose and key return elements. It could mention how to obtain the matter id (e.g., via clio_find_matters), but that is not essential for a straightforward getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the only parameter (id: 'Matter id') with 100% coverage. The description adds no additional parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('get') and resource ('matter') with scope ('full detail') and explicitly mentions key contents (linked client, recent documents). This clearly distinguishes it from sibling tools like clio_find_matters, which are search/list operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Full detail for one matter' implies it should be used when a single matter's complete details are needed, but it does not explicitly state when to use it versus alternatives like clio_find_matters, nor does it mention prerequisites (e.g., obtaining the matter id). Usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the transparency burden. It discloses that the operation is destructive and requires a confirm_token on the second call, which is critical behavioral context. However, it omits details like reversibility or error responses.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, using two short sentences. The purpose is front-loaded, and the critical warning about destructiveness and confirmation follows immediately. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description conveys the core purpose and a key safety requirement, but for a two-step destructive process it does not explain the first-call flow, what the first call returns (e.g., a token), or how the confirm_token should be supplied. This leaves important workflow ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds some meaning for confirm_token ('requires confirm_token on the second call') but does not explain id or parent_folder_id. While those parameter names are somewhat self-explanatory, the description fails to fully compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Move a document to a different folder'), with a specific verb and resource that distinguishes it from sibling tools like get_document, update_document, and delete_document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for moving documents between folders and includes a caution about being destructive and requiring confirm_token on the second call. However, it does not explicitly state when to use this tool versus alternatives or include exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds a meaningful behavioral detail ('Handles Clio's multi-step storage upload atomically'), which implies safety and internal complexity. However, it does not disclose permissions, return values, error conditions, or what happens if both matter_id and parent_folder_id are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with no wasted words. The first sentence states the primary purpose, and the second adds an important execution detail. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no output schema, and no annotations. The description does not explain whether matter_id or parent_folder_id is required, how content_type is determined, or what the function returns. It is terse and leaves significant ambiguities for a multi-step upload operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, so the description must compensate. The phrase 'under a matter or folder' gives semantic meaning to matter_id and parent_folder_id, which lack schema descriptions. However, content_type is entirely unexplained, and the relationship between matter_id and parent_folder_id is ambiguous. This is partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Upload') and resource ('local file as a new document'), and clarifies placement ('under a matter or folder'). This clearly distinguishes it from siblings like clio_download_document, clio_get_document, clio_update_document, and clio_delete_document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use the tool—when uploading a new local file as a document under a matter or folder. It does not explicitly mention exclusions or alternatives, but no direct upload alternative exists among the siblings, so the context is sufficient. It could improve by noting that it is not for updating existing documents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It clearly indicates a non-mutating action ('download') and discloses that content is saved to a local sandbox with a returned path, plus inline text for text/markdown. It omits edge cases like binary files or permission requirements, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the main action and immediate outcome. Every word adds value, with no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description covers the key aspects: what it does, where output goes, and the inline return for text/markdown. It lacks details on error handling or file types, but those are less critical for this straightforward download operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'id' has zero schema description coverage, and the description does not explicitly state that 'id' refers to the document identifier. While the name is self-explanatory, the description adds no meaning beyond the schema field itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('download') and clearly states the resource ('a document's content') and the outcome ('return its path'). It distinguishes from siblings like clio_get_document and clio_browse by focusing on content retrieval rather than metadata listing or folder navigation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a read/download use case and mentions the local sandbox, but it does not explicitly state when to prefer this over clio_get_document or other alternatives. There are no exclusions or comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. The verb 'List' implies a read-only operation, but it does not explicitly state safety, side effects, or pagination behavior. Still, 'List' is a strong indicator of non-mutating behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. The parenthetical 'for tagging matters' adds useful context without bloating it, and the action verb is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description adequately covers the core purpose and intended use. It does not mention the limit behavior or return format, but the schema handles the parameter details, making it sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% because the description does not mention the 'limit' parameter at all. The schema itself defines the parameter with constraints, but the description adds no additional meaning to guide the agent on how to set it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'practice areas' and adds the use-case 'for tagging matters,' clearly distinguishing this from sibling tools like clio_find_matters or clio_list_users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use the tool ('for tagging matters'), and while there are no direct alternatives among siblings, the intended use case is explicit and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the current user is included in results, which is useful. However, it doesn't mention other behavioral aspects like response format, ordering, or permission requirements, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary purpose and includes a helpful parenthetical. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description covers the main purpose and a notable behavioral trait (includes current user). It doesn't describe the output format or the limit parameter, but given the tool's simplicity and the schema providing constraints, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (limit) with 0% description coverage, and the tool description does not mention this parameter at all. The description fails to add meaning beyond the schema, leaving the agent to infer from the parameter name and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List firm users' with a specific verb and resource, and provides additional context indicating the use case ('for assigning tasks/activities'). This distinguishes it from sibling tools, none of which list users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool by stating 'for assigning tasks/activities', giving clear context. No alternative user-listing tool exists among siblings, so no explicit exclusion is needed, though it doesn't state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly states the destructive nature and the two-call confirmation mechanism, which is valuable beyond the schema. However, it doesn't detail what the preview contains or any error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short sentences that front-load the action and key workflow. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description captures the essential two-step workflow but omits details about the second call's full requirements (e.g., whether id is still needed) and the return value of execution. The preview's contents and error handling are also unspecified, leaving some gaps for a multi-step destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description only indirectly mentions confirm_token ('call again with the token') and never explains the id parameter. It fails to clarify what id refers to or that it is required, leaving parameter semantics mostly to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a folder' uses a specific verb and resource, clearly distinguishing it from sibling tools like clio_delete_document and clio_delete_activity. It leaves no ambiguity about the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly outlines the two-step usage: first call returns a preview and confirm_token, then call again with the token to execute. It implies this is the correct way to delete a folder, but doesn't explicitly contrast with alternatives; still, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses the destructive nature and the crucial two-step preview/confirm mechanism, including the confirm_token requirement. This is significant context for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys purpose, destructiveness, and the execution flow. Every phrase is essential, and it is front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core deletion flow but omits details such as what the preview returns (beyond confirm_token), what happens after execution, and how to obtain the entry ID. With no output schema, more context about the preview and consequences would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explicitly explains the role of confirm_token in the two-step flow and implies that id identifies the calendar entry. This adds meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Delete a calendar entry.' This distinguishes it from sibling delete tools (e.g., clio_delete_document, clio_delete_activity) by naming the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit usage guidance by describing the two-step deletion flow, but it does not explicitly state when to use this tool versus alternatives or when not to use it. The intended use case is implied by the resource type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses a critical behavioral trait: the entry becomes a billable line by default unless non_billable is set. This adds meaningful context beyond the schema, though it omits other side effects like return values or editability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with zero wasted words. The key action and the most important behavioral consequence are stated upfront.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no output schema and no annotations, the description is minimal. It explains the core purpose and billing default but does not describe return values, validation rules, or relationships to related entities like activity descriptions, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by clarifying that the entry is on a matter (giving context to matter_id) and that non_billable overrides the default billable status. It also reinforces that quantity is in hours, compensating for the 57% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Log', the resource 'a time entry on a matter', and specifies 'hours' as the unit. It distinguishes itself from sibling tools like clio_log_expense by explicitly focusing on time entries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the name and description (logging time vs. expenses), but there is no explicit guidance on when to use this tool instead of alternatives, nor any mention of exclusions or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the two creation modes and their parameter mapping, but does not mention side effects, required permissions, or error behavior. This is minimally adequate but lacks depth for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action, then concise parameter guidance. Every word earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with 4 parameters and no output schema, the description covers the core usage and type-specific fields. It lacks details on return values or prerequisites, but the essential behavior is clear enough for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It effectively maps 'type' to Person/Company and explains when to use first/last_name versus name, adding meaning beyond the raw schema. It does not describe each parameter individually but provides the essential usage pattern.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with 'Create' which is a specific verb for a write operation, and identifies the resource as 'client or party'. This clearly distinguishes it from sibling read tools like clio_find_contacts and clio_get_contact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs on how to use the tool for two entity types: 'type=Person with first/last name, or type=Company with name'. This provides clear context on which parameters to use in which scenario, though it does not explicitly name alternative tools for reading contacts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full transparency burden. It explicitly discloses that the tool is 'Destructive' and requires a two-step process: first call returns a preview + confirm_token, second call with the token executes. This goes beyond simply saying 'delete' and gives the agent essential behavioral context. It does not describe the exact preview structure, but the key destructive behavior is well-covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero filler. The first sentence states the action, and the second sentence explains the destructive workflow. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete tool with a two-step confirmation, the description covers the essential workflow. It explains what happens on first and second calls. It does not detail the preview contents or token expiration, but with no output schema and no annotations, it provides sufficient context for an agent to invoke the tool correctly. Sibling tools are not needed for this action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It does by explaining that the confirm_token is generated in the first call and used in the second call to execute the deletion. This gives crucial meaning to the confirm_token parameter. The id parameter's purpose is obvious from the tool name and required status, though not explicitly restated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Delete a document.' which is a specific verb and resource, clearly distinguishing it from sibling tools like clio_get_document, clio_upload_document, and clio_move_document. It unambiguously states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool is used to delete a document. It also explains the two-step confirmation workflow (preview + confirm_token, then second call to execute), which is an actionable usage guideline. It does not explicitly mention alternatives, but the purpose is unambiguous and no exclusions are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on the burden of disclosing behavior. It clearly labels the operation as destructive and explains the two-step confirmation requirement via confirm_token. This goes beyond the schematic information and gives important safety guidance, though it could also mention what exactly gets overwritten or the side effects on the previous version.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the primary actions and the destructive nature. Every word earns its place; there is no fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and no annotations, the description covers the key behavioral aspects: what operations are available and the confirmation requirement. It is complete enough for an agent to use correctly, though it could be slightly more explicit about the lifecycle of the confirm_token (e.g., how it is obtained after the first call).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It gives meaning to 'name' (rename), 'new_version_path' (upload new version), and 'confirm_token' (required on second destructive call). It does not detail the exact format of the token or the path, but it provides the essential semantic mapping for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: renaming a document or uploading a new version (overwrite). The verb 'rename' and phrase 'upload a new version' specify distinct operations, and the mention of 'overwrite' distinguishes this from sibling tools like clio_upload_document or clio_delete_document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the two primary use cases (rename or overwrite) and explicitly warns that it is destructive and requires a confirm_token on the second call. While it does not name alternative tools, the context signals are clear enough for an agent to infer when to use this tool versus a plain upload or delete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description explicitly signals 'Destructive' and discloses the two-phase execution requiring a confirm_token. This goes beyond the schema, which lists confirm_token as optional without explaining its role, making the behavior transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences pack the core action, destructive warning, and the critical two-step confirmation mechanism without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, destructive nature, and the confirm-token workflow, which is sufficient for a simple deletion tool with two parameters. It doesn't detail permissions or the preview return structure, but the description is complete enough for an agent to execute correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description gives meaning to the confirm_token parameter by explaining it is returned from the preview call and required for execution. The 'id' parameter is not explicitly described, but its role as the entry identifier is clear from the first sentence. With 0% schema description coverage, this partial explanation is valuable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific action 'Delete' and names the resource 'time/expense entry', which clearly distinguishes it from sibling tools like clio_get_activity and clio_update_activity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains the two-call confirmation flow, which guides when to call once for preview and when to call again to execute. It does not explicitly contrast with alternatives, but the destructive warning and confirmation pattern provide strong usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ClioMCP MCP server](https://glama.ai/mcp/servers/ToddHebebrand/ClioMCP/badges/card.svg)](https://glama.ai/mcp/servers/ToddHebebrand/ClioMCP)

Score Badge

Copy to your README.md:

[![ClioMCP MCP server](https://glama.ai/mcp/servers/ToddHebebrand/ClioMCP/badges/score.svg)](https://glama.ai/mcp/servers/ToddHebebrand/ClioMCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ToddHebebrand/ClioMCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server