HubSpot MCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Tools are well-differentiated by resource type (calls, emails, CRM objects, etc.) and action (create, get, update, archive, search), with clear boundaries. Minor ambiguity exists between 'list' and 'search' operations across resources, but descriptions clarify that 'list' retrieves all with optional filtering while 'search' uses specific filters, making them distinguishable.
Naming Consistency5/5
Naming follows a highly consistent pattern throughout: resource_action (e.g., calls_create, crm_get_company) with batch operations as resource_batch_action (e.g., emails_batch_update). This verb_noun structure is uniformly applied across all 112 tools, making them predictable and easy to parse.
Tool Count2/5
With 112 tools, the count is excessive for a single server, leading to cognitive overload and potential inefficiency. While the tools cover multiple HubSpot domains (CRM, communications, engagements), the sheer volume suggests over-fragmentation, such as having separate batch and single operations for each resource, which could be streamlined.
Completeness5/5
The tool set provides comprehensive CRUD and lifecycle coverage across all major HubSpot domains (calls, emails, CRM objects, engagements, meetings, notes, products, tasks). Each resource includes create, get, update, archive, list, and search operations, with batch variants for scalability, ensuring no obvious gaps for agent workflows.
Average 2.6/5 across 112 of 112 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
- Last stable release on July 24, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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 full burden for behavioral disclosure but fails completely. It doesn't indicate whether this is a mutation (implied by 'create'), what permissions are required, whether it's idempotent, what happens on conflicts, or what the response looks like. For a creation tool with 11 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just 4 words, this is under-specification rather than effective conciseness. The single sentence doesn't earn its place by adding meaningful information beyond the tool name. A truly concise description would still provide essential context in minimal words.
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 complex creation tool with 11 parameters, no annotations, no output schema, and 0% schema description coverage, the description is completely inadequate. It doesn't explain what's being created, how to use it, what the parameters mean, or what to expect in return. This leaves the agent with insufficient information to 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?
With 0% schema description coverage and 11 parameters (5 required), the description provides no information about any parameters. It doesn't mention what 'name', 'label', 'type', 'fieldType', or 'groupName' mean, nor does it explain the purpose of optional parameters like 'options', 'description', or 'hasUniqueValue'. 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.
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 a tautology that restates the tool name 'crm_create_lead_property' without adding specificity. It doesn't explain what a 'lead property' is in this CRM context or what the creation entails, making it only slightly better than just the name alone.
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 'crm_create_lead', 'crm_create_company_property', and 'crm_get_lead_properties', there's no indication of when to create a lead property versus using other related tools or what prerequisites might be needed.
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 claims a write operation ('Create') but the tool name suggests reading, creating fundamental confusion about whether this is a read or write operation. No information about permissions, rate limits, side effects, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that's technically concise, but it's under-specified rather than efficiently informative. While it's front-loaded, it fails to provide necessary context for a 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.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Completely inadequate for a 5-parameter tool with no annotations and no output schema. The description contradicts the tool name, provides no parameter information, and offers no behavioral context. 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%, so the description must compensate for 5 undocumented parameters. The description provides no information about any parameters - it doesn't mention objectType, objectIds, properties, propertiesWithHistory, or idProperty. This leaves all parameters completely unexplained.
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 states 'Create multiple CRM objects in a single request' which is a tautology that restates the tool name 'crm_batch_read_objects' - the name suggests reading while the description suggests creating, creating confusion. It doesn't specify what type of objects or distinguish from sibling tools like crm_batch_create_objects or crm_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 Guidelines1/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_objects, crm_batch_read, or crm_get_object. The description contradicts the tool name (read vs create), providing misleading usage information.
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 offers nothing beyond the basic action. It doesn't mention permissions required, whether this is a write operation (implied but not stated), what happens on success/failure, rate limits, or any side effects. For a creation tool with complex nested 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, which could be appropriate if it were more informative. However, it's under-specified rather than efficiently structured - it wastes no words but also provides no value beyond the tool name. It's front-loaded by default due to brevity but lacks substance.
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 creation tool with 2 complex parameters (including nested objects), 0% schema coverage, no annotations, and no output schema, the description is completely inadequate. It doesn't address any of the complexity, provide usage context, explain return values, or help the agent understand how to properly invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning all parameters are undocumented in the schema. The description provides zero information about the 2 parameters (associations and properties) or their nested structures. It doesn't explain what properties are required, what associations mean, or provide any semantic context for the complex input schema.
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' is a tautology that restates the tool name without adding specificity. It doesn't distinguish this tool from sibling tools like 'meetings_batch_create' or provide any details about what kind of meeting is being created (e.g., CRM meeting, calendar event). The verb+resource is present but lacks 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?
No guidance is provided on when to use this tool versus alternatives like 'meetings_batch_create' or other meeting-related tools. The description offers no context about prerequisites, constraints, or appropriate scenarios for single meeting creation versus batch 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?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Search products' reveals nothing about whether this is a read-only operation, what permissions are required, whether it supports pagination, rate limits, or what the response format looks like. This is completely inadequate for a tool with 6 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just two words, which could be appropriate if it were more informative. However, this brevity comes at the cost of being under-specified rather than efficiently informative. It's front-loaded but lacks substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, 0% schema description coverage, no annotations, no output schema, and complex filtering capabilities (as evidenced by the filterGroups structure), the description is completely inadequate. It provides no information about the tool's behavior, parameters, or output, making it impossible for an agent 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 description coverage is 0%, meaning none of the 6 parameters have descriptions in the schema. The description 'Search products' adds no information about any parameters - it doesn't mention filtering, sorting, pagination, or any of the actual capabilities revealed by the parameter names. This 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.
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. While it indicates the verb 'search' and resource 'products', it lacks specificity about what kind of search this performs (e.g., full-text, filtered, paginated) and doesn't distinguish it from sibling tools like 'products_list' or 'products_read'.
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 related to products (products_list, products_read, products_create, etc.), but the description offers no context about when this search tool is appropriate versus those other options.
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 read-only operation, what permissions might be required, whether there are rate limits, what the response format looks like, or any other behavioral characteristics. For a search tool with 5 parameters, this lack of behavioral context is severely 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 extremely concise - just 5 words. While this could be seen as efficient, it's more accurately described as under-specified rather than appropriately concise. However, it does follow a front-loaded structure with no wasted words, earning some credit for brevity.
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 description coverage, no annotations, no output schema), the description is completely inadequate. A search tool with complex filtering capabilities requires much more context about available properties, filter operators, result format, pagination behavior, and usage patterns to be effectively usable.
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?
With 0% schema description coverage and 5 parameters (including complex nested objects for filters and sorts), the description 'Search tasks with specific filters' only hints at the 'filterGroups' parameter. It completely ignores the 'after', 'limit', 'properties', and 'sorts' parameters, providing no semantic context for any of them beyond what's minimally implied by the tool name.
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 tasks with specific filters' restates the tool name 'tasks_search' with minimal elaboration - it's essentially a tautology. While it mentions 'tasks' as the resource and 'search' as the verb, it doesn't specify what kind of tasks or provide any distinguishing context from sibling tools like 'tasks_list' or 'tasks_get'.
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. It doesn't mention when this search tool is appropriate versus 'tasks_list' or 'tasks_get', nor does it provide any context about prerequisites, appropriate use cases, or limitations.
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. The description only states 'Create a new call record' without mentioning required permissions, whether this is a write operation, what happens on success/failure, rate limits, or any side effects. For a creation tool with complex nested parameters, 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 four words. While this brevity reflects under-specification rather than optimal communication, it contains no wasted words and is front-loaded with the core action. Every word earns its place, even if insufficient overall.
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 (2 parameters with nested objects, no annotations, no output schema), the description is completely inadequate. It doesn't explain what a 'call record' is, what data is required, how associations work, what the tool returns, or any behavioral aspects. This leaves the agent unable to 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?
Schema description coverage is 0%, meaning none of the 2 parameters (with complex nested structures) are documented in the schema. The description provides zero information about parameters, not even mentioning the required 'properties' object or optional 'associations'. It 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new call record' states the basic action but is tautological with the tool name 'calls_create'. It doesn't specify what a 'call record' entails or differentiate from sibling tools like 'calls_batch_create' or other creation tools in the system. The purpose is clear at a surface level but lacks specificity about what's being created.
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 about when to use this tool versus alternatives. With multiple sibling tools including 'calls_batch_create', 'calls_update', and various CRM creation tools, the description offers no indication of appropriate contexts, prerequisites, or distinctions from related functionality.
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. It states 'Create a new company property' but does not clarify whether this is a mutating operation, what permissions are needed, if there are rate limits, or what happens on success/failure. For a creation tool with 11 parameters and no 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—a single sentence with no wasted words. It is front-loaded and directly states the tool's action. While this brevity contributes to clarity in structure, it comes at the cost of informational completeness.
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, 5 required, 2 enums), lack of annotations, and no output schema, the description is severely incomplete. It does not explain the tool's behavior, parameter meanings, or expected outcomes. For a creation tool in a CRM context, this leaves critical gaps for an AI agent to understand and 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?
The schema description coverage is 0%, meaning none of the 11 parameters have descriptions in the schema. The tool description adds no information about parameters, such as what 'fieldType', 'type', or 'options' mean in context. With 5 required parameters and complex enums, the description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new company property' restates the tool name with minimal elaboration. While it specifies the verb ('create') and resource ('company property'), it lacks detail on what a 'company property' entails or how it differs from sibling tools like crm_create_contact_property or crm_create_lead_property. This is closer to a tautology than a clear, distinct purpose statement.
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. It does not mention prerequisites (e.g., required permissions), context for creating company properties, or how it relates to sibling tools such as crm_get_company_properties or crm_update_company. Without any usage context, the agent must infer everything 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, so the description carries full burden for behavioral disclosure. It only states the action 'create' without addressing permissions, side effects, error conditions, or response format. For a mutation tool with 11 parameters, this lack of transparency is inadequate and could lead to misuse.
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 no wasted words. It is front-loaded and efficiently communicates the core action, though this brevity comes at the cost of completeness. Every word earns its place in stating the tool's basic purpose.
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 severely incomplete. It does not address parameter meanings, behavioral traits, usage context, or output expectations. This is inadequate for a tool of this nature, 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.
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 11 parameters are documented in the schema. The description adds no information about parameters, failing to compensate for this gap. It does not explain what fields like 'fieldType', 'options', or 'hasUniqueValue' mean or how they interact.
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 contact property' restates the tool name with minimal elaboration. It specifies the verb 'create' and resource 'contact property', but lacks detail on what a contact property is or how it differs from similar tools like crm_create_company_property or crm_create_lead_property. This is borderline tautological, scoring above 1 only because it includes 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 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. The description does not mention prerequisites, context, or comparisons to sibling tools like crm_create_company_property or crm_get_contact_properties. This leaves the agent without 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.
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 offers none. It doesn't mention that this is a write/mutation operation, what permissions are required, whether it's idempotent, what happens on failure, or what the response contains. 'Create' implies mutation but lacks essential 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 4 words, with no wasted language. However, this conciseness comes at the cost of being under-specified for a tool with 3 parameters and complex schema.
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 mutation tool with 3 parameters (including nested objects), 0% schema description coverage, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what the tool does beyond the obvious, provide parameter guidance, or describe behavioral aspects.
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?
With 0% schema description coverage and 3 parameters (objectType, properties, associations), the description provides no information about any parameters. It doesn't explain what 'objectType' accepts, what 'properties' should contain, or what 'associations' are for. The schema has enums and nested objects that need explanation.
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 CRM object' states the basic action but is tautological with the tool name 'crm_create_object'. It doesn't specify what types of objects can be created or distinguish this tool from its many sibling tools like crm_create_company, crm_create_contact, etc., which create 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 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 the many sibling tools that create specific object types (companies, contacts, leads) or batch creation tools. The description offers no context about appropriate use cases or alternatives.
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. 'Create a new email record' implies a write/mutation operation but reveals nothing about permissions required, whether creation is idempotent, what happens on failure, rate limits, or what the response contains. This is critically inadequate for a mutation tool with complex parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise at 4 words with no wasted language. However, this conciseness comes at the cost of being severely under-specified for such a complex tool. Every word earns its place, but far too few words are present.
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 mutation tool with 2 complex parameters (0% schema coverage), no annotations, no output schema, and no sibling differentiation, the description is completely inadequate. It provides minimal purpose statement but lacks all necessary context about behavior, parameters, usage, and expected outcomes that an agent needs to invoke 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?
Schema description coverage is 0%, meaning parameters are completely undocumented in the schema. The description mentions no parameters at all, failing to compensate for this gap. With 2 parameters (including a complex nested 'properties' object with 15+ fields), the agent has no semantic understanding of what inputs are needed or their purposes.
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 email record' states the verb ('Create') and resource ('email record'), but it's a tautology that essentially restates the tool name 'emails_create'. It doesn't provide any distinguishing details about what constitutes an email record or how this differs from sibling email tools like emails_batch_create or emails_update.
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. There's no mention of prerequisites, appropriate contexts, or comparison to sibling tools like emails_batch_create for bulk operations or emails_update for modifications. The agent receives no usage 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?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Create a new task' implies a write/mutation operation, but it reveals nothing about permissions required, whether the creation is immediate or queued, what happens on failure, rate limits, or what the response contains. For a mutation tool with zero annotation coverage, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words. While this brevity reflects severe under-specification, it is technically front-loaded with the core action and contains no redundant or unnecessary phrasing. Every word ('Create', 'a', 'new', 'task') contributes to the minimal statement of purpose.
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 (2 parameters with nested objects, no output schema, no annotations), the description is completely inadequate. It fails to explain what the tool does beyond the obvious, provides no parameter guidance, no behavioral context, and no differentiation from sibling tools. For a creation tool with complex input requirements, this leaves the agent unable to use it 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 description mentions no parameters at all, while the input schema has 2 parameters (associations and properties) with 0% schema description coverage. The schema shows complex nested structures for task properties and associations, but the description provides zero guidance about what these parameters mean, what values are expected, or how to format them. This leaves all parameter semantics 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 'Create a new task' is a tautology that merely restates the tool name 'tasks_create'. It specifies the verb 'create' and resource 'task', but lacks any distinguishing details about what kind of task, in what system, or how it differs from sibling tools like 'tasks_batch_create' or 'tasks_update'. This provides minimal value beyond the name itself.
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 tasks (e.g., tasks_batch_create, tasks_update, tasks_archive), but the description offers no context about when this single-task creation tool is appropriate versus batch operations or updates. No prerequisites, constraints, or comparison to other task-related tools are 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. 'Update an existing note' implies a mutation operation but provides zero information about permissions required, whether the update is reversible, rate limits, error conditions, or what happens to existing note properties not mentioned in the update. For a mutation tool with zero annotation coverage, this is completely inadequate behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise at three words. While severely under-specified, it contains zero wasted words and is front-loaded with the essential action. Every word earns its place, though the place is too small for adequate tool documentation.
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 provides only the most basic purpose statement without any context about usage, behavior, parameters, or expected outcomes. For a tool that modifies data with multiple undocumented parameters, this level of documentation is dangerously incomplete.
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 description 'Update an existing note' adds no information about the two required parameters (noteId and properties) or the nested properties object with hs_note_body, hs_timestamp, and hubspot_owner_id fields. The description 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing note' is a tautology that essentially restates the tool name 'notes_update'. It provides the basic verb+resource but lacks specificity about what aspects can be updated or how this differs from sibling tools like notes_batch_update or notes_archive. It doesn't distinguish this tool from alternatives in any meaningful way.
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 about when to use this tool versus alternatives. There are multiple sibling tools for notes (notes_batch_update, notes_archive, notes_create, etc.), but the description offers no context about when this single-note update operation is appropriate versus batch operations or other related tools. This leaves the agent with no usage 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states 'Search calls with specific filters'—it doesn't mention whether this is a read-only operation, if it requires authentication, what the output looks like, pagination behavior, rate limits, or error conditions. For a search tool with complex parameters, 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.
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 and appropriately sized for its limited content, 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.
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 objects in schema, no output schema, 0% schema coverage, no annotations), the description is completely inadequate. It doesn't explain the tool's behavior, parameter usage, output format, or how it differs from siblings. For a search tool with rich filtering capabilities, this leaves the agent unable to use it 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%, meaning none of the 5 parameters are documented in the schema. The description mentions 'specific filters' but doesn't explain what parameters are available (e.g., filterGroups, sorts, limit), their purposes, or how to use them. This leaves the agent guessing about parameter meanings and usage.
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' states the basic verb+resource but is vague about what 'specific filters' means. It doesn't distinguish this tool from sibling tools like calls_list, calls_get, or other search tools (emails_search, meetings_search), leaving the agent unclear about when to choose this over alternatives. It's better than a tautology 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 on when to use this tool versus alternatives like calls_list or calls_get. The description mentions 'specific filters' but doesn't explain what scenarios require this tool, what prerequisites exist, or when other tools might be more appropriate. This leaves the agent with no usage 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. 'Create a new engagement' implies a write/mutation operation, but the description doesn't mention required permissions, whether this is idempotent, what happens on failure, rate limits, or what the response contains. For a creation tool with complex nested parameters and no annotation coverage, this is a significant gap in behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 5 words. It's front-loaded with the core action ('Create a new engagement') and adds a clarifying detail ('with details'). 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?
Given the complexity (3 parameters with nested objects, no output schema, no annotations, 0% schema description coverage), the description is completely inadequate. It doesn't explain what an 'engagement' is in this system, what fields are required beyond the schema's technical requirements, what the tool returns, or any behavioral aspects. For a creation tool with this level of complexity, the description should do much more.
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, meaning none of the 3 parameters (engagement, associations, metadata) have any documentation in the schema. The description mentions 'with details' but doesn't explain what those details are, what the 'engagement' object should contain, what 'associations' means, 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 states 'Create a new engagement with details' which clearly indicates a creation operation on an engagement resource. However, it's somewhat vague about what 'engagement' means in this context and doesn't differentiate from sibling tools like 'engagement_details_update' or 'crm_create_object' that might handle similar resources.
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 that create various entities (calls_create, emails_create, notes_create, tasks_create, meetings_create, crm_create_company, etc.), but the description doesn't explain when an 'engagement' is appropriate versus these other entity types or when to use this versus batch creation 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 the full burden of behavioral disclosure. 'Update an existing meeting' implies a mutation operation but fails to describe any 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 zero wasted words. It is front-loaded with the core action ('Update an existing meeting'), making it easy to parse quickly. Every word serves a purpose, adhering to principles of conciseness.
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 (a mutation tool with 2 parameters, nested objects, and no output schema) and the absence of annotations, the description is severely incomplete. It lacks details on parameters, behavioral context, usage guidelines, and expected outcomes, making it inadequate for an agent to effectively select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning none of the parameters (meetingId and properties with nested fields like hs_meeting_title) are documented in the schema. The description adds no information about these parameters—it doesn't explain what meetingId is, what properties can be updated, or the meaning of fields like hs_meeting_outcome. This fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/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 understandable. However, it doesn't distinguish this tool from its sibling 'meetings_batch_update' or other update tools in the server, 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?
The description provides no guidance on when to use this tool versus alternatives like 'meetings_batch_update' or 'meetings_create'. It mentions 'existing meeting', implying a prerequisite of an existing meeting ID, but offers no explicit usage context, exclusions, or comparisons 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 the full burden. It states 'Read,' which implies a safe, non-destructive operation, but doesn't disclose any behavioral traits such as error handling, authentication needs, rate limits, or what happens if the ID is invalid. This leaves significant gaps for a tool with 3 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence with no wasted words, making it appropriately concise. However, it's front-loaded but lacks depth, as it doesn't provide necessary details for effective tool use.
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 (3 parameters, 0% schema coverage, no output schema, no annotations), the description is incomplete. It doesn't explain return values, parameter usage, or behavioral context, making it inadequate for an agent to reliably invoke the tool.
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 'ID' (hinting at 'productId'), but doesn't explain the 'associations' or 'properties' parameters at all. 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Read an Object identified by ID' is tautological—it essentially restates the tool name 'products_read' (read + products) without adding specificity. It doesn't clarify what type of object (e.g., product record) or what data is retrieved, making it vague. However, it's not entirely misleading, just insufficient.
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_list' or 'products_batch_read' from the sibling tools. The description implies a single-object lookup by ID, but it doesn't specify prerequisites, constraints, or comparative use cases, 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.
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 mentions 'validated properties', hinting at input validation, but fails to describe critical traits like required permissions, mutation effects (e.g., data persistence), error handling, or rate limits. This leaves significant gaps for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that is front-loaded with the core action. There is no wasted verbiage, making it appropriately concise. However, it could benefit from more structured detail given 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 (2 parameters with nested objects, no output schema, and no annotations), the description is inadequate. It lacks details on parameter usage, behavioral expectations, and output, leaving the agent with insufficient information to invoke the tool correctly 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?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only vaguely references 'validated properties', without explaining the two parameters ('properties' and 'associations') or their structures. This adds minimal meaning beyond the schema, failing to address the coverage 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 action ('Create') and resource ('new lead'), which clarifies the basic purpose. However, it doesn't specify what distinguishes this from sibling tools like 'crm_batch_create_leads' or 'crm_create_contact', making it vague in differentiation. The mention of 'validated properties' adds some specificity but remains ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives such as batch creation or other CRM create operations. The description implies usage for creating leads with validation, but it lacks context on prerequisites, exclusions, or comparisons to sibling tools, offering minimal 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 of behavioral disclosure. While 'Get' implies a read-only operation, the description doesn't address critical aspects like authentication requirements, rate limits, pagination, error handling, or whether it returns all properties by default. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence with no wasted words. It's appropriately front-loaded with the core action. However, given the complexity of the tool (2 undocumented parameters, no annotations), this brevity borders on under-specification rather than optimal 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 tool with 2 undocumented parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'properties' are, how results are structured, or any behavioral constraints. The agent would struggle to use this tool correctly without guessing about parameters and output format.
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, meaning neither parameter is documented in the schema. The description doesn't mention these parameters at all, failing to compensate for the schema gap. It doesn't explain what 'archived' filters or what the 'properties' array should contain, 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 'Get all properties for companies' clearly states the verb ('Get') and resource ('properties for companies'), making the basic purpose understandable. However, it doesn't distinguish this tool from similar sibling tools like 'crm_get_contact_properties' or 'crm_get_lead_properties', nor does it clarify what 'properties' means in this context (custom fields, metadata, etc.).
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 retrieving company-related data (e.g., 'crm_get_company', 'crm_search_companies'), but the description doesn't indicate whether this tool is for metadata/properties only versus full company records, or when filtering via parameters might be 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 the full burden. It mentions searching with filters but doesn't disclose behavioral traits such as whether this is a read-only operation, pagination behavior (implied by 'after' parameter but not explained), rate limits, or authentication needs. This is inadequate for a search tool with multiple parameters.
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 simple search tool, though it could be more informative without sacrificing 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 the complexity (5 parameters, 0% schema coverage, no annotations, no output schema), the description is incomplete. It lacks details on parameter usage, behavioral context, and output expectations, making it insufficient for an agent 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 schema provides no parameter descriptions. The description only vaguely mentions 'company-specific filters,' which doesn't explain the 5 parameters (filterGroups, after, limit, properties, sorts) or their semantics. It adds minimal value beyond 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 states the tool searches companies with filters, which is a clear verb+resource combination. However, it doesn't differentiate from sibling tools like crm_search_contacts or crm_search_leads beyond mentioning 'company-specific filters,' which is somewhat vague about what makes them company-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 on when to use this tool versus alternatives like crm_list_objects or other search tools. The description mentions 'company-specific filters' but doesn't explain what this means or when it's preferable, leaving the agent without clear 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 the full burden of behavioral disclosure. It states this is a search operation but doesn't mention whether it's read-only (likely, but not confirmed), what the output format is (no output schema exists), pagination behavior (implied by 'after' parameter but not explained), rate limits, or error conditions. For a search tool with 5 parameters and no annotations, 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.
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 search tool, though it could benefit from being more informative. The structure is straightforward, though not front-loaded with critical details beyond the core 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 tool's complexity (5 parameters with nested objects, no output schema, 0% schema description coverage, and no annotations), the description is inadequate. It doesn't explain the search scope, result format, pagination, error handling, or how parameters interact. For a search tool with rich filtering capabilities, this leaves the agent guessing about proper usage and expected behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 5 parameters have descriptions in the schema. The description only vaguely mentions 'contact-specific filters' which partially relates to the 'filterGroups' parameter but doesn't explain any parameters' purposes, formats, or relationships. It fails to compensate for the complete lack of schema descriptions, 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 'Search contacts with contact-specific filters' clearly states the verb ('Search') and resource ('contacts'), making the basic purpose understandable. However, it doesn't differentiate this tool from sibling search tools like crm_search_companies or crm_search_leads, nor does it specify what makes the filters 'contact-specific' beyond the obvious. The purpose is clear but lacks 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. There's no mention of when to use crm_search_contacts versus crm_get_contact (for single contact retrieval) or crm_list_objects (for unfiltered listing), nor does it indicate prerequisites like authentication needs. The phrase 'contact-specific filters' is vague and doesn't help the agent choose between this and other 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?
No annotations are provided, so the description carries full burden. It mentions 'specific filters' which hints at filtering capabilities, but doesn't disclose critical behavioral traits: whether this is a read-only operation, pagination behavior, rate limits, authentication requirements, or what happens when no results are found. For a search 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at 4 words with no wasted text. However, this conciseness comes at the cost of being under-specified rather than efficiently informative. It's front-loaded but lacks necessary 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 annotations, no output schema), the description is severely incomplete. It doesn't explain what properties can be filtered/sorted, how filterGroups work, what 'after' means, or what the tool returns. For a search tool with rich filtering capabilities, this minimal description leaves the agent 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 all 5 parameters are undocumented in the schema. The description only vaguely references 'specific filters' which partially relates to the 'filterGroups' parameter but doesn't explain any parameters' purposes, formats, or relationships. It 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 'Search emails with specific filters' states the verb (search) and resource (emails) but is vague about scope and capabilities. It doesn't specify what kind of search this is (full-text, property-based, etc.) or how it differs from sibling tools like 'emails_list'. The purpose is understandable 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. With sibling tools like 'emails_list' and 'emails_search' existing, the description doesn't indicate whether this is for complex filtering versus simple listing, or any prerequisites for usage. The agent receives no contextual decision-making help.
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 but reveals almost nothing about behavioral traits. It doesn't disclose whether this is a write operation (implied by 'create'), what permissions are needed, whether it's idempotent, how failures are handled in partial batches, or what the response format looks like. This is inadequate 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?
The description is a single, focused sentence with no wasted words. It's appropriately sized for what it communicates, though what it communicates is insufficient. 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?
For a batch creation tool with complex nested parameters (0% schema coverage), no annotations, and no output schema, the description is completely inadequate. It doesn't explain the input structure, expected behavior, error handling, or return values. The agent would struggle to use this tool correctly based solely on this description.
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?
With 0% schema description coverage and 1 parameter ('inputs') that contains complex nested objects, the description provides zero information about parameter semantics. It doesn't explain what 'inputs' should contain, the structure of meeting properties, required fields, or the associations 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 verb ('create') and resource ('multiple meetings'), and specifies the operation scope ('in a single request'). It distinguishes from the singular 'meetings_create' sibling by emphasizing batch capability, 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 the singular 'meetings_create' or other batch tools. It mentions 'multiple meetings' but doesn't specify minimum/maximum batch sizes, prerequisites, or error handling 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 full burden but offers minimal behavioral context. It doesn't disclose whether this is a read-only operation, what permissions are required, whether results are paginated, rate limits, or what the output format looks like. 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, which is efficient for a simple concept. However, this conciseness comes at the cost of completeness - it's arguably under-specified rather than optimally concise. The single sentence is front-loaded but lacks necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 undocumented parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns, how parameters work, or behavioral characteristics. While it states the basic purpose, it leaves too many unknowns for effective agent use given the complexity implied by the parameter count.
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 5 parameters, the description provides no information about what parameters exist or their meanings. 'Optional filtering' vaguely references parameters but doesn't name or explain any of them (after, archived, associations, limit, properties). 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 'List all notes with optional filtering' clearly states the verb ('List') and resource ('notes'), but it's vague about scope and doesn't differentiate from sibling tools like notes_search. It doesn't specify what 'all notes' means (e.g., all accessible notes, all notes in a workspace) or how filtering works.
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_search or notes_batch_read. The description mentions 'optional filtering' but doesn't explain what filtering capabilities exist or when this tool is preferred over search tools for similar functionality.
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 'Get details' which implies a read-only operation, but doesn't clarify permissions, rate limits, error handling, or what happens if the task doesn't exist. For a tool with zero annotation coverage, this leaves critical behavioral aspects unspecified, though it doesn't contradict any annotations.
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 with the core purpose ('Get details of a specific task'), making it easy to parse quickly. Every word earns its place, achieving maximum efficiency without being 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?
Given the tool's complexity (3 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what 'details' are returned, how parameters affect the output, or behavioral constraints. For a retrieval tool with undocumented inputs and outputs, 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters, while the schema has 3 parameters with 0% description coverage. 'taskId' is required but unexplained; 'associations' and 'properties' arrays are undocumented. The description fails to compensate for the schema's lack of parameter documentation, leaving all parameter meanings ambiguous to an 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 'Get details of a specific task' clearly states the verb ('Get') and resource ('task'), making the purpose understandable. However, it's vague about what 'details' include and doesn't distinguish this from sibling tools like tasks_list or tasks_search, which also retrieve task information. The description is functional 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 that this is for retrieving a single task by ID (as implied by the required 'taskId' parameter), nor does it contrast with tasks_list (for multiple tasks) or tasks_search (for filtered searches). Without this context, an agent might misuse it when other tools are more 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 mentions 'update' which implies mutation, but doesn't disclose critical behavioral traits such as permissions required, whether updates are destructive or partial, error handling for invalid inputs, rate limits, or response format. 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 with zero waste—'Update multiple call records in a single request' is front-loaded and appropriately sized. It directly conveys the core purpose without unnecessary elaboration, earning 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?
Given the complexity of a batch update tool with 1 parameter (but nested objects), no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It lacks details on behavior, parameters, error handling, and output, 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 only mentions 'multiple call records' without explaining the 'inputs' parameter structure, required fields like 'id' and 'properties', or the nested properties (e.g., 'hs_call_body', 'hs_call_status'). This leaves parameters largely undocumented, failing to add meaningful 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 'Update multiple call records in a single request' clearly states the action (update) and resource (call records), but it's somewhat vague about scope and doesn't distinguish from sibling tools like 'calls_update' (single update) or 'calls_batch_create' (batch create). It specifies 'multiple' and 'in a single request' which adds some specificity, but lacks detail on what 'update' entails 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 explicit guidance on when to use this tool versus alternatives is provided. The description implies batch operations but doesn't specify scenarios (e.g., efficiency for bulk updates, prerequisites like existing call IDs, or limitations). With siblings like 'calls_update' for single updates and 'calls_batch_create' for creation, the lack of comparative context leaves 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. It states 'Create' which implies a write/mutation operation, but it doesn't mention permissions required, whether the operation is idempotent, what happens on conflicts, or what the response looks like. For a creation 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 5 words, with zero wasted language. It's front-loaded with the core action and resource. While this conciseness comes at the cost of completeness, the structure itself is efficient and to the point.
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 5-parameter creation tool with no annotations and no output schema, the description is severely incomplete. It doesn't explain what an 'association' entails in this system, doesn't document any of the parameters, doesn't describe the response format, and provides no behavioral context. The conciseness comes at the expense of necessary information 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, meaning none of the 5 parameters are documented in the schema. The description provides no information about what 'fromObjectId', 'toObjectId', 'associationTypes', or the object types mean. It doesn't explain the relationship between these parameters or provide examples, failing 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 'Create an association between two objects' clearly states the action (create) and resource (association), but it's vague about what an 'association' means in this CRM context. It doesn't distinguish this tool from sibling tools like 'crm_batch_create_associations' or 'crm_create_object', leaving ambiguity about when to use this specific tool versus 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?
No guidance is provided on when to use this tool versus alternatives like 'crm_batch_create_associations' for multiple associations or 'crm_create_object' for creating the objects themselves. The description offers no context about prerequisites, such as whether the objects must exist first, or any constraints on association types.
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. 'Search' implies a read operation, but the description doesn't clarify if this is paginated, has rate limits, requires specific permissions, or what the output format looks like. It mentions 'lead-specific filters' but doesn't explain what makes them specific to leads versus other resources. The description adds 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 extremely concise at just 5 words with zero wasted language. It's front-loaded with the core purpose. While it may be too brief for adequate tool understanding, it achieves perfect conciseness within its limited scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 5 parameters (one required), 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the complex filtering system, pagination behavior, return format, or how this differs from other search/list tools. The minimal description leaves critical gaps 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?
Schema description coverage is 0%, meaning none of the 5 parameters have descriptions in the schema. The description mentions 'lead-specific filters' which loosely relates to the 'filterGroups' parameter, but doesn't explain any of the other parameters (after, limit, properties, sorts) or provide guidance on how to construct filter groups. 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 'Search leads with lead-specific filters' states the verb ('search') and resource ('leads'), making the basic purpose clear. However, it's vague about what 'lead-specific filters' means and doesn't distinguish this tool from its sibling 'crm_search_contacts' or 'crm_search_companies' beyond the resource type. It doesn't specify whether this searches all leads or has specific scope limitations.
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 siblings like 'crm_get_lead' (single lead retrieval), 'crm_list_objects' (generic listing), and other search tools for different resources, there's no indication of when this search tool is preferable. No prerequisites, limitations, or comparison to similar tools 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. 'Search' implies a read operation, but the description doesn't disclose whether this requires authentication, has rate limits, returns paginated results, or what format results come in. For a search tool with 6 parameters and no annotation coverage, this is a significant behavioral information 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 zero 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex search tool with 6 parameters (2 required), 0% schema description coverage, no annotations, and no output schema, the description is severely incomplete. It doesn't explain what 'CRM objects' encompasses, how search results are returned, or provide any context about the filtering system that the schema details.
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. 'using filters' only hints at the filterGroups parameter, ignoring the other 5 parameters (objectType, properties, sorts, limit, after). The description adds minimal value beyond what the parameter names themselves suggest, failing to explain what CRM objects are searchable or how filters work.
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' states the verb ('Search') and resource ('CRM objects'), but is vague about scope and lacks specificity. It doesn't distinguish this from sibling tools like crm_search_companies, crm_search_contacts, or crm_search_leads, which appear to be more specific versions of 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?
No guidance is provided on when to use this tool versus alternatives. With multiple sibling search tools (crm_search_companies, crm_search_contacts, crm_search_leads) and a general crm_list_objects tool, the description offers no context about when this general search is preferred over more specific searches or listing 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Update' implies a mutation operation, the description doesn't address critical behavioral aspects: whether this requires specific permissions, what happens if the object doesn't exist, whether updates are partial or complete, if there are rate limits, or what the response contains. For a mutation tool with zero annotation coverage, this represents a significant transparency 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 zero wasted language. It's front-loaded with the essential action and resource. While it lacks detail, every word earns its place by communicating the core function 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 mutation tool with 3 required parameters, 0% schema description coverage, no annotations, and no output schema, the description is incomplete. It doesn't address what the tool returns, error conditions, authentication requirements, or how it differs from the many similar sibling tools. The minimal description leaves too many contextual questions unanswered 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 and 3 required parameters, the description provides no information about parameters beyond what's implied by the tool name. The schema shows objectType with enum values and a properties object, but the description doesn't explain what these mean, what format properties should take, or how objectId is obtained. 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.
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'), making the basic purpose understandable. However, it's somewhat vague about what constitutes a 'CRM object' and doesn't distinguish this tool from its many sibling tools like crm_update_company, crm_update_contact, or crm_batch_update_objects, which all perform similar update operations on CRM entities.
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 numerous sibling tools like crm_update_company, crm_update_contact, crm_update_lead, and crm_batch_update_objects, there's no indication of when this generic 'update_object' is preferred over the more specific tools or batch operations. No prerequisites, constraints, or comparison context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'update' implies a mutation, it doesn't specify whether this requires special permissions, what happens on success/failure, if changes are reversible, or any rate limits. For a mutation tool with zero annotation coverage, this lack of detail 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, direct sentence with no wasted words: 'Update an existing email record'. It's front-loaded and efficiently conveys the core action, though this brevity comes at the cost of missing helpful 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 (2 parameters with nested objects, 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't explain parameter meanings, behavioral traits, or output expectations. For an update tool with rich input structure, 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.
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 mentions 'email record' but doesn't explain the two required parameters ('emailId' and 'properties') or the nested properties object with fields like 'hs_email_subject'. It fails to add meaningful semantics beyond what's inferred from the tool name, leaving parameters 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 'Update an existing email record' clearly states the verb ('update') and resource ('email record'), making the basic purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'emails_batch_update' or 'emails_update' (if there were multiple email update tools), nor does it specify what aspects of an email can be updated beyond the generic term 'record'.
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 email ID), compare it to batch operations like 'emails_batch_update', or indicate scenarios where it's appropriate. Without this context, an agent might misuse it or overlook better options.
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 'List all engagements' which implies a read-only operation, but doesn't clarify if this is safe, paginated, or has rate limits. For a tool with 5 parameters and no annotation coverage, this lacks critical context about performance, permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just one sentence: 'List all engagements with optional filtering'. It's front-loaded and wastes no words, making it easy to parse quickly. Every word serves a purpose in conveying 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 tool with 5 undocumented parameters, no annotations, no output schema, and many sibling alternatives, the description is incomplete. It doesn't explain what 'engagements' are, how filtering works, what the response contains, or how this differs from other list tools. The minimal description leaves too many open questions 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 none of the 5 parameters have descriptions in the schema. The description only vaguely mentions 'optional filtering' without explaining what parameters are available or their purposes. It fails to compensate for the complete lack of schema documentation, leaving parameters like 'activityTypes', 'startTime', and 'limit' 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 'List all engagements with optional filtering' clearly states the verb ('List') and resource ('engagements'), but it's vague about what 'engagements' specifically refers to compared to sibling tools like 'calls_list' or 'meetings_list'. It doesn't distinguish itself from other list tools in the server, leaving ambiguity about the scope of 'engagements'.
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 'engagement_details_get', 'engagement_details_get_associated', 'calls_list', and 'meetings_list', there's no indication of how this tool differs or when it's preferred. The mention of 'optional filtering' is generic and doesn't help with 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 the full burden of behavioral disclosure. It states 'Update' implying a mutation, but doesn't disclose critical traits like required permissions, whether changes are reversible, rate limits, or what happens to unspecified fields. 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 with no wasted words. It's appropriately sized and front-loaded, stating the core action clearly 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 tool's complexity (mutation with 3 parameters, nested objects, no output schema, and no annotations), the description is incomplete. It lacks details on behavioral traits, parameter meanings, and usage context, making it insufficient for safe and effective tool invocation 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 for undocumented parameters. It mentions 'engagement's details' but doesn't explain the three parameters (engagementId, engagement, metadata) or their semantics (e.g., engagementId identifies the target, engagement contains updatable fields). This adds minimal value beyond 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 'Update an existing engagement's details' clearly states the verb ('Update') and resource ('engagement's details'), but it's vague about what specific details can be updated. It doesn't distinguish from sibling tools like 'engagement_details_create' or 'engagement_details_archive', leaving ambiguity about scope and 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. The description doesn't mention prerequisites (e.g., needing an engagement ID), exclusions, or comparisons to siblings like 'engagement_details_create' for new engagements or 'engagement_details_archive' for deletion, 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.
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 'search' and 'filters' but doesn't explain what the search returns (e.g., pagination, result format), potential rate limits, authentication requirements, or error conditions. For a search tool with 5 parameters and no 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence: 'Search meetings with specific filters.' It's front-loaded and wastes no words, making it easy to parse quickly. However, this conciseness comes at the cost of detail, which is reflected in lower scores for 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?
Given the complexity (5 parameters, 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't explain what the tool returns, how to use the filters effectively, or any behavioral aspects. For a search tool with multiple parameters and no structured support, more context is needed to guide 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 are documented in the schema. The description only vaguely references 'specific filters,' which doesn't explain parameters like 'after,' 'filterGroups,' 'limit,' 'properties,' or 'sorts.' It fails to compensate for the lack of schema 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 'Search meetings with specific filters' clearly states the verb ('search') and resource ('meetings'), making the basic purpose understandable. However, it's vague about what constitutes 'specific filters' and doesn't distinguish this tool from sibling tools like 'meetings_list' or 'meetings_get' in any meaningful way. It's adequate 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. With sibling tools like 'meetings_list' and 'meetings_get' available, there's no indication of when filtering is needed versus simpler listing or retrieval. No prerequisites, exclusions, or comparative context 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Create a new note' implies a write operation, but it fails to describe critical behaviors: whether authentication is required, if there are rate limits, what happens on success/failure, or if the note is immediately visible. 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 at three words, with zero wasted language. It's front-loaded with the core action ('Create'), making it easy to parse quickly. However, this conciseness comes at the cost of completeness, as noted 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?
Given the tool's complexity (2 parameters with nested objects, no annotations, no output schema), the description is inadequate. It doesn't cover parameter meanings, behavioral traits, usage context, or expected outputs. For a create operation in a CRM-like system with sibling tools, more detail 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.
Parameters2/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 no information about them. It doesn't explain what 'properties' or 'associations' mean, their required fields (e.g., 'hs_note_body'), or how to structure them. With low schema coverage, the description fails to compensate, 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 'Create a new note' clearly states the verb ('Create') and resource ('note'), making the basic purpose understandable. However, it lacks specificity about what constitutes a 'note' in this context (e.g., a CRM note, engagement note) and doesn't distinguish it from sibling tools like 'notes_batch_create' or 'engagement_details_create', leaving room for 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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., required permissions), when to choose batch operations (like 'notes_batch_create'), or how it differs from similar tools (e.g., 'engagement_details_create'). This absence 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. 'Get' implies a read operation, but it doesn't disclose behavioral traits like whether it requires authentication, returns structured data, handles errors, or has rate limits. For a tool with 3 parameters and no 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, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. This is an example of efficient communication.
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 parameter usage, return values, or behavioral context. For a tool that likely retrieves structured note data, this leaves too many gaps for effective 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 documentation. The description mentions 'details' but doesn't explain what parameters like 'associations' or 'properties' do, or how 'noteId' should be formatted. 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.
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'), making the purpose understandable. However, it lacks specificity about what 'details' include and doesn't distinguish this tool from potential siblings like 'notes_list' or 'notes_search' beyond the singular focus. It's adequate but vague 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. With siblings like 'notes_list' (for multiple notes) and 'notes_search' (for filtered queries), it's unclear if this is for retrieving a single note by ID only, or if it has other use cases. 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action ('search') without mentioning whether this is read-only, has rate limits, requires authentication, returns paginated results, or what happens on errors. For a search tool with complex parameters, this leaves critical behavioral traits 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 extremely concise with just four words, front-loading the core action. There's no wasted language, though this brevity contributes to underspecification rather than 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 complexity (5 parameters with nested structures, 0% schema coverage, no output schema, and no annotations), the description is inadequate. It doesn't explain the search capabilities, result format, error handling, or prerequisites, leaving the agent with insufficient 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?
The schema has 0% description coverage, so parameters like 'filterGroups', 'properties', 'sorts', 'limit', and 'after' are undocumented. The description mentions 'specific filters' which hints at 'filterGroups', but doesn't explain the other parameters, their purposes, or how they interact. It 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search notes with specific filters' states the basic verb ('search') and resource ('notes'), but is vague about what 'specific filters' means. It doesn't differentiate from sibling tools like 'notes_list' or 'notes_search' (if that exists elsewhere), nor does it specify the scope or nature of the search beyond filtering.
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_get'. The description mentions 'specific filters' but doesn't explain what scenarios warrant this tool over simpler listing tools or how it relates to other search 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?
With no annotations provided, the description carries full burden but only states the action ('create') without disclosing behavioral traits like permissions required, whether it's idempotent, rate limits, error handling, or what happens on partial failures. It's a basic statement that fails to add meaningful context beyond the obvious.
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—'Create a batch of products' is front-loaded and appropriately sized for its minimal content. It earns its place by stating the core action, though it lacks 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 tool's complexity (batch creation with nested parameters), no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't address return values, error cases, or operational context, making it inadequate for effective 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%, and the description adds no parameter information beyond implying batch creation. It doesn't explain the 'inputs' array structure, required fields like 'properties', or the nested properties (e.g., 'name', 'price'), leaving parameters undocumented and unclear 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 'Create a batch of products' clearly states the verb ('create') and resource ('products'), but it's vague about what 'batch' entails and doesn't distinguish from sibling tools like 'products_create' (single creation) or 'products_batch_update' (batch update). It provides basic purpose but lacks specificity about scope or 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 such as 'products_create' for single products or 'products_batch_update' for updates. The description implies batch creation but doesn't specify use cases, prerequisites, or exclusions, leaving the agent to infer usage from context 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. It states this is an update operation (implying mutation) but doesn't cover critical aspects: whether it requires specific permissions, if updates are atomic/partial, error handling for invalid inputs, rate limits, or what the response contains. For a batch mutation tool, 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 waste. It's front-loaded with the core action ('Update multiple tasks') and adds clarifying context ('in a single request'). No extraneous words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch mutation tool with no annotations, 0% schema description coverage, and no output schema, the description is inadequate. It doesn't explain input semantics, behavioral traits (permissions, atomicity), error handling, or output format. Given the complexity of batch operations and lack of structured documentation, more guidance 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 description must compensate but fails to do so. It mentions 'multiple tasks' but doesn't explain the 'inputs' parameter structure, required fields (id, properties with hs_task_subject/body), or property meanings (e.g., hs_task_priority enum values). The schema details these, but without description coverage, users rely solely on raw schema interpretation.
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 multiple tasks in a single request' clearly states the verb (update) and resource (tasks), and specifies it's a batch operation. However, it doesn't distinguish this from sibling tools like 'tasks_update' (single task update) or 'tasks_batch_create' (batch creation), leaving the differentiation implicit rather than explicit.
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 task IDs), compare it to single-task updates ('tasks_update') or batch creation ('tasks_batch_create'), or specify scenarios where 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?
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 disclose critical traits such as required permissions, whether the update is idempotent, potential side effects (e.g., triggering notifications), or error handling. 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 at three words, with no wasted language. It's front-loaded with the core action ('Update'), making it easy to scan. However, this conciseness comes at the cost of completeness, as it lacks necessary details for effective tool use.
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 no output schema), the description is incomplete. It doesn't cover behavioral aspects, parameter meanings, or usage context. Without annotations or an output schema, the description should provide more guidance on what the tool does, how to use it, and what to expect, but it falls short.
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 adds no information about parameters beyond the generic 'update' action. It doesn't explain what 'taskId' is, what 'properties' contains, or the meaning of fields like 'hs_task_priority' or 'hs_task_status'. With low schema coverage, the description fails to compensate, 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 'Update an existing task' clearly states the verb ('update') and resource ('task'), which provides a basic understanding of the tool's function. However, it doesn't differentiate this tool from its sibling 'tasks_batch_update' or other update tools in the server, nor does it specify what aspects of a task can be updated beyond the generic term. This makes the purpose somewhat vague in the broader 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. It doesn't mention prerequisites (e.g., needing a taskId), when not to use it (e.g., for creating new tasks, which would require 'tasks_create'), or how it differs from batch operations like 'tasks_batch_update'. This lack of context leaves the agent without clear usage 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 states a read operation ('Get'), implying it's likely safe and non-destructive, but doesn't confirm this or address other behaviors like authentication needs, rate limits, error handling, or response format. For a 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 easy to parse. It's front-loaded with the core purpose. However, it could be more structured by explicitly separating purpose from parameter context, but its brevity is appropriate for a simple-sounding tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 parameters with 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't explain the tool's behavior, parameter usage, or return values, leaving critical gaps for the agent. For a tool that might filter or customize property retrieval, 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 they're undocumented in the schema. The description adds no information about these parameters—it doesn't explain what 'archived' filters, what 'properties' array contains, or how they affect the output. With low coverage, the description fails to compensate, leaving parameters ambiguous.
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') and target resource ('all properties for leads'), which is specific and unambiguous. It distinguishes from sibling tools like 'crm_get_lead' (which gets lead data) and 'crm_create_lead_property' (which creates properties). However, it doesn't explicitly mention what 'properties' refers to (e.g., custom fields, attributes), 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 prerequisites (e.g., needing lead IDs), differentiate from similar tools like 'crm_get_company_properties' or 'crm_get_contact_properties', or specify use cases (e.g., retrieving metadata for filtering). This leaves the agent to 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. 'Update' implies mutation, but there's no information about permissions required, whether changes are reversible, validation specifics beyond the mention of 'validated properties', error handling, or what happens to unspecified properties. For a mutation 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.
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. There's no wasted verbiage, though it could potentially benefit from being slightly more informative given 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 2 parameters (one being a complex nested object), 0% schema description coverage, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens during the update, what 'validated' means, what the response contains, or how this differs from similar 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 'validated properties' which hints at the 'properties' parameter, but doesn't explain what 'contactId' is, what validation entails, or provide any examples of valid property values. With 2 parameters (including a complex nested object) completely undocumented in the schema, the description adds minimal value.
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 contact'), making the purpose understandable. It specifies 'with validated properties' which adds some nuance. However, it doesn't distinguish this from sibling tools like crm_update_company or crm_update_lead, which have similar patterns.
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 available (including crm_batch_update_contacts, crm_update_company, crm_update_lead), there's no indication of when this single-contact update is preferred over batch operations or when to use contact-specific versus generic object 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 for behavioral disclosure. It states 'Get' which implies a read operation, but doesn't specify if it's safe (non-destructive), requires authentication, has rate limits, or what the output format might be. For a tool with zero 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, clear sentence with no wasted words. It's appropriately sized for a simple lookup tool and front-loads the essential 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?
Given the tool's complexity (simple read operation), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'details' includes, potential error conditions, or how this differs from sibling tools. For a tool in a rich ecosystem with many alternatives, more contextual information 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?
The description mentions 'specific engagement' which implies the 'engagementId' parameter, but adds no semantic details beyond what the bare schema provides (0% coverage). With only one required parameter, the baseline is 4, but the description doesn't explain what format the ID should be, where to find it, or provide examples, so it's reduced to 3 for minimal added value.
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 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?
The description provides no guidance on when to use this tool versus alternatives like 'engagement_details_list' (for multiple engagements) or 'engagement_details_get_associated' (for related data). It mentions 'specific engagement' which implies you need an ID, but offers no explicit usage context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions creation but lacks details on permissions, rate limits, error handling, or whether the operation is atomic. For a batch creation tool, this is a significant gap, as agents need to understand risks like partial failures or system 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 no wasted words. It's front-loaded with the core action and efficiently conveys the batch nature of the operation, making it easy to scan and understand 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 (1 parameter with nested objects, 0% schema coverage, no annotations, no output schema), the description is inadequate. It doesn't explain parameter semantics, behavioral traits, or output expectations, leaving critical gaps for a tool that performs batch creation operations.
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%, and the description provides no information about parameters. It doesn't explain the 'inputs' array structure, required fields like 'hs_note_body', or how to format associations. With 1 parameter (a complex nested array) undocumented, 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 action ('create multiple notes') and scope ('in a single request'), which is specific and distinguishes it from the singular 'notes_create' sibling tool. However, it doesn't explicitly differentiate from other batch operations like 'notes_batch_update' or 'notes_batch_archive', which would require more precise language about the creation aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 merely states what it does without context about efficiency, prerequisites, or limitations, leaving the agent to infer 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read-only operation ('Read', 'Retrieve'), which is consistent with the tool name, but doesn't specify whether it's safe, idempotent, or has side effects. It lacks details on rate limits, authentication needs, error handling, or return format, leaving significant gaps 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that directly address the tool's function. It's front-loaded with the main purpose and avoids unnecessary fluff. However, the second sentence is somewhat redundant with the first, slightly reducing efficiency.
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 batch read tool with 4 parameters (3 required), 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain parameter interactions, return values, error cases, or how it differs from sibling tools. For a tool with significant contextual needs, this provides inadequate guidance.
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 only mentions 'idProperty' for retrieving records by custom unique values, ignoring 'productIds', 'properties', and 'propertiesWithHistory'. This leaves three required parameters and their interactions unexplained, failing to add meaningful semantics 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 tool's purpose: reading a batch of products by internal ID or unique property values. It specifies the verb ('Read'), resource ('products'), and scope ('batch'), distinguishing it from single-read tools like 'products_read'. However, it doesn't explicitly differentiate from other batch operations like 'products_batch_archive' or 'products_batch_update' beyond the read 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 minimal usage guidance, mentioning retrieval by 'idProperty' parameter for custom unique values. It doesn't explain when to use this tool versus alternatives like 'products_list', 'products_search', or 'products_read', nor does it mention prerequisites or constraints. The guidance is limited to parameter usage without broader context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a mutation operation ('Update') but fails to mention critical aspects like required permissions, whether updates are idempotent or reversible, rate limits, or error handling. 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.
Conciseness4/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 ('Update a batch of products'). It avoids redundancy but could be more structured by separating key concepts like identification methods and update scope.
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 update tool with 0% schema coverage, no annotations, and no output schema, the description is insufficient. It lacks details on input structure, behavioral constraints, error responses, and sibling tool differentiation, making it incomplete 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%, so the description must compensate for undocumented parameters. It only mentions 'idProperty' in passing without explaining its role or how it interacts with 'id'. The complex 'inputs' array structure and nested 'properties' object are not addressed, leaving most parameter semantics unclear.
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 specifies the target ('by internal ID, or unique values specified by the `idProperty` query param'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'products_update' (single update) or 'products_batch_create', leaving room for ambiguity in sibling 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 such as 'products_update' for single updates or 'products_batch_create' for creation. The description mentions the 'idProperty' param but doesn't explain its use cases or prerequisites, offering minimal contextual 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 full burden for behavioral disclosure. It only states it's a read operation, which implies non-destructive behavior, but doesn't cover critical aspects like authentication requirements, rate limits, error handling for partial failures in batch requests, response format, or whether it returns all data or requires pagination. For a batch operation with complex inputs, 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 front-loaded with the core purpose and uses clear, direct language. Every word earns its place in conveying the batch reading concept.
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 complex nested parameters (0% schema coverage), no annotations, and no output schema, the description is incomplete. It doesn't address how results are returned, error handling, limitations on batch size, or relationship to other call tools. The agent lacks sufficient context to use this tool effectively 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?
The schema has 0% description coverage, with one complex parameter ('inputs' array containing objects with 'id', 'properties', and 'associations'). The description adds no information about parameter meanings, required fields beyond schema, or how to structure batch requests. It doesn't explain what 'properties' or 'associations' represent, or provide examples. With low schema coverage, the description fails to compensate.
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') and resource ('multiple call records'), and specifies the batch operation aspect ('in a single request'). It distinguishes from individual read tools like 'calls_get' but doesn't explicitly differentiate from other batch operations like 'calls_batch_archive' or 'calls_batch_update' beyond the 'Read' 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. It doesn't mention when batch reading is preferable to individual 'calls_get' calls, when to use 'calls_list' for broader queries, or any prerequisites or constraints for batch operations. 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 'Get details' which implies a read operation, but doesn't disclose behavioral traits like whether it requires authentication, has rate limits, returns structured data, or handles errors. For a tool with 3 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?
The description is a single, clear sentence with zero wasted words. It's appropriately sized for a simple retrieval tool and front-loads the essential 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?
Given 3 parameters with 0% schema coverage, no annotations, no output schema, and multiple sibling tools, the description is incomplete. It doesn't explain what details are returned, how to use optional parameters, or how this differs from other call-related tools, 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 schema provides no parameter documentation. The description mentions 'a specific call' which hints at the 'callId' parameter, but doesn't explain the optional 'associations' or 'properties' parameters at all. It 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 ('Get') and resource ('details of a specific call'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'calls_list' or 'calls_search' which also retrieve call information, missing 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 like 'calls_list' for multiple calls or 'calls_search' for filtered searches. It lacks any context about prerequisites, exclusions, or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'List all calls' implies a read operation, but the description doesn't mention pagination behavior (though 'limit' parameter exists), rate limits, authentication requirements, whether archived calls are included by default, or what format the results will be in. For a tool with 5 parameters and no output schema, this leaves significant behavioral questions unanswered.
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 upfront. There's no wasted language or redundancy. It's appropriately sized for a list operation, though the lack of additional context makes it feel sparse rather than 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 5 parameters, 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the filtering parameters, doesn't describe return format or pagination, doesn't mention rate limits or permissions, and doesn't differentiate from sibling tools. The agent would struggle to use this tool effectively without guessing about parameter meanings and expected behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 5 parameters have descriptions in the schema. The description only mentions 'optional filtering' generically without explaining what parameters are available, what 'after' means (cursor pagination?), what 'associations' filters do, or what 'properties' controls. The description 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all calls with optional filtering' clearly states the verb ('List') and resource ('calls'), and specifies scope ('all') with an additional capability ('optional filtering'). It distinguishes from other call tools like calls_get (single call) and calls_search (likely more advanced search), but doesn't explicitly differentiate from calls_batch_read or other list operations. The purpose is clear but sibling differentiation could be more explicit.
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, calls_batch_read, or calls_get. With multiple sibling tools available (calls_search, calls_batch_read, calls_get, etc.), the agent receives no explicit or implied direction about when this list tool is appropriate versus other call retrieval methods. The mention of 'optional filtering' hints at some capability but doesn't define boundaries.
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 'Update' implying mutation but fails to mention permissions needed, whether changes are reversible, rate limits, or what the response looks like. 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 no wasted words, making it easy to parse. It's appropriately sized for a basic tool definition, though it could benefit from more detail given the 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 no annotations, 0% schema description coverage, no output schema, and complex nested parameters, the description is inadequate. It doesn't explain behavioral traits, parameter meanings, or output expectations, leaving the agent under-informed.
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 by explaining parameters. It mentions 'call record' but doesn't detail what 'callId' or 'properties' entail, such as the nested fields like 'hs_call_status' or required fields. This 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 ('Update') and resource ('an existing call record'), making the purpose evident. However, it doesn't differentiate from sibling tools like 'calls_batch_update' or 'emails_update', which would require more specificity to achieve 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 tool versus alternatives such as 'calls_batch_update' for multiple updates or 'calls_create' for new records. The description lacks context about prerequisites or exclusions, offering 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Get' implies a read-only operation, it doesn't specify whether this requires authentication, has rate limits, returns structured data, or handles errors. For a tool with zero 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 gets straight to the point with no wasted words. It's appropriately sized for a simple retrieval 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 tool with 2 parameters (0% schema coverage), no annotations, and no output schema, the description is insufficient. It doesn't explain what 'communication preferences' consist of, what format they're returned in, or provide enough parameter guidance. The context demands more detail than this minimal description provides.
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 'for a contact' which hints at the 'contactId' parameter, but doesn't explain what format this ID should be in or mention the optional 'subscriptionId' 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 verb ('Get') and resource ('communication preferences for a contact'), making the purpose specific and understandable. However, it doesn't differentiate from sibling tools like 'communications_get_subscription_status' or 'communications_get_subscription_definitions' which might retrieve related but different data.
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 sibling tools like 'communications_get_subscription_status' and 'communications_update_preferences' that handle related aspects, but the description doesn't indicate when this specific retrieval tool is appropriate or what distinguishes it from those alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a read operation ('Get') but doesn't disclose whether this requires specific permissions, has rate limits, returns paginated results, or what the output format might be. 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 that gets straight to the point with no wasted words. It's appropriately sized for a simple retrieval tool and front-loads the core functionality 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?
Given the tool's moderate complexity (2 required parameters), lack of annotations, and no output schema, the description is insufficiently complete. It doesn't explain what 'subscription status' entails, how results are returned for multiple contacts, or any error conditions. The agent would need to guess about important operational details.
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 contacts' which hints at the 'contactIds' parameter, but doesn't explain what 'subscriptionId' represents, the expected format of IDs, or any constraints. With 2 undocumented parameters, this 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 ('Get') and resource ('subscription status for multiple contacts'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'communications_get_preferences' or 'communications_get_subscription_definitions', which also retrieve communication-related data, so it doesn't reach the highest 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. There's no mention of prerequisites, when-not-to-use scenarios, or comparison with sibling tools like 'communications_get_preferences' or 'communications_update_subscription_status'. 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 the action without behavioral details. It doesn't disclose whether this is a mutation (implied by 'Subscribe'), what permissions are required, if it's idempotent, what happens on success/failure, or any rate limits. 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, clear sentence with zero wasted words. It's front-loaded with the core action and target, making it immediately understandable 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 (one with complex enums), 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the operation's effects, parameter meanings, return values, or error conditions, leaving the agent with insufficient context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 'contactId' represents, what the legal basis parameters mean, or why they might be required. The description adds no value beyond what the bare schema provides, failing to address 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 ('Subscribe') and target ('a contact to all email communications'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'communications_update_preferences' or 'communications_update_subscription_status' that might handle similar subscription operations with different scopes or methods.
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 'communications_update_preferences' or 'communications_unsubscribe_contact'. The description doesn't mention prerequisites, such as needing a valid contact ID, or contextual factors like whether this overrides existing preferences.
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 'Unsubscribe' implies a mutation operation, the description doesn't disclose whether this action is reversible, what permissions are required, whether it triggers notifications, or what happens to historical communications. It mentions 'all email communications' which is useful context, but lacks other critical behavioral details 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, clear sentence with zero wasted words. It's appropriately sized for the tool's apparent 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 mutation tool with 3 parameters (one with complex enum values), 0% schema coverage, and no output schema, the description is inadequate. It doesn't explain the legal basis parameters, doesn't describe what the tool returns, and provides minimal behavioral context. Given the complexity implied by the legal basis parameters, the description should do significantly more to help an agent understand this tool.
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 any parameters. It doesn't explain what 'contactId' represents, what the legal basis parameters mean, or how they affect the unsubscribe operation. The description fails to compensate for the 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 action ('Unsubscribe') and resource ('a contact from all email communications'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'communications_update_preferences' or 'communications_update_subscription_status', which might handle 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 like 'communications_update_subscription_status' or 'communications_update_preferences'. It doesn't mention prerequisites, exclusions, or specific contexts where this tool is appropriate versus other subscription management 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. 'Update' implies a mutation operation, but the description doesn't specify permissions required, whether changes are reversible, rate limits, or what happens on success/failure. For a mutation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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 zero wasted words. It's appropriately sized for a basic tool description 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 mutation tool with 3 parameters (including complex nested objects), 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what gets updated, how the parameters interact, what legal basis or status values mean, or what the tool returns. The description fails to compensate for the lack of structured 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?
With 0% schema description coverage and 3 parameters (including a nested object with 4 properties), the description provides no parameter information beyond what's implied by the tool name. It doesn't explain what 'contactId', 'subscriptionId', or 'preferences' represent, nor does it clarify the relationship between these parameters or the meaning of the nested preference fields.
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. It doesn't explicitly differentiate from sibling tools like 'communications_update_subscription_status' or 'communications_subscribe_contact', but the specificity of 'preferences' (vs 'status' or subscription actions) provides some implicit 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. With multiple sibling tools in the communications domain (get_preferences, subscribe_contact, unsubscribe_contact, update_subscription_status), there's no indication of when this update tool is appropriate versus those other operations. No prerequisites or context for usage 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?
With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose permissions needed, whether changes are reversible, rate limits, error handling, or what happens to existing data. For a 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 with zero waste. It's front-loaded and appropriately sized for the tool's complexity, though 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 mutation tool with 2 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It lacks parameter details, behavioral context, 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 but adds no parameter information. It doesn't explain 'subscriptionId' or 'updates' structure, legal basis enums, or status meanings. With 2 parameters and nested arrays/objects, this leaves critical 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 action ('Update') and target ('subscription status for multiple contacts'), which is specific and actionable. It distinguishes from sibling tools like 'communications_subscribe_contact' and 'communications_unsubscribe_contact' by handling multiple contacts, 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 'communications_subscribe_contact' or 'communications_unsubscribe_contact'. The description implies bulk operations but lacks explicit context, prerequisites, or exclusions, leaving usage ambiguous.
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 'archive (delete)' implies a destructive mutation, it doesn't clarify whether this is reversible, what permissions are required, how errors are handled, or what happens to related data. 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 that gets straight to the point with zero wasted words. It's appropriately sized for the tool's complexity and front-loads the core 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 mutation tool with 4 required parameters, 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain parameter meanings, behavioral implications, error conditions, or what constitutes a successful archive operation. The agent would be left guessing about critical aspects of 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?
The schema has 0% description coverage, so all 4 parameters are undocumented in the schema. The description provides no information about what 'fromObjectId', 'fromObjectType', 'toObjectId', or 'toObjectType' mean, their expected formats, or how they relate to the association being archived. This leaves critical parameter semantics 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 ('archive/delete') and resource ('association between two objects'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'crm_archive_object' or 'crm_batch_archive_associations', which would require more specific context about what distinguishes association archiving from object archiving.
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_batch_archive_associations' or 'crm_archive_object'. It doesn't mention prerequisites, appropriate contexts, or exclusions, 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 full burden. It discloses the destructive action ('archive/delete') but doesn't mention permissions needed, whether deletions are reversible, rate limits, or what happens on partial failures. For a batch destructive tool, 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 with zero waste—front-loaded with the core action and scope. Every word earns its place, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch destructive tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It lacks details on parameter usage, behavioral traits like error handling, and expected outcomes, 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. It mentions 'multiple associations' which hints at the 'inputs' array parameter but doesn't explain 'fromObjectType' or 'toObjectType' enums, the structure of 'from' and 'to' objects with 'id' fields, or how these parameters define the associations to archive.
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 associations') with the scope 'in a single request.' It distinguishes from sibling 'crm_archive_association' by specifying batch capability, but doesn't explicitly contrast with other batch tools like 'crm_batch_archive_objects'.
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_archive_association' for single deletions or 'crm_batch_archive_objects' for archiving objects instead of associations. The description implies batch usage but lacks explicit 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?
With no annotations, the description carries full burden. It states 'Archive (delete)' indicating destructive action, but lacks details on permissions needed, whether deletion is permanent/reversible, rate limits, error handling for partial failures, or response format. 'Archive' vs 'delete' terminology is ambiguous without clarification.
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 with zero waste - every word contributes meaning. Front-loaded with core action ('Archive (delete) multiple CRM objects'), followed by operational context ('in a single request'). No redundant phrasing.
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 inadequate. It doesn't cover critical behavioral aspects like safety implications, parameter usage, or what to expect upon execution. The context demands more comprehensive guidance.
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 description must compensate but adds no parameter information. It doesn't explain what 'objectType' enum values represent, format of 'objectIds', or constraints like maximum batch size. The schema provides structure but description offers 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 ('Archive (delete) multiple CRM objects') and resource ('CRM objects'), with 'in a single request' indicating batch capability. It distinguishes from single-object operations like 'crm_archive_object' but doesn't explicitly differentiate from other batch tools like 'crm_batch_archive_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?
No guidance on when to use this tool versus alternatives like 'crm_archive_object' (single object) or 'crm_batch_archive_associations' (different resource type). The description implies batch usage but lacks explicit comparison 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, the description carries full burden but only states it's a creation operation. It doesn't disclose behavioral traits like whether it's idempotent, requires specific permissions, has rate limits, returns partial successes, or what happens on failure. 'Create' implies mutation, but details are missing, leaving significant gaps for a batch write 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 waste. It's front-loaded with the core action ('Create multiple associations') and adds context ('in a single request') concisely. 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 tool's complexity (batch creation with 3 parameters, nested objects, no annotations, and no output schema), the description is incomplete. It lacks parameter explanations, behavioral context, usage guidelines, and output details. For a mutation tool with significant schema complexity, this minimal description doesn't provide enough context for 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 'fromObjectType', 'toObjectType', or 'inputs' structure (e.g., IDs, association types). For 3 parameters with complex nested objects, this is inadequate, failing to clarify semantics 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 ('Create') and resource ('multiple associations'), specifying it's a batch operation ('in a single request'). It distinguishes from non-batch siblings like 'crm_create_association' by emphasizing 'multiple' and 'batch', though it doesn't explicitly contrast with other batch tools like 'crm_batch_create_objects'.
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 prerequisites, error handling, or compare it to single-association creation ('crm_create_association') or other batch operations. Usage context is implied by 'batch' 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?
No annotations are provided, so the description carries full burden. It mentions it's a batch creation tool, implying mutation, but doesn't disclose critical behaviors: whether it's idempotent, what happens on partial failures, rate limits, authentication needs, or what the response looks like (e.g., success/failure details). 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 front-loaded with the core purpose and appropriately sized for a simple statement, though it lacks detail needed for 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 tool's complexity (batch mutation with a nested schema), lack of annotations, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't explain the input structure, behavioral traits, or output, leaving the agent with insufficient context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 doesn't explain the 'inputs' parameter or its structure (e.g., that it's an array of company objects with properties and optional associations). The description adds no parameter semantics beyond the tool name, leaving the complex schema 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 ('Create multiple companies') and resource ('companies'), specifying it's a batch operation ('in a single request'). It distinguishes from non-batch siblings like 'crm_create_company', but doesn't explicitly differentiate from other batch create tools like 'crm_batch_create_contacts' or 'crm_batch_create_leads' 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. It doesn't mention prerequisites (e.g., required permissions), when batch creation is preferable to single creation, or how it compares to other batch tools (e.g., 'crm_batch_create_objects'). 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?
No annotations are provided, so the description carries full burden. It mentions creation but doesn't disclose behavioral traits like required permissions, whether duplicates are allowed, rate limits, error handling for 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 front-loads the core functionality. There's no wasted verbiage 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 (batch mutation with nested objects), lack of annotations, 0% schema description coverage, and no output schema, the description is inadequate. It doesn't explain parameter requirements, behavioral constraints, or what to expect upon success/failure, leaving critical gaps for agent 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 contacts' but provides no details about the 'inputs' parameter structure, required fields, or semantics of nested properties like 'associations'. The description adds minimal value beyond the schema's existence.
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 a batch operation ('in a single request'). However, it doesn't distinguish this from sibling tools like 'crm_batch_create_companies' or 'crm_batch_create_leads', which have identical descriptions except for 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 like 'crm_create_contact' (single creation) or other batch tools. The description only states what it does, not when it's appropriate 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?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states this is a creation operation (implying mutation), but doesn't disclose permissions required, rate limits, whether leads are created synchronously/asynchronously, error handling for partial failures, or what the response contains. For a batch write tool with zero annotation coverage, this leaves critical 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 front-loaded with the core action and resource, making it easy to parse quickly 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 the tool's complexity (batch creation with nested parameter structures), lack of annotations, and no output schema, the description is severely incomplete. It doesn't explain the input format, behavioral expectations, error scenarios, or what success looks like. For a mutation tool with rich parameter schema but 0% description coverage, 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 but fails to do so. It mentions 'multiple leads' but provides no details about the 'inputs' parameter structure, required fields like 'properties', optional associations, or property constraints (e.g., email format, enum values for leadstatus/rating). The description adds almost no value beyond the schema's structural definition.
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 leads') and resource ('leads'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'crm_create_lead' or 'crm_batch_create_contacts', which would require specifying this is specifically for leads rather than other CRM objects.
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 creation is preferable to single creation (e.g., for efficiency with many leads), nor does it reference sibling tools like 'crm_create_lead' for single operations or 'crm_batch_create_contacts' for other object types.
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 any behavioral traits: no information about permissions required, whether it's idempotent, rate limits, error handling for partial failures, or what happens when associations fail. For a batch mutation 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 states the core functionality without unnecessary words. It's appropriately sized and front-loaded with the essential information about batch creation.
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 (associations, properties), no annotations, and no output schema, the description is insufficient. It doesn't explain what constitutes a valid CRM object, how associations work, what properties are expected, or what the tool returns. The combination of complexity and lack of structured documentation requires more descriptive content.
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 adds no information about what 'inputs' or 'objectType' mean, their formats, or constraints. With 2 parameters (including a complex nested 'inputs' array), the description 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 action ('Create multiple CRM objects') and scope ('in a single request'), which is a specific verb+resource combination. It distinguishes from single-object creation tools like 'crm_create_object' by emphasizing batch capability, though it doesn't explicitly differentiate from other batch creation tools like 'crm_batch_create_companies' or 'crm_batch_create_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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, limitations, or when to choose batch creation over individual creation tools. With many sibling tools available (including other batch creation tools for specific object types), this lack of 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 write/mutation operation, the description doesn't mention permission requirements, whether updates are atomic or partial, error handling for failed updates, rate limits, or what happens to unspecified contact properties. 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 extremely concise at just 6 words, front-loading the core functionality ('Update multiple contacts') without any wasted words. Every word earns its place, though this conciseness comes at the expense 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 batch mutation tool with no annotations, 0% schema description coverage, and no output schema, the description is severely incomplete. It doesn't address critical context like authentication requirements, mutation consequences, error handling, or response format. The description fails to provide the necessary information for safe and 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?
The schema has 0% description coverage, meaning no parameters are documented in the schema. The description mentions 'multiple contacts' which hints at the 'inputs' array parameter, but provides no details about the structure of contact objects, required fields like 'id', or the meaning of properties like 'leadstatus' and 'lifecyclestage'. 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 ('Update') and resource ('multiple contacts'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'crm_update_contact' (single contact update) or other batch update tools like 'crm_batch_update_companies', leaving some ambiguity about when to choose this specific batch contact 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 tool versus alternatives. With multiple sibling tools including 'crm_update_contact' (single contact), 'crm_batch_update_objects' (generic batch), and 'crm_batch_update_companies' (other entity type), there's no indication of when batch contact updates are preferred over individual updates or other 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. While 'update' implies mutation, it doesn't address critical aspects like required permissions, whether updates are atomic or partial, rate limits, error handling for partial failures, or what happens to unspecified fields. For a batch mutation tool, 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 for a straightforward batch update operation and gets directly 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 batch mutation tool with no annotations, 0% schema description coverage, and no output schema, the description is inadequate. It doesn't address behavioral expectations, parameter usage, error conditions, or return values. The agent would struggle to use this tool correctly without significant trial-and-error or external 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?
The schema has 0% description coverage, meaning parameters are completely undocumented in the structured schema. The description mentions 'multiple leads' but doesn't explain the 'inputs' parameter structure, required fields, or how to format the update data. It 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 ('update') and resource ('multiple leads'), making the purpose evident. It specifies 'in a single request' which adds useful context about batch operations. However, it doesn't explicitly differentiate from sibling tools like 'crm_update_lead' or 'crm_batch_update_contacts', which would require 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 single-lead updates or batch updates for other CRM objects. There's no mention of prerequisites, limitations, or appropriate contexts for batch operations versus 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 full burden for behavioral disclosure. While 'Update' implies mutation, it doesn't address critical aspects: whether this requires specific permissions, what happens on partial failures, rate limits, whether updates are atomic, what the response format looks like, or any side effects. For a batch 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, efficient sentence with zero wasted words. It's front-loaded with the core purpose and includes the key operational detail ('in a single request'). Every word earns its place, making it maximally concise while still communicating the essential 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 batch mutation tool with 2 parameters (0% schema coverage), no annotations, and no output schema, the description is inadequate. It doesn't explain parameter usage, behavioral characteristics, error handling, or what constitutes a successful operation. The description fails to provide the necessary context for safe and 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 provides no parameter information. It doesn't explain what 'objectType' represents (despite having an enum), what 'inputs' should contain, the structure of properties objects, or any validation rules. With 2 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.
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 the operational context ('in a single request'). It distinguishes from single-update tools like crm_update_object by emphasizing batch processing. However, it doesn't explicitly differentiate from other batch update tools like crm_batch_update_companies/contacts/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?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools for batch updates (crm_batch_update_companies, crm_batch_update_contacts, crm_batch_update_leads) and single-update tools, but the description doesn't explain when this general batch update is preferred over type-specific batch updates or when batch operations are appropriate versus 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 mentions 'validated properties' which hints at input validation, but fails to describe critical traits like whether this is a mutation (implied by 'Create'), authentication requirements, rate limits, error handling, or what happens on success (e.g., returns a company ID). This is inadequate for a creation 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 with no wasted words. It is 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?
Given the tool's complexity (2 parameters with nested objects, no output schema, and no annotations), the description is insufficient. It lacks details on parameter usage, behavioral expectations, return values, and differentiation from siblings. For a creation tool in a CRM context, this leaves significant gaps for an AI agent to operate 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 descriptions. The description only vaguely mentions 'validated properties', which partially relates to the 'properties' parameter but doesn't explain its structure or the 'associations' parameter at all. It adds minimal semantic value beyond the bare 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 action ('Create') and resource ('new company'), making the purpose evident. It adds 'with validated properties' which hints at input validation, but doesn't explicitly distinguish this tool from other company-related tools like crm_update_company 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 is provided on when to use this tool versus alternatives like crm_batch_create_companies or crm_create_object. The description lacks context about prerequisites, such as required permissions or when to choose this over batch operations, 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. It mentions 'validated properties', hinting at input validation, but fails to describe critical traits like whether this is a write operation (implied by 'Create'), authentication needs, rate limits, error handling, or what happens on success (e.g., returns a contact ID). 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 with no wasted words. It is appropriately sized and front-loaded, 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 tool's complexity (2 parameters with nested objects, no output schema, and no annotations), the description is incomplete. It doesn't explain the return value, error conditions, or detailed parameter usage, leaving significant gaps for an agent to invoke it correctly in a CRM 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 schema description coverage is 0%, meaning parameters are undocumented in the schema. The description only vaguely references 'validated properties', which doesn't explain the two parameters ('properties' and 'associations') or their nested structures. 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 ('Create') and resource ('contact'), making the purpose specific and understandable. However, it doesn't distinguish this tool from its sibling 'crm_batch_create_contacts' or other creation tools in the CRM domain, 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 'crm_batch_create_contacts' or 'crm_create_object'. It lacks context about prerequisites, such as required permissions or system states, 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. It mentions 'Get all associations' but fails to specify if this is a read-only operation, whether it requires authentication, any rate limits, pagination behavior (implied by 'after' and 'limit' parameters but not explained), or what the output format might be. This leaves significant gaps 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 waste—it directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly, though this conciseness comes at the cost of detail 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?
Given the complexity (5 parameters with 0% schema coverage, no annotations, and no output schema), the description is incomplete. It lacks details on behavioral traits, parameter usage, output expectations, and differentiation from siblings. For a tool that retrieves data with multiple inputs, this minimal description doesn't provide enough context for effective 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 description must compensate for undocumented parameters. It mentions 'associations of a specific type between objects,' which hints at 'fromObjectType' and 'toObjectType' but doesn't explain the enum values, required 'fromObjectId,' optional 'after' for pagination, or 'limit' constraints. This adds minimal meaning beyond the bare schema, failing to adequately cover the 5 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get all associations') and resource ('of a specific type between objects'), which provides a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'crm_list_association_types' or 'crm_get_object' that might handle related but different operations, nor does it mention the CRM context explicitly.
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_list_association_types' or 'crm_search_objects' from the sibling list. It lacks context about prerequisites (e.g., needing specific object types) or exclusions, offering only a basic functional statement without comparative usage 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get all properties for contacts', which implies a read-only operation, but doesn't clarify critical aspects like whether it requires authentication, returns paginated results, handles errors, or has rate limits. 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 zero wasted words. It's front-loaded with the core action ('Get all properties for contacts'), making it easy to parse. Every word serves a purpose, adhering to the principle of conciseness without being overly sparse.
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 (2 parameters with 0% schema coverage, no annotations, and no output schema), the description is incomplete. It doesn't explain the parameters, return format, or behavioral traits like error handling. For a read operation in a CRM context, more details are needed to ensure the agent can use it correctly without guesswork.
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 their purposes are undocumented. The description 'Get all properties for contacts' doesn't explain what these parameters do—for example, whether 'archived' filters results or 'properties' specifies which properties to retrieve. It adds no meaningful semantics 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 'Get all properties for contacts' clearly states the verb ('Get') and resource ('properties for contacts'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'crm_get_contact' (which likely gets contact details) and 'crm_get_company_properties' (for companies). However, it doesn't specify whether this retrieves all properties globally or for specific contacts, 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 prerequisites (e.g., needing contact IDs), exclusions (e.g., not for archived contacts unless specified), or related tools like 'crm_get_contact' or 'crm_get_company_properties'. The agent must infer usage from the name alone, which is insufficient for optimal 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 the full burden of behavioral disclosure. It states it's a 'get' operation (implying read-only), but doesn't mention permissions, rate limits, error handling, or what happens if the object doesn't exist. For a tool with 4 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?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and appropriately sized for a basic retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't explain parameter usage, behavioral constraints, or return values, leaving the agent with insufficient information 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 adds no parameter information. It doesn't explain what 'associations' or 'properties' arrays do, the meaning of 'objectType' enum values, or format requirements for 'objectId'. With 4 parameters completely undocumented, this is a significant 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 'Get a single CRM object by ID' clearly states the action (get) and resource (CRM object) with a specific mechanism (by ID). It distinguishes from sibling tools like crm_list_objects (which lists multiple) and crm_search_objects (which searches with criteria), though it doesn't explicitly name these 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 crm_get_company, crm_get_contact, or crm_batch_read_objects. The description implies usage when you have a specific object ID and type, but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'validated properties' which hints at input validation, but doesn't describe what validation entails, whether the operation is idempotent, what permissions are required, or what happens on success/failure. For a mutation tool with zero annotation coverage, this 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 zero wasted words. It's appropriately sized for a basic update operation and front-loads the essential information (update action + target 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 mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't explain what 'validated' means, what happens to unspecified properties, what the response contains, or any error conditions. The agent lacks critical context 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%, so the description must compensate for undocumented parameters. It mentions 'validated properties' which relates to the 'properties' parameter, but doesn't explain what 'companyId' is, what format it expects, or provide any examples of valid property values. With 2 parameters completely undocumented in the schema, the description adds minimal semantic value.
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 company'), making the purpose unambiguous. It distinguishes from creation tools like 'crm_create_company' by specifying 'existing'. However, it doesn't explicitly differentiate from other update tools like 'crm_update_contact' or 'crm_update_object' beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a companyId), when to use batch updates instead, or how it differs from other update operations like 'crm_update_object'. 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 'Create' implies a write operation, it doesn't specify permissions required, whether the operation is idempotent, rate limits, error behavior for partial failures, or what happens on success. 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 a single, efficient sentence that communicates the core functionality without unnecessary words. It's appropriately sized for the tool's purpose and front-loads the key information about batch creation of email records.
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), no annotations, and no output schema, the description is inadequate. It doesn't explain the parameter structure, expected inputs, return values, or behavioral characteristics 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?
Schema description coverage is 0%, meaning all parameter semantics must come from the description. The description mentions 'multiple email records' which hints at the 'inputs' array parameter, but provides no details about the structure, required fields, or meaning of nested properties like 'associations' and 'properties'. This leaves critical parameter information 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 email records') with the operational context ('in a single request'). It distinguishes from the singular 'emails_create' sibling tool by specifying batch capability, though it doesn't explicitly contrast with other batch operations 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?
The description provides no guidance on when to use this tool versus alternatives like the singular 'emails_create' or other batch operations. There's no mention of prerequisites, performance considerations, or error handling for batch operations, leaving the agent without contextual usage 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Read' implies a non-destructive operation, it doesn't address important behavioral aspects: whether this requires specific permissions, how errors are handled when some IDs fail, what the response format looks like, or any rate limiting implications of batch operations. The description is too minimal 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 extremely concise - a single sentence with zero wasted words. It's front-loaded with the core functionality and uses efficient language. Every word earns its place in communicating the basic 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 tool with complex nested parameters (array of objects with id, properties, and associations), no annotations, and no output schema, the description is severely incomplete. It doesn't explain parameter requirements, return format, error handling, or operational constraints. The minimal description is inadequate for the tool's 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?
With 0% schema description coverage and 1 parameter (which is a complex array of objects), the description provides no information about the 'inputs' parameter structure. It doesn't explain what 'id' represents, what 'properties' array should contain, or what 'associations' enum values 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 action ('Read') and resource ('multiple email records') with the operational context ('in a single request'). It distinguishes from individual read operations like 'emails_get' by specifying batch capability. However, it doesn't explicitly differentiate from other batch read tools like 'notes_batch_read' or 'products_batch_read' that 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. It doesn't mention when batch reading is preferable to individual reads (emails_get) or list operations (emails_list), nor does it specify prerequisites like authentication requirements or rate limiting 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 full burden for behavioral disclosure. 'Update multiple email records' implies a write/mutation operation but doesn't specify permissions required, whether changes are reversible, rate limits, error handling for partial failures, or what the response contains. For a batch mutation 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.
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 core function, though the brevity comes at the cost of completeness. Every word earns its place by conveying the essential action and scope.
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 a batch mutation tool with complex nested parameters (1 top-level parameter with array of objects containing multiple properties), 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'update' entails, what fields can be modified, how to identify records, or what happens upon success/failure. The agent lacks critical context 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?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. The description mentions 'multiple email records' which hints at the 'inputs' array parameter, but provides no details about what constitutes a record (id + properties), required fields, or the structure of properties. It doesn't explain the nested schema for email properties at all, leaving critical parameter semantics 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 ('Update') and resource ('multiple email records') with the operational context ('in a single request'). It distinguishes from individual update tools like 'emails_update' by specifying batch capability. However, it doesn't explicitly differentiate from other batch operations like 'emails_batch_create' or 'emails_batch_archive' beyond the verb '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 prerequisites, when batch updating is preferred over individual updates, or how it differs from other batch operations like 'emails_batch_create' or 'emails_batch_archive'. 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 'gets details' but doesn't clarify if this is a read-only operation, what permissions are required, whether it's idempotent, or how errors are handled. This leaves significant gaps for a tool that likely accesses sensitive data.
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 with the core purpose, making it easy to scan and understand 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% schema coverage, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'details' include, how to use optional parameters, or what the return format looks like, leaving too much undefined for 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 schema has 0% description coverage, so the description must compensate. It mentions 'a specific email' which hints at the emailId parameter but doesn't explain the associations or properties parameters at all. This leaves two of three parameters undocumented, failing to address 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 ('Get') and resource ('details of a specific email'), making the purpose understandable. However, it doesn't differentiate from sibling tools like emails_list or emails_search, which also retrieve email information but with different scopes or filters.
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 email ID), contrast with emails_list for bulk retrieval, or specify use cases like fetching metadata for a known email.
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 but doesn't mention pagination behavior (despite 'after' and 'limit' parameters), rate limits, authentication requirements, or what happens when no emails exist. The description doesn't disclose whether this is a read-only operation or has side effects, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 7 words, front-loading the core purpose with zero wasted words. Every element ('List all emails with optional filtering') earns its place, making it easy to scan and understand the basic function 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 5 parameters, 0% schema description coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain the filtering parameters, return format, pagination behavior, or error conditions. While concise, it lacks the contextual details needed for effective tool selection and invocation given the complexity of the input schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. The description only mentions 'optional filtering' generically without explaining any of the 5 specific parameters (after, archived, associations, limit, properties). It doesn't clarify what 'after' refers to (timestamp, cursor), what 'associations' filtering does, or what 'properties' controls. 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 'List all emails with optional filtering' clearly states the verb ('List') and resource ('emails'), and specifies scope ('all') with optional filtering. It distinguishes from other email tools like emails_get (single email) and emails_search (search with criteria), but doesn't explicitly differentiate from emails_list's siblings beyond the filtering aspect.
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_search or emails_get. It mentions 'optional filtering' but doesn't explain what filtering capabilities exist or when filtering should be used versus other tools. No prerequisites, exclusions, or comparative context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'Get all engagements,' implying a read operation, but lacks details on permissions, rate limits, pagination (despite limit/offset parameters), or response format. This leaves significant behavioral 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, making it easy to parse. It's front-loaded with the core action, though this 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?
Given the complexity (7 parameters, no annotations, no output schema), the description is incomplete. It doesn't cover parameter meanings, behavioral traits like pagination or permissions, or return values, leaving the agent with insufficient information 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?
With 0% schema description coverage and 7 parameters, the description adds no meaning beyond the schema. It doesn't explain what 'objectId' or 'objectType' refer to, the purpose of 'activityTypes', or the format of 'startTime'/'endTime'. The description 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 ('engagements associated with an object'), making the purpose specific and understandable. However, it doesn't distinguish this tool from sibling tools like 'engagement_details_get' or 'engagement_details_list', which appear to handle engagements differently, so it misses full 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, such as 'engagement_details_get' or 'engagement_details_list', nor does it mention prerequisites like required object types. It's a basic statement 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get' implies a read operation, the description doesn't specify whether this requires authentication, what happens if the meeting doesn't exist, rate limits, or the format of returned details. For a tool with zero 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, 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.
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 annotations, no output schema), the description is incomplete. It doesn't explain what 'details' include, how to use optional parameters, error conditions, or authentication needs. For a tool that retrieves specific data with configuration options, this leaves too much unspecified 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 'specific meeting' which hints at the required meetingId parameter, but doesn't explain the optional 'associations' or 'properties' parameters at all. It adds minimal value beyond what's inferred from the parameter names, failing 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 ('Get') and resource ('details of a specific meeting'), making the purpose immediately understandable. It distinguishes this from sibling tools like meetings_list or meetings_search by specifying 'specific meeting' rather than listing or searching multiple meetings. However, it doesn't explicitly differentiate from other 'get' tools like calls_get 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like needing a meetingId), when not to use it (e.g., for multiple meetings), or point to sibling tools like meetings_list for listing meetings or meetings_search for finding meetings. 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a read operation, implying it's non-destructive, but doesn't mention authentication requirements, rate limits, error handling, or what happens with invalid IDs. The description is too minimal 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 extremely concise with just 7 words, front-loading the core functionality. Every word earns its place with no redundancy or unnecessary elaboration. It's efficiently structured for a basic tool 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 read tool with complex nested parameters (0% schema coverage), no annotations, and no output schema, the description is severely incomplete. It doesn't explain the parameter structure, expected return format, error conditions, or performance characteristics. The minimal description is inadequate for this tool's 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?
The schema has 0% description coverage for its single parameter ('inputs'), which is a complex array of objects with 'id', 'properties', and 'associations' sub-parameters. The description adds no information about what these parameters mean, what format IDs should be in, what properties can be requested, or how associations work. It fails to compensate for the poor 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 ('multiple notes'), and specifies the operational context ('in a single request'), which distinguishes it from single-note read operations. However, it doesn't explicitly differentiate from sibling tools like 'notes_get' or 'notes_list' beyond the batch aspect.
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 'notes_get' (for single notes) or 'notes_list' (for listing notes with filtering). There's no mention of prerequisites, performance considerations, or trade-offs between batch and 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 but only states it's an update operation. It doesn't disclose behavioral traits like required permissions, whether it's idempotent, error handling for partial failures, rate limits, or what happens to existing note properties not mentioned. 'Update' implies mutation, but safety aspects are unaddressed.
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 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?
Given the tool's complexity (batch mutation with nested objects), lack of annotations, 0% schema description coverage, and no output schema, the description is inadequate. It doesn't cover parameter meanings, behavioral expectations, or output format, leaving critical gaps for safe and correct 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%, so the description must compensate but adds no parameter information. It doesn't explain the 'inputs' array structure, the 'id' and 'properties' fields, or the required 'hs_note_body'. For a tool with one complex parameter (array of objects), this is a significant 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 ('Update') and resource ('multiple notes'), specifying it's a batch operation ('in a single request'). It distinguishes from non-batch siblings like 'notes_update', but doesn't explicitly differentiate from other batch operations like 'notes_batch_create' or 'notes_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 on when to use this tool versus alternatives like 'notes_update' (single note) or other batch operations. The description implies batch updating but doesn't specify prerequisites, constraints, 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a read operation, implying it's non-destructive, but doesn't address critical aspects like authentication requirements, rate limits, error handling, pagination, or response format. For a batch operation with zero 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 with no wasted words. It's front-loaded with the core purpose and structured clearly, making it easy to parse quickly. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a batch operation with 1 parameter (including nested objects), 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain parameter usage, behavioral constraints, or what the tool returns, leaving the agent with insufficient information 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 description mentions no parameters, while the schema has 1 parameter ('inputs') with 0% description coverage. The schema reveals 'inputs' is an array of objects with 'id', 'properties', and 'associations', but the description adds zero semantic context about what these mean or how to use them. 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 ('Read multiple tasks') and scope ('in a single request'), which is a specific verb+resource combination. It distinguishes itself from single-task operations like 'tasks_get' but doesn't explicitly differentiate from other batch operations like 'tasks_batch_archive' or 'tasks_batch_update' beyond the 'read' 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. It doesn't mention when batch reading is preferred over individual 'tasks_get' calls, nor does it reference sibling tools like 'tasks_list' for broader queries or 'tasks_search' for filtered searches. Usage context is entirely absent.
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 list operation, implying it's likely read-only, but doesn't confirm this or mention any behavioral traits like pagination (implied by 'after' parameter), rate limits, authentication requirements, or what happens when no filters are applied. For a tool with 5 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 extremely concise at just 5 words, with no wasted language. It's front-loaded with the core purpose ('List all tasks') followed by the key additional feature ('with optional filtering'). Every word earns its place, making this optimally efficient in terms of length and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, how results are structured, what the filtering options are, or any behavioral constraints. For a list tool with multiple filtering parameters, this leaves too many gaps for effective 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?
The schema description coverage is 0%, meaning none of the 5 parameters have descriptions in the schema. The description only mentions 'optional filtering' generically without explaining what parameters exist, what they do, or how to use them. This fails to compensate for the complete lack of schema documentation, leaving parameters like 'after', 'archived', 'associations', 'limit', and 'properties' completely 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 verb ('List') and resource ('all tasks'), making the purpose immediately understandable. It also mentions optional filtering, which adds specificity. However, it doesn't distinguish this tool from sibling tools like 'tasks_search' or 'tasks_get', which is why it doesn't reach a score 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 'tasks_search' or 'tasks_get' from the sibling list. It mentions optional filtering but doesn't explain what types of filtering are available or when to use this versus a search tool. This leaves the agent with insufficient context for proper 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 the full burden of behavioral disclosure. It indicates a destructive action ('Archive (delete)'), implying mutation and potential irreversibility, but fails to mention critical details like permissions required, confirmation steps, rate limits, or what happens to associated data. This leaves significant gaps for a tool that performs deletion.
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, front-loaded sentence that directly states the action and resource without any unnecessary words. It efficiently communicates the core purpose, making it easy to parse and understand 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's complexity as a destructive operation with no annotations, 0% schema description coverage, and no output schema, the description is incomplete. It lacks essential context such as behavioral implications, error handling, return values, and differentiation from siblings, 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add any parameter details beyond the input schema, which has 0% description coverage and only specifies 'callId' as a required string. Since schema coverage is low, the description does not compensate by explaining the parameter's meaning, format, or examples, but the single parameter is straightforward, so it 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 verb ('Archive (delete)') and resource ('a call record'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'calls_batch_archive' or 'calls_update', which might handle multiple calls or updates instead of single deletion, leaving room for slight ambiguity 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, such as 'calls_batch_archive' for multiple calls or 'calls_update' for modifications. It lacks context on prerequisites, exclusions, or specific scenarios, offering only a basic action statement without usage 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 full burden. It states the tool archives/deletes records, implying destructive mutation, but lacks details on permissions, reversibility, confirmation prompts, rate limits, or response format. The parenthetical '(delete)' adds some clarity but not comprehensive 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?
Single sentence, front-loaded with key action and resource. No wasted words; every element ('archive', 'delete', 'multiple call records', 'single request') contributes essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive batch tool with no annotations, 0% schema coverage, and no output schema, the description is inadequate. It lacks critical context like side effects, error handling, permissions, and what 'archive/delete' entails operationally, leaving significant gaps for safe agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, with one parameter 'callIds' undocumented in schema. The description mentions 'multiple call records', which hints at the parameter's purpose but doesn't specify format, constraints, or example values. It adds marginal 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 ('archive/delete') and resource ('multiple call records'), with 'in a single request' indicating batch operation. It distinguishes from 'calls_archive' by specifying multiple records, but doesn't explicitly differentiate from other batch operations like 'calls_batch_read' or 'calls_batch_update' beyond the 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?
No explicit guidance on when to use this tool versus alternatives like 'calls_archive' (single record) or other batch operations. The description implies batch processing but doesn't specify thresholds, prerequisites, or error handling compared to 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 the full burden of behavioral disclosure. It mentions creation but doesn't address critical aspects like whether this requires specific permissions, if it's idempotent, how failures are handled in partial batches, rate limits, or what the response contains. For a batch write operation, 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, clear sentence with zero wasted words. It's front-loaded with the core action and efficiently communicates the batch nature of the operation. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch creation tool with complex nested parameters (1 parameter with deep nesting), 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't compensate for the missing structured information about permissions, error handling, response format, or parameter details, leaving the agent poorly equipped to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The tool description mentions 'multiple call records' which hints at the 'inputs' array parameter, but doesn't explain what constitutes a call record, required fields beyond the schema's 'properties', or the structure of nested objects like 'associations'. It adds minimal value beyond what's inferred from the parameter 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 call records') and scope ('in a single request'), which distinguishes it from the singular 'calls_create' sibling tool. However, it doesn't specify what type of call records (e.g., CRM calls) or differentiate from other batch create tools like 'emails_batch_create' or 'meetings_batch_create' beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this batch operation versus the singular 'calls_create' tool, nor are there any prerequisites, limitations (e.g., maximum batch size), or error handling considerations mentioned. The description only states what it does, not when or why 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?
No annotations are provided, so the description carries full burden. It implies a read-only operation ('Get'), but doesn't disclose behavioral traits like authentication requirements, rate limits, pagination, error handling, or what 'all' entails (e.g., if it returns archived items by default). This is a significant gap 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, efficient sentence that front-loads the core purpose without unnecessary words. Every part of the sentence contributes directly to understanding the tool's function, making it appropriately 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 no annotations, 0% schema description coverage, and no output schema, the description is incomplete. It lacks details on behavior, parameter usage, return format, and differentiation from siblings. For a tool in a complex server with many alternatives, this minimal description leaves critical gaps for an agent to use it 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 no parameters, while the schema has one optional parameter ('archived'). The description implies fetching 'all' definitions, which might relate to the 'archived' parameter, but doesn't explain its purpose or how it affects results. Baseline is 3 since schema coverage is low and description adds minimal param 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 ('Get') and resource ('all subscription definitions for the portal'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'communications_get_subscription_status', but the resource specificity provides adequate clarity for a read operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 sibling tools like 'communications_get_subscription_status' and 'communications_get_preferences', the description offers no context about differences in scope, data returned, or appropriate use cases, leaving the agent to infer 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 indicates a destructive action ('Archive (delete)'), which is helpful, but lacks critical details: whether archiving is reversible, what permissions are required, if there are rate limits, or what happens to associated data. For a mutation tool with zero annotation coverage, 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 extremely concise—a single, front-loaded sentence that states the core action without any fluff. Every word earns its place: 'Archive (delete)' clarifies the action, and 'a CRM object' specifies the target. This is efficient and immediately informative.
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 destructive mutation tool), no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It lacks information on behavioral traits (e.g., irreversibility, side effects), output format, error conditions, and usage context. For a tool that permanently modifies data, this minimal description is inadequate to ensure safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond what the input schema provides. Schema description coverage is 0%, but the schema itself clearly defines objectId (string) and objectType (enum with specific values). The description doesn't explain what these parameters mean (e.g., objectType selects the CRM entity type). Since the schema is well-structured with an enum, the baseline of 3 is appropriate, but the description fails 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 ('Archive (delete)') and resource ('a CRM object'), making the purpose immediately understandable. It distinguishes from siblings like crm_update_object or crm_get_object by specifying the destructive action. However, it doesn't explicitly differentiate from crm_batch_archive_objects or other archive tools for different object types, which slightly reduces 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. It doesn't mention prerequisites (e.g., object must exist), when to choose batch operations (crm_batch_archive_objects) for multiple objects, or differences from other archive tools like calls_archive. Usage is implied by the action but lacks explicit context for 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. While 'update' implies mutation, it doesn't disclose critical behavioral traits like required permissions, whether updates are atomic or partial, error handling for invalid inputs, rate limits, or what the response contains. This is inadequate 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 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 mutation tool with no annotations, 0% schema description coverage, and no output schema, the description is insufficient. It lacks details on behavior, error handling, response format, and differentiation from siblings. The context demands more completeness given the complexity and potential impact of batch updates.
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 by implying the 'inputs' parameter contains company data. However, it doesn't explain the structure (array of objects with id and properties), valid property fields, or constraints. With 1 parameter but poor schema documentation, this meets the baseline but doesn't fully compensate.
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 companies'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like crm_update_company (single update) or crm_batch_update_objects (generic batch update), 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. With many sibling tools available (e.g., crm_update_company for single updates, crm_batch_update_objects for generic batch updates), there's no indication of when batch updating companies is preferred 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a read operation ('Get'), but doesn't specify whether it requires authentication, rate limits, error conditions (e.g., invalid ID), or response format. For a tool with 3 parameters and no output schema, this leaves significant gaps in understanding how the tool behaves beyond basic purpose.
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 ('Get a single company by ID') and adds key details ('with specific properties and associations'). There is no wasted language, and it directly addresses what the tool does 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 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It covers the basic purpose and hints at parameters but lacks critical details: no behavioral traits (e.g., read-only nature, error handling), no parameter specifics (e.g., valid 'properties' values), and no output information. This leaves the agent with significant gaps in understanding how to use the tool 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 schema provides no parameter documentation. The description mentions 'by ID' (mapping to 'companyId'), 'specific properties' (hinting at 'properties' array), and 'associations' (mapping to 'associations' array), adding meaningful context for all 3 parameters. However, it doesn't explain parameter formats (e.g., what values 'properties' accepts) or constraints, leaving some ambiguity.
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 a single company') and specifies the resource ('by ID with specific properties and associations'). It distinguishes this from broader search/list tools like 'crm_search_companies' or 'crm_list_objects' by emphasizing retrieval of a single entity. However, it doesn't explicitly differentiate from other 'get' tools like 'crm_get_contact' or 'crm_get_lead' 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a company ID), exclusions (e.g., not for bulk retrieval), or comparisons to sibling tools like 'crm_batch_read_objects' for multiple companies or 'crm_search_companies' for filtering. Usage is implied by the name 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?
No annotations are provided, so 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 if it's safe or has side effects. It doesn't mention authentication needs, rate limits, error handling, or what happens if the lead ID doesn't 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 that front-loads the core action ('Get a single lead by ID') and adds necessary detail ('with specific properties and associations'). There's no wasted words or redundancy, making it appropriately sized and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the return format, error cases, or how properties/associations are specified. For a tool that retrieves data with filtering options, more context is needed to use it effectively, especially without annotations or output schema to fill in the 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 'by ID with specific properties and associations', which hints at the 'leadId', 'properties', and 'associations' parameters. However, with 0% schema description coverage, the schema provides no descriptions for these parameters. The description adds some semantic value by indicating what the parameters control, but doesn't fully compensate for the coverage gap—it doesn't explain format (e.g., string for leadId), optionality, or enum values for associations.
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 by ID', making the purpose specific and understandable. It also mentions 'with specific properties and associations' which adds detail about what data is retrieved. However, it doesn't explicitly differentiate from sibling tools like 'crm_get_lead_properties' or 'crm_get_associations', 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 when to choose this over 'crm_search_leads' for finding leads, 'crm_batch_read_objects' for multiple leads, or 'crm_get_lead_properties' for just properties. Without any context or exclusions, 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?
No annotations are provided, so the description carries the full burden. It implies a read-only operation ('List') but doesn't disclose behavioral traits such as whether it's safe, if it requires permissions, rate limits, or what the output format looks like. For a 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 waste—it directly states the action, resource, and scope without unnecessary words. It's appropriately sized and front-loaded, 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 enums but 0% schema coverage), no annotations, and no output schema, the description is incomplete. It lacks details on parameter usage, behavioral context, and return values, making it inadequate for a tool that likely returns a list of association types without further guidance.
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 'object type pair', which aligns with the two parameters (fromObjectType and toObjectType) but doesn't explain their semantics, enum values, or relationship. The description adds minimal meaning beyond the schema, resulting in a baseline score due to incomplete parameter 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 ('List') and resource ('association types') with scope ('for a given object type pair'), making the purpose specific and understandable. It doesn't explicitly distinguish from sibling tools like 'crm_get_associations' or 'crm_create_association', but the verb 'List' implies a read operation rather than retrieval 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?
The description provides no guidance on when to use this tool versus alternatives like 'crm_get_associations' or 'crm_create_association'. It states the basic context ('for a given object type pair') but lacks explicit when/when-not instructions or named alternatives, leaving usage unclear relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'List' implies a read operation, it doesn't specify whether this requires authentication, has rate limits, returns partial data, or handles errors. The mention of 'pagination' hints at some behavior but lacks details about how pagination works (e.g., cursor-based vs offset).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the core functionality. Every word earns its place with no redundancy 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 5 parameters, 0% schema description coverage, no annotations, and no output schema, the description is insufficient. It doesn't explain the return format, error conditions, authentication needs, or how filtering/pagination parameters work together. 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.
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 partially does. It mentions 'optional filtering and pagination' which maps to parameters like 'archived', 'properties', 'after', and 'limit', but doesn't explain what these parameters mean or how they interact. The description adds some context but leaves most 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 ('List') and resource ('CRM objects of a specific type'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'crm_search_objects' or 'crm_batch_read_objects', which likely serve similar listing/searching functions.
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_batch_read_objects' from the sibling list. There's no mention of prerequisites, limitations, or comparison to 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an update operation but doesn't mention permissions required, whether changes are reversible, rate limits, or what happens to unspecified properties. The mention of 'validated properties' hints at some validation but doesn't explain what validation occurs 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 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.
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 2 parameters (including a complex nested object), the description is inadequate. It doesn't explain what 'validated' means, doesn't mention the sibling tools for context, and provides no information about return values or error conditions.
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 relates to the 'properties' parameter, but doesn't explain what 'leadId' is or provide any details about the nested properties object structure. This adds minimal value beyond what's evident 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') and resource ('an existing lead'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'crm_update_company' or 'crm_update_contact', which follow the same pattern for different CRM objects.
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_batch_update_leads' or 'crm_update_object'. It mentions 'validated properties' but doesn't explain what validation entails or when this tool is preferred over other update 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 but only states the action ('archive/delete') without clarifying permanence, reversibility, permissions required, or error conditions. It mentions 'delete' which implies destructive behavior, but lacks details on consequences (e.g., whether archived emails are recoverable).
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. There is no wasted verbiage, and it directly communicates the tool's function 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 destructive tool with no annotations, 0% schema coverage, and no output schema, the description is inadequate. It fails to address critical aspects like what 'archive' entails, potential side effects, required permissions, or response format, leaving significant gaps for safe 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%, but the description adds no parameter information beyond what's implied by the action. The single parameter 'emailId' is undocumented in both schema and description. Baseline is 3 since schema coverage is low but description doesn't compensate meaningfully.
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 ('an email record'), making the purpose unambiguous. It distinguishes from sibling tools like emails_get or emails_update by specifying the destructive action. However, it doesn't explicitly differentiate from emails_batch_archive, which handles multiple emails.
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_batch_archive for multiple emails or emails_update for modifications. The description lacks context about prerequisites (e.g., needing an existing email) 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. It discloses the destructive nature ('Archive (delete)') and batch behavior, but lacks critical details: whether archiving is reversible, permission requirements, rate limits, error handling for partial failures, or what 'delete' entails (soft/hard). For a destructive batch tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, and every word earns its place. No unnecessary elaboration or repetition.
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 tool with no annotations, no output schema, and 0% schema coverage, the description is incomplete. It misses behavioral details (reversibility, permissions), parameter specifics, and response expectations. Given the complexity and risk of batch deletion, 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%, but the description adds minimal value beyond the schema. It implies 'emailIds' parameter corresponds to 'multiple email records', but doesn't explain format, constraints, or maximum batch size. With 1 parameter and low coverage, baseline is 3 as the description partially compensates but not fully.
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) multiple email records') and resource ('email records'), with 'in a single request' indicating batch operation. It distinguishes from sibling 'emails_archive' by specifying batch capability, though it doesn't explicitly contrast them. 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 is provided on when to use this tool versus alternatives like 'emails_archive' (single email) or other batch operations. The description mentions 'multiple email records' but doesn't specify thresholds, prerequisites, or exclusions. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'archive (delete)' which implies a destructive mutation, but doesn't specify if this is reversible, requires special permissions, has side effects on associated data, or provides confirmation feedback. 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 extremely concise with just three words, front-loading the essential action and resource. There's zero wasted language or redundancy, making it efficient for quick comprehension despite its limitations in 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 destructive operation with no annotations, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't address critical questions: Is this permanent deletion? What happens to associated data? What permissions are required? What does it return? The context demands more disclosure for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond what the schema provides (a single 'engagementId' parameter with 0% schema description coverage). Since there's only one parameter and the description doesn't explain what an 'engagementId' is or where to find it, the baseline of 3 is appropriate - the schema shows the parameter exists but neither source provides meaningful semantics.
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 engagement'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'calls_archive', 'emails_archive', or 'engagement_details_get', which would require clarification about what makes 'engagement_details_archive' unique versus other archive 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. With multiple sibling archive tools (e.g., 'calls_archive', 'emails_archive', 'engagement_details_get'), there's no indication of whether this is for permanent deletion versus soft archiving, or when to choose this over other engagement-related tools like 'engagement_details_get' or 'engagement_details_update'.
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 'archive (delete)', implying a destructive mutation, but doesn't specify if this is permanent, reversible, requires permissions, or has side effects (e.g., affecting related data). For a destructive 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 just three words, front-loaded with the core action and resource. There's no wasted language, 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?
Given the tool's destructive nature (implied by 'archive/delete'), no annotations, no output schema, and incomplete parameter guidance, the description is inadequate. It should address behavioral risks, usage context, and result expectations to be complete 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 description adds no information about the 'meetingId' parameter beyond what the input schema provides (a required string). With 0% schema description coverage, the description doesn't compensate by explaining the parameter's format, constraints, or how to obtain it. However, since there's only one parameter, the baseline is 4, but the lack of any semantic detail reduces it to 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 verb ('archive/delete') and resource ('a meeting'), making the purpose specific and understandable. However, it doesn't distinguish this tool from sibling tools like 'meetings_batch_archive' or 'calls_archive', which have similar purposes but different scopes or 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 'meetings_batch_archive' for multiple meetings or other archive tools for different resources (e.g., 'calls_archive'). It lacks context on prerequisites, such as whether the meeting must exist or be in a specific state.
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 'Archive (delete)' which implies destructive behavior, but doesn't clarify if deletion is permanent/reversible, what permissions are required, or how errors are handled for partial failures. For a batch destructive operation, this minimal disclosure 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core functionality without wasted words. It's appropriately sized for a straightforward tool, 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 destructive batch operation with no annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't address critical aspects like error handling, confirmation requirements, or what happens to associated data. 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?
Schema description coverage is 0%, so the description must compensate. It implies 'meetingIds' parameter through 'multiple meetings' but doesn't explain format, constraints, or maximum batch size. The description adds minimal value beyond what's inferable from the schema name, meeting the baseline for low coverage without fully compensating.
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) multiple meetings') and resource ('meetings'), making the purpose immediately understandable. It distinguishes from the singular 'meetings_archive' sibling by specifying 'multiple meetings in a single request', though it doesn't explicitly contrast with other batch operations like 'meetings_batch_create' or 'meetings_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 prerequisites (e.g., needing meeting IDs), compare with 'meetings_archive' for single deletions, or warn about irreversible deletion. With many sibling tools available, this lack of contextual 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 but offers minimal behavioral insight. It implies a write operation ('Update') but doesn't disclose permissions needed, rate limits, error handling for partial failures, or whether changes are reversible. 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 with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly 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 batch update tool with 1 parameter (complex nested array), 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what constitutes a valid update, how errors are handled, what permissions are required, or what the response contains. The context demands more comprehensive guidance.
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 tool description mentions 'multiple meetings' which hints at the 'inputs' array parameter, adding some context beyond the bare schema. However, it doesn't explain the structure of individual meeting updates (id, properties fields) or the specific properties that can be modified, leaving key 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 action ('Update') and resource ('multiple meetings'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'meetings_update' (single meeting update) or 'meetings_batch_create' (batch creation), 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 'meetings_update' for single updates or 'meetings_batch_create' for batch creation. It mentions 'in a single request' but doesn't explain the trade-offs or prerequisites 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 indicates this is a destructive operation ('Archive (delete)'), which is helpful, but lacks critical details: whether archiving is permanent or reversible, if it requires specific permissions, what the response looks like, or any rate limits. 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 extremely concise—a single phrase with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable. Every word earns its place, though this 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 mutation tool with no annotations, no output schema, and minimal parameter guidance, the description is incomplete. It doesn't address critical context like the permanence of deletion, error conditions, or what happens to associated data. 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 description adds no parameter information beyond what the schema provides (noteId as a required string). With 0% schema description coverage, the description doesn't compensate by explaining what noteId represents (e.g., format, source, uniqueness). However, since there's only one parameter, the baseline is 4, but the lack of any semantic context reduces it to 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 ('Archive (delete)') and resource ('a note'), making the purpose immediately understandable. It distinguishes this tool from sibling tools like notes_create, notes_update, and notes_get by specifying the destructive archival operation. However, it doesn't explicitly differentiate from notes_batch_archive, which handles multiple notes.
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., note must exist), when to choose notes_batch_archive for multiple notes, or what happens after archiving (e.g., permanent deletion vs. recoverable). 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 is to 'archive (delete)', implying a destructive mutation, but doesn't cover critical aspects like permissions required, reversibility, side effects, rate limits, or response format. This is inadequate for a batch destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('archive (delete) multiple notes') and adds clarifying context ('in a single request') without waste. Every word serves a purpose, 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?
For a batch destructive tool with no annotations, no output schema, and low schema coverage, the description is insufficient. It lacks details on behavioral traits (e.g., permanence, errors), parameter semantics, and usage context, leaving the agent under-informed about critical operational aspects.
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 'multiple notes' which implies the 'noteIds' parameter, but with 0% schema description coverage, it doesn't add details like ID format, array size limits, or validation rules. Since schema coverage is low, the description partially compensates but leaves significant gaps, warranting 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) multiple notes') and resource ('notes'), with the specific scope of 'in a single request' distinguishing it from individual operations. However, it doesn't explicitly differentiate from sibling tools like 'notes_archive' (single note) or 'notes_batch_update' (batch update vs. archive), 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 'notes_archive' (single note) or 'notes_batch_update' (batch update). It mentions 'multiple notes' but doesn't clarify thresholds, prerequisites, or exclusions, leaving usage context implied at best.
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, implying a destructive operation, but doesn't clarify if this is reversible, what permissions are required, or any side effects (e.g., impact on associated data). The description is minimal and lacks critical behavioral context 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 waste—every word contributes to the core action. It's appropriately sized and front-loaded, 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 tool's complexity (a destructive mutation with no annotations, 0% schema coverage, and no output schema), the description is inadequate. It lacks details on behavioral traits, error handling, return values, and differentiation from siblings, leaving significant gaps for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, so the description must compensate. It mentions 'ID' which maps to 'productId', adding meaning by indicating it identifies the object to archive. However, it doesn't specify the ID format, source, or validation rules, leaving gaps in parameter understanding.
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 resource ('Object identified by ID') with specific destination ('to the recycling bin'). It distinguishes from sibling tools like 'products_batch_archive' by focusing on single-object archiving, though it doesn't explicitly mention the 'products' context from the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'products_batch_archive' or other archive tools for different resource types (e.g., 'calls_archive', 'emails_archive'). The description implies it's for archiving products but doesn't specify prerequisites, conditions, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Archive (delete)' clearly indicates a destructive operation, it doesn't specify whether this is reversible, what permissions are required, whether there are rate limits, or what happens to associated data. The parenthetical '(delete)' adds some clarity but insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable and 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?
For a destructive batch operation with no annotations and no output schema, the description is inadequate. It doesn't address critical context like whether the operation is atomic, what confirmation is provided, error handling for invalid IDs, or system behavior when some products can't be archived. The minimal description leaves too many unknowns for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'by ID' which provides context for the 'productIds' parameter, but doesn't specify ID format, array size limits, or validation rules. This adds some meaning beyond the bare schema 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 ('Archive (delete)') and resource ('a batch of products by ID'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from its sibling 'products_archive' (singular vs batch), 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?
No guidance is provided about when to use this tool versus alternatives like 'products_archive' (singular) or 'products_batch_update'. The description only states what it does, not when it's appropriate 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?
With no annotations provided, the description must fully disclose behavioral traits. It states the tool creates a product and returns an object with an ID, which implies a write operation and output format. However, it lacks details on error handling, authentication needs, rate limits, or side effects (e.g., whether creation is idempotent or affects other data). This is a significant gap 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.
Conciseness4/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 ('Create a product') and includes the return value. There's no wasted text, making it easy to parse, though it could be slightly more structured (e.g., separating input and output 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?
For a creation tool with no annotations, no output schema, and low schema description coverage (0%), the description is incomplete. It covers the basic purpose and output but misses critical context: parameter details, error cases, behavioral constraints, and differentiation from siblings. This leaves the agent under-informed 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 description mentions 'properties' as input, aligning with the single parameter in the schema (a nested object with fields like name, price, sku). Since schema description coverage is 0%, the description adds some value by hinting at the parameter's role. However, it doesn't explain the structure or constraints of the properties object (e.g., required fields, format), so it only partially compensates for the low 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 ('Create') and resource ('a product'), and specifies the action involves 'given properties' and returns 'a copy of the object, including the ID.' This distinguishes it from sibling tools like products_list or products_update by focusing on creation. However, it doesn't explicitly differentiate from other creation tools (e.g., products_batch_create), so it's not a perfect 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 products_batch_create for multiple products, or prerequisites such as required permissions. It only describes what the tool does, not when it's appropriate, leaving the agent to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 a task, which implies a destructive mutation, but doesn't clarify if archiving is reversible, what permissions are required, whether it affects associated data, or what the response looks like. The parenthetical '(delete)' suggests permanent removal but lacks confirmation.
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, making it immediately scannable and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't explain the parameter, behavioral implications, return values, or how it differs from sibling tools. The agent would struggle to use this correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It doesn't mention the 'taskId' parameter at all, leaving the single required parameter completely undocumented. However, with only one parameter, the baseline is 4, but the description adds no value beyond what's obvious from the tool name, so it scores lower.
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 'Archive (delete) a task' clearly states the verb (archive/delete) and resource (task), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'tasks_batch_archive' which likely archives multiple tasks, 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 'tasks_batch_archive' for multiple tasks or 'tasks_update' for modifying instead of archiving. There's no mention of prerequisites, permissions needed, or consequences of archiving versus other 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 the action ('archive (delete)'). It lacks critical behavioral details like whether deletion is permanent/reversible, required permissions, rate limits, error handling for partial failures, or confirmation prompts. This is inadequate for a destructive batch 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 no wasted words. It's front-loaded with the core action and scope, 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 batch tool with no annotations and no output schema, the description is insufficient. It doesn't address critical context like side effects, success/error responses, or how it differs from single-task deletion. More detail is needed given the complexity and risk.
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 implies the parameter's purpose ('multiple tasks'). However, it doesn't specify format constraints (e.g., ID requirements, array size limits) or provide examples. Baseline 3 is appropriate as it 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 ('archive (delete)') and resource ('multiple tasks'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling 'tasks_archive' (single vs. batch), 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?
No guidance is provided on when to use this tool versus alternatives like 'tasks_archive' (single task) or other batch operations. The description mentions 'multiple tasks' but doesn't clarify thresholds or prerequisites for batch 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's a creation operation. It doesn't disclose whether this is a write operation (implied but not explicit), authentication needs, rate limits, idempotency, or what happens on failure (e.g., partial creation). More behavioral context is needed 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, clear sentence with no wasted words. It's front-loaded and efficiently conveys 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, no output schema, and complex nested parameters, the description is inadequate. It doesn't explain the input structure, expected output, error behavior, or usage trade-offs, 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.
Parameters3/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 'inputs' array parameter, but with 0% schema description coverage and complex nested objects (e.g., properties with required fields like hs_task_subject), it doesn't add meaningful semantics beyond what the bare schema structure implies. Baseline 3 is appropriate as the schema exists but lacks 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 multiple tasks') and scope ('in a single request'), which is specific and distinguishes it from the singular 'tasks_create' sibling. However, it doesn't explicitly mention what resource type (tasks) beyond the tool name, making it slightly less than perfect.
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 operation versus the singular 'tasks_create' tool, nor does it mention prerequisites, error handling for partial failures, or rate limits. It's a basic statement 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'optional filtering' but doesn't describe key behaviors like whether this is a read-only operation, if it requires authentication, rate limits, pagination behavior, or what the output looks like. 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 extremely concise - a single sentence with no wasted words. It's front-loaded with the core purpose and includes the key feature (filtering). 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 (5 parameters with 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't explain parameter usage, behavioral aspects, or output format. For a list tool with multiple filtering options, this leaves too many gaps for the agent to use it effectively 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%, meaning none of the 5 parameters have descriptions in the schema. The description only vaguely mentions 'optional filtering' without explaining what parameters are available (e.g., 'after', 'createdAfter', 'limit', 'properties'), their purposes, or how to use them. This fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('meetings'), making the purpose understandable. It distinguishes this tool from other meeting tools like 'meetings_get' (single meeting) and 'meetings_search' (search with more complex criteria). However, it doesn't specify the scope (e.g., all meetings in what context - user's, workspace's) or mention pagination/ordering, which keeps it from being fully specific.
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 through 'optional filtering' but doesn't explicitly state when to use this tool versus alternatives like 'meetings_search' or 'meetings_get'. It provides some context (filtering available) but lacks clear guidance on use cases, exclusions, or prerequisites, leaving the agent to infer from sibling tool names.
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 what the tool does, not how it behaves. Missing: whether this is a read-only operation (implied by 'Get' but not explicit), authentication requirements, error handling, rate limits, or what happens with invalid IDs. No contradiction with annotations.
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 core purpose, zero wasted words. Every element ('Get', 'single contact by ID', 'specific properties and associations') earns its place by clarifying scope.
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 no annotations, 0% schema coverage, and no output schema, the description is inadequate. It doesn't explain return values, error conditions, or behavioral constraints. The agent lacks sufficient context to use this tool correctly beyond basic intent.
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' (mapping to contactId) and 'specific properties and associations' (hinting at the properties and associations parameters), adding some meaning. However, it doesn't explain parameter formats, optionality, or the enum values for associations.
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'), and specifies the scope ('with specific properties and associations'). It distinguishes from list/search siblings but doesn't explicitly name alternatives like 'crm_search_contacts' or 'crm_list_objects'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need a specific contact by ID with optional property/association filtering, but doesn't explicitly state when to use this vs. alternatives like 'crm_search_contacts' for broader queries or 'crm_list_objects' for bulk retrieval. No guidance on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it's a read operation (implied by 'Read'), supports pagination (via 'after' cursor and 'limit'), and allows property selection. However, it lacks details on permissions, rate limits, error handling, or response format, which are important for a tool with 3 parameters.
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 and front-loaded: the first sentence states the core purpose, and the second adds key details about parameters. It avoids unnecessary fluff, but could be slightly more structured by separating pagination and property control into distinct points.
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 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is moderately complete. It covers pagination and property selection but misses details like default behaviors, error cases, or example usage. For a list tool with no structured support, it should do more to compensate.
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 explains 'properties' (controls returned fields) and 'after' (paging cursor), adding meaning beyond the bare schema. However, it doesn't cover 'limit' (pagination size) or provide examples or constraints for parameters, leaving gaps in understanding.
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' specifies the verb (read) and resource (products), and 'Control what is returned via the `properties` query param' adds detail about customization. However, it doesn't explicitly differentiate from sibling tools like 'products_read' or 'products_search', which is why it's not 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. It mentions pagination and property control but doesn't compare to siblings like 'products_read' (for single product) or 'products_search' (for filtered queries), leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it's a partial update (not full replacement), errors occur for read-only/non-existent properties, and empty strings clear values. However, it lacks information about permissions, rate limits, or what happens on success/failure.
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 two sentences that each add value: the first states the core action, and the second provides critical behavioral details. It's front-loaded and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (mutation tool with nested objects, no annotations, no output schema), the description is moderately complete. It covers the update type and error conditions but lacks details about the response format, authentication needs, or how it fits with sibling tools.
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 'productId' identifies the object and 'properties' contains updatable fields, but doesn't explain the specific properties shown in the schema or their formats. The description adds some meaning but doesn't fully document the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('perform a partial update') and resource ('Object identified by ID'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'products_batch_update' or 'products_update' (if that exists elsewhere), 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 batch updates or other product-related tools. It mentions error conditions but doesn't help the agent choose between this and other update methods available 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.

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/shinzo-labs/hubspot-mcp/badges/card.svg)](https://glama.ai/mcp/servers/shinzo-labs/hubspot-mcp)

Score Badge

Copy to your README.md:

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

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