lawmatics-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct entity or action, and overlapping categories like find-* vs get-* vs list-* are clearly separated by unique ID, exact match, or filtered listing. No tools appear to do the same thing.
Naming Consistency5/5
All tool names follow a predictable verb_noun pattern with consistent separators and verbs (get, list, create, update, find, attach, detach, submit). The naming is uniform and easy to infer.
Tool Count2/5
With 37 tools, this server is well over the 25-tool threshold for a heavy surface. While the domain is broad, many reference-data list tools could be consolidated, and the count will overwhelm agents.
Completeness3/5
Core workflows for matters, contacts, tasks, and forms are covered, but there are notable gaps: no delete for any entity, no create/update for companies, no update/delete for events/notes, and no true pipeline stage movement. These are workable limitations but leave lifecycle coverage incomplete.
Average 3.9/5 across 37 of 37 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 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
This repository is licensed under MIT License.
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 does clarify that this is a partial update ('Only the provided fields change'), but it omits other critical behavioral aspects such as required permissions, whether updates are reversible, what the response contains, or potential side effects.
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 short, focused sentences. Every word earns its place; 'Only the provided fields change' adds meaningful partial-update context. There is no fluff or unnecessary 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 tool with 5 parameters, a required contact_id, and no output schema, the description is far too sparse. It does not mention return values, required contact_id usage, error handling, or any contextual prerequisites, leaving significant gaps for an agent to make correct calls.
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 low (only contact_id has a description), and the description does not compensate. It says 'Only the provided fields change' implying any of the fields can be updated, but it does not list or explain parameters like email, phone, or names. Agents must infer semantics from property names alone.
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 'Update a contact' which identifies the verb and resource, distinguishing it from sibling tools like get-contact, list-contacts, and create-contact. However, it lacks specificity about which fields or any special scope, making it clear but not exceptionally detailed.
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. The phrase 'Only the provided fields change' hints at partial update semantics, but does not state when this tool is appropriate, prerequisites like contact existence, or when to prefer create-contact or other update variants.
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 only says 'List' and does not reveal pagination, filtering, fetch_all behavior, or any potential side effects. For a tool with 8 parameters, this is a notable gap.
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 sentence with no fluff or redundancy. It is extremely efficient, but its brevity borders on under-specification; still, for pure conciseness, it scores well.
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 8 parameters, no output schema, and no annotations, the description is grossly incomplete. It explains neither the return shape, pagination limits, filtering constraints, nor any contextual use cases, leaving the agent to infer everything from the schema alone.
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 provides highly detailed descriptions for 88% of parameters, including pagination, filtering, and sorting semantics. The description adds no parameter-related value, so it neither helps nor hurts; the baseline of 3 is appropriate.
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 the verb 'List' and resource 'tags' directly, making the tool's core function clear. However, it does not differentiate from sibling list tools (e.g., list-contacts, list-matters) beyond the resource name, lacking any scope or qualification.
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 zero guidance on when to use this tool versus alternatives, no mention of prerequisites, and no exclusions. It is a bare statement with no contextual advice.
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 bears full responsibility for behavioral disclosure. It only mentions optional filter/sort/pagination but omits critical constraints like the single-filter limit, fixed page size of 25, the 1,000-record cap on fetch_all, or how results are returned. These behaviors are documented in the schema but not in the description, leaving the agent without a complete operational picture.
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 efficient sentence with no wasted words. It front-loads the primary action and resource. It could be more informative but is appropriately concise for a list operation.
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 8 parameters, no output schema, and no annotations, a single-sentence description is insufficient. It fails to convey API quirks (persistent filters, pagination behavior), when to use it vs. find-company, and what the response shape might be. The schema helps but the overall tool definition remains incomplete for an agent to confidently invoke it in varied contexts.
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 88%, and each parameter has detailed descriptions within the schema. The main description adds no additional semantic value; it simply summarizes capabilities already present in the schema. Baseline of 3 is appropriate since the schema carries the load.
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 ('List'), the resource ('companies'), and the scope of behavior (optional filter, sort, pagination). This distinguishes it from sibling tools that operate on different resources or fetch single records (e.g., get-company).
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 choose this tool over alternatives such as find-company or get-company. The description does not mention scenarios, exclusions, or relationships to sibling tools.
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 disclose effects, merge semantics, permissions, or error behavior, but it only gives a high-level action. Details about field replacement, partial updates, and failure scenarios are absent.
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?
A single sentence with an em-dash and examples that is efficient and front-loaded. No filler, but it is not as minimal as a two-sentence zero-waste case.
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 7-parameter mutation tool with no annotations, no output schema, and low schema coverage, the description leaves significant gaps in usage context, parameter details, and behavioral expectations.
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?
Examples map to done, due_date, and user_ids, but the description does not explain name, priority, or description. Schema coverage is only 29%, so the partial mapping is not fully compensatory.
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 resource ('task'), and provides concrete examples ('mark it done, change the due date, or reassign it') that distinguish it from sibling tools like create-task and list-tasks.
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 implies use for modifying existing tasks but does not explicitly contrast with alternatives like create-task. It offers no when-not-to-use criteria 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, and the description does not disclose behavioral traits such as pagination limits, default sorting, or read-only nature. It simply states that it lists practice areas, leaving the agent to infer behavior from the schema.
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 directly states the tool's purpose with no extraneous words, earning high marks for conciseness and 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 tool with 8 optional parameters and no output schema, the description is overly minimal. It doesn't mention advanced capabilities like filtering, pagination, or sorting, which the schema includes. An agent would need to inspect the schema fully to understand the tool's potential.
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 88%, so the schema already explains most parameters. The description adds minimal value by hinting that the default output includes id, name, and color, but this does not significantly enrich parameter meaning beyond what the schema provides.
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' and identifies the resource as 'the firm's practice areas', with the parenthetical indicating the returned fields. This clearly distinguishes it from sibling list tools like list-matters or list-contacts.
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, no prerequisites, and no exclusions. It merely states what the tool does without context for agent decision-making.
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 target types, omitting details about idempotency, error handling for nonexistent tags, permissions, or return values.
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 efficiently states the tool's purpose. It has no wasted words and is appropriately sized for the simple operation.
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 annotations and no output schema, the description needs to provide behavioral context but does not. The schema's tag creation note referencing 'attach' creates ambiguity for detach, and the description is too sparse to clarify key edge cases.
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 100%, so the schema already documents all parameters clearly. The description adds no parameter information, and the tags schema note about creating nonexistent tags on attach may confuse detach behavior, but that is a schema issue, not a description flaw.
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 the specific action 'Detach tags' and the resource types 'matter, contact, company, or task', matching the target_type enum. This clearly distinguishes it from sibling tools like attach-tags.
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 verb 'detach', but the description does not explicitly state when to use it vs alternatives or mention any prerequisites or edge cases. No exclusions or alternative 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 must bear the full burden of disclosing behavioral traits. It does mention one side effect—'Tags that don't exist yet are created'—but omits other important behaviors such as whether existing tags are appended or replaced, whether the operation is idempotent, or any error conditions. This is a significant transparency gap 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 sentence, front-loaded with the action, and contains zero redundant words. Every part earns its place, making it highly 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?
The tool is relatively simple with 3 well-documented parameters, but there is no output schema and no annotations. The description covers the core function and tag creation side effect, yet it does not explain what the tool returns or any prerequisites (e.g., target must exist). This leaves some gaps in the overall context, though it is adequate for basic use.
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 already provides 100% coverage with descriptions for all three parameters, including the note about automatic tag creation. The description adds no additional parameter-specific meaning beyond what the schema already states, so it meets the baseline for high 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 specific action ('Attach tags') and explicitly lists the resource types (matter, contact, company, task). This distinguishes it from sibling tools like detach-tags and list-tags, making its purpose unmistakable.
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 when to use the tool ('Attach tags to...') but provides no explicit guidance on when not to use it or alternatives (e.g., detach-tags for removal). It offers no exclusion criteria or comparison to sibling tools, so usage context is only inferred.
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 full responsibility for behavioral disclosure. It only mentions the semantic scope ('without a matter') but provides no information about side effects, return values, permissions, validation, or error behavior. This is a significant gap for a create operation.
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, front-loaded with the primary purpose, and immediately provides an alternative link. Every word earns its place with no redundancy.
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 lack of annotations and output schema, the description is too sparse to fully support an agent. It covers the purpose and one alternative but omits essential context such as response format, error conditions, or any notes on parameter usage. For a 5-parameter create tool, this is incomplete.
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 20%, and the description adds no parameter-level semantics. It does not explain what 'first_name', 'last_name', 'email', 'phone', or 'notes' mean beyond their names, nor does it clarify required vs optional fields. 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.
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 new contact (person)'), and explicitly scopes it as 'without a matter.' It also distinguishes itself from the sibling tool create-matter, making its 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent when to use this tool versus an alternative: 'To create a lead with a case, use create-matter.' This provides clear usage direction and differentiates from the most likely confusable sibling.
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 behavioral traits on its own. It adds domain knowledge about top-level statuses but doesn't mention read-only nature, pagination behavior, response structure, or any error conditions. The schema covers parameters, but with no output schema, the description should clarify what the response contains. The lack of any behavioral disclosure beyond the basic 'List' verb leaves significant 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 extremely concise: two sentences, no fluff. It front-loads the purpose, then adds essential domain context and usage guidance. Every sentence contributes value, making it an efficient and well-structured description.
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 important context for a tool with 8 parameters and no output schema. It does not mention what a sub-status entity looks like (e.g., id, name), whether filtering or pagination is relevant (though schema covers this), or any rate limits. The top-level status explanation is helpful but insufficient for an agent to know what to expect from the response. More behavioral and return-value context is needed.
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 88%, so the baseline is 3. The description does not add parameter-specific detail beyond what the schema already provides, but the mention of 'Use the IDs' indirectly clarifies the purpose of the returned data, which helps contextualize the tool. It does not compensate for the uncovered parameters, but those are already well-documented in 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 clearly states the tool's function: 'List matter sub-statuses.' It also distinguishes from siblings by specifying the relationship to top-level statuses ('pnc, hired, or lost') and explicitly ties it to use with create-matter / update-matter, which differentiates it from other list tools like list-stages or list-pipelines.
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 gives practical usage context: 'Use the IDs with create-matter / update-matter.' This tells the agent when the tool is relevant (when needing sub-status IDs for those mutations). It does not explicitly contrast with alternatives, but the context is clear enough for a list utility. No exclusions are stated, but the primary use case is conveyed.
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 disclose behavioral traits; it only states that a note is created, which is a mutating operation. It omits any details about permissions, side effects, or return value, leaving the agent with minimal 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, direct sentence that front-loads the action and resource. There is no superfluous text, making it optimally concise.
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 create operation with four scalar parameters fully described in the schema, the description covers the core purpose but lacks details on prerequisites or response format. The absence of an output schema and annotations means the agent must infer some behavior, leaving moderate gaps.
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 provides full descriptions for all four parameters, including the mapping of notable_type 'Prospect' to 'matter'. The description adds no parameter-specific information, so the baseline of 3 applies due to complete 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 a specific action ('Create a note') and identifies valid attachment targets ('matter, contact, or company'), aligning with the input schema's notable_type enum. This distinguishes it from other creation tools like create-task or create-event.
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 appropriate context: creating a note on one of three entity types. It doesn't explicitly name alternatives or exclusion criteria, but the purpose is unambiguous enough for an agent to select it when a note needs to be created.
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 only the optional attachment/assignment behavior but does not mention permissions, return value, or failure modes. For a mutation tool, this is insufficient.
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, front-loaded with the action, efficient and to the point. Every word 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?
With 9 parameters and no output schema, the description is minimal. It does not specify return value or behavior for invalid inputs, but the core purpose is adequately covered given the schema's parameter descriptions.
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 covers 67% of parameters. Description adds meaning by clarifying 'attached to a matter/contact/company' maps to taskable_type/taskable_id and 'assigned to users' maps to user_ids, providing relational context beyond individual schema definitions.
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 clearly states the action 'Create a task' with optional attachment and assignment, distinguishing it from sibling tools like create-note or create-event. It is specific and 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?
No explicit guidance on when to use versus alternatives, but the description implies usage context for task creation. It does not name alternative tools 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, so the description carries the full burden of behavioral disclosure. It only restates the tool's function ('Get full details') without addressing the optional fields parameter, return format, error handling, or side effects. The phrase 'full details' could be misleading when a subset of fields is requested.
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 of nine words, front-loaded with the action and target. Every word earns its place, with no redundant or irrelevant content.
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 get-by-ID tool, the description covers the primary purpose but omits the selective fields parameter and any details about response behavior or non-existent IDs. It is minimally adequate but lacks depth for edge cases, especially given there is no output 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 coverage is 100% with both parameters described in the schema, so the baseline is 3. The description adds no parameter meaning beyond the schema; it does not explain how 'fields' works or the default behavior.
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 'Get' with resource 'company' and scope 'single company by ID', clearly distinguishing it from sibling tools like list-companies (listing) and find-company (searching). It concisely states what the tool does and its unique target.
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 usage when a specific company ID is known ('by ID'), providing clear context for when to use this tool. It does not explicitly mention alternatives or exclusions, but the context is sufficiently clear among 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?
No annotations are provided, so the description carries the full burden. It only adds that forms are custom/intake forms and that form IDs are UUIDs, but it does not disclose pagination behavior, sorting/filtering capabilities, or any side effects. This is minimal 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 two sentences long with no redundant information. It is front-loaded with the core action and resource, and every clause adds value.
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 purpose and an alternative, but with 8 parameters and no output schema, it is not fully complete. The schema covers parameter details, but the description does not mention return format or usage nuances like pagination or filtering, leaving some gaps.
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 88%, and the schema itself has detailed parameter descriptions. The description adds no parameter-level meaning beyond what the schema already provides, 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 clearly states the tool lists the firm's custom forms (intake forms) with a specific verb+resource. It also distinguishes itself from get-form by pointing to that sibling for field structure, making the scope unambiguous.
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 gives an explicit alternative ('Use get-form to see a form's field structure'), which is helpful for choosing between tools. However, it does not state when not to use list-forms or mention other relevant list tools, so it lacks full exclusion guidance.
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 mentions the output fields and a companion usage, but does not disclose pagination behavior, default limits, read-only nature, or any side effects. The two sentences add little beyond what the tool's name implies.
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 consists of exactly two sentences, both of which carry useful information: the first states the primary purpose and output, and the second gives a practical cross-reference. There is no fluff or repetition of schema content.
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 has 8 parameters and no output schema or annotations. The description gives a clear purpose and a companion tool reference, which helps an agent decide when to use it. However, it lacks details about return structure, pagination defaults, or how the parameters interact (e.g., filter behavior), making it only minimally adequate given the tool's complexity.
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 88%, which is high, so the baseline is 3. The description itself does not add parameter-level meaning beyond the schema; the phrase 'stage references' hints at stage_id but does not clarify any specific parameter. The schema already explains each parameter in detail, so no penalty.
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 purpose: 'List the firm's pipelines with matter counts, estimated value, and stage references.' This is a specific verb+resource pairing (list pipelines) with scope ('firm's') and defines the return content, distinguishing it from sibling list-* tools like list-stages.
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 says 'Use with list-stages to build a full pipeline board view,' providing a concrete use case and naming a companion tool. This counts as clear context, though it doesn't state when NOT to use this tool or list alternative approaches.
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 for behavioral disclosure. It only notes the basic 'list' function and that IDs are used for assignments, but does not mention pagination behavior, permissions, or that results are limited (e.g., 25 per page, 1,000 cap). This leaves the agent without safety or operational 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 two short sentences, front-loading the core purpose and adding a practical use case. Every word earns its place; 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters and no output schema, but the schema itself is rich and covers pagination, filtering, and sorting. The description addresses the primary use case but does not explicitly mention supported operations like pagination or filtering; however, those are available in the schema. The description is adequate but not fully complete on its own.
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 high coverage (88%) with detailed parameter descriptions, so the baseline is 3. The main description adds little parameter-specific context; mentioning 'Use the IDs for task/event assignment' hints at the importance of the id field but does not clarify any of the eight 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 states 'List the firm's Lawmatics users (staff)', using a specific verb and resource. It distinguishes from sibling list tools like list-contacts and list-matters by explicitly targeting users/staff, making the tool's function unambiguous.
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 gives a clear usage context: 'Use the IDs for task/event assignment', indicating when an agent should call this tool. It does not mention exclusions or alternatives, but the context is specific enough to guide appropriate use.
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 transparency burden. It mentions 'full details' and 'including custom fields', which gives some behavioral context, but it does not disclose default behavior around the fields parameter or error handling. For a read operation, this is adequate but not comprehensive.
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, well-structured sentence that front-loads the verb and object, includes a specific detail (custom fields), and contains no unnecessary 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?
This is a simple read tool with only two parameters and no output schema. The description conveys the core functionality (return full details for a contact) and includes the custom fields nuance. However, it does not mention potential errors or response format, which would make it fully complete.
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 already describes both parameters (contact_id and fields) with 100% coverage. The description adds minimal value by mentioning 'custom fields', which hints at the fields parameter, but it does not explain the comma-separated format or 'all' option that the schema already documents. Baseline 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 clearly states the tool fetches full details for a single contact by ID, including custom fields. The verb 'get' and resource 'single contact' distinguish it from list-contacts and find-contact, which handle multiple or searched contacts.
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 should be used when you have a contact ID and need full details, but it does not explicitly state when not to use it or mention alternatives like find-contact. No exclusions or prerequisites 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?
With no annotations, the description carries the full burden. It discloses the return structure (field layout details) but does not explicitly state that this is a read-only operation with no side effects. The verb 'Get' implies safety, but the description does not elaborate on any behavioral traits like permission requirements or error 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 that efficiently states the purpose and expected output. No wasted words or irrelevant 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?
For a simple tool with one parameter and no output schema, the description adequately conveys the primary purpose and return information (field layout). It could be slightly more complete by mentioning what else the form object contains, but the core use case is clear.
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 fully describes the only parameter (form_uuid) with context ('from list-forms'), covering 100% of the schema. The tool description adds no additional parameter semantics beyond what the schema already provides, so a baseline score 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 clearly states the action ('Get') and the resource ('one custom form'), and specifies the return content (field layout with IDs, labels, types, required flags). It distinguishes from siblings like list-forms (plural listing) and get-form-entries (entries vs. definition).
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 use for retrieving a specific form definition, but does not explicitly state when to use this vs. alternatives (e.g., list-forms for all forms, get-form-entries for submissions). No when-not or alternative conditions 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?
Annotations are absent, so the description carries the full burden. It only states the tool lists contacts with optional filter/sort/pagination and does not disclose read-only semantics, pagination caps, or filter limitations. Some of these details appear in the schema, but the description itself is thin and lacks behavioral caveats.
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 sentences, front-loaded with the main purpose and a concise clarifying note. No redundant information, and the structure is efficient.
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 gives a solid overview and valuable entity disambiguation. It does not mention alternative tools or pagination/truncation behavior, but the rich schema compensates for many behavioral details, making the description adequate for a tool with 8 parameters.
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 88%, so the baseline is 3. The description does not add meaning beyond the schema; however, the contact/matter clarification helps interpret filter_by=matter_id, providing a small semantic extra.
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 contacts (people)' with a specific verb and resource, and it distinguishes contacts from matters ('the matter (prospect) is the case/lead attached to them'). This disambiguates the tool from list-matters and other related tools.
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 that contacts are person records and matters are separate entities, guiding an agent when to use contact tools vs. matter tools. It does not explicitly name alternatives like find-contact, but the entity clarification serves as practical usage 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, the description carries the full burden. It discloses partial update behavior and the lack of a direct stage move mechanism, which is useful. However, it omits side effects, return values, permissions, or what happens on error, leaving significant behavioral 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 two sentences, front-loaded with the core purpose. It includes a valuable caveat without any fluff or repetition, making every word earn 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?
Given 12 parameters, no output schema, and no annotations, the description is too thin. It lacks return format, error handling, permission requirements, and detailed field semantics. The pipeline stage note is helpful but leaves the rest of the tool's operation undocumented.
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 coverage is only 25%, so the description should compensate. It adds meaning to sub_status_id by explaining its role as the closest control for stage moves and clarifies that all parameters are partial updates. However, most parameters (e.g., tags, email, notes) remain unexplained by both schema and description.
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 updates a matter, using the verb 'Update' and resource 'matter'. It also differentiates from siblings by noting that there is no documented way to move a matter between pipeline stages, and sub_status_id is the closest control, which is unique to this tool.
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 usage context by explaining that only provided fields change (partial update) and warns about the pipeline stage limitation, implicitly telling users to use sub_status_id for stage changes. However, it does not explicitly name alternatives like create-matter or list-matters.
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 disclose behavioral traits. It discloses that send_invites defaults to true and emails attendees, advising to set it false to avoid emails. It does not, however, describe other side effects, permission requirements, or return behavior, leaving significant behavioral unknowns for a create operation.
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 sentences, no wasted words, front-loaded with the verb and resource. Effectively communicates the essential optionality without unnecessary detail.
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 14 parameters, 3 required, and no output schema, a brief description leaves gaps. It omits any mention of required fields, reminder settings, all_day, location, or event_type, which an agent would need to know for correct invocation. The schema provides some parameter descriptions, but the description alone is not comprehensive enough for such a complex tool.
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 semantic value for send_invites ('avoid emailing attendees'), eventable_type/eventable_id ('optionally attached'), and user_ids ('with user hosts'). With schema description coverage at 50%, many parameters (all_day, reminder_type, location_id, etc.) lack explanations in either the description or the schema, so the description only partially compensates.
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 creates an event/appointment and mentions optional attachments to a matter/contact and user hosts. This distinguishes it from other create-* tools in the sibling list (e.g., create-note, create-task, create-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?
Provides clear context that the event can be optionally attached to a matter/contact and can have user hosts, indicating typical use cases. However, it does not explicitly mention when not to use it or suggest alternatives, though no direct alternative event-creation tool exists in 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 provided, the description carries full behavioral burden, but it merely summarizes capabilities already present in the schema. It does not disclose additional traits such as return format, rate limits, or error behavior, and repeats information like 'optional filter, sort, and pagination' without adding value.
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 core action, and lists filter examples without fluff. Every word 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 schema richly documents all parameters, making the tool usable, but the description itself adds little beyond a quick summary. It omits return behavior (no output schema exists) and does not mention pagination details or the single-filter limit, though these are in the schema. Adequate but with gaps.
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 high (88%), so the baseline is 3. The description adds useful filter examples (done, due_date with operators, priority, matter_id, contact_id) that help the agent understand valid filter attributes and operator usage, going beyond the schema's generic descriptions.
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 that the tool lists tasks, with optional filtering, sorting, and pagination. It distinguishes itself from sibling list tools (list-matters, list-contacts) by the resource, and from create-task/update-task by being a read 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 on what the tool does (list tasks with options) and gives examples of useful filters. However, it does not explicitly mention when not to use it or point to alternatives, so it earns a 4 rather than a 5.
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 term 'List' implies a read-only operation, but with no annotations, the description alone carries the burden. It does not disclose pagination behavior, default limits, or potential edge cases like empty results. The schema covers fetch_all, but the description itself stays minimal.
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 conveys the primary purpose and output shape without any redundancy or irrelevant 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?
No output schema exists, so the description should convey return shape; it does so by mentioning label/value pairs and the linked matter. Pagination limits and ordering are absent, but for a simple listing tool the description is largely complete.
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 67%, so form_uuid and fetch_all are explained, but the 'page' parameter lacks a description and the tool description does not compensate. The description adds no semantic detail about parameters, though form_uuid is implied by 'for a custom form'.
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 ('List submissions'), identifies the resource ('custom form'), and adds output detail ('label/value pairs and the matter it created'). This distinguishes it from siblings like 'get-form' (which retrieves the form definition) and 'submit-form' (which creates submissions).
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 wording 'List submissions for a custom form' gives clear context for when to use the tool, implying it is for viewing entries rather than managing forms. However, it does not explicitly exclude alternatives or name related tools such as 'get-form' or 'list-forms'.
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 useful behavioral details such as inclusion of custom fields and related records, and specifically notes invoices are returned as {id, type} references. However, it does not mention error behavior, permissions, or other potential side effects, though for a read-only 'get' operation this is moderately adequate.
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, focused sentence that front-loads the action and object, then efficiently lists what is included. There is no redundant wording or 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?
Since there is no output schema, the description clearly enumerates the key return components (custom fields, related records, and the invoice reference format). It does not discuss the fields parameter's ability to reduce output or error scenarios, but for a single-resource GET tool with moderate complexity, it covers the essential 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?
Schema description coverage is 100%, so both parameters are already documented. The tool description does not add extra parameter semantics beyond what the schema provides; it primarily describes the response contents rather than parameter usage. Baseline 3 applies because schema carries the load.
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 'Get full details for a single matter by ID', which is a specific verb + resource + scope. It also distinguishes itself from sibling tools like list-matters (which lists all) and find-matter (likely search) by emphasizing 'single matter by ID'.
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 phrase 'for a single matter by ID' clearly implies this tool is for retrieving one known matter, in contrast to listing or searching. It does not explicitly name alternatives or exclusions, but the context is clear enough to guide usage.
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 usefully states that the tool is read-only and that amounts are integer cents, which helps interpretation. However, it does not disclose pagination behavior, API rate limits, or the single-filter limitation, though these are covered in the schema. The description adds some context but not extensive behavioral insight.
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: the first states purpose and read-only nature; the second lists useful filters and fields. Every sentence adds value, with no filler. The description is front-loaded with the primary action and distinguishes this tool from siblings immediately.
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 an 8-parameter tool with no output schema, the description is adequate. It covers the essential context (read-only, cents, useful filters/fields) while relying on the rich schema for parameter details. It does not describe the return structure beyond field mentions, but the schema's detailed parameter descriptions compensate. Slightly more behavioral guidance (e.g., pagination) would make it fully complete.
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 coverage is high (88%), so the baseline is 3. The description adds semantic context by calling out useful filters (status, due_at, matter_id) and notable fields (amount_cents, amount_paid_cents, outstanding_amount_cents, due_at, pdf_url). This enriches understanding beyond the schema but does not deeply explain parameter syntax or offer additional meaning not already in 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 begins with 'List invoices', a specific verb+resource, and adds 'read-only' to clarify the operation type. It clearly distinguishes from siblings by targeting invoices exclusively, while sibling tools target other entities like contacts, matters, etc.
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 this tool: when listing invoices. It also highlights useful filters (status, due_at, matter_id) which implicitly guide the user toward common use cases. No explicit exclusions or alternatives are given, but the resource specificity makes this unambiguous.
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 behavioral burden. It discloses that the search uses exact values, returns exactly one company ('best match'), and returns 'not_found' if no match exists. This is meaningful, though it doesn't detail how 'best match' is ranked or edge cases like case sensitivity.
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 concise two-sentence statement that front-loads the function and criteria. Every sentence adds value, with no filler or repetition.
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 find operation with fully documented parameters, the description covers the input method and the high-level output behavior (match or not_found). It does not specify the structure of the returned company object, but given the low complexity and no output schema, this is a minor gap and the description is largely complete.
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 100%: both 'by' and 'value' have descriptions. The tool description adds that the lookup is exact and that 'by' accepts email, phone, or name, matching the enum. This is a slight addition but not substantial beyond schema, 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 clearly states 'Find a single company by exact email, phone, or name' with a specific verb, resource, and criteria. It also distinguishes from sibling tools by specifying exact matching and single result, unlike list-companies or get-company.
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 gives clear context for when to use this tool: when you need a single company by exact email, phone, or name. It does not explicitly mention alternatives, but the exact-match criterion and 'single company' phrase imply distinct usage from listing or fetching by ID, which is evident from sibling names.
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. It discloses the key behavioral quirk that a filter is required, and frames the tool as a read-only audit trail. It does not mention pagination limits or response format, but those are partially covered by the schema's fetch_all description.
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 tool's purpose and immediately followed by a critical usage constraint. Every word earns its place with no redundancy.
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 list tool with no output schema, the description adequately covers the essential purpose and the required parameters. It omits return structure, but that is self-evident from the phrase 'list timeline activities'. The schema fills in pagination details via fetch_all.
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 coverage is 75% and already explains filter_by, filter_on, and fetch_all. The description reiterates the enum values for filter_by and clarifies filter_on, but adds little beyond the schema. It does not elaborate on page or fetch_all further.
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 timeline activities, and provides specific examples (notes, emails, stage moves) that distinguish it from sibling tools like list-notes or list-events. The verb 'list' plus the resource 'timeline activities' makes 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool (to view the full audit trail) and highlights a critical usage requirement: the API mandates filter_by and filter_on. It does not explicitly name alternative tools, but the scope is well-defined enough to imply appropriate use.
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. It does clarify a key limitation (definitions vs. values), which is useful. However, it omits other important behavioral aspects such as pagination behavior, filter constraints, and read-only implications, though some are present in schema descriptions.
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-loading the core purpose in the first sentence and a useful cross-reference in the second. There is no fluff or repetition; every sentence 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 list tool with 8 parameters and no output schema, the description provides the essential context: it lists definitions, outlines return fields, and redirects to other tools for values. The schema covers parameter nuances well, and the description is sufficient to guide correct use, though a bit more detail on response format would push it higher.
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 provides detailed descriptions for 88% of parameters, so the baseline is 3. The tool description adds no parameter-specific guidance, but the schema descriptions already cover filter operators, pagination limits, and field selection, so the description does not need to compensate.
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 the firm's custom field definitions and enumerates specific attributes (id, name, field_type, owner type, list options). It distinguishes this tool from sibling list tools by focusing on custom field definitions rather than matters, contacts, or other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs how to read custom field VALUES by adding 'custom_fields' to get-matter / get-contact / list-matters, making it clear this tool is for definitions, not values. This guides the agent on when to use this tool versus the alternatives.
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?
No annotations are provided, so the description carries the disclosure burden. It mentions the one-filter-per-request limitation and suggests pagination for date windows, which adds useful context. However, it does not discuss response format, rate limits, or any side effects, leaving some behavioral aspects 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 two sentences, front-loaded with the core purpose, and every clause adds value. The specific guidance about date range is concise and actionable without extraneous detail.
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 has 8 parameters, no required fields, no output schema, and no annotations. The description gives a key usage pattern and the schema covers parameter details. While it doesn't mention fetch_all, fields selection, or return values, the schema fills those gaps, making the overall context reasonably complete.
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 88% (high), so baseline is 3. The description adds value by tying filter_by, filter_with, start_date, sort_by, and pagination together into a concrete pattern, giving operational meaning beyond the schema's individual parameter descriptions.
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 events/appointments with optional filter, sort, and pagination. It uses a specific verb and resource ('List events'), and distinguishes from sibling tools like list-activities by specifying appointments.
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 a concrete usage scenario for date ranges: filter_by 'start_date' with filter_with '>=', sort by start_date, and paginate for windows. This gives clear context for when to use these parameters, though it does not explicitly discuss when not to use this tool or name alternatives.
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, but it only states 'List notes with optional filter, sort, and pagination.' It fails to mention important constraints like the 25-record page limit, 1,000-record cap, complete flag behavior, or the single-filter limitation. The matter_id example adds minor context but not enough for a mid score.
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 exactly two sentences. The first sentence front-loads the core purpose, and the second sentence provides a useful usage example. No words are wasted, and every sentence contributes.
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?
Although there is no output schema, the input schema's property descriptions thoroughly cover pagination, filtering, and fields. The description adds the matter_id example, making the tool reasonably complete for a listing operation. It falls short only because it doesn't summarize response behavior, but the schema compensates.
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 88%, setting a baseline of 3. The description adds semantic value by giving a concrete example of combining filter_by='matter_id' and filter_on=ID, which is not explicitly shown in the schema. This helps the agent understand how to apply the parameters together.
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 notes with optional filter, sort, and pagination. It also gives a specific example (filter_by='matter_id') that distinguishes it from other list tools like list-matters or list-contacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence provides explicit guidance on the common use case of listing one matter's notes, telling the agent exactly which filter_by and filter_on values to use. This effectively communicates when and how to use the tool, and since there is no get-note sibling, no alternative is needed.
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 is minimal and does not disclose behavioral details such as pagination behavior, filtering limitations, or response structure. Since no annotations are provided, the description carries the full burden, but 'List' does imply a read-only operation. It adds no extra context beyond what the schema already communicates.
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 succinct sentences: the first states the purpose, and the second provides a valuable cross-reference to list-matters. There is no wasted wording, and the most important information 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?
Despite lacking an output schema, the description is clear about the resource being listed and the alternative use case. The input schema covers the 8 parameters comprehensively, so an agent has sufficient context to invoke the tool correctly. A small deduction for not describing the response shape.
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 does not discuss any parameters, but the input schema has high coverage (88%) with detailed descriptions for most parameters. According to the guideline, high schema coverage yields a baseline of 3; the description adds no additional semantic value to 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?
Clearly states the action and resource with 'List marketing sources' and provides concrete examples (Google, referrals). It also distinguishes from the sibling list-matters by specifying that the latter is for source ROI reporting. This makes the tool's purpose unambiguous and distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides alternative usage: 'For source ROI reporting, use list-matters with filter_by: source_id.' This tells the agent exactly when to use this tool versus list-matters, enhancing decision-making.
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 full burden of disclosing side effects. It explicitly states that a contact is created by default, that match_contact_by falls back to creating a contact, and that missing tags are auto-created. This is strong behavioral transparency, though it doesn't mention details about permissions or 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 three sentences long and immediately front-loads the primary purpose. Each sentence earns its place by adding distinct behavioral or parameter context—no fluff or repetition. It is dense but well-structured.
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 tool with 14 parameters and no output schema, the description covers the most important behavioral nuances (contact handling, company matters, tags). It does not clarify that first_name and last_name are always required even for company matters, nor does it describe return values, but these are minor gaps given the richness of the schema and the focus on creation behavior.
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 79%, so the baseline is 3. The description adds meaningful semantics beyond the schema: it clarifies the precedence of contact_id over match_contact_by, explains the fallback matching behavior, indicates that tags are auto-created, and notes company matters via company_id/company_name. These enrich understanding beyond field-level descriptions.
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 'Create a new matter (lead)' which is a specific verb+resource statement that clearly distinguishes it from siblings like update-matter or list-matters. It also adds essential context about default contact creation and company matter variations, leaving no ambiguity about the tool's core function.
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 on when to use different parameters (contact_id vs match_contact_by vs company_id), which guides usage without explicit exclusions. However, it doesn't directly contrast with sibling tools like create-contact, so it falls short of an explicit 'when not to use this' statement.
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 of behavioral disclosure. It reveals return behavior ('Returns the best match or not_found') and exact-match semantics. It falls short of fully detailing potential errors or permissions, but for a simple lookup this is adequate.
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 sentences, no filler. The first sentence states purpose and return, the second provides an alternative. Information is front-loaded and 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 simple tool with 2 parameters and no output schema, the description covers purpose, return value, and distinction from fuzzy search. It does not explicitly differentiate from get-contact (likely ID-based), but this is a minor gap given the tool's straightforward nature.
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 coverage is 100% with clear descriptions for both 'by' and 'value', including an enum for 'by'. The description adds contextual context (exact matching) but does not add significant parameter-level meaning beyond the schema, so baseline 3 applies.
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 'Find a single contact by exact email, phone, or name' with a specific verb, resource, and scope. It distinguishes itself from sibling list-contacts by emphasizing 'exact' matching and 'single' result, and mentions the return value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'For fuzzy searches use list-contacts with filter_with: ilike and % wildcards.' This tells the agent when to use this tool versus an alternative, fulfilling the when/when-not requirement.
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?
No annotations exist, so the description must carry the transparency burden. It notes that stages reference their pipeline, but it does not explicitly state read-only behavior, pagination behavior, or other side effects. While 'List' implies non-destructive, the description offers limited behavioral detail beyond the schema.
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, front-loaded with the core action. Every word contributes meaning, with no redundancy or 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 tool is a straightforward list operation with well-covered input parameters. The description clarifies the stage-pipeline relationship and provides a usage pointer for counting, which is sufficient for common list-tool contexts. No output schema exists, but the description conveys the essential data shape (stages reference pipelines).
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 high (88%), so parameters are well-documented. The description adds value by tying the filter_by parameter to a concrete example (stage_id) and hinting at the pipeline reference, which helps the agent understand how to use filtering effectively.
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 'List all pipeline stages,' a specific verb+resource statement. It further distinguishes the tool from siblings by noting that each stage references its pipeline and explicitly pointing to list-matters for counting, clarifying what this tool does not do.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance for a common alternative use case: 'To count matters per stage, use list-matters with filter_by: stage_id.' This directly tells the agent when to choose a different tool, providing clear when-not-to-use guidance.
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. It discloses key side effects: creates a matter/contact and fires automations. It also clarifies the accepted key types and custom field format, reducing surprise. It does not mention permission requirements or idempotency, but the main behavioral traits are transparently disclosed.
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 efficient: two sentences front-load the core purpose, then add essential key-format details. No fluff or redundancy—every sentence 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 tool with 2 parameters and no output schema, the description provides the necessary context: what it does, what side effects occur, and how to format the data. It lacks only peripheral details like response shape or rate limits, but these are not critical for a form submission tool and are not required given the simple parameter structure.
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 100%, but the description adds considerable value beyond the schema. It explains the standard keys (first_name, last_name, email, phone), the custom_field_<id> format, and the accepted UTM parameters, giving agents precise guidance on how to structure the data object. This goes beyond the schema's generic 'Field values keyed by field ID.'
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 a specific verb ('Submit') and resource ('entry to a custom form'), and clearly differentiates from siblings by noting that it 'creates a matter/contact and fires the form's automations, exactly like a website submission.' This distinguishes it from direct matter/contact creation tools and read-only form tools.
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 gives clear context for when to use the tool (for custom form submissions triggering automations), and implicitly contrasts with direct entity creation. It also tells users where to find IDs ('from get-form or list-custom-fields'). However, it does not explicitly state when NOT to use it or name alternative tools for non-form-creation scenarios.
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 full burden. It explicitly states the tool retrieves the user associated with the access token, and 'cheapest way to verify the connection' implies a low-cost, read-only operation. While it doesn't mention side effects or permissions, the wording makes the behavioral intent clear.
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 with the main purpose front-loaded. No fluff or repetitive information. Every phrase adds value, including the secondary note about connection verification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, no output schema, and a simple purpose, the description is complete. It explains what the tool returns (the current user) and covers a common use case (connection check). Nothing essential is missing.
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 tool has zero parameters and the schema is empty, so the description cannot add parameter-level detail. The baseline of 4 applies because there are no parameters to explain, and the description appropriately focuses on the tool's purpose.
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 'Get the user the access token belongs to,' which is a specific verb + resource and distinguishes this from sibling tools like get-contact or get-matter. It also adds a secondary purpose (connection verification), but the main action is unambiguous.
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 phrase 'Also the cheapest way to verify the connection works' provides a clear context for when to use this tool—specifically for lightweight connection testing. However, it does not explicitly mention when not to use it or compare it to alternative tools, but for a unique getter this is sufficient.
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 and does well: it discloses fixed 25-per-page pagination, fetch_all cap at 1,000, the single-filter restriction, filter operators, currency in cents, and status meanings. It does not cover error handling or response shape, which is a minor gap.
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?
Three sentences, all dense with information. It is front-loaded with the core action, then filters, then a use case, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema or annotations, the description covers the main behavior, filter semantics, pagination, and a concrete aggregation scenario. Together with the detailed schema, an agent has enough context to invoke the tool 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 coverage is high (88%), so the baseline is 3. The description adds value by listing useful filter attributes and clarifying the single-filter constraint and status values, which are not fully explicit in 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?
Clearly states 'List matters' with categories in parentheses, identifies the resource (matters), and mentions optional filter, sort, and pagination. Distinguishes from sibling list tools like list-contacts and list-companies by focusing on matters.
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?
Provides a specific use case for pipeline reporting with filter_by, fields, and fetch_all, and lists useful filters and status values. However, it does not explicitly exclude alternatives like get-matter/find-matter, so it is clear but not fully conclusive.
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?
The description discloses that the tool returns the best match or not_found, which is critical behavioral context. Since no annotations are provided, this is the sole source of behavior, and it adequately covers the return behavior for a simple lookup.
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 three terse sentences, each with a distinct purpose: purpose, behavior, and alternative. No waste, and it's front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with no output schema, the description is complete: it covers the action, the return value, and the alternative. It also implicitly signals a read-only, non-destructive operation.
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 schema covers 100% of parameters, but the description adds the key 'exact' matching semantics and clarifies the relationship between the 'by' enum and the 'value' parameter. This goes slightly beyond the schema's terse descriptions.
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 finds a single matter by exact email, phone, or name, and explicitly distinguishes it from list-matters for fuzzy searches. The verb 'find' and the resource 'matter' are specific, and the scope (single, exact) is defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use this tool (exact single lookup) and when to use the alternative list-matters with ilike and wildcards for fuzzy or multi-result searches. This provides clear usage boundaries.
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:

[![lawmatics-mcp MCP server](https://glama.ai/mcp/servers/oktopeak/lawmatics-mcp/badges/card.svg)](https://glama.ai/mcp/servers/oktopeak/lawmatics-mcp)

Score Badge

Copy to your README.md:

[![lawmatics-mcp MCP server](https://glama.ai/mcp/servers/oktopeak/lawmatics-mcp/badges/score.svg)](https://glama.ai/mcp/servers/oktopeak/lawmatics-mcp)

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/oktopeak/lawmatics-mcp'

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