HubSpot MCP

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v1.7.0
Disambiguation5/5
Every tool has a clearly distinct purpose with no ambiguity. Tools are organized by resource type (e.g., calls, crm, emails) and operation (e.g., create, get, update, search), making it easy for an agent to select the correct one. The batch vs. single-operation variants are clearly differentiated by naming and descriptions.
Naming Consistency5/5
Tool names follow a highly consistent pattern throughout: resource_action (e.g., calls_create, crm_get_company) or resource_batch_action (e.g., emails_batch_update). Minor deviations like 'products_read' vs. 'products_list' are minimal and don't break the overall consistency. The naming is predictable and systematic.
Tool Count2/5
With 111 tools, the count is excessive for typical MCP server purposes, making it overwhelming and difficult to navigate. While the server covers a broad CRM domain, the sheer number of tools (including many batch variants) feels heavy and could hinder agent efficiency, suggesting a need for consolidation or better scoping.
Completeness5/5
The tool set provides complete CRUD/lifecycle coverage for all major HubSpot resources (calls, communications, CRM objects, emails, engagements, meetings, notes, products, tasks). Each resource type includes create, read, update, delete, list, and search operations, with batch variants for scalability, leaving no obvious gaps for agent workflows.
Average 2.7/5 across 111 of 111 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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.
This repository includes a glama.json configuration file.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers none. It doesn't indicate whether this is a read-only operation, whether it has side effects, what authentication is needed, rate limits, pagination behavior, or what the return format looks like. For a search tool with 6 parameters and no output schema, this is critically inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just two words, this is a case of harmful under-specification rather than effective brevity. The description doesn't contain enough information to be useful, so its conciseness is detrimental. No structure exists beyond the minimal phrase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters including arrays and nested objects), 0% schema description coverage, no annotations, no output schema, and no sibling differentiation, the description is completely inadequate. It provides no information about what the tool actually does, how to use it, what it returns, or when to choose it over alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 6 parameters have descriptions in the schema. The tool description 'Search products' provides zero information about any parameters - not what 'query' searches, what 'limit' controls, what 'after' means for pagination, how 'sorts' work, what 'properties' returns, or how 'filterGroups' operates. The description fails completely to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search products' is a tautology that essentially restates the tool name 'products_search'. While it indicates the verb 'search' and resource 'products', it provides no additional specificity about what kind of search this is, what scope it covers, or how it differs from other search tools in the sibling list like 'crm_search_companies' or 'emails_search'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. There are multiple sibling search tools (e.g., crm_search_companies, emails_search, calls_search) but no indication whether this searches a product catalog, inventory system, or something else. No prerequisites, exclusions, or comparative context is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers almost nothing. 'Search calls with specific filters' doesn't indicate whether this is a read-only operation, whether it has side effects, what permissions are required, how results are returned, or any rate limits. For a search tool with complex filtering capabilities, this leaves critical behavioral aspects completely undocumented.
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 maximally concise - a single 5-word phrase. While this represents severe under-specification, it's not wordy or poorly structured. Every word earns its place, and there's no redundant information. The extreme brevity is a completeness failure rather than a conciseness failure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters with nested objects, 0% schema coverage, no annotations, no output schema), the description is completely inadequate. A search tool with sophisticated filtering, sorting, pagination, and property selection requires substantial explanation of its capabilities, limitations, and proper usage. The current description fails to provide any meaningful context for the agent to understand how to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for all 5 parameters, meaning the schema provides no semantic information about what 'filterGroups', 'properties', 'limit', 'after', or 'sorts' actually mean. The description 'Search calls with specific filters' only vaguely hints at the 'filterGroups' parameter but doesn't explain any parameters' purposes, formats, or relationships. This leaves all parameters semantically undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search calls with specific filters' is tautological - it essentially restates the tool name 'calls_search' with minimal elaboration. While it identifies the resource ('calls') and action ('search'), it lacks specificity about what kind of search this performs or how it differs from sibling tools like 'calls_list' or other search tools in the system. The description doesn't provide meaningful differentiation from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. With multiple sibling tools including 'calls_list', 'calls_get', and other domain-specific search tools (like 'emails_search', 'meetings_search'), the agent receives no indication of when this filtered search is appropriate versus simpler listing operations or other search variants. There's no mention of prerequisites, use cases, or comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails completely. It doesn't indicate whether this is a safe operation, what permissions are required, whether it's idempotent, what happens on failure, or what the response looks like. For a mutation tool that creates new data structures, this lack of behavioral context is a critical gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise - a single sentence with no wasted words. While this conciseness comes at the expense of completeness, the structure is clear and front-loaded with the core action. Every word in 'Create a new lead property' serves a purpose, making it efficient if inadequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, mutation operation, no annotations, no output schema), the description is completely inadequate. It doesn't explain what a lead property is, how it's used, what the parameters mean, what happens after creation, or provide any context for this significant data definition operation in a CRM system.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about any of the 11 parameters, despite 0% schema description coverage. It doesn't explain what 'name', 'label', 'type', 'fieldType', 'groupName' or any other parameters mean in the context of creating a lead property. With 11 parameters (5 required) and no schema descriptions, the description fails to add any semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new lead property' is essentially a tautology that restates the tool name 'crm_create_lead_property' with minimal elaboration. It specifies the verb 'create' and resource 'lead property', but doesn't distinguish this from sibling tools like 'crm_create_company_property' or 'crm_create_contact_property', nor does it explain what a 'lead property' actually is in this CRM context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides zero guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when this operation is appropriate, or what alternatives exist among the many sibling CRM tools. For example, it doesn't clarify when to create a lead property versus using existing properties or other lead-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Delete an engagement' implies a destructive, irreversible operation, but the description doesn't mention permissions required, whether deletion is permanent or recoverable, side effects on associated data, or any rate limits. This is inadequate for a destructive operation with zero annotation coverage.
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 maximally concise with just three words. While it's under-specified, it's not verbose or poorly structured. Every word serves a purpose, and there's no wasted language or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive deletion tool with no annotations, 0% schema description coverage, and no output schema, the description is completely inadequate. It doesn't explain what 'engagement' means, doesn't provide parameter guidance, doesn't warn about the destructive nature of the operation, and doesn't differentiate from sibling tools. This leaves the agent with insufficient information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the single parameter 'engagementId' has no documentation in the schema. The description provides no information about this parameter - what format it should be in, where to find it, or what constitutes a valid engagement ID. With no parameter information in either schema or description, this fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete an engagement' is a tautology that merely restates the tool name 'engagement_details_delete'. It doesn't specify what type of engagement is being deleted or what 'engagement' means in this context. While the verb 'delete' is clear, the resource 'engagement' remains undefined, making this minimally informative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are sibling tools like 'engagement_details_create', 'engagement_details_get', and 'engagement_details_update', but the description doesn't differentiate this deletion tool from them or explain when deletion is appropriate versus archiving or updating.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but provides almost none. 'Search notes with specific filters' doesn't indicate whether this is a read-only operation, whether it has pagination (though the schema suggests it does via 'limit' and 'after'), what authentication is required, rate limits, or what the return format looks like. For a search tool with complex filtering capabilities, this is critically insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 5 words. While this leads to severe under-specification, it's not wordy or repetitive. Every word technically serves a purpose, though far more content is needed for this complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters with nested filter/sort structures, 0% schema description coverage, no annotations, and no output schema), the description is completely inadequate. A search tool with this level of parameter complexity needs substantial explanation of filtering capabilities, return format, pagination behavior, and usage context, none of which is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 5 parameters with 0% description coverage, and the description provides no parameter information whatsoever. 'Search notes with specific filters' vaguely references filters but doesn't explain the complex filterGroups structure, what properties can be filtered on, what the 'properties' parameter does, or how sorting works. The description fails to compensate for the complete lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search notes with specific filters' restates the tool name 'notes_search' without adding meaningful specificity. It mentions 'specific filters' but doesn't explain what kind of notes or what search capabilities exist. Compared to sibling tools like 'notes_list' and 'notes_get', it doesn't clearly differentiate this as a filtered search operation versus other note retrieval methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'notes_list' (likely for unfiltered listing) and 'notes_get' (likely for retrieving specific notes by ID), there's no indication of when this filtered search is appropriate versus those other options. No prerequisites, limitations, or use case context is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Create a new note' implies a write/mutation operation, but the description doesn't disclose any behavioral traits: no information about permissions needed, whether creation is idempotent, rate limits, what happens on failure, or what the return value might be. For a mutation tool with zero annotation coverage, this is a critical gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, which is appropriately front-loaded. There's no wasted language or redundancy. However, this conciseness comes at the cost of being under-specified rather than efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations, 0% schema description coverage, no output schema, and complex nested parameters, the description is completely inadequate. It doesn't explain what a 'note' means in this context, what fields are required, how associations work, or what happens after creation. The agent would have insufficient information to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters with 0% description coverage, and the description provides zero information about parameters. It doesn't mention the 'properties' object containing note content and metadata, or the 'associations' array for linking to other objects. With schema coverage at 0%, the description fails completely to compensate, leaving parameters entirely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new note' clearly states the verb ('create') and resource ('note'), making the basic purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'notes_batch_create' or specify what kind of note system this is (HubSpot CRM based on parameter names). The purpose is clear but lacks differentiation and context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools for creating notes (e.g., 'notes_batch_create'), but the description doesn't indicate whether this is for single vs. batch creation, or any prerequisites like authentication. This leaves the agent guessing about appropriate usage contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Create a new meeting,' implying a mutation operation, but fails to mention permissions, side effects, error handling, or response format. This is inadequate for a tool with complex nested parameters and no 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 a single, clear sentence with no wasted words. It is front-loaded and efficiently communicates the basic action, though this brevity contributes to its lack of detail in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with nested parameters, no annotations, no output schema), the description is severely incomplete. It omits critical details like parameter explanations, behavioral traits, and usage context, making it inadequate for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and includes 2 parameters with nested objects (e.g., properties with required fields like hs_timestamp, associations). The description adds no information about parameter meanings, required fields, or usage, leaving all semantics undocumented and failing to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new meeting' restates the tool name with minimal elaboration, making it tautological. It specifies the verb ('Create') and resource ('meeting') but lacks any distinguishing details from sibling tools like meetings_batch_create or meetings_update, failing to clarify what makes this specific creation tool unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With sibling tools like meetings_batch_create and meetings_update available, the description offers no context on appropriate use cases, prerequisites, or distinctions, leaving the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It doesn't disclose any behavioral traits: no mention of read/write nature (though 'search' implies read-only), no pagination details (despite 'limit' and 'after' parameters), no rate limits, no authentication requirements, and no error handling. The description adds no context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a search tool, though it could be more informative. The structure is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, nested filtering logic, no output schema, and no annotations), the description is completely inadequate. It doesn't explain the search functionality, parameter usage, return format, or behavioral expectations. For a tool with rich filtering capabilities and no structured documentation elsewhere, this description fails to provide necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'lead-specific filters' but doesn't explain any parameters (filterGroups, properties, limit, after, sorts) or their semantics. The description adds no meaningful information beyond what's inferable from the tool name, leaving all 5 parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search leads with lead-specific filters' states the verb ('search') and resource ('leads'), but is vague about what 'lead-specific filters' means. It distinguishes from non-CRM siblings but not clearly from other CRM search tools like crm_search_companies or crm_search_contacts, which have similar structures but target different resources.
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 like crm_get_lead (for single lead retrieval) or other CRM search tools. The description mentions 'lead-specific filters' but doesn't explain what makes them specific or when this tool is preferred over simpler list operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'search' but provides no behavioral details: no information about permissions needed, rate limits, pagination behavior (despite 'after' and 'limit' parameters), response format, or error conditions. For a search tool with 5 parameters, this is critically inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. However, it's so brief that it under-specifies rather than being optimally concise. Every word earns its place, but more words would be justified given the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 5 parameters (including complex nested filterGroups), 0% schema coverage, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what properties can be filtered, how sorting works, what 'after' means for pagination, or what the tool returns. The agent cannot use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so parameters are undocumented in the schema. The description mentions 'specific filters' but doesn't explain any of the 5 parameters (filterGroups, properties, limit, after, sorts) or their relationships. It provides no semantic information beyond what's implied by the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search emails with specific filters' states the basic action (search) and resource (emails), but is vague about scope and lacks sibling differentiation. It doesn't specify what 'specific filters' means or how this differs from sibling tools like emails_list or emails_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like emails_list or emails_get. The description implies filtering capability but doesn't specify use cases, prerequisites, or exclusions. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description offers no behavioral information. It doesn't mention whether this is a read-only operation, what permissions are required, how results are returned, pagination behavior, rate limits, or error conditions. For a search tool with complex parameters, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at 5 words with no wasted language. It's front-loaded with the core action and resource. While under-specified, it's not verbose or poorly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 5 parameters (including complex nested objects), 0% schema description coverage, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what the tool returns, how to construct valid queries, or provide any context about the search functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 5 parameters have descriptions in the schema. The description only mentions 'specific filters' which hints at the 'filterGroups' parameter but ignores the other 4 parameters (properties, limit, after, sorts). This provides minimal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search tasks with specific filters' states the verb ('Search') and resource ('tasks'), but is vague about scope and doesn't distinguish from sibling tools like 'tasks_list' or 'tasks_get'. It lacks specificity about what kind of search this performs compared to alternatives.
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 like 'tasks_list' or 'tasks_get'. The description mentions 'specific filters' but doesn't explain when filtered search is appropriate versus basic listing or direct retrieval by ID.
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. 'Create a new call record' implies a write/mutation operation, but it doesn't disclose any behavioral traits: no information about required permissions, whether the operation is idempotent, what happens on failure, rate limits, or what the response contains. This leaves significant gaps for an agent to understand how to use this tool safely and effectively.
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 extremely concise at just 5 words, which is appropriate for a simple statement of purpose. However, this conciseness comes at the cost of completeness - it's arguably under-specified rather than efficiently informative. The structure is front-loaded with the core action but lacks any supporting context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 parameters with nested objects, no annotations, no output schema, and 0% schema description coverage), the description is severely incomplete. For a creation tool that likely requires specific data formatting and has behavioral implications, the single sentence provides inadequate context for an agent to use this tool correctly without additional documentation or trial-and-error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning none of the parameters are documented in the schema. The description provides no information about parameters beyond the generic 'call record' reference. With 2 complex parameters (properties and associations) containing nested objects and multiple sub-properties, the description fails to compensate for the complete lack of schema documentation, leaving the agent with no guidance on what data to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new call record' clearly states the verb ('Create') and resource ('call record'), making the basic purpose understandable. However, it doesn't distinguish this tool from its sibling 'calls_batch_create' or other create operations in the server, leaving ambiguity about when to use this specific tool versus batch alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'calls_batch_create' and 'calls_create' both available, there's no indication whether this is for single-record creation versus batch operations, nor any context about prerequisites, permissions, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the basic operation without disclosing any behavioral traits: no information about permissions required, rate limits, whether updates are atomic or partial, error handling for failed updates, or what the response contains. This is inadequate for a mutation tool with zero annotation coverage.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (batch mutation tool with 1 parameter but deeply nested structure), lack of annotations, 0% schema description coverage, and no output schema, the description is severely incomplete. It fails to address critical aspects like behavioral traits, parameter meanings, or expected outcomes, making it inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no descriptions for parameters. The description adds no parameter semantics beyond the tool name—it doesn't explain the 'inputs' array structure, the 'id' field, or the 'properties' object with its numerous fields. This leaves all parameter meaning undocumented.
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 action ('update multiple companies') and resource ('companies') with the specific context of batch processing ('in a single request'). It distinguishes from individual update tools like 'crm_update_company' by emphasizing batch capability, though it doesn't explicitly contrast with other batch tools like 'crm_batch_update_contacts'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when batch updates are preferable to individual updates, or how it differs from other batch tools like 'crm_batch_update_contacts' or 'crm_batch_update_objects'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Create' which implies a write/mutation operation, but doesn't address permissions, side effects, error conditions, or response format. For a tool with 11 parameters and no output schema, this leaves significant gaps in understanding how the tool behaves beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 4 words, with no wasted language. It's front-loaded with the core action and resource. While under-specified, it's structurally efficient with every word serving the basic purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, 5 required), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what a company property is, how it's used, what the parameters control, or what happens after creation. For a creation tool with significant configuration options, this minimal description leaves too much unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero information about any of the 11 parameters. With 0% schema description coverage, the description fails to compensate by explaining what parameters like 'type', 'fieldType', 'options', or 'hasUniqueValue' mean or how they should be used. This leaves all parameter semantics undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new company property' clearly states the action (create) and resource (company property), which is better than a tautology. However, it doesn't differentiate from sibling tools like crm_create_contact_property or crm_create_lead_property, nor does it specify what a 'company property' entails beyond the basic verb+resource pairing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context (e.g., when defining custom fields for companies), or sibling tools like crm_get_company_properties for retrieval. Usage is implied only by the tool name, with no explicit when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'Create' implying a mutation, but doesn't address permissions, side effects, rate limits, or response format. For a mutation tool with zero annotation coverage, 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 a single, efficient sentence with no wasted words, making it appropriately concise. However, it's front-loaded with minimal content, which could be seen as under-specified rather than optimally structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters with nested objects, no output schema, and no annotations), the description is incomplete. It doesn't explain parameter usage, behavioral traits, or output expectations, making it inadequate for effective agent use in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description adds no information about the three parameters (objectType, properties, associations), their meanings, or how they interact. It fails to compensate for the lack of schema documentation, leaving parameters semantically unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb ('Create') and resource ('new CRM object'), which provides a basic understanding of the tool's function. However, it lacks specificity about what constitutes a CRM object and doesn't differentiate from sibling tools like crm_create_company, crm_create_contact, or crm_batch_create_objects, making it vague in comparison.
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. With many sibling tools for creating specific CRM objects (e.g., companies, contacts) or batch operations, the description fails to indicate appropriate contexts, prerequisites, or exclusions, leaving the agent without usage direction.
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. 'Get all properties' suggests a read-only operation, but it doesn't specify whether this requires authentication, what permissions are needed, whether there are rate limits, or what format the results come in. For a CRM tool with zero annotation coverage, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 5 words, which is efficient for a simple tool. However, this brevity comes at the cost of completeness - it's arguably under-specified rather than optimally concise. The single sentence is front-loaded with the core purpose but lacks necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a CRM system, 2 undocumented parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'properties' means in this context, doesn't describe the return format, and doesn't provide context about the CRM system it interacts with. For a tool that likely returns structured data about company properties, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters (archived, properties) with 0% description coverage in the schema. The tool description provides no information about these parameters - it doesn't mention that you can filter by archived status or specify which properties to retrieve. With low schema coverage and no parameter information in the description, the agent has insufficient guidance on how to use these parameters effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all properties for companies' clearly states the verb ('Get') and resource ('properties for companies'), making the basic purpose understandable. However, it doesn't differentiate from sibling tools like 'crm_get_company' or 'crm_get_contact_properties' - it's unclear if this returns property definitions or actual property values on companies. The description is somewhat vague about what 'properties' means in this context.
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. There are multiple CRM-related tools in the sibling list (like crm_get_company, crm_get_contact_properties, crm_search_companies) but no indication of when this specific tool is appropriate versus those others. The agent receives no usage context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Search contacts' implies a read operation, but the description doesn't disclose whether this requires authentication, has rate limits, returns paginated results, or what happens with empty filters. The complex input schema suggests significant behavioral complexity that isn't addressed in the description.
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 extremely concise - just 6 words. It's front-loaded with the core purpose. However, this conciseness comes at the cost of being under-specified for such a complex tool with 5 parameters and no annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, nested filter structures, no output schema, no annotations), the description is incomplete. A search tool with complex filtering capabilities needs more explanation about how filters work, what properties are available, pagination behavior, and return format. The minimal description doesn't provide enough context for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but fails to do so. The description mentions 'contact-specific filters' but doesn't explain what filterGroups, properties, limit, after, or sorts parameters mean or how they work together. With 5 parameters completely undocumented in both schema and description, this is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool searches contacts with filters, which is a clear verb+resource combination. However, it doesn't differentiate from sibling tools like crm_search_companies, crm_search_leads, or crm_search_objects, all of which follow the same pattern for different entity types. The phrase 'contact-specific filters' is somewhat vague about what makes them contact-specific.
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 description doesn't mention when to use crm_search_contacts versus crm_get_contact (for single contact retrieval) or crm_batch_create_contacts (for creation). There's no context about prerequisites, permissions, or typical use cases for searching versus other contact operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it's an update operation without disclosing behavioral traits like permission requirements, whether updates are partial or full, idempotency, error handling, or side effects. It mentions 'existing' object but doesn't clarify what happens if the object doesn't exist or if properties are invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. However, it's arguably too concise given the tool's complexity (3 parameters including nested objects) and lack of annotations, potentially under-specifying rather than being optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters (including nested objects), 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what CRM object types are available, how updates work, what the response contains, or error conditions. The context demands more completeness than provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what objectType enum values represent, how objectId is formatted, or what properties object should contain. The description 'Update an existing CRM object' implies parameters but provides no semantic details beyond what's obvious from the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing CRM object' clearly states the verb (update) and resource (CRM object), but it's vague about what constitutes an update and doesn't differentiate from sibling tools like crm_update_company, crm_update_contact, or crm_batch_update_objects. It provides basic purpose but lacks specificity about scope or distinction from alternatives.
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 the many sibling update tools (e.g., crm_update_company, crm_batch_update_objects). The description doesn't mention prerequisites, constraints, or alternatives, leaving the agent to infer usage from the tool name alone.
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. 'Create a new email record' implies a write/mutation operation, but it doesn't describe what 'create' entails—whether it sends an email, saves a draft, requires specific permissions, has side effects (e.g., notifications), or what happens on success/failure. For a mutation tool with zero annotation coverage, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a basic tool description, though its brevity contributes to gaps in other dimensions. No structural issues are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 parameters with nested objects, no annotations, no output schema), the description is incomplete. It doesn't explain the tool's behavior, parameters, or output, making it inadequate for an agent to use the tool effectively. The lack of annotations and output schema increases the burden on the description, which it doesn't meet.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, meaning parameter meanings are undocumented in the schema. The description 'Create a new email record' adds no information about the 2 parameters (properties and associations) or their nested structures (e.g., what properties like hs_email_subject represent, how associations work). It fails to compensate for the schema's lack of documentation, leaving parameters largely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new email record' clearly states the verb ('Create') and resource ('email record'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like emails_batch_create, emails_update, or other creation tools in the system (e.g., calls_create, notes_create), leaving ambiguity about when to use this specific tool versus alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like emails_batch_create (for batch operations) and emails_update (for modifications), the agent receives no indication of whether this is for single-record creation, when batch operations might be preferred, or any prerequisites or constraints for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it 'gets' details, implying a read-only operation. It doesn't disclose behavioral traits like authentication requirements, rate limits, error handling, or what happens if the email doesn't exist. The description is minimal and lacks critical context for safe 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 a single, efficient sentence with no wasted words. It's front-loaded with the core action, though it could be more structured by including key parameter hints. It earns its place but is overly terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what details are returned, how to use optional parameters, or error conditions. Given the complexity, it should provide more context to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'emailId' is, what 'properties' array should contain, or what 'associations' enum values mean. The description fails to provide any semantic context beyond the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific email' clearly states the verb ('Get') and resource ('email'), but it's vague about what 'details' entail. It distinguishes from siblings like emails_list or emails_search by focusing on a single email, but lacks specificity about the scope of details retrieved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like emails_list or emails_search. The description implies it's for a specific email, but doesn't clarify prerequisites (e.g., needing an emailId) or exclusions (e.g., not for bulk operations).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It doesn't disclose whether this is a read-only operation, what permissions might be required, whether results are paginated, or any rate limits. The mention of 'optional filtering' hints at some behavior but lacks specifics.
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 extremely concise at 6 words, front-loading the core purpose. There's no wasted language, though this brevity comes at the cost of completeness. Every word earns its place in conveying the basic function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the tool's behavior, parameter usage, or relationship to sibling tools. The agent would struggle to use this effectively without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but fails to do so. It mentions 'optional filtering' but doesn't explain what parameters control this filtering (limit, after, properties, associations, archived) or their purposes. The description adds almost no meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all emails with optional filtering' clearly states the verb ('List') and resource ('emails'), but it's vague about scope and doesn't differentiate from sibling tools like emails_search or emails_get. It specifies 'all emails' but doesn't clarify if this means all emails in the system, for a user, or within a workspace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like emails_search or emails_get. The description mentions 'optional filtering' but doesn't explain what types of filtering are available or when to choose this over more specific search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Create a new engagement' implies a write/mutation operation, but the description doesn't address permissions needed, whether the operation is idempotent, what happens on failure, rate limits, or what the response contains. For a creation tool with complex nested parameters and no annotations, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 5 words. It's front-loaded with the core action and resource. While it's arguably too brief for such a complex tool, every word earns its place by communicating the essential purpose without any fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters with nested objects, no annotations, no output schema), the description is inadequate. It doesn't explain the relationship between this general engagement tool and the specific engagement type tools (calls_create, emails_create, etc.), doesn't clarify parameter usage, and provides no behavioral context for a creation operation. The description leaves too many open questions for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning none of the 3 parameters or their nested properties have descriptions in the schema. The description mentions 'with details' which hints at the 'engagement' parameter but doesn't explain what 'details' include or mention the 'associations' and 'metadata' parameters at all. This fails to compensate for the complete lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new engagement with details' clearly states the verb ('Create') and resource ('engagement'), but it's vague about what 'with details' means and doesn't distinguish this tool from sibling tools like 'engagement_details_update' or 'calls_create'. It provides basic purpose but lacks specificity about what makes this tool unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are many sibling tools for creating different types of engagements (calls_create, emails_create, meetings_create, etc.), but the description doesn't explain when to use this general engagement creation tool versus those specific ones, nor does it mention any prerequisites or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It doesn't disclose whether this is a read-only operation, what permissions are needed, whether it's paginated, rate-limited, or what the return format looks like. 'Search' implies querying, but behavioral details like performance characteristics or error conditions are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a basic tool description, though it could be more informative. The structure is straightforward but lacks depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters with 0% schema coverage, no annotations, no output schema, and complex nested objects in the input schema, the description is inadequate. It doesn't explain how to construct filter groups, what properties are available, or what the tool returns. For a search tool with this complexity, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so parameters are undocumented in the schema. The description mentions 'specific filters' which hints at the 'filterGroups' parameter but doesn't explain the other 4 parameters (properties, limit, after, sorts) or provide any syntax examples. It adds minimal value beyond the parameter names visible in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search meetings with specific filters' states the verb ('search') and resource ('meetings'), but it's vague about scope and doesn't distinguish from sibling tools like 'meetings_list' or 'meetings_get'. It doesn't specify what kind of search this is (e.g., full-text, filtered list, advanced query).
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 like 'meetings_list' or 'meetings_get'. The description mentions 'specific filters' but doesn't explain what makes this tool different from other meeting-related tools in the sibling list. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a read operation, implying it's non-destructive, but doesn't disclose behavioral traits like authentication needs, rate limits, error handling, or what happens if the ID is invalid. It's minimal and lacks context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that's front-loaded with the core action. It's appropriately sized for a simple tool, though it could be more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with 0% schema coverage, no annotations, no output schema, and a read operation, the description is incomplete. It doesn't explain return values, parameter usage, or behavioral context, leaving significant gaps for an AI agent to understand how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'ID' which maps to 'productId', but doesn't explain the 'properties' or 'associations' parameters (e.g., what they filter or include). The description adds minimal value beyond the schema, failing to clarify parameter purposes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the basic action ('Read') and target ('Object identified by ID'), but it's vague about what type of object (product vs. general object) and doesn't differentiate from sibling tools like 'products_get' or 'crm_get_object'. It's not tautological but lacks specificity.
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 like 'products_list', 'products_batch_read', or other read tools in the sibling list. The description implies usage for reading a single product by ID but doesn't specify context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'create', implying a write/mutation operation, but doesn't disclose behavioral traits like whether it's idempotent, requires specific permissions, returns the created association, or has side effects. For a tool that creates data relationships with 5 required parameters, this lack of context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically correct sentence with zero wasted words. It's front-loaded with the core action ('Create an association'), making it easy to parse. However, this conciseness comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 required parameters, no output schema, no annotations), the description is incomplete. It doesn't explain the CRM context, association types, or what happens post-creation. For a mutation tool that links business objects, more context is needed to guide effective use, especially with siblings like batch operations and 'crm_get_associations' available.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'fromObjectType'/'toObjectType' enums represent, how 'associationTypes' defines the relationship, or that IDs reference existing objects. With 5 undocumented parameters, the description fails to provide essential semantics beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create an association between two objects' clearly states the verb ('create') and resource ('association'), but it's vague about what an 'association' means in this CRM context. It doesn't specify that this links CRM entities like companies, contacts, deals, etc., which the schema reveals through enum values. While it distinguishes from obvious non-association siblings like 'crm_create_company', it doesn't differentiate from the batch version 'crm_batch_create_associations'.
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 doesn't mention prerequisites (e.g., existing objects to associate), contrast with batch operations (like 'crm_batch_create_associations'), or indicate typical use cases. The agent must infer usage from the schema and sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Create' implying a write operation, but fails to mention critical traits: whether it requires admin permissions, if it's idempotent, what happens on duplicate names, rate limits, or the response format. For a mutation tool with 11 parameters, this leaves significant gaps in understanding its behavior and constraints.
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, clear sentence with zero wasted words. It's front-loaded with the core action ('Create a new contact property'), making it easy to parse quickly. Every word earns its place by directly stating the tool's purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, 5 required, no schema descriptions, no annotations, no output schema), the description is incomplete. It doesn't compensate for the lack of structured data: no parameter explanations, no behavioral context, no output details. For a creation tool in a CRM context, this leaves the agent poorly equipped to use it correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 11 parameters are documented in the schema. The description adds no information about parameters—it doesn't explain what 'name', 'label', 'type', or other fields mean, their relationships, or provide examples. This forces the agent to guess parameter purposes, which is inadequate for a tool with complex inputs like 'options' arrays and enums.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new contact property' clearly states the verb ('Create') and resource ('contact property'), making the basic purpose understandable. However, it lacks specificity about what a 'contact property' entails (e.g., custom field in CRM) and doesn't distinguish it from sibling tools like 'crm_create_company_property' or 'crm_create_lead_property', leaving ambiguity about the exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., required permissions), when not to use it (e.g., for existing properties), or how it differs from similar tools like 'crm_create_company_property'. The agent must infer usage from the name alone, which is insufficient for effective tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it's a search operation. It doesn't disclose behavioral traits such as whether it's read-only, pagination behavior (implied by 'limit' and 'after' in schema but not described), rate limits, authentication needs, or what happens on errors. The description adds minimal value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized and front-loaded, though its brevity contributes to lack of detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters with nested structures, 0% schema coverage, no output schema, no annotations), the description is incomplete. It doesn't explain input semantics, output format, or behavioral context, making it inadequate for a search tool with rich filtering capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but fails to do so. It mentions 'company-specific filters' which loosely relates to 'filterGroups' but doesn't explain parameter purposes, required vs. optional fields, or how filters work. With 5 parameters (1 required) and no schema descriptions, the description adds insufficient meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search companies with company-specific filters' states the verb ('Search') and resource ('companies'), but is vague about what 'company-specific filters' means. It doesn't differentiate from sibling tools like crm_search_contacts or crm_search_leads beyond the resource type, nor does it specify search scope or result format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like crm_list_objects or crm_get_company, nor any prerequisites or context for usage. The description implies filtering but doesn't specify when filtering is appropriate or necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action ('Search') without disclosing behavioral traits such as permissions needed, rate limits, pagination behavior (implied by 'limit' and 'after' parameters but not explained), or what happens on errors. It doesn't add meaningful context beyond the basic 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 a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, 0% schema coverage, no output schema, no annotations), the description is incomplete. It doesn't explain return values, error handling, or provide enough detail for effective tool use, especially for a search operation with multiple object types and filtering options.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but only mentions 'filters' generically. It doesn't explain the six parameters (e.g., objectType, filterGroups, properties, limit, after, sorts) or their purposes, leaving them undocumented. The description adds minimal value beyond the schema's structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search CRM objects using filters' clearly states the verb ('Search') and resource ('CRM objects'), but it's vague about scope and doesn't distinguish from sibling tools like crm_search_companies, crm_search_contacts, etc. It mentions 'filters' which hints at the input schema but lacks specificity about what types of objects can be searched.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like crm_search_companies or crm_list_objects. The description implies a general search capability but doesn't specify prerequisites, exclusions, or comparative contexts with other search tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is an update operation, implying mutation, but doesn't disclose critical behavioral traits such as required permissions, whether changes are reversible, rate limits, or what happens to unspecified properties. This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for its limited content and front-loaded with the core action, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 parameters with nested objects, 0% schema coverage, no annotations, no output schema), the description is inadequate. It doesn't explain the input structure, behavioral implications, or expected outcomes, leaving the agent with insufficient information to use the tool effectively in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, meaning no parameters are documented in the schema. The description mentions 'email record' but doesn't explain what 'emailId' or 'properties' mean, nor does it clarify the complex nested structure with many fields like 'hs_email_subject'. It adds minimal semantic value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing email record' clearly states the verb ('Update') and resource ('email record'), but it's vague about what specific aspects can be updated and doesn't distinguish this tool from sibling tools like 'emails_batch_update' or other update tools in the system. It provides basic purpose but lacks specificity.
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 like 'emails_batch_update' or 'emails_create', nor does it mention prerequisites such as needing an existing email ID. It simply states what the tool does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose if this is a read-only operation (implied by 'Get' but not explicit), authentication needs, rate limits, error conditions, or what the return format might be, which is insufficient for a tool with no annotation coverage.
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, clear sentence with no wasted words. It's front-loaded and efficiently conveys the core action, making it easy to parse despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, no output schema, and a simple but undocumented parameter, the description is incomplete. It lacks details on behavior, parameters, and output, making it inadequate for reliable tool invocation in a context with many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'engagementId' is, its format, or where to obtain it, leaving the single required parameter undocumented beyond the schema's type constraint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific engagement' clearly states the verb ('Get') and resource ('engagement'), but it's vague about what 'details' entails and doesn't differentiate from sibling tools like 'engagement_details_get_associated' or 'engagement_details_list'. It's adequate but lacks specificity about scope or content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context (e.g., after listing engagements), or exclusions, leaving the agent to infer usage from the name alone among many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Update' implies a mutation operation, but it doesn't disclose behavioral traits like permission requirements, whether partial updates are allowed, what happens to unspecified fields, or error conditions. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 5 words, with no wasted language. It's front-loaded with the core action, though this brevity comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters (including nested objects), 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what constitutes valid updates, expected outcomes, or error handling. The context demands more information than provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 3 parameters (including a complex nested object), the description adds no semantic information beyond the tool name. It doesn't explain what 'engagementId' refers to, what fields in 'engagement' can be updated, or what 'metadata' is for. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing engagement's details' clearly states the action (update) and target (engagement details), which is better than a tautology. However, it doesn't specify what constitutes 'details' or differentiate from sibling tools like 'engagement_details_create' or 'calls_update', leaving the purpose somewhat vague.
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. With sibling tools like 'engagement_details_create' and 'engagement_details_get', there's no indication of prerequisites (e.g., needing an existing engagement) or when this update is appropriate versus other update tools in the system.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Delete a meeting' implies a destructive operation, but it doesn't specify whether this is permanent or reversible, what permissions are required, whether it affects associated data, or what happens on success/failure. For a mutation tool with zero annotation coverage, this leaves critical behavioral aspects undocumented.
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 at just three words, with zero wasted language. It's front-loaded with the core action and resource. While this brevity contributes to under-specification in other dimensions, as pure conciseness it's optimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations, 0% schema coverage, and no output schema, the description is inadequate. It doesn't explain the deletion behavior, parameter requirements, error conditions, or what happens to related data. Given the complexity of a delete operation and the lack of structured documentation, this leaves too many gaps for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the single parameter 'meetingId' is undocumented in the schema. The description provides no additional information about this parameter—no explanation of what format the ID should be, where to find it, or validation rules. With low coverage and no compensation in the description, this creates ambiguity for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a meeting' clearly states the verb (delete) and resource (meeting), making the basic purpose understandable. However, it lacks specificity about what constitutes a 'meeting' in this context and doesn't distinguish this tool from potential alternatives like 'meetings_archive' or 'meetings_batch_archive' that appear in the sibling list.
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. With sibling tools like 'meetings_archive', 'meetings_batch_archive', and other meeting-related operations available, there's no indication whether this is for single meetings, permanent vs. soft deletion, or any prerequisites. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it 'gets details' without disclosing behavioral traits like read-only nature, authentication requirements, rate limits, error handling, or what happens if the note doesn't exist. It's minimally informative for a retrieval 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 a single, clear sentence with zero wasted words. It's appropriately sized for a simple retrieval tool and front-loads the core purpose immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what details are returned, how parameters affect the response, or provide necessary context for proper tool invocation given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'noteId' is, what 'properties' array controls, or what 'associations' does despite these being critical for proper usage. The description fails to provide meaningful parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific note' clearly states the verb ('Get') and resource ('note'), but it's vague about what 'details' includes and doesn't differentiate from sibling tools like notes_list or notes_search. It's functional but lacks specificity about scope or content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like notes_list or notes_search. The description implies retrieval of a single note by ID, but doesn't explicitly state this is for known IDs versus searching or listing notes, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states what the tool does ('List all notes with optional filtering') without any information about permissions required, rate limits, pagination behavior, what 'optional filtering' entails, or the format of returned data. This is inadequate for a tool with 5 parameters and no 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 a single, efficient sentence with zero wasted words. It's appropriately sized and front-loaded with the core functionality. Every word earns its place by conveying essential information about the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no annotations, no output schema, and 0% schema description coverage), the description is incomplete. It doesn't explain what the tool returns, how filtering works, or any behavioral aspects. For a list operation with multiple filtering options and no structured output documentation, this leaves significant gaps for an AI agent to understand proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 5 parameters (limit, after, properties, associations, archived) are documented in the schema. The description mentions 'optional filtering' which hints at some parameters but doesn't specify which ones or their purposes. It fails to compensate for the complete lack of schema documentation, leaving parameters semantically undefined.
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 'List all notes with optional filtering' clearly states the verb ('List') and resource ('notes'), and specifies scope ('all notes') and capability ('optional filtering'). However, it doesn't differentiate from sibling tools like notes_search or notes_get, which also retrieve notes data, so it doesn't achieve full sibling differentiation.
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. With sibling tools like notes_search, notes_get, and notes_list in the same server, there's no indication of when this list operation is preferred over search or get operations, nor any mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Update an existing note' implies a mutation operation, but it doesn't describe permissions required, whether the update is destructive or reversible, rate limits, error conditions, or what happens to unspecified properties. For a mutation tool with zero annotation coverage, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence 'Update an existing note', which is front-loaded and wastes no words. While it may be too brief for completeness, it earns full marks for conciseness as every word contributes directly to the core purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mutation tool with 2 parameters, nested objects, and 0% schema coverage) and no annotations or output schema, the description is incomplete. It fails to explain parameter meanings, behavioral traits, or usage context, making it inadequate for an agent to confidently invoke the tool. The conciseness comes at the cost of essential details needed for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no descriptions for the 2 parameters (noteId and properties) or their nested properties. The description adds no parameter semantics beyond implying that 'noteId' identifies the note and 'properties' contains update data. It doesn't explain the structure of 'properties' (e.g., that it includes hs_note_body, hs_timestamp, hubspot_owner_id) or their purposes, leaving parameters largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing note' clearly states the action (update) and resource (note), making the basic purpose understandable. However, it doesn't distinguish this from sibling tools like 'notes_batch_update' or 'notes_update' (if there were multiple note update tools), and it lacks specificity about what aspects of a note can be updated. It's not tautological but remains somewhat vague.
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 doesn't mention prerequisites (e.g., needing an existing note ID), compare it to batch update tools like 'notes_batch_update', or specify contexts where it's appropriate. Without such information, the agent must infer usage from the tool name alone, which is insufficient for optimal selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states what the tool does ('Read multiple tasks') without any information about permissions required, rate limits, whether it's idempotent, what happens with invalid IDs, or the format/scope of returned data. This leaves critical behavioral aspects completely undocumented.
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 at just 6 words, front-loading the core functionality with zero wasted words. Every element ('Read multiple tasks in a single request') directly contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch read operation with 1 parameter (a complex array structure), 0% schema description coverage, no annotations, and no output schema, the description is severely inadequate. It doesn't explain the request format, response format, error conditions, or any behavioral characteristics needed for proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate but fails to do so. It mentions 'multiple tasks' which hints at the array structure, but provides no explanation of what 'inputs' contains, what 'id' represents, what 'properties' and 'associations' mean, or how to format requests. The description adds minimal value beyond what's obvious from the tool name.
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 action ('Read multiple tasks') and scope ('in a single request'), which is specific and distinguishes it from single-task read operations. However, it doesn't explicitly differentiate from other batch read tools for different resources (like calls_batch_read or emails_batch_read), though the tool name itself provides that context.
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 like tasks_get (for single tasks) or tasks_list (for listing tasks with filters). There's no mention of prerequisites, performance considerations, or error handling for batch operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Create a new task' implies a write operation, but it doesn't specify permissions needed, whether creation is idempotent, error handling, or what happens on success/failure. For a mutation tool with complex nested parameters, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, with no wasted language. It's front-loaded with the core action and resource. While it may be too brief for adequate tool understanding, it earns full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create/mutation tool with 2 complex nested parameters, 0% schema description coverage, no annotations, and no output schema, the description is severely inadequate. It doesn't explain what a 'task' is in this system, what fields are required beyond the schema's technical requirements, or what the tool returns. The agent would struggle to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are completely undocumented in the schema. The description provides no information about the 2 parameters (properties and associations) or their nested structures. While the schema defines the structure, the description adds zero semantic meaning about what these parameters represent or how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new task' clearly states the action (create) and resource (task), but it's vague about what constitutes a 'task' in this context and doesn't distinguish this tool from sibling tools like 'tasks_batch_create' or 'tasks_create' in other contexts. It provides basic purpose but lacks specificity.
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 like 'tasks_batch_create' or 'tasks_update'. The description doesn't mention prerequisites, constraints, or typical use cases, leaving the agent with no contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Get' which implies a read operation, but doesn't disclose behavioral traits like whether it requires authentication, rate limits, error conditions, or what happens with invalid taskIds. The description is minimal and leaves critical 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?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a simple retrieval tool and front-loads the core purpose immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters (0% documented in schema), no annotations, no output schema, and multiple sibling tools, the description is inadequate. It doesn't explain what details are returned, how parameters affect the response, or how this differs from other task-related tools. The minimal description leaves too many gaps for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 3 parameters, the description doesn't compensate at all. It mentions 'specific task' which hints at taskId, but provides no information about the optional 'properties' and 'associations' parameters or their purposes. The description adds minimal value beyond what's implied by the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific task' clearly states the verb ('Get') and resource ('task'), but it's vague about what 'details' includes and doesn't differentiate from sibling tools like tasks_list or tasks_search. It's adequate but lacks specificity about the scope of information retrieved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like tasks_list (for multiple tasks) or tasks_search (for filtered searches). The description implies it's for a single task but doesn't explicitly state this or mention prerequisites like needing a taskId.
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. 'Update an existing task' implies a mutation operation, but it doesn't specify required permissions, whether updates are partial or full, error handling, or what happens to unspecified properties. For a mutation tool with zero annotation coverage, this leaves critical behavioral traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, with zero wasted language. It's front-loaded with the core action and resource. While it lacks detail, every word earns its place by conveying the essential function without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (mutation tool with 2 parameters, nested objects, 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't explain parameter meanings, behavioral constraints, or output expectations. For a tool that modifies data, this minimal description leaves too many gaps for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions no parameters at all, failing to explain that taskId identifies the task and properties contains the fields to update (like hs_task_body, hs_task_priority). With 2 parameters and nested objects, the description adds no semantic value beyond what's inferable from the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing task' clearly states the action (update) and resource (task), but it's vague about what specifically can be updated. It doesn't distinguish this tool from sibling tools like tasks_batch_update or tasks_archive, which handle different update scenarios. The purpose is understandable but lacks specificity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing taskId), when to use tasks_batch_update for multiple tasks, or when tasks_update is preferred over tasks_create for new tasks. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a creation operation but doesn't mention authentication requirements, rate limits, error handling, or whether the operation is idempotent. For a batch mutation tool, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized for a basic declaration, though it lacks depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch creation tool with no annotations, 0% schema description coverage, and no output schema, the description is incomplete. It doesn't explain the complex nested parameter structure, expected behavior, or return values, leaving critical gaps for the agent to understand and use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning parameters are undocumented in the schema. The description adds no information about the 'inputs' parameter or its structure (which includes properties and associations arrays). This leaves the agent with no semantic understanding of what data to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('multiple contacts'), specifying it's for batch creation in a single request. However, it doesn't differentiate from sibling tools like crm_batch_create_companies or crm_batch_create_leads, which have similar batch creation patterns for different resources.
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 like crm_create_contact (for single contact creation) or other batch tools. It lacks context about prerequisites, limitations, or typical use cases for batch operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a list operation with optional filtering, but doesn't mention whether this is a read-only operation, what permissions might be required, whether results are paginated, or any rate limits. The description is minimal and leaves critical 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single 7-word sentence that efficiently communicates the core purpose. It's front-loaded with the main action and resource. However, for a tool with 5 parameters and no annotations, this brevity comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters with 0% schema coverage, no annotations, no output schema, and multiple sibling tools with overlapping functionality, the description is insufficiently complete. It doesn't help an agent understand how to properly invoke this tool versus alternatives, what the parameters mean, or what behavior to expect from the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 5 parameters, the description doesn't compensate by explaining what the parameters mean. It mentions 'optional filtering' but doesn't specify which parameters provide filtering, what 'after', 'createdAfter', 'createdBefore', 'limit', or 'properties' mean, or how they should be used. The description adds minimal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all meetings with optional filtering' clearly states the verb ('List') and resource ('meetings'), and specifies the scope ('all') with optional filtering. However, it doesn't differentiate from sibling tools like 'meetings_search' or 'meetings_get', which appear to serve similar purposes in the same domain.
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 like 'meetings_search' or 'meetings_get'. It mentions optional filtering but doesn't specify what types of filtering are available or when to choose this over other meeting-related tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a read operation, but doesn't mention permissions required, rate limits, pagination behavior, error handling, or what happens when some IDs in the batch don't exist. For a batch operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 appropriately concise with two sentences that directly address the tool's purpose. However, the second sentence is somewhat redundant with the first and could be more efficiently integrated. No unnecessary information is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch read tool with 4 parameters (3 required), 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain parameter meanings, return format, error conditions, or how this differs from other product retrieval methods. The description leaves too many open questions for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for all 4 parameters, the description only mentions 'idProperty' and vaguely references 'internal ID' (likely mapping to 'inputs.id'). It doesn't explain what 'propertiesWithHistory', 'properties', or the structure of 'inputs' objects mean. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Read') and resource ('batch of products'), and specifies two retrieval methods: by internal ID or unique property values. However, it doesn't explicitly differentiate this from sibling tools like 'products_read' (singular read) or 'products_list' (list all), which would be needed for 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 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 like 'products_read' (single product), 'products_list' (list all), or 'products_search' (filtered search). It mentions the 'idProperty' parameter but doesn't explain when batch reading by unique property is preferable to other methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an update operation (implying mutation) but doesn't mention permission requirements, whether updates are reversible, rate limits, error handling for partial failures, or what the response contains. For a batch mutation tool, this leaves critical behavioral aspects undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point without unnecessary words. It's appropriately sized for a batch update operation, though it could be slightly more structured by separating key concepts.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch mutation tool with no annotations, 0% schema description coverage, and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., permissions, side effects), comprehensive parameter explanations, and output expectations, making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'internal ID' and the 'idProperty' query param, which helps clarify the 'id' and 'idProperty' fields in the schema. However, it doesn't explain the 'objectWriteTraceId' parameter or the nested 'properties' object containing fields like 'name', 'price', etc., leaving most parameters without semantic context.
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 action ('Update a batch of products') and identifies the target resource ('products'), which provides a specific verb+resource combination. However, it doesn't explicitly differentiate this tool from sibling tools like 'products_update' (single update) or 'products_batch_create' (batch creation), missing full sibling distinction.
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 like 'products_update' for single updates or 'products_batch_create' for batch creation. It mentions the 'idProperty' parameter but doesn't explain when batch updating is preferred over individual updates or what prerequisites might exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool creates records, implying a write/mutation operation, but doesn't disclose any behavioral traits: no information about permissions required, whether it's idempotent, error handling for partial failures, rate limits, or what happens if validation fails. For a batch creation tool with complex nested parameters, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a tool whose complexity is largely in the schema. The sentence is front-loaded with the core action and resource, making it immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (batch creation with deeply nested input schema, no annotations, and no output schema), the description is inadequate. It doesn't explain the parameter structure, expected behavior, error handling, or return values. For a mutation tool with 0% schema description coverage, the description should provide much more context to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The tool description mentions 'multiple call records' but doesn't explain the 'inputs' parameter structure, required fields like 'hs_call_body' and 'hs_call_title', or the nested 'properties' and 'associations' objects. The description adds minimal value beyond what's inferable from the parameter name 'inputs'.
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 action ('Create multiple call records') and resource ('call records'), and specifies the operational context ('in a single request'). It distinguishes from the singular 'calls_create' sibling tool by emphasizing batch capability. However, it doesn't explicitly differentiate from other batch operations like 'calls_batch_update' beyond the 'create' verb.
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 like 'calls_create' for single records or other batch operations. There's no mention of prerequisites, limitations, or scenarios where batch creation is preferred over individual creation. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Read' implying a safe operation, but doesn't disclose behavioral traits like authentication requirements, rate limits, error handling, or response format. For a batch tool with complex input schema, this lack of behavioral context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—'Read multiple call records in a single request' front-loads the core action and scope perfectly. Every word earns its place, making it 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (batch operation with nested input schema), lack of annotations, and no output schema, the description is incomplete. It doesn't address how results are returned, error cases, or practical usage details, leaving the agent under-informed for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'multiple call records' hinting at an array input, but doesn't explain the 'inputs' parameter structure, required 'id' fields, optional 'properties' and 'associations', or their purposes. The description adds minimal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Read multiple call records in a single request' clearly states the verb ('Read'), resource ('call records'), and scope ('multiple...in a single request'), making the purpose specific and understandable. It distinguishes from individual read tools like 'calls_get' by emphasizing batch processing, though it doesn't explicitly name alternatives.
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 like 'calls_get' (for single records) or 'calls_list' (for listing with filtering). It mentions batch reading but doesn't specify scenarios where batch is preferred over individual reads or list operations, leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an update operation (implying mutation) but doesn't mention permissions required, whether changes are reversible, rate limits, error handling for partial failures, or what the response looks like. For a batch mutation tool with zero annotation coverage, this leaves critical behavioral aspects undocumented.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch mutation tool with no annotations, 0% schema description coverage, and no output schema, the description is inadequate. It doesn't explain parameter semantics, behavioral traits like error handling, or provide usage guidance relative to sibling tools. The agent would struggle to use this tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no descriptions for any parameters. The tool description mentions 'multiple call records' but doesn't explain the structure of the 'inputs' array, what 'id' refers to, what properties can be updated, or the meaning of fields like 'hs_call_disposition'. The description adds minimal value beyond what's inferable from the schema structure alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('update multiple call records') and scope ('in a single request'), which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'calls_update' (single update) or 'calls_batch_archive' (batch archive), leaving some ambiguity about when to choose this exact batch operation over alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'calls_update' for single updates or other batch operations. The description mentions it's for 'multiple' records but doesn't specify thresholds, prerequisites, or performance considerations that would help an agent decide between batch and individual updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Get details' which implies a read-only operation, but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or what happens if the callId is invalid. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.
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, clear sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a simple retrieval tool. Every word earns its place by conveying essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain the return format, error handling, or parameter usage beyond a basic hint. For a tool with undocumented parameters and no structured output guidance, more context is needed to help the agent use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions 'a specific call' which hints at the callId parameter, but doesn't explain the 'properties' or 'associations' parameters at all. It adds minimal value beyond what's inferable from parameter names, failing to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('details of a specific call'), making the purpose unambiguous. It distinguishes from siblings like calls_list (which lists multiple calls) and calls_search (which searches calls). However, it doesn't specify what kind of details are retrieved, leaving some ambiguity compared to more specific alternatives like engagement_details_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid callId), differentiate from similar tools like calls_batch_read (for multiple calls) or engagement_details_get (for engagement details), or indicate any constraints. The agent must infer usage from the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'optional filtering' but doesn't clarify if this is a read-only operation, what permissions are needed, whether it supports pagination (implied by 'limit' and 'after' parameters but not stated), or what the output format is. For a list tool with 5 parameters and no annotations, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly, though this conciseness comes at the cost of detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, 0% schema coverage, no annotations, no output schema), the description is inadequate. It doesn't explain parameter meanings, behavioral traits, or output expectations, leaving the agent with insufficient information to use the tool effectively beyond a basic understanding of its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 5 parameters are documented in the schema. The description only vaguely mentions 'optional filtering' without explaining what parameters are available or their purposes (e.g., 'limit' for pagination, 'archived' for filtering status). It adds minimal value beyond the schema, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('calls'), and mentions optional filtering, which provides basic purpose. However, it doesn't distinguish this tool from sibling tools like 'calls_search' or 'calls_get', which likely offer different filtering or retrieval approaches, so it doesn't fully differentiate from alternatives.
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 like 'calls_search' or 'calls_get', nor does it mention any prerequisites or exclusions. It merely states the function without context, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a read operation ('Get'), but doesn't disclose authentication needs, rate limits, error conditions, or what the return format looks like. For a tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a simple get operation and front-loads the core purpose immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero annotation coverage, 0% schema description coverage, no output schema, and 2 parameters, the description is incomplete. It doesn't explain what 'communication preferences' include, how results are structured, or provide any operational context needed for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It mentions 'contact' which maps to 'contactId', but doesn't explain what 'subscriptionId' is or how these parameters interact. With 2 parameters and no schema descriptions, this leaves significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('communication preferences for a contact'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'communications_get_subscription_status' or 'communications_get_subscription_definitions', which have similar 'get' operations on related resources.
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 doesn't mention sibling tools like 'communications_update_preferences' for modifying preferences or 'communications_get_subscription_status' for related data, leaving the agent with no context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It implies a read-only operation ('Get'), but doesn't specify whether it requires authentication, has rate limits, returns paginated results, or handles errors. For a tool with two required parameters and no output schema, this leaves significant behavioral gaps that could confuse an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core functionality without unnecessary words. It's perfectly front-loaded with the main action and resource. Every word earns its place, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 required parameters with 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns, how to interpret results, or provide any context about the subscription system. For a tool that presumably returns status data for multiple entities, more completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions 'subscription status for multiple contacts' which hints at the purpose of 'contactIds' but doesn't explain what 'subscriptionId' represents, the format of contact IDs, or any constraints. It adds minimal value beyond what's inferable from the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'subscription status for multiple contacts', making the purpose unambiguous. It distinguishes itself from sibling tools like 'communications_get_preferences' and 'communications_get_subscription_definitions' by focusing on contact-level status rather than definitions or preferences. However, it doesn't specify the exact scope (e.g., current vs historical status) which prevents 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 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 doesn't mention sibling tools like 'communications_update_subscription_status' for modifications or 'communications_get_preferences' for related data, nor does it specify prerequisites or appropriate contexts. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Subscribe') but fails to mention critical details like required permissions, whether this is a write operation, potential side effects (e.g., sending confirmation emails), or error handling. This is inadequate for a mutation tool with zero annotation coverage.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized, with no wasted verbiage, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters (one with an enum), 0% schema coverage, no annotations, and no output schema, the description is insufficient. It lacks details on parameters, behavioral traits, return values, and usage context, leaving significant gaps for an AI agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The tool description adds no information about the three parameters (contactId, portalSubscriptionLegalBasis, portalSubscriptionLegalBasisExplanation), leaving their meanings, formats, and usage completely undocumented. This fails to compensate for the schema gap.
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 action ('Subscribe') and resource ('a contact to all email communications'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'communications_unsubscribe_contact' or 'communications_update_preferences' beyond the obvious opposite action, missing explicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'communications_update_preferences' or 'communications_update_subscription_status'. The description lacks context about prerequisites, such as whether the contact must exist or have specific permissions, leaving usage unclear.
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. While 'unsubscribe' implies a mutation operation, the description doesn't disclose important behavioral traits like whether this action is reversible, what permissions are required, whether it affects historical data, or what the expected response looks like. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's appropriately sized for the tool's apparent purpose and gets straight to the point without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters (including legal basis parameters that suggest compliance requirements), no annotations, and no output schema, the description is insufficient. It doesn't explain the parameters, behavioral implications, or what happens after the unsubscribe operation. Given the complexity suggested by the legal basis parameters, more context is needed for proper tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 3 parameters (one required, one with enum values), the description provides no information about any parameters. It doesn't mention the contactId parameter (which is required), nor does it explain the legal basis parameters that appear in the schema. The description fails to compensate for the complete lack of schema documentation.
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 action ('unsubscribe') and target ('a contact from all email communications'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'communications_update_subscription_status' or 'communications_update_preferences', which might offer similar functionality.
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. There are multiple sibling tools related to communications and subscriptions (e.g., 'communications_update_subscription_status', 'communications_update_preferences'), but the description doesn't indicate when this specific unsubscribe operation is appropriate versus those other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Update' implies a mutation operation, the description doesn't specify what permissions are required, whether changes are reversible, if there are rate limits, or what the response looks like. For a tool that modifies contact preferences (potentially sensitive data), this lack of behavioral context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for what it communicates, though what it communicates is insufficient for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 required parameters (including a nested object with legal/enum fields), 0% schema description coverage, no annotations, and no output schema, the description is severely inadequate. It doesn't explain parameter relationships, behavioral implications, or what constitutes valid preference updates, leaving critical gaps for proper tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate but fails to do so. It mentions 'communication preferences' but doesn't explain what the three required parameters (contactId, subscriptionId, preferences) represent or how they relate to each other. The preferences object contains complex fields like legalBasis with specific enum values that are completely undocumented in the description.
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 action ('Update') and resource ('communication preferences for a contact'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'communications_update_subscription_status' or 'communications_subscribe_contact', which appear to handle similar communication preference operations.
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 like 'communications_update_subscription_status' or 'communications_subscribe_contact/unsubscribe_contact'. There's no mention of prerequisites, appropriate contexts, or exclusions that would help an agent choose correctly among similar communication tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it's an update operation. It doesn't disclose whether this is a destructive mutation, what permissions are required, how errors are handled for partial updates, rate limits, or what the response contains. 'Update' implies mutation, but critical behavioral details are missing for a batch operation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for what it conveys. Every word earns its place, though it could benefit from additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch mutation tool with 2 parameters (including a complex array), 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the operation's impact, error handling, or return values. The agent lacks sufficient context to use this tool confidently without trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what subscriptionId refers to, the structure of updates array, the meaning of status enum values, or legalBasis fields. The agent must deduce everything from the raw schema without semantic context.
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 'Update subscription status for multiple contacts' clearly states the action (update), target resource (subscription status), and scope (multiple contacts). It distinguishes from sibling tools like communications_subscribe_contact and communications_unsubscribe_contact by specifying batch/multiple operations. However, it doesn't explicitly mention the subscriptionId parameter's role.
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 like communications_subscribe_contact or communications_unsubscribe_contact. It doesn't mention prerequisites, error conditions, or when batch updates are preferred over individual operations. The agent must infer usage from the name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it's a creation operation. It doesn't disclose whether this requires specific permissions, if it's idempotent, what happens on partial failures, rate limits, or the response format. For a batch mutation tool, this leaves critical behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch creation tool with 3 complex parameters (including nested arrays/objects), no annotations, and no output schema, the description is severely incomplete. It doesn't address parameter meanings, behavioral expectations, error handling, or when to use versus alternatives, leaving the agent with insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'fromObjectType', 'toObjectType', or 'inputs' represent, their relationships, or the structure of association types. This leaves all 3 parameters semantically undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('create') and resource ('multiple associations'), making the purpose understandable. However, it doesn't distinguish this batch operation from the singular 'crm_create_association' sibling tool, which would require explicit comparison for 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 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 batch tool versus the singular 'crm_create_association' tool, nor any prerequisites, limitations, or error handling considerations. The description merely restates the action without contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Create' implies a write/mutation operation, the description doesn't mention authentication requirements, rate limits, error handling for partial failures, whether the operation is atomic, or what happens if duplicate companies are submitted. For a batch creation tool with complex nested parameters, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 6 words, front-loading the core purpose without any wasted words. Every word earns its place, though this conciseness comes at the cost of completeness for such a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch creation tool with complex nested parameters (1 top-level parameter containing arrays of objects with multiple properties and associations), no annotations, no output schema, and 0% schema description coverage, this description is severely inadequate. It doesn't explain what the tool returns, how to handle errors, or provide any semantic context for the numerous property fields, making it insufficient for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate but fails to do so. It mentions 'multiple companies' which hints at an array structure, but doesn't explain the 'inputs' parameter, the nested 'properties' and 'associations' objects, or any of the 16+ property fields. The agent would have no semantic understanding of what data to provide beyond the bare schema structure.
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 action ('Create multiple companies') and resource ('companies'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'crm_create_company' (single creation) or other batch creation tools like 'crm_batch_create_contacts', leaving room for confusion about when to choose this specific batch tool.
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 batch creation tool versus the single-company creation tool ('crm_create_company') or other batch tools for different resources. It mentions 'in a single request' which hints at efficiency benefits, but doesn't specify scenarios like bulk imports, data migration, or performance considerations that would help an agent make the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a creation tool ('Create'), implying mutation, but doesn't disclose behavioral traits like required permissions, whether it's idempotent, error handling for partial failures, rate limits, or what the response contains. For a batch mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the core action, zero waste. It's appropriately sized for a simple statement of purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (batch mutation with nested parameters), no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It lacks crucial details for safe and effective use, such as parameter explanations, behavioral constraints, or differentiation from sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'multiple CRM objects' and 'single request', hinting at batch inputs, but doesn't explain the two parameters ('objectType' and 'inputs') or their semantics (e.g., what 'objectType' enum values mean, structure of 'inputs' array). The description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('multiple CRM objects'), specifying it's a batch operation ('in a single request'). It distinguishes from single-create tools like 'crm_create_object' but doesn't explicitly differentiate from other batch create tools like 'crm_batch_create_companies'.
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. There are many sibling tools (e.g., 'crm_batch_create_companies', 'crm_batch_create_contacts') for specific object types, but the description doesn't mention these or provide context for choosing this generic batch tool over type-specific ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It confirms this is a deletion operation (destructive), but doesn't address critical aspects like permissions needed, whether deletions are permanent/reversible, rate limits, error handling for partial failures, or what happens to associated data. For a batch destructive tool, this is inadequate.
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 at just 6 words, with zero wasted language. It's front-loaded with the core action and immediately specifies the batch nature. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch destructive operation with 3 parameters (2 with enums), 0% schema coverage, no annotations, and no output schema, the description is severely incomplete. It doesn't explain what associations are, how they're identified, what the object types mean, error scenarios, or return values. The agent lacks sufficient context to use this tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but fails to do so. It mentions 'multiple associations' which hints at the 'inputs' array parameter, but provides no explanation of what 'associations' are, what 'fromObjectType' and 'toObjectType' represent, or the structure of the 'inputs' objects. The three parameters remain largely unexplained.
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 action ('Delete multiple associations') and scope ('in a single request'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from its sibling 'crm_delete_association' (single vs. batch) or other batch deletion tools like 'crm_batch_delete_objects', leaving room for improvement in sibling distinction.
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. There's no mention of when batch deletion is preferred over single deletion ('crm_delete_association'), what prerequisites might exist, or any limitations. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Delete' clearly indicates a destructive operation, the description lacks critical details: whether deletions are permanent or reversible, what permissions are required, rate limits, error handling for partial failures, or what happens to associated data. For a destructive batch operation with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without waste. It's appropriately sized for a tool with a straightforward name and clear action, though the brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive batch operation with 2 parameters (0% schema coverage), no annotations, and no output schema, the description is incomplete. It lacks critical context about behavioral implications, parameter usage, error handling, and differentiation from sibling tools. The agent would struggle to use this tool correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but provides no parameter information. It doesn't explain what 'objectType' represents (the enum values like 'companies', 'contacts'), what format 'objectIds' should be in, or any constraints (e.g., maximum batch size). With 2 undocumented parameters, the description adds no value beyond what the bare schema provides.
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 action ('Delete multiple') and resource ('CRM objects'), and specifies it's done 'in a single request', which adds useful context about batch operation. However, it doesn't differentiate from sibling tools like 'crm_delete_object' or 'crm_batch_delete_associations', which would require more specificity about what distinguishes this batch deletion from those alternatives.
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 like 'crm_delete_object' (single deletion) or other batch operations. There's no mention of prerequisites, limitations, or appropriate contexts for batch deletion versus individual deletions, leaving the agent with insufficient usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is an update operation (implying mutation) but doesn't disclose critical behavioral traits like required permissions, whether updates are atomic or partial, error handling for failed updates, rate limits, or what happens if some objects don't exist. For a batch mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for what it communicates and front-loads the core purpose immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch mutation tool with 2 parameters (0% schema coverage), no annotations, and no output schema, the description is incomplete. It lacks parameter explanations, behavioral context, usage guidance relative to siblings, and any information about return values or error conditions. The tool's complexity demands more comprehensive documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'objectType' means (the enum values like 'companies', 'contacts'), what 'inputs' array contains, or the structure of individual input objects. With 2 parameters completely undocumented in both schema and description, this is inadequate.
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 action ('Update multiple') and resource ('CRM objects'), and specifies 'in a single request' which indicates batch processing. However, it doesn't differentiate from sibling batch update tools like crm_batch_update_companies, crm_batch_update_contacts, or crm_batch_update_leads, which are more specific versions of this general tool.
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. There are many sibling tools including specific batch update tools (e.g., crm_batch_update_companies) and single-object update tools (e.g., crm_update_object), but the description doesn't mention any of these or provide context for choosing this general batch tool over more specific ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Create' implies a write operation, but it doesn't specify permissions required, whether validation is strict or permissive, what happens on duplicate data, or what the response contains. The mention of 'validated properties' adds minimal context about input validation but lacks details on validation rules or error handling.
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 at just 6 words, front-loading the essential action and resource. Every word earns its place with no wasted verbiage, though this conciseness comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with complex nested parameters (2 parameters with deep object/array structures), no annotations, no output schema, and 0% schema description coverage, the description is severely inadequate. It doesn't explain what gets created, how validation works, what the response looks like, or provide any operational context needed for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 2 parameters (one required, one optional with complex nested structure), the description adds almost no semantic value. It mentions 'validated properties' which hints at the 'properties' parameter but doesn't explain what validation entails or describe the 'associations' parameter at all. This fails to compensate for the schema's lack of descriptions.
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 action ('Create') and resource ('new company'), making the purpose immediately understandable. However, it doesn't distinguish this from sibling tools like 'crm_batch_create_companies' or 'crm_create_contact', which would require explicit differentiation to earn 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?
The description provides no guidance on when to use this tool versus alternatives like batch creation tools or other CRM creation tools. There's no mention of prerequisites, limitations, or comparative context with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Create' implies a write/mutation operation, but the description doesn't mention permission requirements, whether the operation is idempotent, what happens on duplicate emails, or what the response looks like. 'Validated properties' hints at input validation but doesn't specify validation rules or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 6 words, with no wasted language. It's front-loaded with the core purpose and includes the validation aspect as additional context. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with complex nested parameters (2 parameters with deep object/array structures), 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens after creation, what validation occurs, error conditions, or how to interpret results. The agent would struggle to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 2 parameters (one required, one optional with complex nested structure), the description provides minimal parameter guidance. It mentions 'validated properties' which hints at the 'properties' parameter, but doesn't explain what properties are available, their formats, or the purpose of the 'associations' parameter. The description doesn't compensate for the complete lack of schema documentation.
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 action ('Create') and resource ('contact'), and specifies 'with validated properties' which adds useful context about input validation. However, it doesn't explicitly differentiate from sibling tools like crm_batch_create_contacts or crm_create_lead, which would be needed for 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 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 like batch creation tools or other CRM creation tools. It doesn't mention prerequisites, constraints, or typical use cases for creating individual contacts versus batch operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only mentions 'validated properties' without detailing validation rules, error handling, permissions required, or mutation effects. It fails to disclose critical behavioral traits like whether creation is idempotent, response format, or rate limits, making it insufficient 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 a single, efficient sentence with zero waste, front-loading the core action. Every word earns its place, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 parameters with nested objects, 0% schema coverage, no annotations, no output schema), the description is inadequate. It lacks details on validation, error handling, return values, and usage context, failing to provide the completeness needed for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but only vaguely references 'validated properties' without explaining the 'properties' and 'associations' parameters. It adds minimal meaning beyond the schema, failing to clarify parameter purposes, required fields, or validation specifics, leaving significant gaps.
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 action ('Create') and resource ('new lead'), making the purpose evident. It distinguishes from siblings like 'crm_batch_create_leads' by specifying single creation, though not explicitly. However, it lacks explicit sibling differentiation, preventing 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 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 like 'crm_batch_create_leads' or 'crm_create_contact' is provided. The description implies usage for lead creation but offers no context on prerequisites, dependencies, or exclusions, leaving the agent without operational direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a deletion operation, implying it's destructive, but doesn't mention critical aspects like whether deletions are permanent, require specific permissions, have side effects on related data, or provide confirmation responses. 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 a single, direct sentence with zero wasted words. It's perfectly front-loaded, immediately conveying the core action without unnecessary elaboration or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with 4 undocumented parameters and no annotations, the description is severely inadequate. It doesn't explain what an 'association' is in this context, how parameters work together, what happens upon deletion, or what (if anything) is returned. No output schema exists to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 4 parameters are documented in the schema. The description doesn't explain what 'fromObjectType', 'toObjectType', 'fromObjectId', or 'toObjectId' mean or how they identify the association to delete. This leaves the agent guessing about parameter meaning and usage.
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 action ('Delete') and resource ('association between two objects'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'crm_batch_delete_associations' or 'crm_delete_object', which would require more specificity about scope or method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'crm_batch_delete_associations' for bulk operations or 'crm_delete_object' for deleting objects themselves. The description lacks context about prerequisites, error conditions, or typical use cases for association deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Delete' clearly indicates a destructive operation, the description provides no additional context about permanence, recovery options, side effects, or what happens to associated data. For a destructive tool with zero annotation coverage, this represents a significant gap in safety information.
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 at just three words, with no wasted language. It's front-loaded with the essential information (delete operation) and contains no unnecessary elaboration. This represents optimal conciseness for such a basic description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with 2 required parameters, 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what constitutes a 'CRM object', provide examples, describe the deletion process, or mention any constraints. The minimal description leaves too many open questions for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning neither parameter has descriptions in the schema. The tool description provides no information about what 'objectType' or 'objectId' represent, their formats, or valid values beyond what's in the enum. For a tool with 2 required parameters and no schema descriptions, the description fails to compensate for the documentation gap.
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 'Delete a CRM object' clearly states the action (delete) and resource (CRM object), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'crm_batch_delete_objects' or 'crm_delete_association', but the verb+resource combination is specific enough for basic understanding.
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 like 'crm_batch_delete_objects' for bulk operations or other deletion tools in the sibling list. The description offers no context about prerequisites, permissions needed, or typical use cases for this specific deletion method.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'Get' implies a read operation, the description doesn't mention important behavioral aspects like pagination (implied by 'after' and 'limit' parameters), authentication requirements, rate limits, error conditions, or what format the associations are returned in. This leaves significant gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a tool with this level of complexity and gets straight to the point without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters (3 required), no annotations, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't explain parameter meanings, return format, pagination behavior, or when to use versus alternatives. The minimal description leaves too many gaps for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage (no parameter descriptions in the schema), the description provides no information about any of the 5 parameters. It mentions 'specific type' which vaguely relates to fromObjectType/toObjectType, but doesn't explain what these parameters mean, their enum values, or how they interact. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('all associations of a specific type between objects'), making the purpose understandable. However, it doesn't distinguish this tool from sibling CRM tools like 'crm_list_association_types' or 'crm_get_object', which could cause confusion about when to use each.
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. With many sibling CRM tools available (like crm_list_association_types, crm_get_object, crm_search_objects), the description offers no context about appropriate use cases, prerequisites, or distinctions from similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get' implies a read-only operation, but it doesn't specify whether this requires authentication, returns paginated results, has rate limits, or what happens if no contacts exist. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a simple-sounding tool and front-loads the core action ('Get all properties for contacts'), making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 undocumented parameters, no annotations, no output schema), the description is inadequate. It doesn't explain what 'properties' are in this CRM context, how results are structured, or any behavioral constraints. For a tool that likely returns structured data, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters (archived and properties) with 0% schema description coverage, meaning neither parameter is documented in the schema. The description adds no information about these parameters—it doesn't explain what 'archived' filters, what 'properties' array should contain, or if both are optional. This fails to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'all properties for contacts', making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'crm_get_contact' or 'crm_get_company_properties', which would require more specificity about what 'properties' means in this context.
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. With many sibling tools available (e.g., 'crm_get_contact' for individual contact data, 'crm_get_company_properties' for company properties), the description offers no context about appropriate use cases, prerequisites, or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Get all properties' implies a read-only operation, but it doesn't disclose whether this requires authentication, has rate limits, returns paginated results, or what format the properties come in. For a tool with no annotation coverage, this is insufficient behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a simple-sounding tool and gets straight to the point without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters (0% schema coverage), no annotations, no output schema, and multiple sibling tools, the description is inadequate. It doesn't explain parameter usage, return format, or how this differs from other lead/property tools. The minimal description leaves too many questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. The description mentions 'all properties' but doesn't explain the 'archived' boolean parameter or the 'properties' array parameter (which appears to allow filtering specific properties despite the 'all' claim). This creates confusion rather than adding clarity.
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 'Get all properties for leads' clearly states the verb ('Get') and resource ('properties for leads'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'crm_get_lead' or 'crm_get_company_properties', but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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. With sibling tools like 'crm_get_lead' (which presumably gets lead data) and 'crm_get_contact_properties', there's no indication of when this specific properties-focused tool is appropriate versus other lead-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Get' implies a read operation, but the description doesn't disclose authentication requirements, rate limits, error conditions, or what happens with invalid IDs. It mentions retrieving 'a single CRM object' but doesn't specify the return format or whether it includes all fields by default.
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 at just 7 words, front-loaded with the core purpose. There's no wasted language or unnecessary elaboration, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters (2 required), 0% schema description coverage, no annotations, and no output schema, the description is insufficient. It doesn't explain parameter usage, return values, error handling, or how this tool relates to the many sibling CRM retrieval tools, leaving significant gaps for an agent to understand proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 4 parameters, the description provides no information about what 'objectType', 'objectId', 'properties', or 'associations' mean. The description doesn't mention that 'objectType' has specific enum values or that 'properties' and 'associations' are optional arrays for filtering/expanding results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'single CRM object by ID', which is specific and actionable. However, it doesn't distinguish this tool from sibling CRM tools like 'crm_get_company', 'crm_get_contact', or 'crm_get_lead', which appear to serve similar purposes for specific object types.
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. With many sibling tools like 'crm_get_company', 'crm_get_contact', and 'crm_list_objects', there's no indication whether this is a generic retrieval tool that supersedes specific ones or when each should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions filtering and pagination capabilities, it doesn't describe important behavioral aspects like whether this is a read-only operation, what permissions are required, rate limits, error conditions, or the format/structure of returned data. For a tool with 5 parameters and no output schema, this leaves significant gaps in understanding how the tool behaves.
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, efficient sentence that front-loads the core purpose. Every word earns its place, with no redundant or unnecessary information. The structure is clear and direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no annotations, no output schema, and 0% schema description coverage, the description is insufficiently complete. It doesn't explain the return format, error handling, authentication requirements, or provide enough context about parameter usage. Given the complexity and lack of structured documentation, the description should do much more to help an agent understand how to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 5 parameters, the description fails to compensate for the lack of parameter documentation. While it mentions 'optional filtering and pagination' which hints at some parameters, it doesn't explain what 'objectType' values mean, what 'properties' refers to, how 'after' works for pagination, what 'limit' constraints exist, or what 'archived' controls. The description adds minimal value beyond what the bare schema provides.
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 action ('List') and resource ('CRM objects of a specific type'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like crm_search_objects or crm_list_association_types, which could cause confusion about when to use this specific listing tool versus search or other list operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'optional filtering and pagination' which implies some usage context, but provides no explicit guidance on when to use this tool versus alternatives like crm_search_objects or crm_get_object. With many sibling tools available, the lack of differentiation guidance is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Update' implies a mutation operation, it doesn't specify what 'validated properties' means in practice - whether validation failures cause errors, what permissions are required, whether updates are partial or complete, or what happens to unspecified properties. This leaves significant gaps 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 extremely concise at just 7 words, with no wasted language. It's front-loaded with the core action and resource. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, 0% schema description coverage, no output schema, and a complex nested parameter structure, the description is inadequate. It doesn't address key questions about validation behavior, error handling, permission requirements, or what constitutes a successful update. The agent would struggle to use this tool correctly without trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 2 parameters (leadId and a complex properties object), the description provides minimal help. 'validated properties' hints at validation but doesn't explain what properties are valid, what validation rules apply, or how the properties object should be structured. The schema shows 20+ possible properties with formats and enums, but the description adds almost no semantic context.
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 action ('Update') and resource ('an existing lead'), making the purpose immediately understandable. It adds specificity with 'with validated properties' which suggests some validation occurs. However, it doesn't distinguish this tool from sibling tools like crm_update_company or crm_update_contact, which follow the same pattern.
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. There are multiple sibling tools for updating different CRM entities (companies, contacts, objects) and batch operations, but the description doesn't help the agent choose between them. It also doesn't mention prerequisites like needing an existing lead ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states it creates records without behavioral details. It doesn't disclose whether this sends emails, saves drafts, requires authentication, has rate limits, returns created IDs, or handles errors. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the core functionality without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex batch creation tool with 1 parameter (but deeply nested), 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'email records' are, how they relate to sending emails, what the tool returns, or any behavioral constraints, leaving critical gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter information. It doesn't explain the 'inputs' array structure, required fields like 'hs_email_subject', or the complex nested objects for properties and associations. The description fails to compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('multiple email records'), specifying it's a batch operation ('in a single request'). It distinguishes from non-batch siblings like 'emails_create', but doesn't explicitly contrast with other batch tools like 'emails_batch_update' or 'emails_batch_read'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, limitations, or compare with single-create ('emails_create') or other batch operations. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it's a read operation. It doesn't disclose behavioral traits like rate limits, authentication requirements, error handling for partial failures, pagination, or response format. The description is minimal and lacks critical operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose ('Read multiple email records') and adds a key constraint ('in a single request') without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (batch operation with nested parameters), 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't cover parameter meanings, behavioral expectations, or output structure, leaving significant gaps for an AI 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain the 'inputs' array structure, the 'id' field, 'properties' array, or 'associations' enum. The schema details (like required fields and enum values) are undocumented in the description, leaving parameters largely unexplained.
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 'Read multiple email records in a single request' clearly states the verb ('Read') and resource ('multiple email records'), distinguishing it from single-read tools like emails_get. However, it doesn't explicitly differentiate from other batch read tools (e.g., notes_batch_read, products_batch_read) beyond the email resource focus.
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 like emails_get (for single emails) or emails_list (for listing/filtering). It mentions 'multiple email records' but doesn't specify thresholds or use cases where batch reading is preferred over individual calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'update' implies mutation, the description doesn't mention required permissions, whether updates are atomic/partial, rate limits, error handling for partial failures, or what happens to unspecified properties. It lacks crucial context for a batch 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 a single, efficient sentence that states the core functionality without unnecessary words. It's appropriately sized for a straightforward batch operation and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch mutation tool with no annotations, 0% schema description coverage, and no output schema, the description is inadequate. It doesn't address behavioral aspects like permissions, atomicity, or error handling, nor does it explain parameter semantics. The tool's complexity demands more complete guidance than provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It mentions 'multiple email records' which hints at the 'inputs' array parameter, but doesn't explain the structure of individual update objects, the meaning of 'id' and 'properties', or the specific email fields that can be updated. The description adds minimal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('update') and resource ('multiple email records'), and specifies the operational context ('in a single request'). However, it doesn't distinguish this tool from its sibling 'emails_update' (singular) or other batch operations like 'emails_batch_create' or 'emails_batch_archive' beyond the 'update' action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'emails_update' (singular update) or other batch operations. It mentions 'multiple email records' which implies batch processing, but doesn't specify thresholds, prerequisites, or when batch updating is preferred over individual updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a 'Get' operation, implying it's read-only, but doesn't confirm this explicitly or mention any side effects. It doesn't describe the return format (e.g., list of engagement objects), pagination behavior (implied by limit/offset parameters but not explained), error conditions, or authentication requirements. For a tool with 7 parameters and no annotation coverage, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a tool with a clear primary function, though the brevity comes at the cost of missing important contextual information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'engagements' encompass, what 'associated' means, how the filtering parameters work, what the return format looks like, or any behavioral characteristics. The agent would struggle to use this tool effectively without additional documentation or trial-and-error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning none of the 7 parameters have descriptions in the schema. The description only mentions 'an object' without explaining what 'objectType' and 'objectId' refer to, or what the other parameters (startTime, endTime, activityTypes, limit, offset) control. It doesn't clarify what 'associated' means in practice or how filtering works. The description adds minimal value beyond the parameter names themselves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('engagements associated with an object'), making the purpose understandable. It distinguishes this from sibling tools like 'engagement_details_get' (which likely gets a single engagement) and 'engagement_details_list' (which likely lists all engagements without object association). However, it doesn't specify what types of engagements are retrieved (e.g., calls, emails, meetings, etc.), leaving some ambiguity.
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 doesn't mention when to use 'engagement_details_list' instead, or how this differs from other engagement-related tools like 'calls_get' or 'meetings_get'. There's no context about prerequisites, permissions needed, or typical use cases for retrieving associated engagements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a list operation with filtering, implying read-only behavior, but doesn't disclose pagination behavior (limit/offset usage), rate limits, authentication requirements, or what 'engagements' encompass. For a tool with 5 parameters and no annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with a single sentence that front-loads the core purpose. Every word earns its place, with no redundant information or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters with 0% schema coverage, no annotations, no output schema, and complex sibling tools (like engagement_details_get), the description is incomplete. It doesn't explain what 'engagements' are, how results are returned, or provide enough context for effective tool selection and use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'optional filtering' but doesn't explain what parameters are available or their purposes (e.g., limit for pagination, startTime/endTime for date ranges, activityTypes for filtering). The description adds minimal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('engagements'), and specifies optional filtering. It doesn't distinguish from sibling tools like 'engagement_details_get' or 'engagement_details_get_associated', but provides a specific, 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 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 like 'engagement_details_get' (for single engagement) or 'engagement_details_get_associated' (for related engagements). The description mentions optional filtering but doesn't explain when filtering is appropriate or what 'engagements' represent in this context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it creates meetings without disclosing behavioral traits. It doesn't mention authentication requirements, rate limits, error handling, whether it's idempotent, what happens on partial failures, or the response format. 'Create' implies mutation, but no safety or side effect information is given.
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 at just one sentence with no wasted words. It's front-loaded with the core action and efficiently communicates the batch nature. Every word earns its place in this minimal description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch creation tool with complex nested parameters (1 parameter with deeply nested structure), no annotations, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't address the tool's complexity, provide usage context, explain parameters, or describe expected behavior - leaving significant gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'inputs' contains, the required meeting properties, or the association structure. The description provides zero semantic context beyond the tool name, leaving all parameter meaning undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('create') and resource ('multiple meetings'), specifying it's a batch operation ('in a single request'). It distinguishes from non-batch siblings like 'meetings_create', but doesn't explicitly differentiate from other batch tools like 'meetings_batch_update' or 'meetings_batch_archive'.
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 doesn't mention prerequisites, when batch creation is preferred over single creation, or compare it to other batch operations like 'meetings_batch_update' or 'meetings_batch_archive' that exist in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an update operation (implying mutation) but doesn't mention permissions required, whether updates are atomic, rate limits, or what happens if some updates fail. For a batch mutation tool with zero annotation coverage, this leaves critical behavioral traits undocumented.
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, efficient sentence with zero wasted words. It's appropriately sized for a tool with a clear primary function, though it could benefit from additional context in subsequent sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch mutation tool with 1 parameter (but complex nested structure), 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the input format, behavioral constraints, error handling, or what the tool returns. Given the complexity and lack of structured documentation, the description should provide significantly more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'multiple meetings' which hints at the array structure, but doesn't explain the 'inputs' parameter, the required 'id' and 'properties' fields, or the specific meeting properties that can be updated (like hs_meeting_title, hs_meeting_outcome with its enum values). The description adds minimal value beyond what's visible in the schema structure.
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 action ('Update multiple meetings') and scope ('in a single request'), which is specific and distinguishes it from single-meeting update tools like 'meetings_update'. However, it doesn't explicitly mention what properties can be updated or reference the sibling 'meetings_batch_archive' for alternative batch operations.
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 like 'meetings_update' (for single meetings) or 'meetings_batch_archive' (for batch deletions). It doesn't mention prerequisites, error handling for partial failures, or performance considerations for batch operations.
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. While 'Get details' implies a read operation, it doesn't specify whether this requires authentication, has rate limits, returns partial or complete data, or handles errors. For a tool with 3 parameters and no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately communicates the core purpose without any wasted words. It's appropriately sized for a simple retrieval tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters (one required), no annotations, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't explain what data is returned, how parameters affect the response, or provide any behavioral context needed for proper tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for all 3 parameters, the description provides no information about what 'meetingId', 'properties', or 'associations' mean or how they should be used. The description doesn't compensate for this complete lack of parameter documentation in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('details of a specific meeting'), making the purpose immediately understandable. However, it doesn't distinguish this tool from potential siblings like 'meetings_list' or 'meetings_search' that might also retrieve meeting information, which prevents 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 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. With sibling tools like 'meetings_list' (for multiple meetings) and 'meetings_search' (for filtered searches), the agent receives no help in selecting the appropriate tool for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Update' implies a mutation operation, but the description doesn't disclose any behavioral traits: no information about permissions required, whether changes are reversible, rate limits, error conditions, or what happens to unspecified properties. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a basic tool description and front-loads the core action. Every word earns its place by conveying the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, 0% schema description coverage, no output schema, and complex nested parameters, the description is incomplete. It lacks crucial context about what can be updated, behavioral constraints, error handling, and response format. The agent would struggle to use this tool correctly without additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions 'an existing meeting' which hints at the meetingId parameter, but doesn't explain the properties object or any of its nested fields (title, body, location, times, outcome, owner). For a tool with 2 parameters (one being a complex nested object), this minimal guidance is insufficient.
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 'Update an existing meeting' clearly states the verb ('Update') and resource ('an existing meeting'), making the purpose immediately understandable. It distinguishes from sibling tools like 'meetings_create' and 'meetings_delete' by specifying it's for existing meetings. However, it doesn't specify what aspects can be updated (title, time, etc.), which prevents 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 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 doesn't mention prerequisites (e.g., needing a meetingId), when to use batch_update instead, or what distinguishes it from meetings_create or meetings_delete. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a creation operation but doesn't disclose behavioral traits like authentication requirements, rate limits, whether it's idempotent, error handling for partial failures, or what the response looks like. For a batch write tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for conveying the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch creation tool with no annotations, 0% schema description coverage, and no output schema, the description is incomplete. It lacks details on parameters, behavioral context, error handling, and output format, making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'multiple notes' but provides no details about the 'inputs' parameter structure, required fields like 'hs_note_body', optional fields, or the 'associations' array. The description adds minimal value beyond what's inferred from the tool name.
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 action ('create multiple notes') and scope ('in a single request'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'notes_create' (single note creation) or 'notes_batch_update' (batch updates), though the batch nature is implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'notes_create' for single notes or other batch operations. The description lacks context about prerequisites, limitations, or typical use cases for batch creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it's a read operation. It doesn't disclose behavioral traits like whether it's safe (non-destructive), what permissions are required, rate limits, error handling for invalid IDs, or the format/scope of returned data. 'Read' implies non-destructive, but this isn't explicitly confirmed.
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, efficient sentence with zero waste. It's front-loaded with the core purpose and appropriately sized for a simple tool, though it could benefit from additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch read tool with 1 parameter (a complex array structure), 0% schema description coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain the parameter structure, return values, error conditions, or usage context, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but provides no parameter information. It doesn't explain what 'inputs' contains (array of note IDs with optional properties/associations), what 'properties' or 'associations' mean, or how to structure requests. The description adds no meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read multiple notes') and resource ('notes'), specifying it's a batch operation ('in a single request'). It distinguishes from individual read operations like 'notes_get' but doesn't explicitly differentiate from other batch operations like 'notes_batch_archive' or 'notes_batch_update'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'notes_get' (for single notes) or 'notes_list' (for listing all notes). The description implies batch reading but doesn't specify scenarios where batch reading is preferred over individual reads.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Update' which implies mutation, but doesn't disclose behavioral traits like permissions required, whether updates are atomic or partial, rate limits, or what happens on failure. For a batch mutation tool with zero annotation coverage, this is a significant gap in safety and operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and scope. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (batch mutation tool), no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It lacks crucial context like response format, error handling, permissions, and detailed parameter guidance. For a tool that modifies multiple resources, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'multiple notes' which hints at the array structure, but doesn't explain the 'inputs' parameter, the required 'id' and 'properties' fields, or the specific properties like 'hs_note_body'. The description adds minimal value beyond what's inferred from the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('multiple notes'), and specifies it's a batch operation ('in a single request'). It doesn't explicitly distinguish from sibling tools like notes_update (single note) or notes_batch_create, but the batch nature is implied. The purpose is clear but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like notes_update (single note update) or notes_batch_create. The description mentions 'multiple notes' but doesn't specify thresholds or scenarios where batch is preferred. There's no mention of prerequisites, limitations, or error handling for partial updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Create' implies a write/mutation operation, but the description doesn't disclose behavioral traits like required permissions, whether it's idempotent, rate limits, error handling, or what happens on partial failures. It lacks crucial context for a batch 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?
Extremely concise with a single sentence ('Create a batch of products') that front-loads the core action. No wasted words or redundant information, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch creation tool with no annotations, 0% schema description coverage, and no output schema, the description is incomplete. It doesn't cover parameter meanings, behavioral expectations, error scenarios, or output format, leaving significant gaps for an AI agent to infer correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'batch' but doesn't explain the 'inputs' parameter structure, required fields (like 'properties'), or the meaning of nested properties (e.g., 'name', 'price', 'sku'). The description adds minimal value beyond the schema's structural hints.
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 'Create a batch of products' clearly states the verb ('create') and resource ('products'), with 'batch' indicating multiple items. It distinguishes from sibling tools like 'products_create' (singular) and 'products_batch_read' (read operation). However, it doesn't specify what 'products' are in this context (e.g., CRM products, e-commerce items).
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 like 'products_create' (for single products) or 'products_batch_update' (for updates). The description implies batch creation but doesn't mention prerequisites, constraints, or typical use cases (e.g., bulk imports).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool creates a product and returns it with ID, which indicates a write operation, but fails to disclose critical behavioral traits such as required permissions, whether creation is idempotent, error handling, or rate limits. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and outcome without unnecessary words. Every part of the sentence contributes directly to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations, 0% schema coverage, no output schema, and complex nested parameters, the description is inadequate. It lacks details on input semantics, behavioral expectations, error cases, and output format, leaving the agent poorly equipped to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It vaguely references 'given properties' but doesn't explain what properties are available (e.g., name, price), their formats, or constraints. With 1 parameter (a nested object) and no schema descriptions, the description adds minimal semantic value beyond the schema structure.
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 action ('Create a product') and the resource ('product'), specifying that it uses given properties and returns the created object with ID. It distinguishes from sibling tools like products_list or products_update by focusing on creation, 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 on when to use this tool versus alternatives like products_batch_create or products_update. The description implies usage for creating new products but lacks context about prerequisites, constraints, or comparative scenarios with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits such as whether this is a write operation (implied but not explicit), permissions required, rate limits, atomicity of batch operations, or what happens on partial failures. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized and front-loaded, directly stating the core functionality without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch creation tool with complex nested parameters (1 parameter with deep nesting), no annotations, and no output schema, the description is insufficient. It doesn't address mutation behavior, error handling, or output expectations, leaving the agent with inadequate context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but provides no parameter information. It doesn't explain the 'inputs' array structure, required fields like 'hs_task_body' and 'hs_task_subject', or the meaning of nested properties and associations. This leaves all parameter semantics undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('multiple tasks'), making the purpose evident. It distinguishes from sibling tools like 'tasks_create' by specifying batch capability ('in a single request'), though it doesn't explicitly contrast with other batch tools like 'tasks_batch_update'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'tasks_create' for single tasks or other batch operations. The description lacks context about prerequisites, error handling, or performance considerations for batch creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Update multiple tasks' implies a mutation operation, but the description doesn't address critical behavioral aspects like authentication requirements, rate limits, error handling, whether updates are atomic or partial, or what happens with invalid inputs. This is a significant gap for a batch 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 extremely concise at just 6 words, with zero wasted language. It's front-loaded with the core action and scope, making it efficient for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch mutation tool with complex nested parameters (1 top-level parameter with deep nesting), 0% schema description coverage, no annotations, and no output schema, the description is severely inadequate. It doesn't provide enough context about behavior, parameters, or expected outcomes for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'multiple tasks' which hints at the array structure, but with 0% schema description coverage and a complex nested parameter structure (inputs array with id and properties objects), the description adds minimal value. It doesn't explain what 'inputs' contains, what properties can be updated, or the required fields, leaving the agent to decipher the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('multiple tasks'), making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from its sibling 'tasks_update' (single task update) or 'tasks_batch_create' (batch creation), which would be needed for 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 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 doesn't mention when batch updates are preferable to individual updates, what prerequisites might exist, or any limitations. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a list operation with filtering, implying read-only behavior, but doesn't disclose pagination behavior (limit/after parameters suggest cursor-based pagination), rate limits, authentication requirements, or what 'all tasks' means in context (e.g., accessible to current user). The description is minimal and lacks behavioral details needed for safe invocation.
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?
Extremely concise with a single sentence that front-loads the core purpose. No wasted words or redundant information. The structure is optimal for a basic description, though it could benefit from additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters with 0% schema coverage, no annotations, no output schema, and sibling tools like tasks_search, the description is incomplete. It doesn't explain parameter meanings, return format, pagination, or when to use versus alternatives. For a list tool with filtering capabilities, this leaves significant gaps for an AI agent to understand and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so parameters are undocumented in schema. The description only mentions 'optional filtering' generically, without explaining any of the 5 parameters (limit, after, properties, associations, archived). It doesn't clarify what 'properties' refers to, what 'associations' does, or how 'archived' affects results. The description adds minimal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all tasks with optional filtering' clearly states the verb ('List') and resource ('tasks'), and specifies scope ('all') with capability ('optional filtering'). It distinguishes from siblings like tasks_get (single task) and tasks_search (search with criteria), but doesn't explicitly differentiate from tasks_batch_read (batch retrieval). The purpose is specific and actionable.
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 like tasks_search or tasks_batch_read. The description mentions 'optional filtering' but doesn't specify what filtering options exist or when to prefer this over search tools. There's no mention of prerequisites, context, or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool archives/deletes multiple calls, indicating a destructive operation, but fails to mention critical details like permissions required, whether deletion is permanent or reversible, error handling for invalid IDs, or rate limits. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action and resource. There is no wasted verbiage, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, lack of annotations, 0% schema description coverage, and no output schema, the description is incomplete. It fails to address critical aspects like behavioral implications, parameter details, error handling, or output expectations, leaving the agent with insufficient context for safe and effective 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 schema description coverage is 0%, so the description must compensate. It implies the parameter is for multiple call records but doesn't specify format (e.g., array of strings), constraints (e.g., max batch size), or semantics (e.g., what happens if some IDs fail). The description adds minimal value beyond the schema's structural definition, resulting in a baseline score.
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 action ('Archive (delete)') and resource ('multiple call records'), making the purpose evident. However, it doesn't explicitly differentiate from its sibling 'calls_archive', which likely archives single calls, leaving some ambiguity about when to choose batch vs. single operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'calls_archive' or 'calls_batch_delete'. The description implies batch processing but lacks explicit context about prerequisites, constraints, or comparative use cases with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an update operation, implying mutation, but doesn't mention permissions required, whether changes are reversible, rate limits, or what happens to unspecified properties. For a mutation tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't explain what properties can be updated, what the response looks like, or behavioral considerations like error handling. Given the complexity (nested object with 9 properties), more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it provides no parameter information beyond what's implied by 'update an existing call record.' The schema shows 2 parameters (callId and properties object with 9 sub-properties), but the description doesn't explain their purpose, required fields, or constraints. Baseline 3 is appropriate given the schema does the heavy lifting structurally.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('an existing call record'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'calls_batch_update' or 'calls_create', which would require mentioning it's for single-record updates rather than batch operations or creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'calls_batch_update' for multiple updates or 'calls_create' for new records. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a creation operation but doesn't disclose behavioral traits like required permissions, rate limits, whether the operation is idempotent, what happens on partial failures, or what the response contains. For a batch mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose. It's appropriately sized and front-loaded with no wasted words or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the input schema (deeply nested with many properties), lack of annotations, and no output schema, the description is insufficient. It doesn't explain the structure of lead data, required fields, association handling, or what the tool returns. For a batch creation tool with rich parameters, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'multiple leads' which hints at the array structure of the 'inputs' parameter, but doesn't explain the nested properties, required fields, or the 'associations' field. The description adds minimal value beyond what's implied by the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('create') and resource ('leads'), and specifies it's for multiple leads in a single request. It distinguishes from single-create siblings like 'crm_create_lead' by mentioning 'multiple leads', but doesn't explicitly contrast with other batch operations like 'crm_batch_create_contacts' or 'crm_batch_create_companies'.
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 is provided. The description doesn't mention when batch creation is preferable over single creation, nor does it reference other batch tools for different resource types. Usage context is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it's an update operation. It lacks critical behavioral details: whether it requires specific permissions, if it's idempotent, rate limits, error handling for partial failures, or what happens to unspecified properties. 'Update multiple contacts' implies mutation but offers no safety or operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with a single, clear sentence that front-loads the core action. No wasted words or redundant information, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't cover behavioral traits, error handling, or return values, leaving significant gaps for an AI agent to understand how to use it safely and effectively. The schema provides parameter details but doesn't compensate for missing operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds minimal value beyond the schema. It implies an array of contacts to update ('multiple contacts'), which aligns with the 'inputs' array in the schema, but doesn't explain parameter structure, required fields, or the meaning of nested properties. The schema documents all parameters thoroughly, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('update') and resource ('multiple contacts'), making the purpose understandable. It distinguishes from single-contact updates (e.g., crm_update_contact) by specifying 'multiple' and 'in a single request', but doesn't explicitly differentiate from other batch tools like crm_batch_update_companies.
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 like crm_update_contact for single updates or other batch tools. The description mentions 'multiple contacts' but provides no context on prerequisites, limitations, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'update' which implies mutation, but doesn't disclose behavioral traits like required permissions, whether updates are partial or full, idempotency, rate limits, or what happens on partial failures. For a batch mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with a single, clear sentence that front-loads the core action. Every word earns its place with no redundancy or fluff, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (batch mutation with nested objects), lack of annotations, and no output schema, the description is incomplete. It doesn't address error handling, response format, limitations, or side effects. For a tool that modifies multiple leads, more context is needed to use it effectively and safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds minimal value beyond the schema. It implies an array of lead updates but doesn't explain parameter structure or semantics (e.g., 'inputs' array containing objects with 'id' and 'properties'). The schema details the nested properties comprehensively, so baseline 3 is appropriate as the description doesn't compensate for the coverage gap.
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 action ('Update multiple leads') and resource ('leads'), and specifies the batch nature ('in a single request'). It distinguishes from single-update siblings like 'crm_update_lead' by emphasizing 'multiple'. However, it doesn't explicitly mention what fields can be updated or the scope beyond 'leads'.
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 like 'crm_batch_update_contacts' or 'crm_update_lead'. It implies batch operations but doesn't specify prerequisites, error handling, or constraints (e.g., maximum batch size). The description only states what it does, not when or why to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a 'Get' operation which implies read-only, but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or what happens if the company ID doesn't exist. The description is minimal and lacks necessary context for safe invocation.
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, efficient sentence that front-loads the core functionality. Every word earns its place with no wasted text, making it easy to parse quickly while conveying essential information about the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, 0% schema description coverage, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'properties' and 'associations' arrays contain, how they filter results, what the response looks like, or error handling. The description leaves too many gaps for effective tool 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?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions 'by ID with specific properties and associations' which hints at the purpose of the three parameters (companyId, properties, associations), but doesn't explain what these parameters mean, their formats, or how they affect the response. It adds some semantic value but doesn't fully compensate for the coverage gap.
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 action ('Get'), resource ('a single company'), and key constraints ('by ID with specific properties and associations'). It distinguishes from sibling tools like crm_search_companies (which searches) and crm_list_objects (which lists), but doesn't explicitly mention these alternatives. The purpose is specific but could be more differentiated.
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 like crm_search_companies or crm_get_object. It mentions 'by ID' which implies you need a specific company identifier, but doesn't state prerequisites, exclusions, or comparative use cases with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a 'Get' operation which implies read-only behavior, but doesn't disclose authentication requirements, rate limits, error responses, or what happens when invalid IDs/properties are provided. For a read operation with 3 parameters and no annotation coverage, this lacks important behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence efficiently conveys core functionality without unnecessary words. Front-loaded with the main purpose. Could potentially benefit from breaking into multiple sentences for clarity about parameters, but overall well-structured and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, 0% schema description coverage, no annotations, and no output schema, the description is insufficient. It doesn't explain return format, error conditions, authentication needs, or provide examples. While it states the basic purpose, it leaves too many contextual gaps for effective agent 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?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions 'by ID with specific properties and associations' which hints at the three parameters' purposes, but doesn't explain format expectations (e.g., what valid contact IDs look like), property naming conventions, or association behavior. It adds some semantic value but doesn't fully compensate for the complete lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'a single contact by ID', specifying the action and target. It distinguishes from sibling tools like crm_list_objects or crm_search_contacts by focusing on retrieval by ID with optional property/association inclusion. However, it doesn't explicitly differentiate from crm_get_object or crm_get_company which follow similar patterns for other entity types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like crm_search_contacts or crm_get_object. The description implies usage for retrieving a specific contact when you have its ID, but doesn't mention prerequisites, error conditions, or comparison to batch operations like crm_batch_create_contacts. Usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action without disclosing behavioral traits. It doesn't mention if this is a read-only operation, potential rate limits, authentication needs, or what the output format looks like (e.g., list structure). For a tool with zero annotation coverage, this is inadequate.
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, efficient sentence that front-loads the core action ('List all available association types') and specifies the context ('for a given object type pair'). There is no wasted language, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters with enums but 0% schema description coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain parameter meanings, output format, or behavioral aspects like safety or performance. For a tool in this context, more detail is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning by explaining that parameters define an 'object type pair'. However, it doesn't detail the enum values or their significance beyond the schema's enum lists. With 2 parameters fully documented in schema but no descriptions, the description provides some context but doesn't fully compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('association types'), specifying it's for 'a given object type pair'. It distinguishes from sibling tools like crm_get_associations by focusing on types rather than instances. However, it doesn't explicitly contrast with all possible siblings, keeping it at 4 instead of 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?
The description provides no guidance on when to use this tool versus alternatives like crm_get_associations or crm_list_objects. It mentions the object type pair context but doesn't specify prerequisites, exclusions, or typical use cases, leaving the agent with minimal usage direction.
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 mentions 'validated properties' which hints at some validation behavior, but doesn't disclose critical traits like whether this is a destructive mutation, what permissions are required, error handling, or what happens to unspecified properties. For a mutation tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 2 parameters (including a complex nested object), 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the update behavior, return values, error conditions, or how it differs from sibling tools, leaving the agent with insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'validated properties' which loosely relates to the 'properties' parameter, but doesn't explain what 'companyId' is, what specific properties can be updated, or what 'validated' means in practice. It adds minimal semantic value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'update' and the resource 'existing company', making the purpose understandable. It specifies 'with validated properties' which adds some detail about the nature of the update. However, it doesn't explicitly distinguish this tool from its sibling 'crm_batch_update_companies' or 'crm_update_object', which could handle similar updates.
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 like batch updates or other CRM update tools. It doesn't mention prerequisites (e.g., needing an existing company ID) or contextual factors that would inform the agent's decision-making process.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. 'Update' implies mutation, but it doesn't disclose permission requirements, whether updates are partial or complete, validation failure behavior, or what the response contains. The mention of 'validated properties' hints at validation but doesn't explain it.
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, efficient sentence with zero wasted words. It's appropriately sized and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, 0% schema description coverage, no output schema, and complex nested parameters, the description is inadequate. It should explain validation, update behavior, response format, and error handling to be 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 0%, so the description must compensate but only adds minimal context. It mentions 'validated properties' which relates to the 'properties' parameter, but doesn't explain the structure or validation rules. The schema documents 2 parameters with rich nested properties, but the description doesn't clarify their semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'update' and resource 'existing contact', making the purpose unambiguous. It distinguishes from sibling tools like crm_create_contact by specifying 'existing', but doesn't explicitly differentiate from other update tools like crm_update_company or crm_update_lead.
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 like crm_batch_update_contacts or crm_update_object. The description mentions 'validated properties' but doesn't explain what validation entails or any prerequisites for successful updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the destructive 'archive/delete' action but lacks critical behavioral details: whether deletion is permanent or reversible, required permissions, rate limits, confirmation prompts, error handling for partial failures, or what happens to associated data. The mention of 'multiple email records' hints at batch capability but doesn't elaborate on batch size limits or processing 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?
Perfectly concise single sentence with zero waste. Front-loaded with the core action ('Archive/delete'), followed by resource scope and request context. Every word earns its place without redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive batch operation with no annotations, 0% schema coverage, and no output schema, the description is insufficient. It identifies the tool's basic purpose but lacks critical context about behavioral implications, parameter details, error handling, and system constraints that an agent needs to use this tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'multiple email records' which aligns with the 'emailIds' array parameter, providing some semantic context. However, it doesn't explain what email IDs are (format, source, validation), whether they must exist, or any constraints on the array (min/max size, uniqueness). The description adds basic meaning but leaves significant gaps.
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 action ('archive/delete') and resource ('multiple email records') with the scope 'in a single request'. It distinguishes from 'emails_archive' by specifying batch capability, but doesn't explicitly contrast with other batch operations like 'emails_batch_create' or 'emails_batch_update'.
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 like 'emails_archive' (single email) or other batch operations. The description implies batch processing but doesn't specify prerequisites, constraints, or appropriate contexts for batch versus individual operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action is 'archive (delete)', implying a destructive operation, but doesn't specify whether this is permanent or reversible, what permissions are required, rate limits, or what happens to associated data. For a destructive batch operation, this leaves critical gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a simple tool and front-loads the key information about what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive batch operation with no annotations, 0% schema description coverage, and no output schema, the description is inadequate. It doesn't address critical aspects like error handling, confirmation requirements, batch size limits, or what the response contains. The context signals indicate this is a non-trivial tool that requires more complete documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't add any parameter information beyond what the schema provides. With 0% schema description coverage and 1 parameter, the baseline would be 4 for 0 parameters, but here we have 1 undocumented parameter. The description doesn't explain what 'meetingIds' should contain, their format, or any constraints, so it doesn't compensate for the schema coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('archive/delete') and resource ('multiple meetings') with the scope 'in a single request'. It distinguishes from individual meeting operations like 'meetings_delete' but doesn't explicitly differentiate from other batch operations like 'calls_batch_archive' or 'emails_batch_archive'.
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 description doesn't mention prerequisites, limitations, or when to choose this over 'meetings_delete' for single meetings or other batch operations. The sibling tools list shows many similar batch operations, but no comparative context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'archive (delete)' which implies a destructive operation, but doesn't specify whether this is reversible, requires specific permissions, or has side effects. For a destructive tool with zero annotation coverage, this is inadequate.
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 - just three words that convey the essential action and resource. There's no wasted language, and the information is front-loaded effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations, no output schema, and incomplete parameter documentation, the description is insufficient. It doesn't address what happens after archiving, whether the action is reversible, what permissions are required, or what the response contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't mention the noteId parameter at all, and with 0% schema description coverage, the parameter is undocumented. However, since there's only one parameter and its purpose is reasonably inferred from context (noteId for identifying which note to archive), this meets the baseline for minimal viability.
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 action ('archive (delete)') and resource ('a note'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like notes_batch_archive or notes_delete (if present), which would be needed for 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 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 like notes_batch_archive or notes_update. The description simply states what it does without context about appropriate use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool archives/deletes notes, implying a destructive mutation, but lacks critical details: whether deletion is permanent or reversible, required permissions, rate limits, error handling for invalid IDs, or response format. The mention of 'single request' hints at efficiency but doesn't clarify batch size limits or atomicity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads key information: action, resource, and batch nature. There's no wasted text, though it could be more structured (e.g., separating purpose from constraints). It appropriately balances brevity with core clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, no annotations, no output schema, and 0% schema description coverage, the description is insufficient. It omits critical context: success/error responses, side effects (e.g., if archiving affects related data), idempotency, or authentication requirements. For a batch deletion tool, this leaves significant gaps for safe and effective 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?
Schema description coverage is 0%, so the description must compensate but adds no parameter details. It doesn't explain 'noteIds' format (e.g., UUIDs), validation rules, or array size constraints. The baseline is 3 because the schema fully defines the parameter structure (array of strings), but the description fails to provide semantic context beyond what's inferable from the tool name.
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 action ('archive (delete)') and resource ('multiple notes'), specifying it's a batch operation ('in a single request'). It distinguishes from the singular 'notes_archive' sibling tool by emphasizing batch capability. However, it doesn't explicitly differentiate from other batch archive tools like 'calls_batch_archive' or 'emails_batch_archive' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., note IDs must exist), compare to singular 'notes_archive', or specify use cases like bulk cleanup. Without annotations or context, the agent lacks direction on appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action is a 'Move' to 'recycling bin' which implies a destructive operation, but doesn't clarify if this is reversible, what permissions are required, whether it triggers notifications, or what happens to associated data. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core action without unnecessary words. It's appropriately sized for a simple operation and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address critical aspects like return values, error conditions, side effects, or how this differs from deletion. The context signals show minimal parameter documentation, and the description doesn't adequately fill these 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 description mentions 'ID' which corresponds to the 'productId' parameter in the schema, adding minimal semantic context. With 0% schema description coverage, the description doesn't compensate by explaining the ID format, validation rules, or examples. However, since there's only one parameter, the baseline is appropriately set at 3.
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 action ('Move') and target ('Object identified by ID to the recycling bin'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'products_batch_archive' or other *_archive tools, which likely perform similar operations on different resource types.
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 like 'products_batch_archive' for multiple products or 'products_update' for modification instead of archiving. It lacks any context about prerequisites, permissions, or system-specific constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Archive') but doesn't explain what archiving entails (e.g., whether it's reversible, if data is preserved, permission requirements, or rate limits). For a destructive operation with zero annotation coverage, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple tool and front-loads the essential information (archive + batch + products + ID).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive batch operation with no annotations and no output schema, the description is inadequate. It doesn't address critical context like what archiving means operationally, error handling for invalid IDs, whether the operation is atomic, or what happens to archived products. The completeness is poor given the tool's complexity and lack of structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'by ID' which implies the 'productIds' parameter contains identifiers, adding some context beyond the schema's 0% description coverage. However, it doesn't specify ID format, validation rules, or batch size limits, leaving important semantic details uncovered.
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 action ('Archive') and target ('a batch of products by ID'), which is specific and actionable. However, it doesn't explicitly differentiate from the sibling 'products_archive' tool, which appears to archive individual products rather than batches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'products_archive' or other batch operations. The description lacks context about prerequisites, constraints, or appropriate use cases for batch archiving versus individual operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal important behavioral traits: it's a partial update (not full replacement), it requires an ID, read-only/non-existent properties cause errors, and empty strings clear values. However, it lacks information about permissions, rate limits, side effects, or what happens to unspecified properties. For a mutation tool with zero annotation coverage, this is adequate but incomplete.
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 appropriately sized with three sentences that each add value: the core action, error conditions, and clearing behavior. It's front-loaded with the primary purpose. There's no wasted text, though it could be slightly more structured for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations, 0% schema description coverage, no output schema, and 2 parameters (one being a nested object with multiple properties), the description is incomplete. It covers the basic operation and some error behaviors but lacks details about available properties, response format, authentication needs, or system constraints. The context demands more comprehensive documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'ID' (mapping to productId) and 'properties' for partial updates, but doesn't explain what properties are available, their formats, or constraints. The description adds minimal semantic value beyond what's implied by the schema structure, failing to adequately compensate for the coverage gap.
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 action ('Perform a partial update') and target ('an Object identified by ID'), providing a specific verb+resource combination. However, it doesn't distinguish this from sibling tools like 'products_batch_update' or 'products_update' (if that exists in the list), which would require explicit differentiation for 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 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 like batch updates or other product-related tools. It mentions error conditions ('Read-only and non-existent properties will result in an error'), but this is behavioral information rather than usage guidance. No explicit when/when-not or alternative tool references are included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the destructive nature ('delete'), which is critical, but lacks other behavioral context: no mention of permissions required, whether the action is reversible, confirmation prompts, error conditions, or what happens to associated data. For a destructive operation with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with zero wasted words. The description is front-loaded and gets straight to the point in a single, clear phrase. Every word earns its place by specifying both action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't address critical aspects like return values, error handling, side effects, or security requirements. The agent lacks sufficient context to use this tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies a 'taskId' parameter is needed to identify the task, but doesn't explain format, constraints, or where to obtain it. The description adds minimal value beyond what's inferable from the schema property name. With 0% coverage and 1 parameter, baseline expectations are higher than delivered.
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 action ('archive (delete)') and resource ('a task'), making the purpose immediately understandable. It distinguishes from sibling tools like tasks_update or tasks_get by specifying the destructive operation. However, it doesn't clarify if 'archive' is distinct from permanent deletion, which could be relevant given sibling tools like tasks_batch_archive exist.
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. There's no mention of prerequisites (e.g., task must exist), when to use batch operations (tasks_batch_archive) instead, or how this differs from other deletion-like tools in the system. The description only states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It indicates this is a destructive operation ('Archive (delete)'), which is helpful, but doesn't mention whether archiving is reversible, what permissions are required, whether there are rate limits, or what happens to archived tasks. For a batch destructive operation, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Archive (delete) multiple tasks') and adds the batch context ('in a single request'). Every word serves a purpose with zero redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch destructive operation with no annotations, 0% schema description coverage, and no output schema, the description is inadequate. It doesn't address critical context like error handling, confirmation requirements, side effects, or return values. The agent lacks sufficient information to use this tool safely and effectively.
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 description coverage is 0%, so the description must compensate. It implies the parameter is task IDs for archiving, which aligns with the schema's 'taskIds' array parameter. However, it doesn't specify format requirements, maximum batch size, or validation rules. The description adds basic meaning but doesn't fully compensate for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Archive (delete)') and resource ('multiple tasks'), making the purpose unambiguous. It specifies batch operation ('in a single request'), which distinguishes it from individual task operations like tasks_archive. However, it doesn't explicitly differentiate from other batch operations like tasks_batch_update.
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 doesn't mention when batch archiving is preferable to individual archiving (tasks_archive), nor does it clarify prerequisites, permissions, or constraints. The sibling tools list shows multiple batch operations, but the description offers no comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It indicates a destructive action ('Archive (delete)') but doesn't specify if archiving is permanent or reversible, what permissions are required, or what happens to associated data. This leaves significant gaps 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 extremely concise—a single phrase that directly states the action and target. There's no wasted language, and it's front-loaded with the essential information, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations, no output schema, and 0% schema description coverage, the description is insufficient. It doesn't explain the outcome (e.g., success/failure response, error handling), behavioral nuances (e.g., soft vs. hard delete), or integration with sibling tools, leaving the agent with critical gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't explicitly mention the 'callId' parameter, but with only one required parameter and 0% schema description coverage, it's clear from context that 'a call record' refers to the callId. Since there are 0 parameters with descriptions in the schema, the baseline is 4, as the description adequately implies the single parameter's purpose without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Archive (delete)') and resource ('a call record'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'calls_batch_archive' or 'calls_delete' (if present), which would require explicit comparison for 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 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 like 'calls_batch_archive' for multiple calls or 'calls_delete' if it exists. It also lacks context about prerequisites, such as whether the call must be in a specific state before archiving.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a read operation ('Get'), which is clear, but doesn't mention permissions, rate limits, error handling, or response format. For a tool with 3 parameters and no output schema, this leaves significant behavioral gaps uncovered.
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, efficient sentence that front-loads the core action ('Get a single lead by ID') and adds necessary qualifiers. There is zero waste—every word contributes to understanding the tool's function without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'properties' and 'associations' entail, how results are structured, or behavioral aspects like errors. For a read tool with sibling alternatives, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining that 'leadId' retrieves 'a single lead by ID', 'properties' are 'specific properties', and 'associations' are 'associations' (though vague). This clarifies the purpose of parameters beyond the bare schema, but doesn't detail format or constraints (e.g., what properties/associations are available).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('a single lead'), specifying it retrieves by ID with 'specific properties and associations'. It distinguishes from siblings like crm_list_objects or crm_search_leads by focusing on single retrieval, though it doesn't explicitly name alternatives. The purpose is specific but lacks explicit sibling differentiation.
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 like crm_get_lead_properties or crm_search_leads. It implies usage for retrieving a specific lead by ID but doesn't mention prerequisites, exclusions, or contextual recommendations. No explicit when/when-not statements are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It indicates this is a destructive operation ('delete'), which is helpful, but doesn't mention whether archiving is permanent or reversible, what permissions are required, rate limits, or what happens to associated data. For a mutation tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence with no wasted words. It's front-loaded with the core action and resource, making it immediately understandable despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description is inadequate. It doesn't explain what 'archive' means operationally, whether the action is reversible, what confirmation or response to expect, or how this differs from batch operations. The minimal information provided is insufficient for safe and effective use.
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 one parameter and 0% schema description coverage, the description doesn't add specific parameter information beyond what's implied by the tool name. However, the single parameter 'emailId' is self-explanatory in context, and the description's focus on the action rather than parameters is reasonable for such a simple tool.
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 action ('Archive (delete)') and resource ('an email record'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'emails_batch_archive' or other archive tools in the system, which prevents 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 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 like 'emails_batch_archive' for multiple emails or 'emails_update' for modifying instead of archiving. There's no mention of prerequisites, consequences, or appropriate contexts for this destructive operation.
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 'Get all' implies a read-only operation, the description doesn't address important behavioral aspects like whether this returns all definitions at once or uses pagination, what format the definitions are returned in, whether authentication is required, or any rate limits. The description provides minimal behavioral context beyond the basic 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 a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for what appears to be a straightforward retrieval operation and is perfectly front-loaded with the core functionality.
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 apparent simplicity (1 optional parameter, no output schema, no annotations), the description is minimally adequate but leaves gaps. It doesn't explain what 'subscription definitions' actually are in this context, doesn't address the undocumented 'archived' parameter, and provides no behavioral context. For a read operation with minimal structured metadata, this is the bare minimum that could work.
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 1 parameter and 0% schema description coverage, the description doesn't mention the 'archived' parameter at all. However, since there's only one parameter and the tool appears to be a simple retrieval operation, the description's omission is less critical. The baseline for 0 parameters would be 4, but with 1 undocumented parameter, this slightly reduces the score from what it could be.
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 action ('Get all') and resource ('subscription definitions for the portal'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'communications_get_subscription_status' or 'communications_get_preferences', which prevents 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 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. With sibling tools like 'communications_get_subscription_status' and 'communications_get_preferences' available, there's no indication of when this specific 'get definitions' operation is appropriate versus those other communications-related read operations.
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 full burden. It discloses key behavioral traits: it's a read operation (implied safe), supports pagination with cursor tokens, and allows property selection. However, it doesn't mention rate limits, authentication needs, error conditions, or what happens with invalid parameters. The description adds useful context but misses important behavioral details for a tool with no annotations.
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?
Two sentences that efficiently convey core functionality. The first sentence states the main purpose, the second explains key parameters. No wasted words, though the second sentence is somewhat long and could be structured more clearly. Overall appropriately sized and front-loaded with essential information.
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 read/list tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is minimally adequate. It covers the pagination mechanism and property selection but doesn't explain response format, error handling, or the limit parameter. Given the complexity and lack of structured documentation, it should do more to be truly 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?
With 0% schema description coverage for 3 parameters, the description compensates well by explaining the semantics of 'properties' (controls what is returned) and 'after' (paging cursor token). It doesn't mention 'limit' parameter at all, which is a gap. However, for 2 out of 3 parameters, it adds meaningful context beyond the bare schema, justifying a score above 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's purpose: 'Read a page of products' with specific functionality for controlling returned data via properties and pagination via after cursor. It distinguishes from sibling tools like products_read (singular) and products_search (filtered search), though not explicitly named. The verb+resource is specific but could be more explicit about sibling differentiation.
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 paginated reading with property selection, but doesn't explicitly state when to use this vs alternatives like products_search or products_read. It mentions the paging mechanism but doesn't provide clear guidance on prerequisites or when-not-to-use scenarios. The context is clear but lacks explicit alternative naming.
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:

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

Score Badge

Copy to your README.md:

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

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