LACRM MCP Server

Server Quality Checklist

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

Latest release: v1.9.1
Disambiguation4/5
Most tools have clearly distinct purposes, but the sheer number of tools and overlapping retrieval patterns (e.g., get_pipeline_custom_fields vs get_custom_fields with pipeline filter, search_* vs get_*_attached_to_contact) create some potential for misselection. Descriptions are detailed enough to resolve most ambiguity.
Naming Consistency4/5
The naming convention is overwhelmingly consistent: snake_case verb_noun (create/edit/delete/get/search) with resource names. Minor deviations like the bulk_* prefix and compound suffixes (e.g., _attached_to_contact, _in_group) are predictable and readable, so the overall pattern is strong.
Tool Count1/5
With 88 tools, this is an extreme number for an MCP server, even considering the broad CRM domain. Many tools are convenience wrappers (e.g., get_X_attached_to_contact vs search_X) and schema/guide tools could be consolidated, making the surface feel bloated.
Completeness4/5
The tool set provides extensive CRUD coverage for contacts, companies, pipelines, statuses, notes, tasks, events, emails, groups, teams, custom fields, webhooks, and relationships. Notable minor gaps include no delete_file and no global file search, but core workflows are fully supported.
Average 4.2/5 across 88 of 88 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 31 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 only states the basic action and does not mention pagination behavior, default limits, error handling, or what happens when a contact has no groups. The description is too sparse for a tool with pagination parameters.
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 communicates the core function with no wasted words. It is appropriately concise for the tool's simplicity.
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 is complete, but the description lacks behavioral and usage context. The tool is relatively simple, so the minimal description might suffice, but the absence of any notes about pagination or error behavior leaves gaps for an agent trying to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of all three parameters, each with a clear description. The tool description adds no additional parameter meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves groups for a contact, with a specific verb and resource. However, it does not explicitly distinguish itself from sibling tools like get_contacts_in_group (the inverse operation) or get_groups (all groups), so it gets a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Given the many related sibling tools, the description offers no context for choosing get_groups_for_contact over get_contacts_in_group or get_groups, resulting in no usage direction.
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 must carry the behavioral burden. It includes a warning that pipeline items may become orphaned, which is valuable side-effect information. However, it omits other relevant details such as reversibility, permission requirements, or what happens to existing items that reference the status.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences: the first states the action, the second an important warning. No filler or redundant content; 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?
For a simple one-parameter destructive operation, the description provides the essential action and a key warning. However, it does not explain what 'orphaned' means, whether there is any undo, or how to prevent the side effect, leaving gaps for safe autonomous 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 covers the single parameter status_id fully with its own description. The tool description adds no additional meaning about the parameter, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it deletes a pipeline status, which is a specific resource and action. It distinguishes from sibling tools like delete_pipeline or delete_pipeline_item by naming the exact entity, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The warning about orphaned items hints at a consequence but does not explain when deletion is appropriate or what preparatory steps might be needed.
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 bear the full burden of behavioral disclosure. It only says 'Update an existing group's properties' without addressing error handling, whether unspecified fields are preserved or replaced, permission requirements, or return values. This is a significant omission for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the operation and immediately followed by a prerequisite. It is concise, avoids redundancy, and every word contributes to understanding the tool.
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 no output schema and no annotations, yet the description doesn't mention what the response looks like or confirm success/failure behavior. It covers the essential purpose and ID lookup but leaves out mutation semantics like partial vs. full update. For a simple group property update, this is a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all five parameters, so the schema already documents them adequately. The description adds value by pointing to get_groups for obtaining group_id, but it doesn't enrich the meaning of name, color, sharing, or team_ids beyond the schema's labels.
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 an existing group's properties', identifying the action (update) and resource (group). It differentiates from sibling tools like create_group, delete_group, and get_group by focusing on modification of an existing group. However, it doesn't explicitly list which properties are updatable beyond what the schema shows.
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 instruction 'Use get_groups to find group IDs first' provides a clear prerequisite and workflow context, implying the tool edits existing groups. It doesn't mention alternatives like add_contact_to_group for membership changes, but the given guidance is sufficient for the core use case.
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 convey behavioral traits. It clarifies that only the note is updated and that the relationship must already exist, but it omits what happens if the relationship_id is invalid, whether the operation is idempotent, whether it returns anything, and any permission or side-effect information. This is a mutation tool with minimal disclosure.
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-loaded with the action and resource. It is concise with no wasted words, every sentence 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?
For a simple 2-parameter update tool, the description covers the core purpose and parameters. However, it lacks guidance on when to use it relative to other relationship tools, and it does not describe return values or error behavior. Given no output schema and no annotations, it falls short of being 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 description coverage is 100%, so the baseline is 3. The description adds some context for the note parameter ('describes the nature of the relationship between contacts'), which slightly enhances the schema's 'Updated relationship description', but it does not add significant meaning beyond what the schema already 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 clearly states the action ('Update'), the resource ('note on an existing relationship'), and the scope ('existing relationship'). It distinguishes itself from sibling tools like create_relationship, delete_relationship, and get_relationship by specifying exactly what is being edited.
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 usage is implied: use when needing to change the note on an existing relationship. However, it does not explicitly state when not to use this tool or mention alternatives, such as using create_relationship for new relationships or get_relationship for reading. No exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it adds useful context about the 'is_active' parameter and valid colors, it does not disclose behavioral traits such as whether the operation requires special permissions, whether it is reversible, what happens if the pipeline does not exist, or what response to expect. For a create operation, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise, using a brief opening sentence and bullet points for clarifying 'is_active' and 'Colors'. It avoids unnecessary fluff and communicates necessary parameter guidance efficiently. A minor inefficiency is that the color list could be considered a bit long, but it is valuable reference material.
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 that this is a simple create operation with no output schema and no annotations, the description adequately covers the core purpose and parameter semantics. However, it lacks usage guidance (e.g., prerequisites like the pipeline existing) and does not mention expected return value or side effects. It is a minimal viable description but with clear gaps in usage and behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all four parameters with baseline descriptions, but the tool description adds meaningful value by explaining the semantics of 'is_active' in the context of pipeline workflow stages and by enumerating valid color options, including named colors and hex code format. This goes beyond the schema's simple 'Active status (true) or closed status (false, default)'.
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 function: 'Create a new status for an existing pipeline.' It uses a specific verb ('create') and resource ('status for an existing pipeline'), and further clarifies that statuses represent workflow stages. This distinguishes it from sibling tools like edit_pipeline_status, delete_pipeline_status, and get_pipeline_statuses.
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 (when adding a stage to an existing pipeline) but provides no explicit guidance on when not to use it or how it compares to alternatives. It doesn't mention, for example, that editing or deleting statuses should use the respective sibling tools. This is implied context rather than explicit instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'Update an existing pipeline's configuration.' It does not disclose whether partial updates are allowed, what permissions are required, or what the response looks like. This is minimal disclosure for a mutation 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, front-loaded with the core action, and contains no wasted words. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with full schema coverage, the description is adequate but lacks behavioral context such as side effects, return values, or permission requirements. With no annotations or output schema, it could be more 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% — every parameter has a clear description. The description adds no extra semantics beyond the schema, but the schema already does the heavy lifting, so the 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 'Update an existing pipeline's configuration' with a specific verb and resource, distinguishing it from sibling tools like create_pipeline, delete_pipeline, and get_pipeline.
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 prerequisite guidance: 'Use get_pipelines to find pipeline IDs first.' This tells the agent when to use a related tool for preparation, though it doesn't explicitly mention when not to use this tool.
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 bears the transparency burden. It provides useful behavioral details such as requiring an options array for Dropdown/RadioList/Checkbox fields and pipeline_id for pipeline fields. However, it does not describe side effects, permissions, return values, or error conditions, which are important 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. The field types list is somewhat redundant with the schema enum but provides a quick reference. Each sentence serves a purpose, and there is minimal fluff.
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 9 parameters and no output schema or annotations. The description covers the core use case and conditional requirements but omits information about the response format, permissions, or potential errors. While it is adequate for a create operation, it lacks completeness in explaining the tool's full behavior.
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 parameters are well-documented. The description adds minimal extra semantics by clarifying the conditional requirements for options and pipeline_id, but this largely duplicates the schema descriptions. No additional insight is given for other parameters like is_required or show_on_report.
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 a new custom field definition and specifies the resources (contacts, companies, pipelines). It distinguishes itself from sibling tools like edit_custom_field and delete_custom_field by focusing on the 'new' creation aspect.
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 this to add new fields for contacts, companies, or pipelines,' providing clear context for when to use it. However, it does not explicitly mention alternative tools for editing or deleting custom fields, so it lacks a direct when-not-to-use 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 provided, the description carries the full burden of behavioral disclosure. It includes an explicit warning: 'WARNING: This permanently removes the email record,' which is a crucial destructive trait. However, it does not mention other behaviors like permissions, cascading effects, 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 two sentences, with the warning front-loaded for visibility. Every sentence earns its place; no redundancy or unnecessary 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?
For a simple delete tool with one parameter and no output schema, the description is mostly complete. It states what the tool does, the target resource, and the permanent consequence. It lacks error conditions or post-deletion behavior, but the low complexity makes this acceptable.
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%, and the input schema already documents 'email_id' as 'The EmailId to delete.' The tool description adds no additional parameter semantics, but the schema fully covers the single parameter, so 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 uses a specific verb and resource: 'Delete a logged email from a contact's profile.' It clearly identifies the action and scope, distinguishing it from sibling tools like delete_event or delete_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or comparison with other email-related tools (e.g., search_emails, get_email).
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 discloses the critical destructive behavior: permanently removes the pipeline configuration and may orphan pipeline items. This goes beyond a simple statement of deletion and warns of irreversible side effects, though it doesn't detail error handling or response 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 three short sentences, front-loaded with the action, followed by a concise warning. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter, the description includes the essential purpose and the key risk, making it sufficiently complete. It doesn't cover alternatives, but given the simplicity and the warning, it serves the agent well.
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 covers the single parameter fully with a clear description ('The PipelineId to delete'). The tool description adds no additional meaning beyond the schema, so 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 uses a specific verb+resource ('Delete a pipeline') and clearly indicates scope ('from the account'). Among many sibling delete tools, it unambiguously targets pipeline, distinct from delete_pipeline_item or delete_pipeline_status.
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 on when to use this tool versus alternatives, prerequisites, or any exclusion criteria. The warning about permanent deletion provides caution but not decision 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 provided, the description carries the full burden of disclosing behavior. It adds a key behavioral consequence: the webhook will stop sending events immediately. However, it does not mention irreversibility or other side effects, but the immediate-stop detail provides meaningful transparency beyond the basic delete action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary action, and the second sentence adds a valuable behavioral detail. There is no redundant or unnecessary text.
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 one-parameter delete tool with no output schema, the description is largely complete. It states the action and the immediate effect, which covers the main concerns. However, it could mention irreversibility or error behavior, but given the simplicity, this is a minor gap.
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% for the single parameter (webhook_id), so the schema already provides full meaning. The description does not add extra parameter details, but the baseline for high coverage is 3, which 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 ('Delete') and the resource ('a webhook from the account'), distinguishing it from sibling tools like get_webhook or create_webhook. 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 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, nor any mention of prerequisites or cautionary notes. The usage is only implied by the tool's name and description, not explicitly stated.
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 transparency burden. It discloses the temporary URL expiration and advises re-calling for a fresh URL, adding meaningful behavioral context beyond the schema. It also lists the returned metadata fields.
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 short sentences that front-load the core action and include a clear operational note. Every sentence 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 simple single-file retrieval with one parameter, the description covers purpose, return fields, and the key expiration behavior. Although there is no output schema or annotations, the description compensates adequately.
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%: the single parameter file_id is already described as 'The FileId to retrieve.' The description adds no further parameter-level meaning, so the baseline score of 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 the tool retrieves file information and a temporary download URL, using a specific verb and resource. It distinguishes itself from listing tools like get_files_attached_to_contact by focusing on a single file retrieval.
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 explicit guidance on when to use this tool versus alternatives, nor any mention of sibling tools or exclusion criteria. The note about URL expiry is operational guidance, not selection 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 carries full responsibility for behavioral disclosure. It states the mutation action but does not mention side effects, irreversibility, required permissions, or error conditions. For a mutating tool, this leaves significant gaps in behavioral understanding.
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 two short, front-loaded sentences. The first sentence states the core action, and the second provides essential parameter usage guidance. No extraneous information or repetition of schema details exists; 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?
Given the simplicity of the tool (3 parameters, no output schema, no enums) and the minimal annotations, the description is largely sufficient. It covers the purpose and the key parameter interaction. However, for a mutation tool without any behavioral disclosures (e.g., what happens if the contact is not in the group), it could be slightly more complete by noting typical outcomes or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% parameter coverage with individual descriptions. The description adds meaningful cross-parameter semantics by explicitly stating that group_id and group_name are mutually exclusive alternatives ("not both"), which is not present in the schema. This extra guidance improves parameter understanding beyond the structured 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?
The description clearly states the tool's action: "Remove a contact from a group in Less Annoying CRM." This is a specific verb+resource that immediately distinguishes it from sibling tools like add_contact_to_group. The additional guidance about group_id vs group_name further clarifies the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (for removing a contact from a group) but does not explicitly contrast with alternatives or provide when-not-to-use scenarios. The only guideline given is the parameter selection rule ("use either group_id or group_name, not both"), which is more about parameter usage than tool selection compared to siblings.
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 full burden. It discloses the key side effect: 'The email is attached to the specified contacts' history.' However, it does not mention whether the email is actually sent, how the system handles invalid contact IDs, or what the response looks like. Minimal but adequate for a logging action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place. It front-loads the main action, provides a usage rationale, and lists required parameters compactly. No redundant or filler 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, nested objects, and no output schema. The description clearly explains the core function and side effect, but does not mention return values, error handling, or the exact nature of the 'log' (e.g., whether it sends or just records). With no output schema, the agent lacks information about expected response. Not fully complete but reasonable for a create tool with a thorough schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description lists required parameters, but this duplicates the schema's required array. It adds some context by explaining that the email is attached to contacts' history, but does not elaborate on parameter specifics beyond the schema. No significant added meaning.
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 logs an email in Less Annoying CRM, using the specific verb 'Log' and the resource 'email'. It distinguishes itself from sibling email tools (e.g., get_email, search_emails, delete_email) by focusing on recording correspondence for tracking, not retrieving or deleting.
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 this to record email correspondence with contacts for tracking purposes', providing clear context for when to use the tool. It does not explicitly mention alternatives or exclusions, but the purpose is sufficiently distinct from siblings to guide the agent.
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 burden of behavioral disclosure. It explains that tasks are reminders appearing on task lists and daily agenda emails, and that tasks are date-only. However, it does not disclose return behavior, permissions, or side effects, which are relevant 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five sentences and front-loads the core purpose. Every sentence contributes useful context—task behavior, differences from events, required/optional parameters, and lookup tool references. It is concise but not terse, and no filler words are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no annotations, and no output schema, the description provides solid context: it explains what tasks are, when to use them, required vs optional fields, and how to find correct IDs. It omits return value details and error conditions, but for a simple create operation with a well-specified schema, it is sufficiently 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%, so the baseline is 3. The description adds limited extra meaning by clarifying that contact_id links to a contact and that assigned_to defaults to the caller (the latter also appears in the schema). It doesn't substantially enrich the parameter semantics beyond what the schema already 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 opens with 'Create a new task in Less Annoying CRM,' using a specific verb and resource. It distinguishes tasks from events ('Unlike events, tasks are date-only') and implicitly from notes and other entity types, making it clearly differentiated from sibling 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 states the required parameter ('Required: name') and key optional parameters, and explicitly directs users to get_users and get_calendars for valid IDs. It also contrasts tasks with events to guide tool selection, though it doesn't explicitly name create_event as the alternative.
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 key behaviors like returning full task data and count_only behavior, but fails to mention pagination details, max_results defaults, or mutual exclusivity of user filters, which are relevant for invocation.
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 concise and front-loaded, with a clear primary action and supporting details. It uses bullet-like emphasis for key behaviors, but some statements are redundant with the schema (e.g., required fields, completion status options), which could be trimmed without losing value.
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 10-parameter tool with no output schema, the description covers essential invocation aspects: required parameters, filters, return behavior, and count_only. It omits pagination and max_results defaults, but these are documented in the schema, so the description is sufficiently complete for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 90%, so the baseline is 3. The description adds minimal extra meaning beyond the schema: it repeats completion_status enums and count_only behavior, and only slightly clarifies user_name_filter over user_filter. The schema itself already explains case-insensitivity and mutual exclusivity, so the description doesn't significantly enhance parameter understanding.
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 'Search for tasks within a date range' and enumerates supported filters (date, user, contact, completion status). It distinguishes itself from siblings by explicitly noting 'no need to call get_task afterward', which sets it apart from the related get_task 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 context for when to use this tool ('Use this tool to find tasks by...') and offers an explicit alternative exclusion: 'no need to call get_task afterward'. It also gives guidance on count_only for large datasets, but lacks comprehensive when-not-to-use scenarios beyond the get_task comparison.
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 states the action without disclosing behavioral traits such as idempotency, error handling when the contact is already in the group, permissions required, or any return value. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core action, followed by essential usage constraints. Every sentence earns its place, with no unnecessary elaboration 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 tool with three parameters and no output schema, the description covers the action, parameter usage, and prerequisite lookup. It does not explain behavior when both group_id and group_name are supplied, but the instruction 'not both' implies this is invalid, making the description mostly 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 description coverage is 100%, so the baseline is 3. The description adds value by clarifying the mutually exclusive relationship between group_id and group_name and by indicating where to find valid group IDs via get_groups, which is not fully captured in the schema's individual property 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 'Add a contact to a group' with the specific CRM context, using a specific verb and resource. It distinguishes from sibling tools like remove_contact_from_group and get_contacts_in_group by its action, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on parameter usage: use either group_id or group_name (not both), and directs users to get_groups for valid group IDs. It lacks explicit exclusions or alternatives, but the context is clear enough for proper tool selection and invocation.
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 adds useful traits like attaching events to contacts, assigning to calendars, and supporting RFC 5545 recurrence rules. However, it does not mention potential side effects (e.g., notifications), error behavior, or success response, leaving some ambiguity 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for purpose, requirements, and additional features. It is not overly verbose, and each sentence contributes meaning. It could be slightly more concise by removing the generic 'Use this tool...' opening, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 11 parameters, no annotations, and no output schema, the description covers the essential context: prerequisites, helper tools, and recurrence support. However, it does not mention what the response looks like after creation or any error conditions, which might be valuable for a create operation. Still, it is adequate for a straightforward creation tool.
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 100%, so baseline is 3. The description adds value by flagging required parameters and directing users to get_calendars and get_users for valid calendar and user IDs, which enriches the semantics of calendar_id and attendees beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a calendar event in Less Annoying CRM' with a specific verb and resource, and distinguishes it from sibling tools like edit_event and delete_event by focusing on creation. It also clarifies the intended use case (scheduling meetings, calls, time-specific activities).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool ('schedule meetings, calls, or other time-specific activities') and explicitly points to get_calendars and get_users for finding valid IDs, which is useful guidance. However, it does not explicitly state when NOT to use it (e.g., for tasks) or name 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?
Since no annotations are provided, the description carries the full burden for behavioral disclosure. It does explain the visibility semantics for Public, Private, and Teams sharing, and notes that Teams requires team_ids. However, it omits other behavioral aspects such as authentication requirements, return value, or error handling, leaving some uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, opening with the core purpose. The sharing options are formatted as a clear, scannable list, and every sentence adds value without redundancy. It is appropriately sized for the tool's complexity.
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 having no output schema, the description explains the key domain-specific concept of sharing visibility and the dependency on team_ids, covering the main decision points. It could mention what the created group object looks like, but for a simple create operation this is not essential. The description is largely self-sufficient.
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 of all four parameters, so the baseline is 3. The description adds meaning by elaborating the sharing enum values and clarifying that Teams requires team_ids, which is helpful. For name and color, the description does not add beyond the schema's own 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 begins with 'Create a new group in Less Annoying CRM,' clearly stating the specific verb, resource, and system. It distinguishes from sibling tools like edit_group, delete_group, and get_group, and adds context about groups being used to segment contacts. This is a precise, non-tautological purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that groups are used to segment contacts for easy retrieval, implying when creation is appropriate. It also details the sharing options and their visibility, which helps the agent choose the right configuration. However, it does not explicitly mention when not to use this tool or contrast it with alternatives like edit_group or add_contact_to_group.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action and a brief note about teams, but omits details such as permissions required, idempotency, failure modes, or what is returned upon success. This is minimal transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, each serving a purpose: stating the action, explaining the context, and providing a practical tip. No fluff or repetition, making it highly scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with two parameters and no output schema, the description covers the core purpose and provides a relevant prerequisite. It lacks some details about expected response or permissions, but given the low complexity and complete schema, it is adequately 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 100% with descriptions for both 'name' and 'user_ids'. The description adds extra value by telling the user to call get_users first to obtain user IDs, which is not in the schema. This supplemental guidance goes beyond the schema's basic field 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's function with a specific verb and resource: 'Create a new team in Less Annoying CRM.' It also clarifies the resource's purpose (organizing users for permission management) and is distinct from sibling tools like edit_team, delete_team, get_team, and get_teams.
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 a useful usage hint by instructing to 'Use get_users first to find user IDs for team membership,' which directly supports the optional user_ids parameter. It does not explicitly mention exclusions or when not to use this tool, but the context is clear enough for a create operation.
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 the full burden. It explicitly warns that the deletion permanently removes the item, which is critical irreversible-destruction context. It does not mention auth, cascading effects, or error behavior, but the permanence warning covers the most important behavioral trait for a delete 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 extremely concise: two sentences plus a required-field note, with the warning placed prominently. Every part contributes value, and the structure is clean and 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?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description adequately covers the action, permanence warning, and required parameter. It does not mention the bulk alternative or error/return details, but for this simple delete operation those are not essential.
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% and the schema already describes pipeline_item_id as 'The PipelineItemId to delete'. The description repeats that it is required but adds no extra semantic meaning beyond the schema, so the baseline score of 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 the verb (Delete), resource (pipeline item), and scope (single, from Less Annoying CRM). The 'single' qualifier effectively distinguishes this tool from the sibling delete_pipeline_items_bulk.
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 'single' wording implies usage for deleting exactly one item, hinting at the existence of a bulk alternative. However, there is no explicit statement of when to use this vs. delete_pipeline_items_bulk or other delete tools, so guidance remains implicit.
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 behavioral disclosure. It clearly explains what the tool returns (field names, required, type, input_format, valid_options) and how to use those results. It does not cover edge cases like pagination or error behavior, but the core behavior is well disclosed.
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 well-structured with clear sections for important return fields, filter options, and an example. It is a bit longer than strictly necessary, but every section serves a purpose and the key 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?
There is no output schema, so the description appropriately explains the return value details. It also covers usage context through the example. It does not explicitly state the default behavior when no filters are supplied, but this is strongly implied by the phrasing 'filter options.'
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all three parameters with good descriptions. The tool description adds meaningful extra context, such as pipeline_id being required when record_type is 'Pipeline' and how field names should be used as keys in custom_fields. This goes beyond the schema's baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves custom field definitions for the LACRM account, with a specific verb and resource. However, it does not explicitly distinguish itself from the sibling tool get_pipeline_custom_fields, so it falls just short of a perfect score.
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 to use this tool FIRST when working with custom fields, and provides a concrete example for creating pipeline items. It does not mention when not to use it or name alternative tools, so it lacks the full exclusion/alternative guidance needed for a 5.
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 burden of behavioral disclosure. It explicitly states the tool retrieves 'all' files, optionally includes previous versions, and excludes File Link custom fields. This gives useful scope boundaries, though it does not mention pagination, ordering, or response format, which would make it more complete.
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 plus a note. The first sentence states the core purpose, the second adds the optional parameter, and the note clarifies an important exclusion. No wasted words; every clause 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 2-parameter read-only tool with no output schema and no annotations, the description covers the main purpose, the optional parameter, and a key limitation. It lacks mention of pagination or return value details, but the essential context for using the tool is present. Given the simplicity, this is adequate.
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 documents both parameters fully (contact_id and include_versions with descriptions). The description restates the include_versions option but adds no new parameter syntax or nuance beyond the schema. Baseline 3 applies due to 100% 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 opens with 'Retrieve all files attached to a specific contact,' which specifies the action (retrieve) and resource (files for a contact). It clearly distinguishes from sibling tools like get_file (single file) and other attached-to-contact tools (emails, notes) by focusing on files, and adds the optional versions behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the name and description: use when you need files attached to a contact. The note about excluding File Link custom fields gives a limitation but does not explicitly state when to use this tool vs alternatives or name any alternative. There is no direct contrast with sibling tools like get_file or search, so guidance is moderate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the burden of disclosing behavior. It clearly states the return payload (both contact IDs, note, metadata), which is helpful. However, it does not describe error behavior, authentication requirements, or any side effects; for a read-only 'get' tool, this is acceptable but not exhaustive.
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, front-loaded with the primary action and followed by a brief return summary. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter get tool with no output schema, the description covers the core purpose and return contents. However, it omits information on error responses and does not explain how the response is structured beyond vague 'metadata'. Adequate but not deeply detailed.
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 sole parameter relationship_id is fully described in the schema (coverage 100%), and the description does not add any additional meaning, context, or format expectations beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') and resource ('specific relationship'), clearly distinguishing it from sibling tools like get_relationships_attached_to_contact (list) or edit_relationship. It also previews the response contents, leaving no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single relationship's details but does not provide explicit when-to-use guidance or mention alternatives such as get_relationships_attached_to_contact for listing multiple relationships. Lacks exclusion criteria or a comparison to sibling tools.
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 burden. It discloses that the tool returns all contacts linked to the contact with their relationship notes, clarifying the return shape. However, it does not address pagination behavior, potential authentication requirements, or edge cases, leaving some behavioral aspects unspecified.
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, concise and front-loaded with the action. No redundant information beyond the necessary clarification of the return value.
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 no output schema, so the description compensates by explaining the return value. It clearly states what the tool returns. Given the simplicity of the tool and the schema coverage, the description is nearly complete, though it omits pagination context which is already in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all three parameters with clear descriptions (contact_id, page, max_results). The tool description adds no additional parameter semantics beyond what the schema already provides. With 100% schema coverage, 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 uses the specific verb 'Retrieve' and identifies the resource 'relationships for a specific contact', clarifying it returns linked contacts with relationship notes. This clearly differentiates it from sibling tools like get_relationship (singular) and create/delete relationship 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: use when you need all relationships for a specific contact. It does not explicitly name alternatives or exclusions, but the contact-scoped wording implies the use case. Not a 5 because it lacks explicit when-not-to-use or alternative naming.
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?
There are no annotations, so the description carries the burden of disclosure. It states the tool returns specific fields, which implies a read-only, non-destructive operation. However, it does not explicitly disclose permissions, error behavior, or what happens if the team does not exist. The return info is helpful but 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 two short sentences that immediately state the verb and resource, then enumerate what is returned. Every word contributes value; there is no fluff 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 read tool with one parameter and no output schema, the description is adequately complete: it names the resource and the specific return fields. It does not explain error handling or edge cases, but for a getter of this simplicity, that is not a significant gap. A perfect score would require explicit notes on not-found behavior or authentication.
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% (team_id is described as 'The TeamId to retrieve'), so the schema already fully documents the parameter. The description adds no additional parameter-specific semantics beyond 'single team', which is already captured by the name. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Get detailed information about a single team'), clearly distinguishing it from the sibling tool get_teams (plural). It also lists the specific data returned (name, creation date, member user IDs), which makes the tool's 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 clearly implies usage: when you need a single team's details by ID. It does not explicitly state an alternative for listing teams, but the sibling name get_teams provides that contrast. There are no exclusions or prerequisites, but the context is clear enough for an agent to decide when to use this tool.
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?
Since no annotations are provided, the description carries the full burden for behavioral disclosure. The verb 'Get' implies a read-only operation, and the optional archived parameter is mentioned, but there is no explicit statement about being non-destructive, pagination, or other side effects. Minimal extra value beyond what 'Get' and the schema already convey.
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 with no filler. Every word adds meaning: 'all webhooks', 'on the account', and 'optionally include archived'. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one optional boolean parameter, no output schema, no nested objects), the description is sufficient. It states the action and the one option, which is enough for an agent to invoke correctly. A slightly richer note about return format could push to 5, but it's not necessary here.
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% (the only parameter has a description). The description's mention of 'include archived webhooks' adds no meaningful information beyond the schema's own description, so 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 uses a specific verb ('Get') and clearly identifies the resource ('all webhooks on the account'), which distinguishes it from the sibling tool 'get_webhook' that retrieves a single webhook. The phrase 'on the account' adds scope clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this is for listing all webhooks, with an optional flag to include archived ones. It does not explicitly mention when to use an alternative like 'get_webhook', but the context of 'all' makes the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
WARNING explicitly states permanent removal from all attendee calendars, which is critical destructive behavior. No annotations are provided, so the description carries the transparency burden; it covers the main side effect but does not mention error cases or idempotency.
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 short sentences with a clear warning and required parameter; every sentence earns its place with no fluff.
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 single-parameter delete tool, the description covers the purpose, permanent effect, and required input. It omits return/error behavior, but with no output schema and a low-complexity operation, this is complete enough.
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 covers event_id with 100% coverage and description simply repeats 'Required: event_id', adding no extra meaning beyond the schema's 'The EventId to delete'.
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 uses specific verb 'Delete' and resource 'calendar event from Less Annoying CRM', clearly distinguishing from sibling tools like create_event, edit_event, and search_events.
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 this versus alternatives like edit_event or search_events. The context of deleting is implied but lacks exclusions or alternative mention.
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?
Since no annotations are provided, the description carries the full burden of disclosing behavioral traits. It does add value by explaining name-based resolution and the need for prerequisites, but it does not mention return behavior, side effects, permissions, or whether automation runs by default. This leaves some ambiguity for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a numbered prerequisites list, a concise use statement, and a short note about name resolution. Every sentence contributes useful context without unnecessary fluff 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?
Given the tool's complexity (8 parameters, nested objects, no output schema, no annotations), the description covers prerequisites and usage well. However, it omits any mention of return values or potential side effects, and does not clarify behavior like automation triggering beyond what the schema already states, leaving some gaps for an agent to infer.
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?
Input schema has 100% coverage, so the baseline is 3. The description adds meaningful parameter guidance beyond the schema by emphasizing the state_name/status_id and custom_field_names/custom_fields resolution strategy, and specifies when pipeline_id is required. This helps the agent choose the right parameter combination.
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 starts with a specific verb and resource: 'Update an existing pipeline item in Less Annoying CRM.' It clearly distinguishes from sibling tools like create_pipeline_item, delete_pipeline_item, and get_pipeline_item by explicitly stating the intended uses: 'change status, add notes, or update custom field values.'
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 prerequisites with exact tool names to call first, and states when to use this tool ('Use this to change status, add notes, or update custom field values'). However, it does not explicitly provide when-not-to-use guidance or name alternatives, relying instead on implicit contrast with sibling tools.
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 transparency burden. It clearly signals a read operation via 'Retrieve' and adds a useful behavioral note that search_pipeline_items returns the same full data, but it does not disclose output format, error handling, or ID formatting constraints. This is adequate but not rich.
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 three short sentences. The first states the core purpose, and the subsequent sentences give usage guidance. The note is useful but slightly overlaps with the previous sentence ('need the record' vs. 'have an ID but not the data'), yet overall it is tight and 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 simple one-parameter read operation with no output schema, the description covers what, when, and when not to use the tool. It does not explicitly describe return values, but the verb 'Retrieve' and the note about search returning full data imply the record is returned, making this nearly 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 documents pipeline_item_id as 'The PipelineItemId to retrieve' with 100% coverage. The description's 'by ID' adds no new semantic meaning beyond the schema, so the baseline 3 for high schema coverage 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 opens with a specific verb and resource: 'Retrieve a single pipeline item by ID.' It clearly defines the tool's scope and distinguishes it from the sibling search_pipeline_items by noting when the ID-based lookup is appropriate.
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 states when to use the tool ('when you already have a PipelineItemId and need the record') and when not to use it ('only use get_pipeline_item when you have an ID but not the data'), and it names the alternative search_pipeline_items.
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 burden of behavioral disclosure. It states the tool returns specific fields (endpoint URL, last send date, subscribed events, archive status), which indicates a read-only operation. However, it does not explicitly confirm non-mutating behavior or describe error handling for invalid IDs.
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 contains no wasted words. It efficiently conveys what the tool does and what it returns.
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 read operation with one parameter and no output schema, the description is complete. It enumerates the returned fields and clearly indicates the parameter needed, making it sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, as webhook_id is described in the schema. The description adds minimal meaning beyond 'single webhook' but does not provide additional parameter syntax or format details. Baseline of 3 is appropriate given the schema already documents the parameter.
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 gets detailed information about a single webhook, using the specific verb 'Get' and identifying the resource. It also distinguishes itself from the sibling tool get_webhooks by specifying 'single webhook'.
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 for retrieving one specific webhook, which provides clear context. However, it does not explicitly name alternatives or state when not to use this tool, such as referencing get_webhooks for listing all webhooks.
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 behavioral traits: results include all event fields, count_only auto-paginates and returns only counts/breakdowns, and filters can be applied by various criteria. It does not mention authentication, rate limits, or the behavior when no filters are supplied, but for a search tool it covers the most relevant runtime behavior.
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 well-structured: a clear opening statement, a bold 'RETURNS FULL DATA' section, a bulleted list of filter types, and a concise tip about count_only. It is slightly longer than strictly necessary but each section serves a distinct and useful purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 optional parameters, no annotations, and no output schema, the description does a good job covering filtering categories, full-data return, and count_only behavior. It does not clarify what happens when no filters are provided (e.g., returns all events) or explain pagination/sort defaults, but these are partly covered by schema parameter descriptions.
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 91% of parameters, including mutual exclusions, case-insensitive name filters, and default/max values. The description adds a high-level grouping of filters and calls out count_only, but it largely restates what the schema already explains, so it adds limited extra parameter meaning.
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 'Search for calendar events within a date range,' a specific verb+resource+scope statement. It clearly distinguishes itself from get_event by explicitly stating that the returned data is full and no subsequent get_event call is needed, making the search tool's purpose and advantage over its sibling clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance: 'Use this tool to find events by date, user, calendar, or contact' and recommends count_only=true for large datasets. It also implicitly differentiates from get_event by saying no follow-up call is needed, but it does not explicitly state when to use alternatives like get_events_attached_to_contact or get_event for single-event lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses that search returns all note fields, eliminating the need for get_note, and that count_only=true auto-paginates and returns only counts without a results array. This is meaningful behavioral context, though it does not explicitly state read-only behavior or pagination defaults.
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 well-structured, with a clear topic sentence, usage guidance, return behavior, filter summary, and a count_only tip. Every sentence adds value, and the all-caps 'RETURNS FULL DATA' emphasizes a key behavioral point without being 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?
For a search tool with 8 optional parameters and no output schema, the description covers the main behavioral nuances: full data return, count_only for accurate counts, and available filters. It does not detail pagination defaults or error behavior, but schema covers page/sort parameters, making it adequate.
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 describes all 8 parameters with 100% coverage, so the baseline is 3. The description reiterates filtering by date range, user, and contact, and explains count_only's purpose, but it does not add substantive new meaning beyond what the schema already 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 clearly states the tool searches for notes with optional date and user filters, and explicitly distinguishes it from get_note by noting full data is returned and no follow-up call is needed. It also scopes usage across all contacts or specific users, differentiating it from contact-attached note retrieval 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 explicit usage context ('Use this tool to find notes across all contacts or for specific users') and advises against calling get_note afterward, which is a clear alternative. However, it does not explicitly mention when to use get_notes_attached_to_contact for single-contact scenarios, so it lacks a full when-not-to-use set.
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 adds useful constraints (50MB max, two mutually exclusive input methods), but does not describe the return value, error behavior, or any side effects beyond attaching the file. For an upload tool, this is partial transparency—enough to use it, but not to anticipate responses or failures.
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 5 sentences with zero fluff. It front-loads the purpose, uses a numbered list for the two input methods, and presents requirements and limits compactly. 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?
The tool has 5 parameters, no output schema, and no annotations. The description covers the essential operational context: purpose, input methods, required fields, and size limit. It does not describe the response format, but given the simplicity of an upload and the parameter focus, the description is largely sufficient. A mention of return value would make it fully 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 description coverage is 100%, so baseline is 3. The description adds meaningful semantics beyond the schema by clarifying that file_base64 and file_path are alternative input methods and that one of them is required along with contact_id. It also notes the 50MB size limit, which is not in the schema. This elevates the parameter understanding beyond raw field names.
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 a specific verb+resource: 'Upload a file and attach it to a contact in Less Annoying CRM.' This clearly distinguishes the tool from siblings like get_file or get_files_attached_to_contact, which are read-oriented, and from create_note or create_email which attach other entity types. The purpose is unambiguous and scoped.
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 usage context by specifying two input methods (file_base64 and file_path), required fields, and a size limit. It implies this tool is for uploading a file to a contact, but does not explicitly mention alternatives or when not to use it. The guidance is actionable, just not exhaustive with exclusions.
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 behavioral disclosure. It discloses that notes are timestamped, appear in contact history, preserve newlines, and escape HTML/markdown, which are meaningful behavioral traits. It doesn't cover permissions, response format, or reversibility, but the disclosed traits give the agent important 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 three concise sentences that front-load the core action, then add key constraints and text-handling behavior. Every sentence earns its place with no filler or 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?
The description covers the purpose, required parameters, and note content behavior, which is substantial for a simple create operation. It lacks return-value details or error behavior, but given the schema richness and straightforward nature of the tool, the description is adequately 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 100%, so the schema already provides full descriptions for all parameters. The description reinforces that contact_id and note are required and adds note content handling behavior, but it doesn't add new parameter-specific meaning beyond the schema. 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 uses the specific verb 'Create' with the resource 'new note attached to a contact,' clearly distinguishing it from sibling tools like edit_note, delete_note, and get_note. It also adds that notes appear in contact history, making the tool's 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 clearly states this tool is for creating new notes in a CRM contact context, which tells the agent when to use it. It doesn't explicitly mention alternatives or exclusions, but the context is sufficient and the verb 'create' implies this is for adding rather than editing or deleting.
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 burden of behavioral disclosure. It adds valuable context about visibility semantics (Public vs TeamSharing) and the team_ids requirement. However, it omits other behavioral aspects like return value, side effects, or default stages, leaving gaps for a creation 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 concise and front-loaded, with the main action stated first. Every sentence adds value, covering purpose and permission details without 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?
Given the 4 parameters with full schema coverage and no output schema, the description adequately covers the core purpose and permission behavior. It could mention the response or additional effects, but the provided information is sufficient for a create operation with clear sibling context.
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 already provides 100% coverage for parameter descriptions, establishing a baseline of 3. The description adds conceptual meaning beyond the schema by explaining what Public and TeamSharing mean (visible to all users vs specified teams), which enriches understanding of the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new pipeline in Less Annoying CRM, with a specific verb ('Create') and resource ('pipeline'). It also explains what pipelines are, and the operation is distinct from sibling tools like edit_pipeline and delete_pipeline.
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 Public vs TeamSharing permissions and specifies that TeamSharing requires team_ids, which guides parameter usage. However, it does not explicitly contrast with alternative tools, though the create operation is self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It goes beyond the basic delete action by warning that contacts within the group are not deleted, which is a crucial side effect. It does not mention irreversibility or permissions, but the warning adds significant transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, with the purpose front-loaded. The warning is relevant and earns its place, providing critical information without unnecessary verbosity.
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 one-parameter delete tool, the description explains what is deleted and a key side effect. It is complete enough for selection and invocation, though it does not describe the return value or explicitly state irreversibility, which are minor gaps for a delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter description 'The GroupId to delete' already explains the single parameter. The main description adds no extra semantic detail beyond what the schema provides, so the 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 verb 'Delete' and the resource 'group from the account', making the tool's purpose unmistakable. It differentiates from sibling tools like create_group, edit_group, and get_group by explicitly naming the delete action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool deletes a group at the account level. The warning about not deleting contacts helps prevent misuse compared to remove_contact_from_group or delete_contact, though it does not explicitly name alternatives or state when not to use this tool.
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 the full behavioral burden. It explicitly warns 'This permanently removes the note,' disclosing the irreversible destructive nature, and identifies the required input. It does not mention auth requirements or return behavior, but for a single-object delete operation the key risk is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences and a one-line 'Required' note convey purpose, risk, and the single parameter. No filler or redundant explanation.
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 one-parameter destructive tool, the description covers the essential action, the permanence warning, and the required note_id. With no output schema, it could optionally mention response behavior, but this is likely unnecessary for a standard delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes note_id as 'The NoteId to delete' and marks it required; the description echoes 'Required: note_id' but adds no additional format, constraints, or origin information beyond the schema. With 100% schema coverage, this meets the baseline but doesn't elevate it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with the verb 'Delete' and identifies the resource as 'a note from a contact's profile in Less Annoying CRM', clearly distinguishing it from sibling tools like get_note, edit_note, search_notes, and create_note. The destructive nature is explicit.
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 states the tool deletes a note and warns that it permanently removes the note, giving clear context for when to invoke it. It doesn't explicitly name alternatives or provide when-not-to-use conditions, but the destructive warning sufficiently scopes the intended use.
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 full responsibility for behavioral disclosure. It effectively communicates the destructive nature ('Delete'), key constraints (same pipeline, max 5000 items), and the return value (count of processed and skipped items). It lacks explicit irreversibility warnings or permission requirements, but provides sufficient context for safe use.
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, front-loaded with the primary action, and every sentence adds value: what it does, a key constraint, a limit, and the return format. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return value (count of processed and skipped items). It covers the essential aspects for a bulk delete tool: target, constraint, limit, and result. Minor gaps include potential error conditions or what 'skipped' means, but overall it is adequately complete for 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 100%, so the schema already documents both parameters ('pipeline_id' and 'pipeline_item_ids'). The description essentially restates the constraint that all items belong to the same pipeline and the 5000 max, which are already in the schema. It adds no meaningful semantic information beyond the structured fields.
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 ('Delete multiple pipeline items at once'), the resource ('pipeline items'), and the system ('Less Annoying CRM'). It distinguishes itself from the sibling 'delete_pipeline_item' by emphasizing the bulk nature, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the appropriate use case (deleting multiple items at once) and provides constraints (all items must belong to the same pipeline, max 5000 per call). It does not explicitly name alternatives or exclusion criteria, but the context is clear enough for an agent to differentiate this from single-item deletion.
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 goes beyond a simple 'delete' by warning that the action permanently removes the relationship from both contact records, which is key side-effect information. It does not detail error handling or return values, but for a single-parameter delete operation this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core purpose and following with a clear warning. Every sentence contributes meaningful information with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one required parameter, no output schema, no annotations), the description sufficiently covers the essential action and its permanent side effect. It could mention return behavior or error cases, but for a simple delete tool these are not critical 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 covers 100% of the parameters, with relationship_id already described as 'The RelationshipId to delete'. The description adds no additional parameter meaning beyond what the schema 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 specific action ('Delete') on the resource ('relationship between two contacts'), distinguishing it from sibling tools like edit_relationship (modify) and get_relationship (read). The additional warning reinforces the specific nature of the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool permanently deletes the relationship, signaling that it should only be used when irreversibility is intended. However, it does not explicitly mention alternatives (e.g., edit_relationship) or when not to use this tool, leaving the guidance implied rather than fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It adds two important behavioral traits: permission requirements (only owners/admins) and the fact that users are not removed along with the team. This goes beyond the basic 'delete' implication, though it does not mention irreversibility 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 three sentences long, each conveying essential information: the action, the permission prerequisite, and a critical warning about user impact. There is no redundant or filler content.
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 one-parameter delete tool with no output schema, the description covers the key aspects: what it does, who can do it, and a notable side effect. It does not explain error handling or response, but given the tool's simplicity, this is reasonably 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 has 100% coverage: team_id is described as 'The TeamId to delete'. The description adds no additional parameter-level detail beyond what the schema already provides, so the baseline score of 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 opens with 'Delete a team from the account', which is a specific verb+resource statement. It clearly distinguishes the action from sibling tools like edit_team or get_team by naming the operation directly.
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 by stating that only account owners and administrators can delete teams, and warns that users are not affected. It does not explicitly name alternatives, but the action is straightforward enough that the when-to-use scenario is obvious from the purpose.
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 full burden. It discloses that this is an update operation and adds a key constraint ('cannot change the field type after creation'), but it does not describe the response, error cases, or impact on existing data. This is adequate but leaves some 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?
Two concise sentences: the first states the action, the second provides a prerequisite and a key constraint. Every sentence is purposeful, with no redundancy 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?
For a 7-parameter update tool with no output schema or annotations, the description covers the core function, a prerequisite, and a critical limitation. It does not explicitly contrast with create/delete tools, but the sibling list makes the intent clear.
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 100%, so the baseline is 3. The description adds value by explaining how to obtain the required custom_field_id via get_custom_fields, which gives practical meaning to that parameter beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an existing custom field definition', using a specific verb ('Update') and resource ('custom field definition'). This distinguishes it from sibling tools like create_custom_field and delete_custom_field.
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 usage context by instructing to 'Use get_custom_fields to find field IDs first' and notes the restriction on changing field type. While it does not explicitly say when not to use this tool, the context is enough for an agent to understand the prerequisite and limitation.
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 count_only behavior and the mutual exclusivity of group_id/group_name, but it doesn't mention pagination details for the default case or describe the return structure. This is a moderate level of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: the purpose, the parameter selection rule, and a useful tip about count_only. It is front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema descriptions and the simple nature of a retrieval tool, the description provides enough context for correct usage. It covers the key behavioral nuance (count_only) and the parameter choice. Some might expect details on response format, but the schema and tool name largely cover that.
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%, so the baseline is 3. The description adds value by clarifying that group_id and group_name are mutually exclusive and by highlighting count_only for accurate counts, which goes beyond the schema 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's function: 'Retrieve all contacts that belong to a specific group.' It uses a specific verb and resource, distinguishing it from sibling tools like add_contact_to_group or get_groups_for_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?
The description provides clear context for using the tool, instructing to use either group_id or group_name (not both). It doesn't explicitly mention alternative tools, but the purpose is unambiguous given the sibling names and the parameter 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?
Given no annotations, the description discloses important behavioral traits: it returns full event data, eliminating the need for a follow-up get_event call, and recommends count_only for counts. It does not cover error handling or rate limits, but it adds meaningful 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?
Three sentences with no fluff: first states purpose, second highlights full data, third gives a usage tip. Front-loaded and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers main functionality and highlights the full-data return and count_only option. Without an output schema, it does not enumerate event fields, leaving some ambiguity about the exact return structure, but it is sufficient for the tool's simplicity.
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 descriptions cover all parameters (100%), so the description adds little beyond the schema. It reinforces count_only usage but does not introduce new parameter semantics or clarify edge cases.
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 'Retrieve all calendar events for a specific contact' – a specific verb and resource that distinguishes it from siblings like get_event and search_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: use when you need all events for a contact and want full data. It also advises using count_only for accurate counts. However, it does not explicitly mention alternatives or when not to use this tool.
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 full burden of behavioral disclosure. The phrase 'Retrieve a single note by ID' implies a read-only operation, but it does not explicitly state that there are no side effects, nor does it mention what happens if the note is not found. The note about search_notes returning the same data slightly enhances transparency by describing data redundancy, but it stops short of full behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It opens with the core purpose, follows with a direct usage instruction, and concludes with a helpful note distinguishing it from search_notes. Every sentence earns its place with zero redundancy 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?
For a simple getter with one parameter and no output schema, the description covers the essential context: what the tool does, when to use it, and how it differs from a sibling tool. The phrase 'need the record' implies the return value, but it could be more explicit about the response format. Still, given the low complexity, this description is sufficiently 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 schema provides 100% coverage with a clear description for note_id ('The NoteId to retrieve'). The tool description does not add additional parameter semantics beyond the schema, so it meets the baseline for high schema coverage without needing extra compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Retrieve a single note by ID.' It uses a specific verb and resource, and explicitly distinguishes itself from search_notes by noting when to use get_note instead. This makes the purpose unambiguous and differentiated from sibling tools.
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 provides explicit usage guidance: 'Use this when you already have a NoteId and need the record.' It also gives an exclusion and alternative: 'Only use get_note when you have an ID but not the data' and notes that search_notes returns the same full data. This clearly explains when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well by disclosing that results include all note fields (removing the need for follow-up calls) and that count_only auto-paginates for accurate counts. It does not cover permission requirements or ordering, but those are less critical for a read-only list 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 tightly written sentences with a clear lead sentence stating purpose. The emphasis on 'RETURNS FULL DATA' and the concrete count_only tip earn their place without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description sufficiently explains return values (all note fields) and count_only behavior. It does not mention pagination defaults or error scenarios, but the schema covers parameter-level details, making this adequate for a list endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all four parameters with descriptions (100% coverage), so the description adds limited value beyond reinforcing count_only behavior and result completeness. This is the appropriate baseline when the schema handles the details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Retrieve' with a clear resource ('all notes for a specific contact'), which distinguishes it from siblings like get_note (single note) and search_notes. The scope is explicit 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly advises against calling get_note afterward and suggests count_only=true for accurate counts without a result set. It provides useful usage context, though it does not explicitly contrast with search_notes or other note-related tools.
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 discloses that results include all pipeline item fields, that items span all pipelines, and that count_only=true avoids returning the full result set. This goes beyond a simple operation statement. It lacks details on authentication, rate limits, or pagination behavior, but for a read-only retrieval tool the provided behavioral notes are useful.
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, each with a distinct purpose: the core action, the full-data benefit, and the count_only tip. It is front-loaded with the primary verb and resource, and no words are wasted. The formatting with RETURNS FULL DATA is slightly emphatic but does not reduce conciseness.
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 no output schema, the description adequately covers what the tool returns (full data across all pipelines) and a key usage variant (count_only). The pagination parameters are documented in the input schema, so the description doesn't need to repeat them. It does not mention edge cases like empty results, but overall it is sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds a bit of context for count_only ('accurate counts without returning the full result set') but the schema already explains that parameter well. No additional meaning is added for contact_id, page, or max_results, so it stays at baseline.
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 ('Retrieve all pipeline items') and the resource ('for a specific contact'), and explicitly differentiates from the sibling tool get_pipeline_item by noting that full data is returned so no follow-up call is needed. The scope (across all pipelines) is also clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it is for retrieving pipeline items for a specific contact, and it notes that get_pipeline_item is unnecessary because full data is returned. It also advises using count_only=true for accurate counts. However, it does not explicitly mention alternative tools like search_pipeline_items or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states that the tool returns user IDs, names, emails, and roles, and emphasizes that user IDs are required for calendar/task assignments. However, it does not mention possible pagination, inactive users, or read-only guarantees, though 'retrieve' implies a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main action and uses four concise sentences. The fourth sentence about user IDs being required for events/tasks is slightly redundant with the second, but it adds a concrete calendar-specific detail without being bloated.
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 zero-parameter list tool with no output schema, the description is complete: it states who the tool returns, what fields are included, and why the tool is useful. No further context is needed to invoke this 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?
The tool has zero parameters, so the baseline is 4. The description correctly focuses on return fields rather than parameter syntax, and no parameter documentation is needed.
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 a specific verb and resource: 'Retrieve all users in this LACRM account.' It clearly distinguishes use from sibling tools by focusing on discovering user IDs for assignment, rather than generic user management. This is more than just a restatement of the name.
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 states when to use the tool: 'Use this tool to discover user IDs when you need to assign contacts, tasks, or events to specific users.' It does not list alternatives or exclusions, but the context is clear and actionable.
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. It discloses what the tool returns (csv, columns, report), how columns are ordered, and that no CRM-specific behavior is built in. It doesn't explicitly state whether the operation is read-only, but 'Generate' suggests no mutation; still, an explicit safety note would make it 5.
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 concise paragraphs front-load the primary purpose and returning shape, with efficient, non-redundant language. Every sentence provides value (same-config guarantee, ordering detail, output contract).
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 nested config and no output schema, the description hands out the return shape, report semantics, and ordering rule. The schema covers parameters in depth; the description fills the output/behavior gap. No significant missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions already cover 100% of parameters with detailed semantics (e.g., enum strategies, address_config rules). The description references field configuration but adds no per-parameter semantics beyond the schema. This meets the baseline but doesn't exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action (generate), a concrete artifact (CSV template), and a distinct output (per-field behavior report). It clearly separates this from sibling bulk_validate and bulk_execute tools by focusing on template generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains the intended workflow by stating the template uses the same field configuration as validate/execute, implying this should run before those tools. It does not name alternatives or explicit when-not conditions, so not a 5.
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 behavioral disclosure. It details return contents: progress (processed/total), success/failure counts, per-row errors, and the final report CSV path. It also notes the 'when complete' condition, giving insight into possible incomplete states. This goes beyond a minimal status 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 sentences, efficiently front-loaded with purpose and followed by specifics. No filler or repetition; every clause adds value.
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?
Given a single parameter, no annotations, and no output schema, the description fully explains what the tool returns and when, including progress, counts, errors, and report path. It is complete for a simple status tool and references the related bulk_execute tool for context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes run_id as 'The run_id returned by bulk_execute.' The description repeats this relationship without adding new syntax or format details. Since schema coverage is 100%, the baseline is 3, and the description does not elevate beyond that.
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: 'Get the status of a bulk run started by bulk_execute.' It specifies the resource (bulk run) and the action (get status), and references the specific start tool, which distinguishes it from sibling bulk tools like bulk_execute and bulk_run_resume.
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 context by stating it is for a run 'started by bulk_execute', signaling that it should be used after executing a bulk run. However, it does not explicitly mention alternatives or when not to use it, so it stops short of full guideline coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and explicitly warns that the operation permanently removes the field and all data stored in it across all records. This discloses critical destructive behavior that goes beyond the basic action 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?
Two short sentences: the first states the purpose, the second adds a critical warning. Every word earns its place, and the warning is front-loaded directly after the 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 delete operation without an output schema, the description fully covers the essential behavior: what it does and the irreversible data loss consequence. The schema covers parameters, leaving no major 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 100% coverage with clear descriptions for both parameters ('The CustomFieldId to delete' and 'If deleting a section, also delete nested fields'). The description adds no further parameter meaning, so 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 action ('Delete a custom field definition') with a specific verb and resource, distinguishing it from sibling tools like create_custom_field, edit_custom_field, and get_custom_field. The warning adds specificity about scope (across all records).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for removing a custom field definition, but does not explicitly state when to use it versus alternatives (e.g., edit_custom_field for modifications instead of deletion). No exclusions or alternative tool references are provided.
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 goes beyond a simple 'get' by explicitly stating the return content: field name, type, options, display settings, and archived status. This gives the agent a clear expectation of the operation's output, though it does not disclose error behavior or permissions.
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 action, and contains no filler. It efficiently conveys the operation and the key return fields.
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?
Given the tool's simplicity (single parameter, no output schema), the description is complete. It explains what the tool does and what the response contains, which is sufficient for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with the parameter description 'The CustomFieldId to retrieve'. The tool description adds no additional parameter semantics, so the baseline of 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 states 'Get detailed information about a single custom field definition' with a specific verb ('Get') and resource ('custom field definition'), and clearly distinguishes from siblings like get_custom_fields (plural) and get_pipeline_custom_fields by emphasizing 'single'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need details for one specific custom field, as opposed to listing all custom fields. There is no explicit alternative mention, but the 'single' wording provides clear context for selecting this tool over its plural siblings.
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 must convey behavioral traits. The verb 'Retrieve' implies a read-only operation, and the note about search_emails returning 'the same full data' hints that get_email returns full email data. However, it does not explicitly state safety, error behavior, or any special side effects, leaving moderate gaps for a no-annotation 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 three sentences, front-loaded with the purpose, followed by usage guidance and a note about an alternative. Every sentence adds value and there is no unnecessary verbosity.
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 getter with one parameter and no output schema, the description is fully sufficient. It states both what the tool does and when to use it, and the note about search_emails clarifies the return data, covering the main context an agent needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has 100% coverage with a clear description of email_id ('The EmailId to retrieve'), and the parameter name is self-explanatory. The description reinforces the use of the ID but does not add extra semantic detail 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 states the exact action: 'Retrieve a single logged email by ID.' This clearly distinguishes it from sibling tools like search_emails and get_emails_attached_to_contact by specifying a single record and the use of an ID.
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 states when to use: 'Use this when you already have an EmailId and need the record.' It also provides an exclusion: 'Only use get_email when you have an ID but not the data,' and names the alternative search_emails with a note about it returning the same full data.
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 the full burden. It explains the tool's behavior (retrieve all groups) and return format, which is sufficient for a simple read-only operation. It does not explicitly state 'read-only' nor mention edge cases like archived groups, but the verb 'Retrieve' implies safety and the return details add context.
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 bit verbose with 5 sentences, including an illustrative example and an extra note about using GroupId. However, it is still fairly concise and well-structured, with purpose, usage, and return info front-loaded. The last two sentences could be trimmed, but they add useful context without excessive bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (0 params, no output schema, no annotations), the description is quite complete. It states what it does, when to use it, what it returns, and how to use the result. Minor gaps like whether archived groups are included or ordering, but these are not critical for a basic list tool.
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 0 parameters, and the schema coverage is 100% (vacuously). The baseline for 0 parameters is 4, and the description appropriately does not need to explain parameters. No additional parameter information is possible or necessary.
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 ('Retrieve') and resource ('all contact groups') with explicit scope ('in this LACRM account'). It distinguishes from siblings like get_group (singular vs plural) by emphasizing 'all' and also mentions return fields (IDs, names, descriptions), making the tool's 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?
Provides a specific use case: 'Use this tool to discover available groups before adding contacts to groups.' This clearly indicates when to use it, but it does not explicitly mention alternatives or exclusions (e.g., use get_group for a specific group, or get_groups_for_contact for groups of a contact). Hence, it lacks direct alternative comparison.
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 discloses the read-only nature by using 'Get' and lists the exact return fields (IDs, names, active/closed state, colors, creation dates). This provides clear expectations without needing an output 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 two sentences, front-loaded with the action and resource, and every word earns its place. It avoids fluff and directly states the scope and return fields.
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?
The tool is simple: one optional parameter, no nested objects, no output schema. The description explains both the parameter behavior and return fields, making it complete for an agent to use without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the single parameter with the description 'Filter by pipeline (omit for all statuses)' (100% coverage). The tool description adds minor redundancy by saying 'specific pipeline or all pipelines,' but it doesn't introduce new semantics 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 clearly states the tool's function: 'Get all statuses for a specific pipeline or all pipelines.' It uses a specific verb ('Get'), identifies the resource ('statuses'), and distinguishes from sibling tools like 'get_pipeline' and 'get_pipelines' by explicitly mentioning the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: whenever you need statuses for a pipeline or all pipelines. It also clarifies the optional parameter usage ('omit for all statuses'). No alternatives are mentioned, but no direct sibling offers the same functionality, so the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses key behaviors: custom_fields are written verbatim and ID-keyed writes ignored, custom_field_names are case-insensitive and validated, status_name auto-resolves, and run_automation triggers side effects like emails/tasks. It lacks explicit permission/error details but goes well 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?
The description is well-structured with a clear opening statement, a numbered prerequisite list, and short explanatory bullets. Every sentence adds value—no filler—making it easy to scan and digest.
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?
Covering prerequisites, custom field behavior, automation, and name resolution, this is thorough for a creation tool with no output schema. It omits response format or error expectations, but those are not required by the schema and the description gives enough to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all parameters and their mutual exclusions (status_id/status_name, custom_fields/custom_field_names). The description adds semantic nuance by explaining the write behavior and validation for custom fields, plus the name-based resolution advantage, which goes beyond the schema 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 states 'Create a new pipeline item attached to a contact' with a specific verb and resource. It clearly distinguishes from sibling tools like edit_pipeline_item, get_pipeline_item, and delete_pipeline_item by focusing on creation and attachment.
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 explicit prerequisites with execution order (get_pipelines, get_pipeline_item_schema, search_contacts) and notes optional automation behavior. However, it does not explicitly compare to alternatives or state when not to use this tool, but the context is strong enough for correct use.
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 behavioral disclosure. It adds important behavior beyond the schema: 'Relationships are bi-directional and visible on both contact records.' This tells the agent that creating a relationship has a side effect on both parties, which is valuable. It could mention permission requirements or return values, but the provided behavioral detail is solid.
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, front-loaded with the main action and then providing relevant behavior and usage details. Every sentence contributes meaningful information with no filler. It is well-structured and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with 3 required parameters and no output schema, the description covers the action, target object types, relationship behavior, and note usage. It doesn't mention return values or error cases, but that's not critical for a straightforward create operation. Overall, it's complete enough for an agent to select and 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?
This parameter's schema description coverage is 100%, so the baseline is 3. The description adds meaning to the 'note' parameter by clarifying it should describe the relationship type, with examples like 'Spouse' and 'Referred by,' which goes beyond the schema's generic 'Description of the relationship.' This enrichment justifies a 4.
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: 'Create a relationship between two contacts or companies.' It uses a specific verb (create) and resource (relationship), and distinguishes from sibling tools by emphasizing creation rather than editing, getting, or deleting. It also clarifies the relationship can involve contacts or companies.
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 use: creating a relationship between two contacts/companies. It also provides direct guidance: 'Use the note field to describe the relationship type (e.g., Spouse, Referred by).' It does not explicitly mention alternatives like edit_relationship, but the purpose is sufficiently clear that it doesn't require explicit exclusions.
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 behavioral disclosure. It explains the handshake requirement, how webhook scope affects triggering, and lists common events. These add meaningful context beyond simply saying 'create a webhook,' even though it does not detail the success response or authentication requirements.
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 well-structured with clear sections for requirements, scope, and common events. Every sentence contributes useful information without wasted words, and the bullet points make it scannable.
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 3-parameter creation tool with no annotations or output schema, the description is fairly complete. It covers the key behavioral aspects (handshake, scope) and provides examples. It does not explicitly state what the API returns upon success, but the absence of an output schema makes this less critical.
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%, so the baseline is 3. The description adds value by specifying that endpoint_url must be HTTPS, explaining the handshake requirement, clarifying the meaning of User vs Account scope, and providing common event examples. This goes beyond the schema's brief 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 'Create a new webhook in Less Annoying CRM' with a specific verb and resource, distinguishing it from sibling tools like get_webhooks and delete_webhook. It also explains the purpose of webhooks (send POST requests when events occur), leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for using the tool, including requirements (HTTPS endpoint, handshake response) and scope options (User vs Account). While it does not explicitly mention alternatives like get_webhooks or delete_webhook, the create action is obviously distinct, and the practical requirements are well covered.
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 trait: 'Only include fields you want to change - other fields remain unchanged,' which is non-obvious and important for a mutation tool. It also states the required parameter. It does not cover error handling or edge cases, but for an update operation this is a solid level of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: purpose, update semantics, and how to find valid IDs. It is front-loaded with the core verb/resource and contains no fluff 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?
Given the tool has 12 parameters and no output schema, the description covers the essential aspects: what the tool does, the partial-update behavior, the required parameter, and how to obtain valid IDs. It does not elaborate on complex fields like recurrence or attendees, but the schema provides some descriptions, making this adequately complete for most use cases.
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?
With only 33% schema description coverage, the description compensates by clarifying the meaning of all optional parameters: only included fields are changed. It also explicitly names event_id as required. This adds semantic value beyond the raw schema, which mostly lists types and minimal 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's function: 'Update an existing calendar event in Less Annoying CRM.' The verb 'Update' is specific, the resource 'existing calendar event' is unambiguous, and it distinguishes from siblings like create_event (new events), get_event (reads), and delete_event (removes).
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 explicit guidance on using the tool: 'Only include fields you want to change' clarifies partial-update usage, and 'Use search_events or get_event to find valid event IDs' gives a clear prerequisite and points to specific sibling tools for locating IDs. However, it does not explicitly state when not to use this tool (e.g., for creating events), though 'existing' implies it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It directly states 'Note content is completely replaced when updated,' which is a critical side effect not evident from the schema alone. It also conveys the partial-update semantic via 'Only include fields you want to change,' adding transparency about how omitted fields are handled.
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 remarkably concise at three short sentences. It front-loads the purpose, then provides essential usage guidance and a key behavioral note. Every sentence earns its place with no redundancy 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?
This is a simple update tool with only three parameters all described in the schema. The description covers the core purpose, usage instructions, and the critical replacement behavior. While it doesn't mention return values or error handling, that is acceptable given the tool's simplicity and the absence of an output schema; the description is sufficiently complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with descriptions for all three parameters, so the baseline is 3. The description adds value by stating 'Only include fields you want to change' and 'Required: note_id', which informs how parameters should be used together. This guidance goes beyond the individual field descriptions and clarifies the update pattern.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an existing note in Less Annoying CRM' with a specific verb ('update') and resource ('note'). This unambiguously distinguishes it from sibling tools like create_note, delete_note, and get_note by focusing on modifying an existing record.
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 explicit usage guidance: 'Only include fields you want to change' and 'Required: note_id.' It also clarifies that note content is completely replaced when updated, which helps decide what to include. While it doesn't explicitly name alternatives, the 'existing' qualifier implicitly excludes create operations, making the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals non-obvious behavior: partial update semantics ('Only include fields you want to change'), special handling for contact_id=null (detach), and preference for is_complete=true over deletion. However, it doesn't mention side effects, permissions, or return values, which is a minor gap but not critical.
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 very concise and well-structured. Every sentence adds value: the first states purpose, the second explains functionality, the third clarifies patch semantics, and the remaining sentences provide essential parameter-specific guidance. No redundant or filler text.
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 mutation tool without annotations or output schema, the description covers the essentials: what the tool does, when to use it, how to update partially, and special parameter behaviors. It doesn't mention return values or error scenarios, but the 100% schema coverage and clear behavioral notes make it sufficiently 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 100%, so the baseline is 3. The description adds extra meaning beyond the schema: it clarifies that omitted fields remain unchanged (patch semantics), explains the preferred use of is_complete=true, and specifies that contact_id=null detaches the task. These enrich the parameter descriptions and justify a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an existing task' with a specific verb and resource. It distinguishes from sibling tools like create_task, delete_task, and get_task by emphasizing modification and marking complete. The phrase 'preferred over deleting' explicitly differentiates from delete_task.
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 usage guidance: use for modifying task details or marking complete, only include fields to change, use is_complete=true instead of deleting, and pass contact_id=null to detach. It doesn't explicitly mention when to use create_task vs edit_task, but the context strongly implies that edit_task is for existing tasks. It names delete as an alternative not to use for completion, which qualifies as explicit 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?
No annotations are provided, so the description carries the full burden. It discloses a critical behavioral trait: passing user_ids completely replaces team membership, and passing an empty array removes all users. This goes beyond the schema and addresses the main 'gotcha.' It doesn't cover permissions or error handling, but for a simple update tool, this is substantial.
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 short sentences: the first states purpose, the second gives a prerequisite, and the third explains the behavior of user_ids. Every sentence earns its place, with no fluff 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 3-parameter tool with no output schema, the description covers the purpose, prerequisite, and the key behavioral nuance. It doesn't discuss return values or error cases, but these are less critical for such an edit operation and are not required by the schema or annotations.
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% so baseline is 3. The description adds meaning beyond the schema by clarifying that 'name and/or membership' can be updated independently, and specifically that an empty user_ids array removes all users. These details are not fully explicit in the schema property 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 states 'Update a team's name and/or membership' which is a specific verb, resource, and scope. It clearly distinguishes this tool from siblings like create_team, delete_team, and get_team by focusing on modification rather than creation, deletion, or retrieval.
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 an explicit prerequisite: 'Use get_teams to find team IDs first.' It also clarifies the when-to-use context (updating name and/or membership). However, it does not explicitly name alternatives like create_team for new teams, so it stops short of full exclusion 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 provided, the description carries the full burden. It uses the read-oriented verb 'Retrieve' to imply a non-destructive operation and details the return contents (IDs, names, user IDs). The domain note 'Each user typically has their own calendar' adds behavioral context. It doesn't explicitly state permissions or side-effect-free behavior, but for a simple list operation, 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?
The description is four short sentences, each earning its place. It front-loads the primary action, then provides usage context, return details, and a domain note. No wasted words or 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 simple zero-parameter tool with no output schema, the description is reasonably complete. It explains what is returned, why to use it, and a relevant domain fact. It doesn't mention pagination or errors, but these are unlikely to be significant for a simple list-all operation. Minor gaps exist, but overall it's effective.
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 coverage is trivially 100%. Per the guidelines, a zero-parameter tool gets a baseline of 4. The description doesn't need to explain parameters, but it does mention 'CalendarId' as a related concept, which adds slight semantic context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Retrieve all calendars in this LACRM account,' clearly stating the action and resource. It also specifies what is returned (calendar IDs, names, associated user IDs), making it easy to distinguish from sibling tools like get_users or get_teams.
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 to use this tool 'to discover calendar IDs when creating events,' providing a clear use case. It also adds 'Use CalendarId when creating calendar events' to reinforce when the returned IDs are needed. It doesn't explicitly name alternative tools or when not to use it, but the guidance is clear enough within the context of siblings like create_event.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses that results include 'all contact fields - same as search_contacts or get_contact' and states the 'Maximum 10,000 results per call.' This provides useful behavioral context beyond the tool name, though it does not detail pagination behavior or error handling for invalid IDs.
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 concise and front-loaded: the first sentence states the core purpose, the second gives usage guidance, and the third highlights key return behavior and limits. Every sentence earns its place with no redundancy 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?
The tool is conceptually simple (bulk ID lookup), and the description covers the essential aspects: what it returns, when to use it, and the result cap. Since there is no output schema, the reference to 'same as search_contacts or get_contact' helps set expectations, though a bit more detail on pagination or partial failures would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning by clarifying that the tool handles both contacts and companies via contact_ids, and by reiterating the result limit. It also contextualizes the contact_ids parameter as coming from webhooks or external references, which the schema does not imply.
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: 'Retrieve multiple contacts or companies by their IDs.' It specifies the resource (contacts/companies) and the scope (by IDs), distinguishing it from sibling tools like search_contacts (which searches by criteria) and get_contact (which retrieves a single contact).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool: 'Use this when you have a list of ContactIds (e.g., from webhooks or external references).' It implies this is the right choice for ID-based lookups, though it does not explicitly name alternative tools or scenarios where they would be preferable.
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 that all email fields are returned and that count_only changes the response shape, which is useful. However, it omits other behavioral details such as pagination semantics, ordering, or potential rate limits, making it adequate but not thorough.
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, each earning its place: first states the core purpose, second delivers the key call-saving benefit, third gives a conditional usage hint. No filler or 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?
With no output schema, the description partially covers return values by noting full email fields and count_only's count/breakdowns. It also implicitly covers pagination via schema params. For a 4-parameter read tool, this is reasonably complete, but it does not detail the count breakdown structure or pagination defaults, leaving some 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 100%, so the baseline is 3. The description adds value beyond the schema by clarifying the effect of count_only (returns total count and breakdowns, no results array) and emphasizing full data return, which helps the agent understand parameter trade-offs without re-reading 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?
Description clearly states the verb 'Retrieve' and resource 'all logged emails for a specific contact', making the tool's purpose unambiguous. It distinguishes from sibling tools like get_email (single email) and search_emails (search across contacts) by scoping to a contact and returning all emails.
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 tells the agent not to call get_email afterward ('RETURNS FULL DATA... no need to call get_email afterward'), and provides a specific conditional for when to use count_only=true for count-only use cases. This gives clear when-to-use and when-not-to-use guidance relative to a sibling tool.
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 the full burden. It discloses what the tool returns in detail (ALL fields, with name, required, type, input_format, valid_options, is_custom_field) and why pipeline_id is needed. It doesn't mention errors or rate limits, but for a read-only schema fetch, the behavioral context 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-sentence summary, a short note about pipeline_id, a bullet list of return fields, and a numbered workflow. Every line adds value, and the formatting is clear.
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?
The tool is simple (1 param, no output schema), but the description thoroughly explains the return structure and integrates the tool into a workflow with sibling tools (get_pipelines, create_pipeline_item). This fully covers what an agent needs to use the tool effectively.
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 the parameter with 'The PipelineId to get the schema for'. The description adds context beyond the schema: 'Requires pipeline_id because each pipeline has different custom fields' and explains where to obtain pipeline_id via get_pipelines in the workflow.
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 'Get complete field schema for creating/editing pipeline items' with a specific resource. It distinguishes from sibling tools like get_pipeline_custom_fields by noting it returns ALL fields (both fixed system fields and custom fields), not just custom fields.
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 a clear workflow: first call get_pipelines to find pipeline_id, then call this tool, then use the schema to construct create/edit calls. It explains why pipeline_id is required. It does not explicitly name alternative tools like get_pipeline_custom_fields for custom-fields-only use, but the workflow gives strong contextual 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 clearly describes the tool as a retrieval operation, discloses the returned fields (IDs, names, icons, status definitions with sort order), and adds context about how PipelineId and StatusId are used downstream. It does not mention pagination, auth, or edge cases, but for a read-only list tool 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a purpose statement, return values, and a numbered workflow. It is slightly longer than necessary but each section earns its place; the front-loaded purpose sentence ensures clarity. The workflow adds value but could be trimmed.
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 lacking an output schema, the description explains the return values (IDs, names, icons, status definitions with sort order) and provides a complete workflow for using the results. For a zero-parameter list tool, this is enough for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so there is no parameter information to add. The description appropriately references PipelineId and StatusId as output values rather than parameters, making the baseline of 4 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 opens with 'Retrieve all pipeline definitions for this LACRM account', giving a specific verb and resource. It further clarifies that it returns pipeline IDs, names, icons, and status definitions, and the workflow positions it as the tool for discovering pipelines before creating or editing pipeline items, distinguishing it from sibling tools like get_pipeline.
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 states 'Use this tool to discover available pipelines and their statuses before creating or editing pipeline items', providing a clear when-to-use context. It also outlines a three-step workflow that references get_pipeline_custom_fields as the follow-up, but it does not explicitly name alternatives like get_pipeline or state when not to use this tool.
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 burden of behavioral disclosure. It adds a useful nuance that get_task returns the same full data as search_tasks, implying a read-only operation. However, it does not address error handling or permissions, which are less critical for a simple retrieve.
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, front-loaded with the purpose, followed by usage and a warning. Every sentence adds value, with no unnecessary words 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 1-parameter get tool with no output schema, the description covers its purpose, usage guidance, and relationship to search_tasks. It does not explicitly describe the return format, but the note about 'same full data' implies what to expect, making it sufficient for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, with a clear description in the schema. The description reinforces that the ID is needed but adds no additional semantic detail 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 'Retrieve a single task by ID,' using a specific verb and resource. It distinguishes itself from search_tasks by focusing on retrieval by ID rather than search, 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?
The description explicitly states when to use the tool ('when you already have a TaskId and need the record') and when not to use it ('search_tasks returns the same full data'). It also names the alternative tool, providing clear 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 discloses important behavioral traits: full task fields are returned per result, and count_only=true auto-paginates and returns only counts/breakdowns. This goes beyond a basic 'retrieve' but does not cover pagination details 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?
Three sentences, each adding distinct value: the core action, the full-data guarantee, and the count_only tip. The information is front-loaded and concise with no 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?
For a list tool with no output schema and no annotations, the description covers the main use case and the count_only mode. It does not explicitly explain pagination behavior for non-count calls, but the schema provides page and max_results parameters, making it adequately 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 100% with detailed parameter descriptions. The description adds value by advising to use count_only=true for accurate counts, reinforcing the parameter's purpose beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all tasks for a specific contact, using a specific verb ('Retrieve') and resource ('tasks'). It is distinguishable from siblings like get_task (singular) and search_tasks (search-oriented).
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 explains that full task data is returned so there is no need to call get_task afterward, and recommends count_only=true for accurate counts. However, it does not discuss when to use search_tasks or other alternatives.
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 behavioral disclosure. It explicitly reveals the permission-based visibility behavior (admins see all, regular users see only their teams), which is a key implementation trait. However, it does not mention other behaviors like pagination, sorting, or response format, but for a parameterless list operation this is acceptable.
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 main purpose and followed by a concise explanation of access behavior. Every word adds value, with no fluff or redundancy. It is an excellent example of efficient, well-structured documentation.
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, zero-parameter list tool, the description is largely complete: it states what is retrieved and the access restrictions. It lacks explicit mention of return value structure or pagination, but given no output schema and sibling tools like get_team for detailed information, the description provides sufficient context for an AI agent to correctly invoke and interpret the result.
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 takes no parameters, so the schema is trivially documented (100% coverage). The baseline for zero parameters is 4, and the description correctly adds no parameter-related information because there is nothing to add. The description's focus on the access scope is more relevant than parameter semantics in this case.
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 with a specific verb and resource: 'Get all teams accessible to the current user.' It also distinguishes from the sibling tool get_team by emphasizing 'all teams' and the current user's access scope, which is a unique characteristic not repeated elsewhere.
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 you need all teams accessible to the current user. It implies a difference from get_team (singular) but does not explicitly mention alternatives or exclusions. The access ruling (admin vs regular user) gives practical guidance on expected results, but no direct 'use this instead of...' 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 provided, the description carries the burden of behavioral disclosure. It adds important behavior: results include all email fields so no follow-up get_email call is needed, and count_only=true returns only counts without the results array. These are valuable insights beyond the schema. It does not mention side effects, but as a search operation, this is acceptable.
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 efficiently structured in three short paragraphs, each earning its place: the main purpose, the key return-data insight, and the count_only use case. It is front-loaded with the primary action and avoids unnecessary 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?
For a search tool with 9 parameters and no output schema, the description covers essential context: what filters are available, that full data is returned, and how to get counts efficiently. Pagination and sorting are left to the schema, which already documents them. While it could mention pagination behavior, the description is sufficiently complete for informing tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (89%), so the baseline is 3. The description adds value by highlighting the key filter dimensions (date range, user, contact) that map to parameters, and provides extra context for count_only beyond the schema description ('accurate counts on large datasets without returning the full result set'). This enriches the parameter understanding without duplicating every schema field.
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 'Search for logged emails with optional filters' with a specific verb and resource. It goes further to specify the filtering dimensions (date range, user, contact), distinguishing it from sibling search tools like search_notes and search_tasks. The statement about returning full data also differentiates it from get_email.
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 usage context, including when to use it ('find emails by date range, user, or contact') and a specific use case for count_only ('accurate counts on large datasets'). It also implies an alternative by stating 'no need to call get_email afterward.' However, it does not explicitly mention when not to use it or contrast with related tools like get_emails_attached_to_contact.
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 the full burden. It clearly states the operation is permanent and destructive, and the warning adds context about history preservation. However, it doesn't mention permissions, side effects, or return behavior, though the key irreversible nature is well 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?
Three short sentences: purpose, warning, and required parameter. Every sentence earns its place with no filler.
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 one-parameter destructive operation, the description is complete: states the action, emphasizes permanence, provides an alternative, and identifies the required parameter. No output schema exists, but none is needed for a straightforward delete.
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 a clear description for task_id ('The TaskId to delete'). The description only restates that task_id is required, adding no new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Permanently delete' with resource 'task from Less Annoying CRM', clearly distinguishing it from edit_task and other task-related tools. The warning also reinforces its destructive purpose.
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 advises when not to use the tool: 'Consider using edit_task with is_complete=true instead to preserve history.' This provides clear alternative and exclusion 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?
No annotations are present, so the description carries the full burden. It discloses that search_events returns the same full data for each match, implying get_event returns similar data. It clearly indicates a read-only operation via 'Retrieve.' It does not mention error handling or permissions, but for a simple get operation this is acceptable.
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 highly concise, with three short sentences: the main purpose, a usage condition, and a note about search_events. Every sentence serves a purpose, and the key information is front-loaded.
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?
Given the tool's simplicity (one parameter, no output schema, read-only retrieval), the description covers all necessary aspects: what it does, when to use it, and its relationship to the search alternative. No significant gaps exist.
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 the event_id parameter already described as 'The EventId to retrieve.' The description adds negligible semantic value beyond the schema, so the 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 tool's function: 'Retrieve a single calendar event by ID.' It uses a specific verb and resource, and distinguishes itself from search_events by noting the same data is returned via search. This 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Use this when you already have an EventId and need the record.' It also explicitly warns not to use it when you don't have the ID, pointing to search_events as the alternative. This fully addresses when and when not to use the tool.
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 burden. It discloses the return fields and explicitly excludes contact membership, which is a key behavioral trait. While it doesn't discuss errors, auth, or other edge cases, for a simple getter this is sufficient and goes beyond a bare statement.
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 verb and resource, and no filler. Each sentence earns its place: first states purpose, second lists return fields and the exclusion/alternative.
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 single-parameter getter with no output schema, the description covers purpose, return content, and a key limitation. It is complete and self-contained, offering all necessary context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with parameter 'group_id' already described. The tool description adds no extra meaning about the parameter, so 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?
Description uses specific verb 'Get details' with resource 'single group', clearly distinguishing from sibling 'get_groups' (plural) and 'get_contacts_in_group'. It also enumerates the returned fields (name, sharing settings, team IDs, color), which adds precision.
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 states what it does NOT include (contact membership data) and directs to the alternative tool 'get_contacts_in_group'. This gives clear when-to-use and when-not-to-use guidance, which is rare and valuable.
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 discloses the exact return scope (name, icon, statuses, permissions, sharing settings) and explicitly excludes pipeline items. It does not mention potential errors or permission requirements, but covers the core behavior well.
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 with no filler. First sentence states purpose, second sentence lists return contents and explicitly names an alternative for excluded data. Efficient and well-structured.
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 read operation with one parameter and no output schema, the description fully explains what the tool returns and what it does not return, and provides an alternative for the excluded case. It is complete and self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single parameter (pipeline_id) with 100% coverage. The description adds minimal semantic value by referring to 'pipeline configuration', but the schema description is sufficient and the description doesn't introduce additional nuance.
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 ('Get') and a specific resource ('pipeline configuration'), with details on what information is returned (name, icon, statuses, permissions, sharing settings). It also explicitly distinguishes itself from related tools like search_pipeline_items and get_pipelines.
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 states what the tool does NOT return and directs users to an alternative ('Does not return pipeline items - use search_pipeline_items for that'). This provides clear when-to-use versus 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 provided, the description fully bears the responsibility of explaining behavior. It clearly lists return fields (name, required, type, input_format, valid_options), explains their meaning, and includes an example interpretation. It does not cover error cases or authentication, but the read-only nature and expected response structure are well articulated.
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 well-structured with a purpose statement, bullet list of return fields, a numbered workflow, and a concrete example. Every sentence adds actionable information, and the formatting makes it easy to parse despite its length.
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?
The tool is simple with one parameter and no output schema, yet the description thoroughly explains the return values and how to use them in a follow-up call. The workflow and example make it self-sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single pipeline_id parameter with a clear description. The tool description adds value by explaining where to obtain the pipeline_id (from get_pipelines) and clarifying that it refers to a specific pipeline, going beyond the schema's basic 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 gets custom fields for a specific pipeline, explicitly distinguishing it from the general get_custom_fields tool. It uses a specific verb-resource pair ('Get custom fields for a specific pipeline') and provides clear scope.
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 an explicit when-to-use ('use this before creating or editing pipeline items') and a step-by-step workflow referencing get_pipelines and create_pipeline_item. It does not explicitly exclude sibling tools like get_custom_fields, but the specific-pipeline framing implicitly differentiates it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns full data for each result, warns about slow performance of broad free-text searches, and explains the behavior of count_only=true (auto-paginates, returns only count/breakdowns). This goes beyond basic schema info, though it omits potential rate limits and auth requirements.
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 well-structured: a clear opening purpose, a prominent note about full data returns, a bulleted list of supported features, and an IMPORTANT callout for geographic searches. Every section earns its place without redundancy, and the use of bullets enhances scannability.
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 having no output schema and no annotations, the description provides a comprehensive overview of the tool's capabilities: full data return, filtering/sorting options, advanced filters, count_only behavior, and a pointer to get_custom_fields for custom field discovery. For a 9-parameter search tool, this covers all key aspects the agent needs to know.
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 78%, and the description adds meaningful parameter context: it explains that search_terms scans all fields (and can be slow), recommends advanced_filters for geographic fields, and advises keeping max_results low for name searches. It also clarifies count_only behavior, which complements the schema's description. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Search for contacts and companies with filters and sorting', a specific verb+resource+scope statement. It further clarifies usage for finding contacts by name, email, or other criteria, and explicitly distinguishes this from get_contact by stating 'no need to call get_contact afterward'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use the tool ('Use this tool to find contacts by name, email, or other criteria') and provides operational guidance such as using advanced_filters for geographic searches and count_only=true for large datasets. However, it does not explicitly mention alternatives like get_contacts_by_ids for ID-based lookups, so it stops short of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description takes full responsibility for behavioral disclosure. It goes beyond basic expectations by detailing the persistence mechanism ('progress is persisted after every row'), the resume point, idempotency ('rows that were already applied are never applied again'), and refusal cases. This gives the agent a clear mental model of the tool's 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 sentences that pack in purpose, behavior, and constraints without any unnecessary words. It is front-loaded with the main action and uses the second sentence to clarify guarantees and refusals. Every clause adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential aspects: when to use, what it does, safety guarantees, and refusal conditions. However, it does not mention what the function returns or how the agent knows if the resume was successful. Since there is no output schema, a brief note about the response would make it fully complete. Still, for a single-parameter tool, it is highly informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the only parameter, run_id, with a description referencing bulk_run_status. The tool description does not add extra parameter-level meaning beyond what the schema already states, 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 a specific action: 'Continue a bulk run whose worker stopped before finishing', with concrete examples (host restart, killed process). It distinguishes itself from sibling tools like bulk_execute and bulk_run_status by focusing on the resume scenario and specifying refusal conditions.
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 when to use the tool (after an interrupted run) and provides exclusion criteria ('Refuses if the run is already finished or still actively running'). It also explains that progress is persisted and rows are not reapplied, reinforcing the safety of using it after a crash. The schema reference to bulk_run_status adds additional context for checking status.
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 discloses key behaviors: it makes no changes, reports specific validation results (row count, present/absent columns, unknown columns, missing required fields, duplicate keys), and notes pacing (~1 request/second). It could further detail error handling or return format, but overall transparency is strong.
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, front-loaded with the main purpose and non-destructive guarantee. Every sentence provides essential information—scope, report contents, pacing, workflow, and input methods—with no filler or 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 validation tool with no output schema and no annotations, the description compensates well by covering purpose, safety, report contents, pacing, and input alternatives. It does not detail interactions with operation, key_column, or address_config, but the schema already documents those, so the description is sufficiently complete for the tool's complexity.
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 86%, giving a baseline of 3. The description adds value by explaining the two CSV input alternatives ('csv_content (inline) or csv_path (a readable file path)') and connecting 'field configuration' to the fields parameter. This goes beyond the schema's individual field 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 states a specific verb ('Validate'), resource ('bulk CSV'), and scope ('against a field configuration') with an explicit non-destructive emphasis ('WITHOUT making any changes'). It clearly distinguishes from sibling bulk_execute by describing validation as a dry run.
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?
Provides explicit workflow guidance: 'Always run this and review it before bulk_execute.' This names the primary alternative and gives a clear when-to-use rule. It also clarifies input methods (csv_content or csv_path).
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 burden of behavioral disclosure. It discloses partial update semantics, flat-string shortcuts for email/phone/website, and name-based custom field resolution. However, it does not describe error cases, return values, or potential side effects of is_company changes, leaving some gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, opening with the primary purpose, then clearly listing prerequisites, usage intent, and key behaviors. Every sentence adds value without redundancy, making efficient use of space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (18 parameters, nested objects, no output schema), the description adequately covers prerequisites, partial updates, and shortcut semantics. It does not explain return values or validation behavior, but for an update tool with such rich schema descriptions, it is 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 100%, so the schema already documents each parameter. The description adds meaningful semantics by explaining the flat-string shortcuts (email_address, phone_number, website_url) and how custom_field_names resolve differently from custom_fields. This goes beyond the raw schema 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 'Update an existing contact or company in Less Annoying CRM' with a specific verb and resource. It distinguishes itself from sibling tools like create_contact, delete_contact, and get_contact by explicitly framing the operation as a modification of an existing record.
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 provides explicit prerequisites, naming specific tools to call first (get_contact_schema, get_company_schema, search_contacts, get_contact) to obtain necessary schema and contact_id. It also states when to use the tool ('Use this tool to modify contact details') and clarifies partial update behavior ('Only include fields you want to change').
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 the burden of disclosing behavior. It clearly states that this is a partial update ('Only include fields you want to change') and that it does not affect pipeline items, adding meaningful context beyond a generic 'update' statement. However, it does not mention permissions, reversibility, or response format, which are minor omissions for an update 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 three short sentences, front-loaded with the core action. It contains no redundant phrases or filler, and every sentence delivers essential information about purpose, scope, or usage.
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 update tool with no output schema, the description covers the essential aspects: what it does, how it differs from related tools, the partial-update behavior, and how to find the required ID. It is not overly verbose and provides enough context for an agent to select and invoke it correctly. Missing details like authentication or return values are not critical here.
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 already describes each parameter with 100% coverage, providing the baseline. The description adds value by clarifying the partial-update semantics ('Only include fields you want to change') and by advising how to obtain the status_id ('Use get_pipeline_statuses'). This goes beyond the raw 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?
The description opens with 'Update an existing pipeline status', clearly stating the verb and resource. It further clarifies that it modifies the status definition rather than individual pipeline items, which distinguishes it from the sibling edit_pipeline_item tool. This is specific and precise.
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 usage guidance: 'Only include fields you want to change' instructs on partial updates, and 'Use get_pipeline_statuses to find status IDs' names the prerequisite lookup tool. It also clarifies the scope boundary ('not individual pipeline items'), effectively telling when not to use this tool.
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 burden of disclosing behavior. It thoroughly describes the output structure (fields like name, required, type, input_format, is_custom_field, notes) and confirms this is a read-only schema retrieval. It also reveals the important relationship to create_contact. However, it doesn't mention potential edge cases such as dynamic custom fields based on account configuration, so not a perfect 5.
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 moderately long but efficiently structured with bullet points, intro sentence, and a final usage note. Every element adds meaning, but the bullet list could potentially be condensed without losing core details. Thus 4.
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?
The description fully covers the tool's purpose, usage instructions, and return format. Since there is no output schema, it compensates by enumerating all returned attributes and their meanings. For a zero-parameter tool with no annotations, this is comprehensive and leaves no critical 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?
The tool accepts zero parameters, so the schema provides no property definitions. Per baseline, a 0-parameter tool scores 4, and the description adds no input parameter semantics (it describes output fields instead). No deduction needed.
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: retrieving the complete field schema for creating or editing companies. It distinguishes itself from siblings like get_contact_schema by specifying company context and referencing create_contact with is_company=true.
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 to ALWAYS call this tool before creating a company to understand required data. It also clarifies that companies are created via create_contact with is_company=true, which prevents misuse. While it doesn't list alternatives, the context makes the use case 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 the transparency burden. It discloses an important behavioral nuance: the tool can return either a contact or a company, and it indicates that search_contacts returns 'the same full data', implying get_contact also returns full data. It does not cover error conditions or permissions, but for a simple read-by-ID, the key behavioral context is present.
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, with the purpose stated first, followed by usage guidance, and a concise note about when not to use it. Every sentence serves a distinct purpose and no words are wasted.
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 single-parameter, read-only retrieval tool with no output schema, the description covers purpose, usage, and references the return nature ('full data'). It does not explicitly describe return structure or error handling, but the 'same full data' note and the existence of get_contact_schema mitigate the gap, making it mostly 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?
The schema describes contact_id as 'The ContactId of the record to retrieve' (100% coverage). The description adds value by clarifying that the ID can reference a company as well, and by mentioning external references as a source of the ID. This goes beyond the schema's narrow 'ContactId' label.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Retrieve' and identifies the exact resource ('a single contact or company by ID'), making the tool's function immediate. It also distinguishes itself from siblings by emphasizing 'single' and by referencing search_contacts as an alternative.
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?
Provides explicit 'when to use' ('when you already have a ContactId and need the record') and 'when not to use' ('Only use get_contact when you have an ID but not the data'), with concrete examples like webhook or external reference. It also names the alternative search_contacts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It clearly frames the tool as an informational guide with no side effects, and the content list ('What schema tools to call', 'Example workflows') discloses its function. It does not explicitly state 'read-only' or describe output format, but for a guide tool this is sufficient.
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 well-structured with a clear 'START HERE' header and bulleted content list. It is front-loaded and easy to scan. The final sentence ('Call this tool first...') slightly repeats the opening instruction, adding a small redundancy, but overall every sentence earns its place.
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?
Given it has no parameters and no output schema, the description is complete: it states purpose, content, and usage timing. The tool is self-contained as a guide, and the description fully equips an agent to understand when and why to call it.
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, so the schema fully covers input requirements. The description does not need to add parameter details; it focuses on what the tool returns, which is appropriate for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies this as a workflow guide for using the LACRM MCP, with a specific verb 'Get' and resource 'workflow guide'. It lists the exact content covered (schema tools to call, required fields, example workflows, interpreting schema responses), which fully distinguishes it from the many CRUD sibling tools.
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?
Provides an explicit usage instruction: 'Call this tool first when connecting to understand how to use the MCP correctly.' It also states what the tool explains (schema tools before create/edit, required fields, example workflows), giving clear context on when to use it relative to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses key behaviors: returns full data with all fields, count_only auto-paginates and omits results, name filters auto-resolve to IDs case-insensitively. It also explains that advanced filters require calling get_pipeline_item_schema, adding helpful 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 compact and uses clear section breaks (RETURNS FULL DATA, Required, Supports). Every sentence conveys essential usage or behavior, with no fluff or repetition. It front-loads the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no output schema, and no annotations, this description covers the most important aspects: required parameter, return payload depth, advanced filters, and count_only for large results. It does not detail pagination or sorting, but those are described in the schema. It adequately references the schema tool for advanced field names, making the tool usable end-to-end.
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 82%, so the schema already documents most parameters. The description adds value by highlighting the required pipeline_id (with pointer to get_pipelines), explaining the name-based filters as alternatives to IDs, and noting count_only is for accurate counts without returning results. These enrich the schema without restating it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Search for pipeline items within a specific pipeline' – a specific verb and resource, and clarifies the purpose by listing filter dimensions (status, user, custom field values). It distinguishes itself from sibling get_pipeline_item by explicitly noting 'no need to call get_pipeline_item afterward'.
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 states when to use the tool ('Use this to find items by status, user, or custom field values') and gives a clear alternative ('no need to call get_pipeline_item afterward'). It also provides a targeted use case for count_only. No explicit when-not list, but the guidance is clear enough.
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 the full burden of behavioral disclosure. It discloses the return value (ContactId), explains flat-string shortcuts for single values, and mentions custom_field_names for name-based resolution. It also tells the agent to call schema/users first. However, it does not explicitly mention side effects like auto-creating a company via company_name, which is left to the schema 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 concise and well-structured: a clear purpose line, followed by prerequisites in a block, then usage guidance, and then key behavioral notes. Every sentence adds value, with no redundancy. The line breaks improve readability.
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?
Given the tool's complexity (17 parameters, nested objects, no output schema), the description covers prerequisites, usage, return value, and special input modes. Combined with the fully described schema, this gives the agent all necessary information to invoke the tool correctly. There is no major gap.
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%, so the baseline is 3. The description adds meaning beyond individual schema descriptions by grouping email_address/phone_number/website_url as 'flat-string shortcuts' and explaining the advantage of custom_field_names over custom_fields. This helps the agent understand input patterns not evident from the schema alone.
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 contact or company in Less Annoying CRM' — a specific verb+resource+system statement. It clearly distinguishes this tool from siblings like edit_contact, delete_contact, and get_contact by focusing solely on creation, and explicitly mentions the is_company flag to create company records.
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 states when to use this tool: 'Use this tool when you need to add a new person or company to the CRM.' It also provides required prerequisites (get_contact_schema/get_company_schema, get_users) and explains how to switch between person and company creation via is_company. This is strong when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It warns 'This action cannot be undone' and discloses that 'the contact and all associated data will be removed,' covering irreversibility and cascade deletion. This is strong behavioral transparency for a destructive 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 concise: it states purpose, includes a prominent warning, and gives a clear prerequisite in under 50 words. Every sentence is purposeful and information is front-loaded.
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?
With only one required parameter and no output schema, the description addresses all key operational concerns: irreversible deletion, scope of data affected, and how to obtain a valid contact_id. No significant gaps remain for likely use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents contact_id with its own description, and the description reinforces that it is required while guiding valid ID discovery. This adds meaningful operational context beyond the schema's basic type/name information.
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 'Permanently delete a contact or company from Less Annoying CRM', giving a specific verb and resource. It clearly distinguishes this from sibling delete tools by naming the target and emphasizing permanence.
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 states 'Required: contact_id' and instructs users to 'Use search_contacts or get_contact to find valid contact IDs before deleting,' providing clear preparation guidance. It does not explicitly contrast with sibling delete tools, but the prerequisites and context are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral transparency burden. It discloses the exact structure of the return value (name, required, type, input_format, is_custom_field, notes), including that it returns ALL fields, and instructs the agent to call it before creating a contact. This provides actionable context beyond the tool name, without any contradictions.
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 well-structured with a clear opening sentence and a bulleted list of return fields. It is slightly verbose with the 'ALWAYS' instruction and detailed bullet list, but each element adds value and the main purpose is front-loaded.
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 zero-parameter tool with no output schema, the description is comprehensive. It explains what the tool does, what it returns in detail, and when to use it, providing an agent with all necessary information to select and 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?
The tool has zero parameters, so the input schema is empty and the description cannot add parameter-level semantics. The baseline for 0-param tools is 4, which is appropriate here since the description focuses on the output fields rather than input semantics, which is exactly what is needed.
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 explicitly states 'Get complete field schema for creating/editing contacts' with a specific verb and resource. It also lists the returned fields, making the purpose unmistakable and distinguishing it from sibling schema tools like get_company_schema or get_pipeline_item_schema.
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 provides explicit usage guidance: 'ALWAYS call this before creating a contact to understand what data is needed.' It also clarifies that the tool returns both system and custom fields, implicitly differentiating it from get_custom_fields and positioning it as the comprehensive schema retrieval for contacts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It thoroughly explains that the tool performs LIVE writes, paces requests at ~1/sec, re-validates before execution, requires confirm=true, and describes the optional async completion behavior including delivery of an editable Google Sheet. This is comprehensive and transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with distinct sections (SAFETY, ASYNC COMPLETION, Update mode) and front-loads the core behavior. Every sentence adds value, and the length is appropriate given the tool's complexity. No fluff or 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?
Given the tool's complexity (14 parameters, nested objects, no output schema), the description is remarkably complete. It covers live-write safety, validation flow, async alternatives, input format (csv_content/csv_path), and update-mode merge strategies. It even mentions the run_id return value and how to poll status, which is sufficient without an output schema.
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 79%, and the description adds meaningful context beyond the schema for key parameters: confirm=true gates live writes, async completion parameters (channel, requestor_email, identifier, request_summary) enable automatic delivery, and fields[].strategy is explained in the context of merge behavior. A few parameters like key_column and create_config are not explained in the description, but the schema provides sufficient detail for them.
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: 'Execute a bulk create/update by launching a detached background worker.' It distinguishes itself from sibling tools like bulk_validate_csv (validation) and bulk_run_status (polling) by specifying that it performs live writes and returns a run_id immediately.
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 provides explicit usage guidance: it instructs users to preview via bulk_validate_csv and obtain approval before setting confirm=true, and it explains that without async completion parameters, users should poll bulk_run_status. It clearly indicates when to use this tool and mentions alternatives.
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:

[![lacrm-mcp MCP server](https://glama.ai/mcp/servers/optimize-overseas/lacrm-mcp/badges/card.svg)](https://glama.ai/mcp/servers/optimize-overseas/lacrm-mcp)

Score Badge

Copy to your README.md:

[![lacrm-mcp MCP server](https://glama.ai/mcp/servers/optimize-overseas/lacrm-mcp/badges/score.svg)](https://glama.ai/mcp/servers/optimize-overseas/lacrm-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/optimize-overseas/lacrm-mcp'

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