HubSpot MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose based on resource type (calls, communications, crm, emails, etc.) and action (create, get, list, update, archive, batch operations). The naming structure makes it easy to differentiate between tools, with no ambiguous overlaps in functionality.
Naming Consistency5/5
Tool names follow a highly consistent pattern throughout: resource_action (e.g., calls_create, crm_get_contact) or resource_batch_action (e.g., emails_batch_update). This verb_noun convention is applied uniformly across all 112 tools, with no deviations in style or structure.
Tool Count2/5
With 112 tools, the count is excessive for an MCP server, even for a comprehensive CRM like HubSpot. This volume will overwhelm agents, making tool selection and management cumbersome, and suggests over-fragmentation of operations that could be consolidated.
Completeness5/5
The tool set provides complete CRUD and lifecycle coverage across all major HubSpot domains (calls, communications, CRM objects, emails, engagements, meetings, notes, products, tasks). It includes individual and batch operations, search capabilities, and property management, leaving no obvious gaps for agent workflows.
Average 2.7/5 across 112 of 112 tools scored. Lowest: 1.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. However, it incorrectly states a create operation, which contradicts the implied read behavior from the tool name and schema (e.g., parameters like 'objectIds' and 'properties' suggest retrieval). This misrepresentation fails to inform about safety, permissions, rate limits, or output format, leaving the agent with unreliable information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it is under-specified and misleading rather than efficiently informative. It fails to front-load critical details about the tool's true purpose, wasting the limited space on incorrect information. While brief, it does not earn its place by adding value.
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, 0% schema coverage, no annotations, no output schema), the description is completely inadequate. It does not clarify the tool's purpose, usage, behavior, or parameters, and the contradiction with the tool name exacerbates the gap. For a batch operation in a CRM context, this leaves the agent without essential context to operate 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 no parameters are documented in the schema. The description does not compensate by explaining any parameters, such as 'objectType', 'objectIds', or 'properties', leaving all 5 parameters undocumented. This lack of semantic information hinders the agent's ability to use the tool correctly, especially with complex enums and arrays.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create multiple CRM objects in a single request' is misleading and contradicts the tool's name 'crm_batch_read_objects' and input schema. The name suggests a read operation, while the description claims a create operation. This creates confusion about the tool's actual purpose, making it tautological to the incorrect action rather than clarifying the intended functionality.
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. Given the sibling tools include both batch read (e.g., 'crm_batch_read_objects' should align with 'calls_batch_read', 'emails_batch_read') and batch create operations (e.g., 'crm_batch_create_objects'), the description fails to clarify its role, leading to potential misuse. It offers no context on prerequisites, constraints, or comparisons to other 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?
With no annotations provided, the description carries the full burden of behavioral disclosure but provides none. 'Search products' doesn't indicate whether this is a read-only operation, what permissions might be required, whether results are paginated, what the response format looks like, or any rate limits. For a search tool with 6 parameters and complex filtering capabilities, this is completely inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just two words, this is a case of harmful under-specification rather than effective brevity. The description doesn't contain enough information to be useful, so its conciseness is detrimental rather than beneficial. No structure exists beyond the minimal phrase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters including nested filtering objects), complete lack of annotations, 0% schema description coverage, and no output schema, the description is woefully incomplete. 'Search products' doesn't provide enough context for an AI agent to understand how to properly use this tool, what it returns, or how it differs from other product-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 6 parameters (including complex nested objects like filterGroups), the description 'Search products' provides zero information about any parameters. It doesn't mention query, limit, pagination via 'after', sorting options, property selection, or filtering capabilities. The description fails completely to compensate for the schema's lack of parameter 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 merely restates the tool name without adding any meaningful clarification. It doesn't specify what kind of search (full-text, filtered, etc.) or what resource scope (all products, specific categories). While it includes the verb 'search' and resource 'products', it provides no differentiation from sibling tools like 'products_list' or 'crm_search_objects'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. There's no mention of when this search tool should be used instead of 'products_list' or other search tools in the sibling list. No context about prerequisites, appropriate scenarios, or limitations is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but provides none. It doesn't mention whether this is a write operation requiring specific permissions, what happens on success/failure, whether properties are editable after creation, or any rate limits. For a creation tool with 11 parameters, this lack of behavioral context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single 4-word phrase. While this is efficient, it's arguably under-specified rather than appropriately concise. However, it's front-loaded with the core action and doesn't contain any redundant information.
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, 0% schema coverage, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what a company property is, what the parameters mean, what the tool returns, or any behavioral characteristics. 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 explain what 'name', 'label', 'type', 'fieldType', 'groupName' mean in this context, nor does it mention the 6 optional parameters. 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 company property' restates the tool name with minimal elaboration. While it specifies the verb 'create' and resource 'company property', it doesn't distinguish this from sibling tools like crm_create_contact_property or crm_create_lead_property, nor does it explain what a 'company property' actually is in this CRM context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites, appropriate contexts, or compare it to similar sibling tools like crm_create_contact_property or crm_create_lead_property. There's no indication of when this tool would be preferred over other property 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. It only states the action ('Create') without mentioning permissions, side effects, error handling, rate limits, or response format. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence with no wasted words. It is appropriately sized and front-loaded, though this conciseness comes at the cost of detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 annotations, no output schema), the description is completely inadequate. It doesn't explain what a call record is, how to structure inputs, what the tool returns, or any behavioral aspects, 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%, and the description provides no information about parameters. The input schema has 2 parameters (properties and associations) with complex nested structures, but the description doesn't explain their purpose, required fields, or usage. It 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 call record' states the basic action but is tautological with the tool name 'calls_create'. It doesn't differentiate from sibling tools like 'calls_batch_create' or specify what a 'call record' entails beyond the generic term. While it identifies the verb and resource, it lacks specificity about scope or distinguishing features.
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 'calls_batch_create' or other creation tools in the sibling list. The description offers no context, prerequisites, or exclusions, leaving the agent with 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 the full burden of behavioral disclosure but only states the action 'create' without detailing permissions, side effects, rate limits, or response format. It fails to inform the agent about the mutation's impact or any constraints, making it inadequate for a tool with complex nested 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 extremely concise with a single sentence 'Create a new note', which is front-loaded and wastes no words. However, this brevity comes at the cost of under-specification, but for conciseness alone, it scores highly.
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, and 0% schema coverage), the description is severely incomplete. It does not compensate for the lack of structured data, failing to explain parameters, behavior, or output, making it inadequate for 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?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The tool description adds no information about the 2 parameters (properties and associations) or their nested structures, leaving the agent with no semantic understanding beyond raw schema definitions.
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 note' restates the tool name 'notes_create' with minimal elaboration, making it tautological. It specifies the verb 'create' and resource 'note' but lacks detail about what a note entails or how it differs from other creation tools like 'calls_create' or 'tasks_create' in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 'notes_batch_create' or other engagement creation tools, 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.
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 to do so. It doesn't indicate whether this is a read-only operation, what permissions are required, if there are rate limits, or what the output looks like (especially critical since there's 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 extremely concise at just 4 words, with no wasted language. It's front-loaded with the core action, though this brevity comes at the cost of clarity and 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 with 0% schema coverage, no output schema, and no annotations), the description is completely inadequate. It doesn't explain the tool's behavior, parameter usage, or expected results, leaving the agent unable to effectively invoke it.
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 5 parameters are documented in the schema. The description mentions 'specific filters' but doesn't explain what filterGroups, properties, limit, after, or sorts mean, their formats, or how to use them, failing to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search notes with specific filters' restates the tool name 'notes_search' in slightly different words, making it tautological. It doesn't specify what kind of notes (e.g., CRM notes, meeting notes) or what resources are involved, nor does it distinguish this tool from sibling tools like 'notes_list' or 'notes_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 no guidance on when to use this tool versus alternatives like 'notes_list' or 'notes_get'. There's no mention of prerequisites, context, or exclusions, leaving the agent with 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Create a new task' implies a write/mutation operation, but the description doesn't mention required permissions, whether the operation is idempotent, what happens on failure, rate limits, or what the response contains. This is a significant gap for a creation tool with complex nested 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 with just three words. While severely under-specified, it contains zero wasted words and is front-loaded with the core action. Every word earns its place, even if the place is inadequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 parameters with nested objects, no annotations, no output schema, and 0% schema description coverage), the description is completely inadequate. It doesn't explain what the tool returns, how to structure the complex input, what system it operates in, or any behavioral characteristics. 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?
The description provides no information about parameters. With 0% schema description coverage and 2 parameters (one required), the agent has no guidance about what 'properties' and 'associations' mean, what fields are available, or how to structure the complex nested objects. 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 task' is essentially a tautology that restates the tool name 'tasks_create'. It specifies the verb ('Create') and resource ('task'), but doesn't differentiate from sibling tools like 'tasks_batch_create' or provide any additional context about what kind of task or in what system.
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 when to use 'tasks_create' versus 'tasks_batch_create', nor any prerequisites, constraints, or typical use cases. The agent must infer usage solely from the tool name.
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 mentions 'search' but doesn't describe whether this is read-only, has side effects, requires permissions, has rate limits, or what the output looks like. For a search tool with complex parameters and no annotations, this is a critical 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 5-word sentence. While this may be too brief for adequate tool understanding, it's perfectly structured with zero wasted words. Every word ('Search meetings with specific filters') contributes directly to the tool's 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 (5 parameters with nested objects, 0% schema coverage, no annotations, no output schema), the description is completely inadequate. A search tool with complex filtering, sorting, pagination, and property selection requires much more explanation about parameter usage, expected behavior, 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?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions 'specific filters' which hints at the 'filterGroups' parameter but doesn't explain any of the 5 parameters (filterGroups, properties, limit, after, sorts) or their purposes. It adds minimal value beyond the parameter names visible in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search meetings with specific filters' states a vague purpose - it mentions the verb 'search' and resource 'meetings' but lacks specificity about what kind of meetings or what search capabilities exist. It doesn't distinguish from sibling tools like 'meetings_list' or 'meetings_get', which likely serve different purposes. The description is better than a tautology but remains too generic.
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 sibling list includes 'meetings_list' and 'meetings_get', but the description doesn't explain when filtering/searching is needed versus simple listing or retrieval. There's no mention of prerequisites, context, or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions 'search' with filters, lacking details on permissions, rate limits, pagination, or response format. For a search tool with 5 parameters and no annotations, 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 with no wasted 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.
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, 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't explain parameter usage, behavioral traits, or output expectations, making it insufficient for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 undocumented in the schema. The description only vaguely mentions 'lead-specific filters', which doesn't explain the 5 parameters (filterGroups, properties, limit, after, sorts) or their semantics. It fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'search' and resource 'leads' with 'lead-specific filters', which clarifies the basic purpose. However, it doesn't distinguish this tool from sibling search tools like crm_search_companies or crm_search_contacts, missing specific differentiation. The purpose is clear but lacks sibling comparison 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. The description doesn't mention sibling tools like crm_search_companies or crm_search_contacts, nor does it specify prerequisites or exclusions. 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but provides almost none. It doesn't indicate whether this is a read-only operation, what permissions might be required, whether it's paginated (though limit/after parameters suggest it might be), what happens on errors, or what the output format looks like. 'Search' implies querying rather than mutation, but this isn't explicitly stated.
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?
Extremely concise at just 5 words, but this brevity comes at the cost of completeness. The single sentence is front-loaded with the core purpose, but lacks necessary elaboration. While efficient, it's arguably under-specified rather than appropriately concise for a tool with 5 parameters and complex filtering logic.
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 for filtering and sorting, 0% schema description coverage, no annotations, no output schema), the description is severely inadequate. It doesn't explain the search capabilities, result format, error conditions, or how to construct valid queries. For a search tool with this level of parameter complexity, much 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. The description mentions 'specific filters' which only hints at the filterGroups parameter, ignoring the other 4 parameters (properties, limit, after, sorts). It doesn't explain what properties can be filtered, what operators are available, or how to structure filter groups. The schema provides structure but no semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search calls with specific filters' clearly states the verb (search) and resource (calls), but it's vague about what 'specific filters' entails. It distinguishes from siblings like calls_list or calls_get by implying filtering capability, but doesn't specify how it differs from other search tools like emails_search or meetings_search 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 explicit guidance on when to use this tool versus alternatives. The description doesn't mention when to choose calls_search over calls_list (which might list all calls without filtering) or other search tools for different resources. There's no indication of prerequisites, performance considerations, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a creation operation but gives no information about permissions required, rate limits, whether the operation is idempotent, error handling for partial failures, or what the response contains. This is inadequate for a mutation tool with complex nested parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a tool name that already conveys the domain (CRM) and operation type (batch create).
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?
This is a complex mutation tool with no annotations, no output schema, and 0% schema description coverage for a deeply nested parameter structure. The description is completely inadequate - it doesn't explain what data leads require, how associations work, what happens on success/failure, or any behavioral constraints. The agent lacks critical information to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameters are documented in the schema. The description mentions 'multiple leads' but provides zero information about the required 'inputs' parameter structure, the nested properties object, or the associations array. 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 ('Create multiple leads') and resource ('leads'), making the purpose immediately understandable. However, it doesn't distinguish this batch operation from the single-lead creation sibling tool (crm_create_lead), which would be helpful for agent selection.
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 tool versus the single-lead creation tool (crm_create_lead), nor does it mention any prerequisites, constraints, or alternative batch tools for other CRM objects. 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 of behavioral disclosure. It states 'Create' which implies a write/mutation operation, but doesn't mention permissions required, whether the creation is irreversible, rate limits, or what happens on success/failure. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence, 'Create a new lead property', which is front-loaded and wastes no words. While it may be too brief for the tool's complexity, it earns full marks for conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, 5 required, no output schema, and no annotations), the description is incomplete. It doesn't explain the purpose beyond the basic action, lacks parameter guidance, and omits behavioral details needed for safe and effective use, making it inadequate for the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning none of the 11 parameters have descriptions in the schema. The tool description provides no information about any parameters, their purposes, or how they interact (e.g., that 'type' and 'fieldType' must be compatible, or that 'options' is required for enumeration types). 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 'Create a new lead property' clearly states the action (create) and resource (lead property), which is adequate. However, it doesn't differentiate from sibling tools like 'crm_create_company_property' or 'crm_create_contact_property' that create similar properties for different CRM entities, leaving the scope somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a lead first), when not to use it, or how it differs from other property-creation tools in the sibling list, such as 'crm_create_company_property' or 'crm_create_contact_property'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Get all properties' suggests a read-only operation, but it doesn't specify whether this requires authentication, has rate limits, returns paginated results, or what format the properties come in (e.g., key-value pairs, metadata objects). For a 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence that gets directly to the point without unnecessary words. It's appropriately sized for a simple-sounding tool, though it could be more informative. There's no structural issue like being front-loaded with irrelevant 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 has 2 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain what the parameters do, what the tool returns (e.g., a list of property objects, a dictionary), or any behavioral constraints. For a tool that likely interacts with a CRM system, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters (archived and properties) with 0% schema description coverage, meaning neither parameter has documentation in the schema. The description 'Get all properties for contacts' doesn't mention either parameter, failing to explain what 'archived' does (filter archived contacts?) or what 'properties' expects (specific property names to retrieve?). With low schema coverage, the description doesn't compensate at all for the undocumented parameters.
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 contacts' clearly states the verb ('Get') and resource ('properties for contacts'), making the purpose understandable. However, it's somewhat vague about scope ('all properties' could mean metadata or field values) and doesn't differentiate from sibling tools like crm_get_contact (which gets contact details) or crm_get_company_properties (which gets company properties).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use it instead of crm_get_contact (which might return basic contact info), crm_search_contacts (which might return filtered contacts), or other property-related tools like crm_get_company_properties. There's no context about prerequisites, limitations, or appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'search' which implies a read-only operation, but doesn't disclose behavioral traits like pagination (implied by 'after' parameter), rate limits, authentication needs, or what happens with no results. The description is too vague to provide meaningful context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a search tool, though it could be more informative while remaining concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters with nested structures, 0% schema coverage, no annotations, no output schema), the description is inadequate. It doesn't explain the search scope, result format, error conditions, or how parameters interact. For a search tool with rich filtering capabilities, 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 description must compensate but fails to do so. It mentions 'company-specific filters' which loosely relates to the filterGroups parameter but doesn't explain any of the 5 parameters (filterGroups, properties, limit, after, sorts) or their purposes. The description adds minimal value beyond what the schema structure implies.
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 purpose but lacks specificity. It doesn't distinguish this from sibling tools like crm_search_contacts or crm_search_leads, nor does it specify what 'company-specific filters' means beyond the generic term.
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 crm_search_contacts and crm_search_leads, the description doesn't indicate if this is for company entities specifically or how it differs from general search tools like crm_search_objects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states 'search' which implies a read-only operation, but doesn't confirm safety, permissions needed, rate limits, pagination behavior, or what happens on errors. For a search tool with 5 parameters and no output schema, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point without unnecessary words. It's appropriately sized for a search tool, though it could benefit from being more specific while maintaining 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 complexity (5 parameters with nested structures, 0% schema coverage, no output schema, no annotations), the description is inadequate. It doesn't explain what properties can be filtered/sorted, how pagination works, what 'contact-specific' means, or what the tool returns. For a search tool with rich filtering capabilities, this leaves too much undefined.
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 5 parameters are undocumented in the schema. The description only vaguely mentions 'contact-specific filters' which hints at 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 contacts with contact-specific filters' states the verb (search) and resource (contacts) but is vague about what 'contact-specific filters' means. It doesn't specify what distinguishes this from generic search tools or what makes filters 'contact-specific.' Compared to siblings like crm_search_companies and crm_search_leads, it's clear this searches contacts but lacks differentiation in filtering approach or scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, when not to use it, or compare it to similar tools like crm_search_objects or crm_get_contact. With many sibling tools available, the agent receives no help in selecting this specific search tool over others.
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 'optional filtering' which hints at some functionality, but doesn't describe important behaviors like pagination (implied by 'limit' and 'after' parameters), whether this is a read-only operation, what permissions might be required, or what the output format looks like. For a list tool with 5 parameters, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - just 6 words. It's front-loaded with the core purpose. While perhaps too brief for a tool with 5 parameters, every word earns its place and there's no redundant information. The structure is simple but effective for such a short 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?
Given the complexity (5 parameters, 0% schema coverage, no annotations, no output schema), the description is inadequate. It doesn't explain what the tool returns, how pagination works, what filtering options exist, or how this differs from emails_search. For a list operation with multiple filtering parameters, users need more 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?
With 0% schema description coverage and 5 parameters, the description 'with optional filtering' provides minimal semantic context. It hints that filtering exists but doesn't explain what parameters control filtering, what 'properties' and 'associations' mean, or how 'archived' affects results. The description adds very little value beyond what the bare parameter names in the schema already suggest.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all emails with optional filtering' clearly states the verb ('List') and resource ('emails'), but it's somewhat vague about scope ('all emails' could mean different things) and doesn't distinguish this from sibling tools like emails_search or emails_get. It provides basic purpose but lacks specificity about what constitutes 'all emails' in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like emails_search or emails_get. There's no mention of prerequisites, typical use cases, or comparison with sibling tools. The phrase 'with optional filtering' hints at some usage context but doesn't provide actionable guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'search' but doesn't disclose behavioral traits like whether this is a read-only operation, what permissions are needed, pagination behavior (implied by 'limit' and 'after' parameters but not explained), rate limits, or what happens when no results are found. The description is minimal and leaves critical behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a basic statement of purpose, though it could benefit from being more informative while maintaining 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 5 parameters with 0% schema description coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain the complex filtering system, return format, error conditions, or usage context. For a search tool with nested parameter structures and no structured documentation elsewhere, this description 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 description must compensate. It mentions 'specific filters' which hints at the 'filterGroups' parameter but doesn't explain the other 4 parameters ('properties', 'limit', 'after', 'sorts') or provide any semantic context about how filters work, what properties are available, or how to structure queries. The description adds minimal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 it's vague about scope and doesn't distinguish from sibling tools like 'emails_list' or 'emails_get'. It lacks specificity about what kind of search this is (e.g., full-text, filtered, advanced).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'emails_list' or 'emails_get'. The description mentions 'specific filters' but doesn't explain when filtered search is appropriate versus simpler listing operations. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Create a new meeting' implies a write/mutation operation, but it doesn't disclose behavioral traits like required permissions, whether it's idempotent, rate limits, or what happens on success/failure. The description is minimal and lacks essential 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 extremely concise with just three words, front-loaded with the core action. There's no wasted text, though this brevity contributes to other deficiencies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 parameters with nested objects, no output schema, and no annotations), the description is incomplete. It doesn't address the tool's behavior, parameter usage, or output expectations, 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 provides no parameter information. With 2 parameters (properties and associations) that have complex nested structures, the description fails to add any meaning beyond the schema. It doesn't explain what 'properties' or 'associations' represent, leaving significant gaps.
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 meeting' clearly states the verb ('Create') and resource ('meeting'), but it's generic and doesn't differentiate from sibling tools like 'meetings_batch_create' or 'calls_create'. It provides basic purpose but lacks specificity about what kind of meeting or system context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'meetings_batch_create' or other creation tools in the sibling list. There's no mention of prerequisites, constraints, or comparative 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 full burden but only states it's an update operation without disclosing behavioral traits. It doesn't mention whether this requires specific permissions, if changes are reversible, potential side effects, rate limits, or what the response looks like (no output schema). This is inadequate 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. However, it's under-specified rather than concise—it lacks necessary details for a mutation tool, so while structurally simple, it doesn't fully earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with nested parameters), lack of annotations, 0% schema coverage, and no output schema, the description is incomplete. It should explain updatable fields, behavioral implications, and usage context, but provides only a basic statement.
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 adds no meaning beyond implying 'meetingId' and 'properties' are needed, but doesn't explain what 'properties' contains (e.g., updatable fields like title, time, outcome) or their formats. It fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('meeting'), but it's vague about what specifically gets updated. It doesn't differentiate from sibling tools like 'meetings_batch_update' or 'meetings_create', leaving ambiguity about scope and granularity.
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 'meetings_batch_update' for multiple meetings or 'meetings_create' for new meetings. The description implies it's for existing meetings but doesn't specify prerequisites (e.g., needing a meetingId) or contextual constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'search' but doesn't disclose behavioral traits like whether this is read-only (likely, but not stated), pagination behavior (implied by 'limit' and 'after' parameters but not explained), rate limits, authentication needs, or what happens on empty results. The description adds minimal context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. However, it's under-specified rather than concise - it lacks necessary detail for a tool with 5 complex parameters. Front-loading is good but content is insufficient.
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, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the complex filtering system, pagination, sorting, or return format. The agent would struggle to use this tool correctly without additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'specific filters' which hints at the 'filterGroups' parameter, but doesn't explain any of the 5 parameters (filterGroups, properties, limit, after, sorts) or their semantics. 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 tasks with specific filters' states the verb ('search') and resource ('tasks'), but it's vague about scope and doesn't distinguish from sibling tools like 'tasks_list' or 'tasks_get'. It mentions 'specific filters' but doesn't clarify what makes this search different from other task retrieval methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'tasks_list' or 'tasks_get'. The description doesn't mention prerequisites, use cases, or exclusions. The agent must infer usage from the tool 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 the full burden of behavioral disclosure. It states 'Update an existing call record,' implying a mutation operation, but fails to mention permissions required, whether changes are reversible, or any rate limits. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it easy to parse. It is front-loaded and appropriately sized for its minimal content.
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 mutation tool with 2 parameters (including a nested object), 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It lacks details on behavior, parameters, and expected outcomes, failing to provide sufficient context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 does not explain the meaning of 'callId' or the nested 'properties' object, nor does it clarify the purpose of fields like 'hs_call_direction' or 'hs_call_status.' This adds little value beyond the schema's structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing call record' clearly states the verb ('Update') and resource ('call record'), distinguishing it from creation or deletion tools. However, it does not differentiate from sibling tools like 'calls_batch_update' or 'emails_update', which limits its 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 such as 'calls_batch_update' for multiple updates or 'calls_create' for new records. The description lacks context on 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. It states 'Create', implying a write/mutation operation, but fails to mention critical details like required permissions, whether the association is reversible, error handling, or side effects. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It is front-loaded and efficiently conveys the core action, making it highly concise and well-structured for its limited content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no annotations, no output schema, and 0% schema coverage), the description is incomplete. It lacks details on behavior, parameters, return values, and usage context, making it insufficient for an AI agent to effectively invoke 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?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It adds no meaning beyond the schema—not clarifying what 'fromObjectType' vs 'toObjectType' represent, the format of IDs, or the structure of 'associationTypes'. With 5 undocumented parameters, this is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Create' and resource 'association between two objects', which clarifies the basic purpose. However, it doesn't specify what types of objects can be associated (though the schema shows enums) or distinguish this from sibling tools like crm_batch_create_associations, making it vague 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 such as crm_batch_create_associations for bulk operations or crm_get_associations for reading. The description lacks context about prerequisites, constraints, or typical use cases, 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 full burden for behavioral disclosure. 'Create' implies a write operation, but the description doesn't mention whether this requires admin permissions, what happens on duplicate property names, whether changes are reversible, or what the response looks like. For a mutation tool with 11 parameters and no annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 4 words, with no wasted language. It's front-loaded with the essential action and resource, though this brevity comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex mutation tool with 11 parameters (5 required), no annotations, no output schema, and 0% schema description coverage, the description is completely inadequate. It provides only the most basic purpose statement without any guidance, behavioral context, or parameter explanation needed for effective tool 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 provides zero information about any of the 11 parameters. With 0% schema description coverage and no parameter explanation in the description, the agent has no semantic understanding of what 'name', 'label', 'type', 'fieldType', 'groupName', or other parameters actually mean or how they should be used.
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 contact property'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'crm_create_company_property' or 'crm_create_lead_property', but the resource specificity is adequate for basic understanding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like batch creation tools or other property creation tools. The description offers no context about prerequisites, permissions needed, or typical use cases for creating contact properties.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Create' implies a write/mutation operation, but the description doesn't disclose any behavioral traits: no information about permissions required, whether creation is reversible, rate limits, error conditions, or what happens on success. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just four words. It's front-loaded with the core action and resource. There's no wasted language or unnecessary elaboration. For a tool name that already includes 'crm_create_object', this brevity is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters with nested objects, no output schema, no annotations), the description is incomplete. It doesn't explain what happens after creation, what data should be provided in 'properties', how associations work, or what the different objectType values mean. For a generic creation tool that can handle multiple object types with complex parameter structures, this minimal description leaves too many questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions 'CRM object' but doesn't explain the three parameters (objectType, properties, associations) or their semantics. It doesn't clarify what 'properties' should contain, what 'associations' mean, or how to use the objectType enum. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a new CRM object' which clearly indicates the verb (create) and resource (CRM object). However, it doesn't specify what types of objects can be created or differentiate from sibling tools like crm_create_company, crm_create_contact, or crm_batch_create_objects. 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. With many sibling tools for creating specific object types (companies, contacts, leads) and batch operations, there's no indication whether this is a generic creation tool or how it relates to those specialized tools. No usage context 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. 'Search CRM objects using filters' implies a read operation but doesn't specify whether this is paginated, what authentication is required, rate limits, or what the response format looks like. It mentions 'filters' but doesn't explain the complex filter structure shown in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 5 words. It's front-loaded with the core action and doesn't waste words. For such a brief statement, every word earns its place by conveying 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 complex tool with 6 parameters (including nested objects), 0% schema description coverage, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what CRM objects are, how filtering works, what the response contains, or any behavioral aspects. The description fails to provide the necessary context for proper tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 6 parameters, the description 'Search CRM objects using filters' only hints at the 'filterGroups' parameter. It doesn't explain the meaning of 'objectType', 'properties', 'limit', 'after', or 'sorts', nor does it clarify the complex nested structure of filters. The description 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search CRM objects using filters' clearly states the verb (search) and resource (CRM objects), but it's vague about what 'CRM objects' specifically are. It doesn't distinguish 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?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling search tools (crm_search_companies, crm_search_contacts, crm_search_leads, crm_list_objects, crm_batch_read_objects), there's no indication of when this general search tool is preferred over the more specific ones or what differentiates them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is an update operation, implying mutation, but doesn't mention required permissions, whether changes are reversible, rate limits, or what the response looks like. For a mutation 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 extremely concise with a single sentence, 'Update an existing email record', which is front-loaded and wastes no words. While it may be under-specified, it earns full marks for brevity and clarity 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?
Given the complexity (mutation tool with nested objects, 2 parameters, no annotations, and no output schema), the description is incomplete. It doesn't cover parameter meanings, behavioral traits, or usage context, making it inadequate for an AI agent to reliably invoke this tool without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters with 0% description coverage, and the tool description provides no information about parameters. It doesn't explain what 'emailId' refers to, what 'properties' contains, or how to structure the update. Given the 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 '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 'crm_update_object', which could also update email-related data, leaving room for confusion about when to use this specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'emails_batch_update' or 'emails_create'. The description implies it's for updating existing records but doesn't specify prerequisites, constraints, or scenarios where this tool is preferred over others in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a list operation, implying read-only behavior, but doesn't disclose pagination behavior (implied by limit/offset parameters), rate limits, authentication requirements, or what 'engagements' entail. The description adds minimal behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 ('List all engagements') and adds necessary qualification ('with optional filtering'). 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 5 parameters with 0% schema coverage, no annotations, no output schema, and sibling tools, the description is incomplete. It doesn't explain what engagements are, how filtering works, pagination, return format, or differentiation from other engagement tools. For a list tool with multiple parameters, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'optional filtering' but doesn't explain what the 5 parameters (limit, offset, startTime, endTime, activityTypes) mean or how they relate to filtering. No parameter details are provided, leaving semantics undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all engagements with optional filtering' clearly states the verb ('List') and resource ('engagements'), but it's vague about what 'engagements' specifically are and doesn't distinguish from sibling tools like 'engagement_details_get' or 'engagement_details_get_associated'. It provides basic purpose but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'engagement_details_get' (for single engagement) or 'engagement_details_get_associated' (for related engagements). The description mentions 'optional filtering' but doesn't explain when filtering is appropriate or what the default behavior is.
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' implies a mutation operation, but the description doesn't mention permissions required, whether changes are reversible, rate limits, or what happens to unspecified fields. For a tool with 3 parameters and nested objects, 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 no wasted words. It's front-loaded and efficiently conveys the core action, making it easy to parse quickly. This is an example of effective 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 (3 parameters with nested objects, no annotations, no output schema, and 0% schema coverage), the description is incomplete. It doesn't explain the update behavior, parameter roles, or expected outcomes. For a mutation tool in a crowded sibling set, more context is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 3 parameters (engagementId, engagement, metadata) are documented in the schema. The description adds no information about what these parameters mean, their formats, or how they interact. 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 states the verb ('Update') and resource ('an existing engagement's details'), which provides a basic purpose. However, it's vague about what 'details' specifically means and doesn't distinguish this tool from sibling tools like 'engagement_details_create' or 'calls_update', which also handle engagement-related updates. 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?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools like 'engagement_details_create', 'engagement_details_archive', and various batch/type-specific update tools (e.g., 'calls_update', 'tasks_update'), the description offers no context on prerequisites, distinctions, or exclusions. This leaves 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 creation but doesn't specify if this is a write operation requiring permissions, whether it's idempotent, what happens on partial failures, or typical response formats. This leaves critical behavioral traits undocumented 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, 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 parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch creation tool with no annotations, 0% schema description coverage, and no output schema, the description is insufficient. It lacks details on parameters, behavioral traits (e.g., error handling, permissions), and doesn't reference sibling tools for context, making it incomplete 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 descriptions. The description adds no information about the 'inputs' parameter, such as what it contains (e.g., meeting properties, associations), required fields, or format examples. 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 states the action ('Create multiple meetings') and scope ('in a single request'), which is clear but basic. It doesn't distinguish this tool from sibling tools like 'meetings_create' (single meeting creation) or 'meetings_batch_update' (batch updates), 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?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention using 'meetings_create' for single meetings, 'meetings_batch_update' for batch updates, or prerequisites like authentication or rate limits. The description only states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers nothing beyond the basic action. It doesn't mention whether this is a safe operation, what permissions are required, whether it's idempotent, what happens on partial failures, rate limits, or what the response contains. This is inadequate 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 batch creation tool with no annotations, 0% schema description coverage, and no output schema, the description is severely incomplete. It doesn't address behavioral aspects, parameter meanings, error handling, or expected outcomes, leaving critical gaps 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description provides no information about the 'inputs' parameter or its nested structure. While the schema shows 'inputs' is an array of objects with 'properties' containing product fields, the description doesn't explain what constitutes valid product data, required fields, or format expectations.
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 ('batch of products'), making the purpose immediately understandable. It distinguishes from sibling 'products_create' by specifying batch operations, though it doesn't explicitly contrast with other batch operations like 'products_batch_update' or 'products_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 'products_create' (single product creation) or other batch operations. There's no mention of prerequisites, constraints, or typical use cases for batch creation versus individual creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a read operation, which implies non-destructive, but doesn't disclose behavioral traits like authentication needs, rate limits, error handling, or what 'Object' entails (e.g., product data). This leaves significant gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and appropriately sized for the tool's apparent simplicity, earning its place 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 3 parameters with 0% schema coverage, no annotations, no output schema, and a vague description, this is incomplete. The tool likely reads product data, but the description doesn't clarify scope, return values, or usage 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%, so the description must compensate. It only mentions 'ID', which maps to 'productId', but doesn't explain 'properties' or 'associations' parameters. This adds minimal value beyond the schema, failing to address the coverage gap adequately.
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 'Read an Object identified by ID' clearly states the verb ('Read') and resource ('Object'), but it's vague about what type of object (product vs. generic) and doesn't distinguish from sibling tools like 'products_get' or 'crm_get_object'. 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?
No guidance is provided on when to use this tool versus alternatives like 'products_list', 'products_batch_read', or other read operations in the sibling list. The description implies usage for reading by ID but doesn't specify context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it 'gets details' without disclosing behavioral traits like read-only nature, error handling, authentication needs, or rate limits. It's minimal and doesn't compensate for the lack of 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, front-loaded sentence with zero waste. It's appropriately sized for its limited content, though this conciseness comes at the cost of detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain what details are returned, how parameters work, or behavioral context, making it inadequate 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 what taskId, properties, or associations mean, their formats, or how they affect the output, leaving all three parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific task' clearly states the verb ('Get') and resource ('task'), but it's vague about what 'details' entail and doesn't distinguish from sibling tools like tasks_list or tasks_search. It avoids 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 tasks_list or tasks_search. The description implies it's for retrieving details of a single task, but there's no explicit mention of prerequisites, exclusions, or comparison 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 but offers minimal behavioral information. It doesn't disclose whether this is a read-only operation, what permissions might be required, if there are rate limits, pagination behavior, or what the response format looks like. The mention of 'optional filtering' hints at some functionality 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 6 words, with no wasted language. It's front-loaded with the core purpose and includes the key feature of filtering. Every word earns its place in this minimal description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the filtering options, return format, or behavioral characteristics needed for proper tool selection and invocation. The agent would struggle to use this tool effectively based on the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 5 parameters, the description doesn't compensate at all. It mentions 'optional filtering' but doesn't explain what parameters are available for filtering (limit, after, properties, associations, archived) or their purposes. The agent would have no semantic understanding of these parameters from the description alone.
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 tasks with optional filtering' clearly states the verb ('List') and resource ('tasks'), but it's vague about scope and doesn't distinguish from sibling tools like 'tasks_search' or 'tasks_get'. It specifies 'all tasks' but doesn't clarify if this includes archived tasks or other statuses.
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_search' or 'tasks_get'. The description mentions 'optional filtering' but doesn't explain what types of filtering are available or when filtering might be preferred over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
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 describe what happens on success/failure, whether it's idempotent, what permissions are required, or how conflicts are handled. 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 just three words, with zero wasted text. It's front-loaded with the core action. While this brevity contributes to under-specification in other dimensions, from a pure conciseness perspective, it's optimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (mutation tool with nested parameters, no annotations, no output schema, and 0% schema coverage), the description is incomplete. It doesn't explain the update behavior, parameter usage, return values, or error handling. For a tool that modifies data with multiple configuration options, this minimal description leaves critical 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%, meaning none of the parameters have descriptions in the schema. The tool description doesn't mention any parameters at all, failing to compensate for the schema gap. With 2 required parameters (taskId and properties) and nested objects with multiple fields, the description provides no semantic information about what these parameters mean or how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing task' clearly states the verb (update) and resource (task), but it's vague about what specifically gets updated. It doesn't distinguish this tool from sibling tools like 'tasks_batch_update' or 'tasks_update' (if there were multiple task update tools), though the sibling list shows only one 'tasks_update' tool. The purpose is understandable but lacks specificity about scope or fields.
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 sibling list includes 'tasks_batch_update' and 'tasks_create', but the description doesn't mention when to prefer single-task update over batch operations or when to update versus create. There's no context about prerequisites, error conditions, 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 full burden. It discloses the destructive nature ('archive (delete)') which is critical, but lacks other behavioral traits: no mention of permissions required, whether deletions are reversible, rate limits for batch operations, response format, or error behavior when some associations fail. The parentheses around 'delete' suggest archiving might be soft deletion, but this is ambiguous.
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. No wasted words, though it could benefit from slightly more detail given the parameter complexity. The parentheses around 'delete' add useful clarification without verbosity.
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 3 complex parameters (including nested objects and enums), no annotations, and no output schema, the description is insufficient. It covers the basic action but misses critical context: parameter meanings, behavioral constraints, error handling, and output expectations. The agent would struggle to use this correctly without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but provides no parameter information. It doesn't explain what 'fromObjectType' and 'toObjectType' represent (the object types being associated), what values the enums accept, or the structure of 'inputs' array (containing from/to objects with IDs). For a tool with 3 required parameters including complex nested objects, this is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('archive (delete)') and resource ('multiple associations') with the scope 'in a single request'. It distinguishes from sibling 'crm_archive_association' by specifying batch operation, but doesn't explicitly differentiate from 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' (single) or 'crm_batch_archive_objects' (different resource type). The description implies batch processing but doesn't specify prerequisites, error handling, or performance considerations for batch operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it's a creation operation but doesn't mention permissions required, whether it's idempotent, rate limits, error handling for partial failures, or what happens if associations already exist. 'Create' implies mutation, but no safety or side-effect details are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action ('Create multiple associations') and adds clarifying context ('in a single request'). 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 3 undocumented parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what associations are, how inputs should be structured, what object types are valid, or what the tool returns. The context signals indicate high complexity that the description doesn't address.
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 no parameters are documented in the schema. The description provides no information about the three parameters (fromObjectType, toObjectType, inputs), their meanings, or how they structure the batch creation. This leaves the agent guessing about required input format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('create') and resource ('multiple associations'), making the purpose understandable. It distinguishes from single-association creation tools like 'crm_create_association' by specifying 'multiple' and 'in a single request', 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?
No guidance is provided on when to use this tool versus alternatives like 'crm_create_association' or other batch tools. The description implies batch usage but doesn't specify thresholds, prerequisites, or exclusions for when batch creation is preferred over individual creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it's a creation operation, implying mutation, but doesn't mention critical behaviors: whether it's idempotent, what happens on partial failures, rate limits, authentication requirements, or response format. For a batch mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it directly states the tool's core function. It's appropriately sized for a simple declarative statement, though its 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 (batch mutation with nested parameters), lack of annotations, 0% schema description coverage, and no output schema, the description is severely incomplete. It doesn't address parameter semantics, behavioral traits, error handling, or output expectations. For a tool with this level of complexity and no structured support, the description fails to provide adequate context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameters are documented in the schema. The description adds no information about the 'inputs' parameter—it doesn't explain the structure, required fields, constraints, or examples. For a complex nested parameter with multiple properties and associations, this leaves the agent with no semantic guidance beyond raw JSON 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 ('Create multiple contacts') and resource ('contacts'), specifying it's a batch operation ('in a single request'). It distinguishes from individual creation tools like 'crm_create_contact' by emphasizing batch capability. However, it doesn't explicitly differentiate from other batch tools like 'crm_batch_create_companies' or 'crm_batch_create_leads' 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., required permissions), when batch creation is preferred over individual creation, or how it differs from other batch tools like 'crm_batch_create_objects'. 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, the description carries full burden but only states it's a batch update. It doesn't disclose critical behavioral traits such as permissions required, whether updates are partial or full, error handling for invalid inputs, rate limits, or response format. 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 zero waste. It's appropriately sized and front-loaded, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a batch update tool with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It lacks details on usage, behavior, parameters, and expected outcomes, making it insufficient for an agent to invoke the tool correctly without guesswork.
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 doesn't add meaningful parameter details beyond implying an array of inputs. It doesn't explain the structure of 'inputs', the required 'id' and 'properties', or the nested property fields. The baseline is 3 due to high schema detail, but the description fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update multiple contacts in a single request' clearly states the action (update) and resource (contacts), but it's vague about scope and doesn't distinguish from siblings like crm_batch_update_companies or crm_update_contact. It lacks specificity about what 'update' entails beyond the basic 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 guidance is provided on when to use this tool versus alternatives like crm_batch_update_objects or crm_update_contact. The description implies batch operations but doesn't specify prerequisites, limitations, or comparative contexts with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Create a new engagement' which implies a write/mutation operation, but it doesn't disclose behavioral traits like required permissions, whether it's idempotent, what happens on failure, rate limits, or what the response looks like. For a creation tool with complex nested parameters, this lack of behavioral context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just one sentence ('Create a new engagement with details'). It's front-loaded with the core action and wastes no words, though this brevity contributes to underspecification in other dimensions. Every word earns its place in this minimal statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters with nested objects, no annotations, no output schema), the description is incomplete. It doesn't explain the engagement types (EMAIL, CALL, etc. from schema), the purpose of associations/metadata, what 'details' refers to, or what the tool returns. For a creation tool with rich input structure, 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.
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 adds minimal value with 'with details', hinting at additional parameters beyond basic creation, but it doesn't explain what the three parameters (engagement, associations, metadata) mean or how they relate. This partially compensates but leaves most semantics undocumented, meeting the baseline for moderate schema coverage gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new engagement with details' states the basic action (create) and resource (engagement), but it's vague about what 'engagement' means and what 'details' encompass. It doesn't distinguish this tool from sibling tools like 'calls_create', 'emails_create', or 'engagement_details_update', leaving ambiguity about when to use this specific creation tool versus others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling creation tools (e.g., calls_create, emails_create, notes_create), the description offers no context about whether this is a generic engagement creator or specific to certain types, nor does it mention prerequisites or exclusions. This leaves the agent guessing about appropriate 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 full burden but only states it's a 'Get' operation. It doesn't disclose behavioral traits such as whether it's read-only, potential rate limits, authentication needs, or what 'engagements' entail (e.g., types, format). This leaves significant gaps for a tool with 7 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 front-loaded and clear, though slightly under-specified 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 tool with 7 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'engagements' are, how results are returned, or provide enough context for effective use, leaving too many unknowns.
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 details. It mentions 'object' vaguely, but doesn't explain parameters like 'objectType', 'objectId', 'activityTypes', or filtering options. This fails to address the undocumented parameters adequately.
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 ('engagements associated with an object'), making the purpose understandable. It doesn't distinguish from sibling tools like 'engagement_details_get' or 'engagement_details_list', but it's not vague or tautological.
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 'engagement_details_get' or 'engagement_details_list'. The description implies usage for retrieving engagements linked to specific objects, but lacks explicit context, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it's a creation operation. It doesn't disclose behavioral traits like whether it's idempotent, atomic, or transactional; what happens on partial failures; authentication requirements; or rate limits. For a batch mutation 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?
The description is extremely concise at just one sentence with no wasted words. It's front-loaded with the core purpose and efficiently communicates the batch nature. 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, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain the parameter structure, expected response format, error handling, or important behavioral constraints. The conciseness comes at the cost of necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero information about parameters. With 0% schema description coverage and a complex nested parameter structure (inputs array with properties and associations objects), the description fails to add any meaning beyond what the bare schema provides. This leaves critical parameter semantics undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('multiple tasks') with the specific context of batch processing ('in a single request'). It distinguishes from the singular 'tasks_create' sibling tool by emphasizing batch capability, though it doesn't explicitly name that sibling.
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 tool versus the singular 'tasks_create' tool, nor does it mention prerequisites, rate limits, or error handling for batch operations. It simply states what the tool does without contextual 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a creation operation but doesn't mention permissions required, whether it's idempotent, rate limits, error handling for partial failures, or what happens on success. For a batch write 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 appropriately sized for what it conveys and front-loads the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch creation tool with complex nested parameters (1 parameter with deep structure), 0% schema description coverage, no annotations, and no output schema, the description is woefully incomplete. It doesn't address the tool's behavior, parameter expectations, or result format, leaving critical gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'inputs' should contain, the structure of call records, required fields, or the association mechanism. The complex nested schema (with properties like hs_call_body, associations, etc.) is completely undocumented in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create multiple call records') and resource ('call records'), and specifies the batch nature ('in a single request'). However, it doesn't explicitly differentiate from sibling 'calls_create' which creates single records, though this distinction is implied by 'multiple' vs single.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'calls_create' for single records or other batch operations. It lacks context about prerequisites, limitations, or typical use cases for batch creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a read operation (non-destructive) but lacks details on permissions, rate limits, error handling, or response format. For a batch tool with complex inputs, this is insufficient 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 core purpose, zero waste. It's appropriately sized for a basic description, though more detail would be 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 no annotations, 0% schema coverage, no output schema, and a complex nested input schema, the description is incomplete. It doesn't address parameter meanings, behavioral traits, or output expectations, leaving significant gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'multiple call records' but doesn't explain the 'inputs' parameter structure, nested fields (id, properties, associations), or their purposes. This leaves 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 'Read multiple call records in a single request' clearly states the action (read) and resource (call records), with the 'multiple...in a single request' specifying batch capability. It distinguishes from non-batch siblings like calls_get (single) and calls_list (list all), though not explicitly named.
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_get (for single records) or calls_list (for listing all). The description implies batch reading but doesn't specify scenarios (e.g., efficiency for many IDs) or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'update' which implies mutation, but doesn't disclose behavioral traits like whether it's idempotent, what permissions are required, if there are rate limits, how errors are handled in batch operations, or what the response format looks like. 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 zero wasted words. It's front-loaded with the core action and resource, making it immediately understandable. 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 mutation tool with 1 parameter (a complex nested array), 0% schema description coverage, no annotations, and no output schema, the description is insufficient. It doesn't explain the parameter structure, behavioral implications, error handling, or response format. The agent would struggle to use this tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. The description mentions 'multiple call records' which hints at the 'inputs' array parameter, but doesn't explain the structure of individual records (id + properties), the required fields, or the meaning of properties like 'hs_call_direction' or 'hs_call_status'. 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.
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 call records') with the operational context ('in a single request'). It distinguishes from the singular 'calls_update' tool by specifying batch operations, though it doesn't explicitly contrast with other batch tools like 'calls_batch_create' or 'calls_batch_read'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites like authentication, compare it to the singular 'calls_update' for single-record updates, or explain when batch updates are preferable over individual updates. The description only states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Get details' suggests a read-only operation, but it doesn't specify authentication requirements, rate limits, error conditions, or what format/details are returned. For a tool with 3 parameters and no output schema, this is insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with zero 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 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what details are returned, how parameters affect the response, or provide any context about the call data structure. The agent would struggle to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for all 3 parameters, the description provides no information about what 'callId', 'properties', or 'associations' mean or how to use them. The description mentions 'details' but doesn't connect this to the parameters, leaving their purpose completely 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 'Get details of a specific call' clearly states the verb ('Get') and resource ('a specific call'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'calls_list' or 'calls_search' beyond specifying 'specific' versus general listing/searching.
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' or 'calls_search'. It mentions 'specific call' which implies you need a call ID, but doesn't explicitly state this prerequisite or contrast with other call-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a list operation but doesn't mention whether it's read-only, pagination behavior (implied by 'limit' and 'after' parameters but not explained), rate limits, authentication requirements, or what happens with archived calls. The description is minimal and lacks important behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 6 words with zero waste. It's front-loaded with the core purpose and could not be more efficient in its current form, though this conciseness comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter tool with no annotations, 0% schema description coverage, and no output schema, the description is inadequate. It doesn't explain the filtering capabilities, return format, pagination, or how parameters interact. Given the complexity and lack of structured documentation, the description should provide much more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but fails to do so. It mentions 'optional filtering' but doesn't explain what the 5 parameters do, their relationships, or filtering capabilities. The description adds almost no value beyond what's inferred from parameter names 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 the scope ('all') with optional filtering. It distinguishes from siblings like calls_get (single call) and calls_search (likely more advanced search), but doesn't explicitly differentiate from calls_batch_read or other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 other list tools in the sibling set. It mentions 'optional filtering' but doesn't explain what filtering capabilities exist or when to choose this over more specific search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for 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 two parameters and no output schema, 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 tool and front-loads 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 two parameters, no annotations, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't explain what 'communication preferences' include, how results are structured, or provide enough context 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?
The schema has 0% description coverage, so the description must compensate but fails to do so. It mentions 'contact' which maps to 'contactId', but doesn't explain what 'subscriptionId' is or when it's required. With two parameters and no schema descriptions, this creates ambiguity about parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('communication preferences for a contact'), making it immediately understandable. However, it doesn't distinguish this tool from its sibling 'communications_get_subscription_status' or 'communications_get_subscription_definitions', which could cause confusion about when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'communications_get_subscription_status' or 'communications_update_preferences'. It mentions neither prerequisites nor exclusions, leaving the agent to infer usage context 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 full burden but only states what the tool does without behavioral details. It doesn't disclose whether this is a read-only operation, potential rate limits, authentication needs, or what the output looks like, which is insufficient for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's 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 no annotations, 0% schema coverage, and no output schema, the description is incomplete. It lacks details on parameters, behavior, output format, and usage context, which are essential for a tool with two required parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'subscriptionId' or 'contactIds' represent, their formats, or constraints, leaving both parameters 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 ('Get subscription status') and target ('for multiple contacts'), which is specific and informative. However, it doesn't explicitly differentiate from sibling tools like 'communications_get_preferences' or 'communications_get_subscription_definitions', 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. The description doesn't mention prerequisites, context, or exclusions, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool performs a subscription action but doesn't disclose whether this requires specific permissions, if it's idempotent, what happens on success/failure, or any rate limits. 'Subscribe' implies a write operation, but no safety or side effect information is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a tool with a straightforward 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 3 parameters (including complex enum-based legal basis parameters), 0% schema description coverage, and no output schema, the description is inadequate. It doesn't explain the subscription mechanism, what 'all email communications' entails, or provide any context about the operation's behavior or expected outcomes.
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's already in the bare schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Subscribe') and target ('a contact to all email communications'), providing specific verb+resource. However, it doesn't differentiate from sibling tools like 'communications_update_preferences' or 'communications_update_subscription_status' which might have overlapping 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 about when to use this tool versus alternatives like 'communications_update_preferences' or 'communications_unsubscribe_contact'. The description doesn't mention prerequisites, constraints, or typical use cases for subscribing contacts to communications.
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 operation, but doesn't mention required permissions, whether changes are reversible, potential side effects, or rate limits. This leaves significant gaps for a tool that modifies 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, efficient sentence with no wasted words. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters (including a nested object), 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the parameters, behavioral aspects, or what the tool returns, leaving the agent with insufficient information to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 3 parameters (contactId, subscriptionId, preferences) are documented in the schema. The description adds no information about what these parameters mean, their formats, or how they interact, failing 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 'Update' and the resource 'communication preferences for a contact', making the purpose understandable. However, it doesn't differentiate from sibling tools like 'communications_update_subscription_status' or 'communications_subscribe_contact', which appear to handle similar communication preference operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'communications_update_subscription_status' or 'communications_subscribe_contact'. The description lacks context about prerequisites, use cases, 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Update' implies a mutation operation, the description doesn't address important behavioral aspects: whether this requires specific permissions, if changes are reversible, what happens on partial failures, or what the response format looks like. The description is too minimal for a batch mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence with no wasted words. It's front-loaded with the core purpose and uses efficient language. While potentially too brief for a complex tool, it earns full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch mutation tool with 2 parameters (one complex), 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the tool's behavior, parameters, or expected outcomes. The minimal description 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?
With 0% schema description coverage and 2 parameters (one being a complex array), the description provides no parameter information beyond what's implied by the tool name. It doesn't explain what 'subscriptionId' refers to, the structure of 'updates', or the meaning of the enum values in the nested objects. 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 ('Update') and target ('subscription status for multiple contacts'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'communications_subscribe_contact' or 'communications_unsubscribe_contact', which appear to handle individual contact subscriptions.
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 batch updates are appropriate versus individual operations, or how this differs from sibling tools like 'communications_subscribe_contact' and 'communications_unsubscribe_contact'.
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 operation, it doesn't clarify whether this is reversible, what permissions are required, or what happens to the association data. The parenthetical '(delete)' adds some context but doesn't fully address behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that gets straight to the point with no wasted words. The parenthetical '(delete)' efficiently clarifies the meaning of 'Archive' without adding unnecessary length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with 4 undocumented parameters and no output schema, the description is inadequate. It doesn't explain what happens after archiving, what the parameters represent, or provide any context about the association being targeted. The lack of annotations exacerbates these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for all 4 parameters, the description provides no information about what the parameters mean or how they should be used. The description doesn't mention any parameters at all, 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.
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 association between two objects'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'crm_batch_archive_associations' or 'crm_archive_object', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like batch operations or other archive tools. With many sibling tools available, this lack of context leaves the agent guessing about appropriate 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 full burden for behavioral disclosure. It mentions 'archive (delete)' which implies a destructive operation, but doesn't clarify if this is reversible, what permissions are required, or how errors are handled for partial failures in batch processing. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that efficiently conveys the core functionality. There's no wasted language or unnecessary elaboration, making it front-loaded 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 destructive batch operation with no annotations and no output schema, the description is inadequate. It doesn't address critical context like error handling, batch size limits, confirmation requirements, or what happens when some objects in the batch can't be archived. The tool's complexity warrants more comprehensive documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'objectType' enum values represent or what format 'objectIds' should follow. The description fails to provide any semantic context beyond what the bare schema shows.
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 target ('multiple CRM objects'), making the purpose evident. However, it doesn't distinguish this batch operation from its single-object sibling 'crm_archive_object', which is a missed opportunity for sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'crm_archive_object' for single deletions or other batch operations. The description merely states what it does without context about appropriate use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a creation operation but doesn't mention permissions required, whether it's idempotent, 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 name and straightforward purpose. Every word earns its place by specifying the batch nature of the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch creation tool with 2 parameters (one complex array), 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain parameter usage, behavioral traits, error handling, or return values. The description should provide more context about the tool's operation and limitations given the complexity of batch object creation.
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 CRM objects' which hints at the 'inputs' array parameter, but doesn't explain the 'objectType' parameter or its enum values. It provides no details about the structure of objects in the 'inputs' array or the 'associations' field. The description adds minimal value beyond what's implied by the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create multiple') and resource ('CRM objects'), and specifies the scope ('in a single request'). It distinguishes from single-object creation tools like crm_create_object, but 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when batch creation is preferred over individual creation, or when to use this general batch tool versus specific batch tools like crm_batch_create_companies. No prerequisites, limitations, or comparison with sibling tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Update' implies a mutation, the description lacks critical details: it doesn't specify if this requires special permissions, whether updates are atomic or partial, what happens on errors (e.g., partial failures), rate limits, or response format. For a batch mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse. Every word contributes to the purpose without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a batch update tool with 1 parameter (but deeply nested structure), no annotations, and no output schema, the description is incomplete. It lacks guidance on usage, error handling, permissions, and response expectations. While concise, it fails to provide the necessary context for safe and effective tool invocation in a CRM system.
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 companies' but doesn't explain the 'inputs' array structure, the required 'id' and 'properties' fields, or the meaning of nested properties like 'lifecyclestage'. It adds minimal value beyond the schema, leaving key semantics unclear (e.g., what 'properties' encompasses, format expectations).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update multiple companies') and resource ('companies') with the batch operation context ('in a single request'). It distinguishes from individual update tools like 'crm_update_company' by specifying the batch nature, though it doesn't explicitly differentiate from other batch update tools like 'crm_batch_update_contacts' or 'crm_batch_update_objects' beyond the company focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., company IDs required), compare it to single-company updates ('crm_update_company') or other batch updates (e.g., 'crm_batch_update_contacts'), or specify use cases like bulk data corrections. The agent must infer usage from the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Create' implies a write/mutation operation, but it doesn't disclose behavioral traits like required permissions, whether the operation is idempotent, rate limits, or what happens on validation failure. 'Validated properties' hints at input validation but lacks specifics on validation rules or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized and front-loaded with the core action, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 parameters with nested objects, 0% schema coverage, no annotations, no output schema), the description is inadequate. It doesn't explain the input structure, expected output, error conditions, or behavioral context needed for a creation tool in a CRM system.
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 loosely relates to the 'properties' parameter but doesn't explain what properties are available, their semantics, or the 'associations' parameter at all. This leaves most parameter meaning undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and resource 'company', making the purpose evident. It adds 'with validated properties' which hints at data validation, but doesn't explicitly differentiate from sibling tools like crm_create_contact or crm_create_lead, which perform similar creation operations for different entity types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, when not to use it, or compare it to sibling tools like crm_batch_create_companies for bulk operations or crm_create_object for generic creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only mentions 'validated properties' without explaining what validation entails, error handling, or mutation effects. It doesn't disclose permissions needed, rate limits, or response format, leaving significant behavioral gaps for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 2 parameters (including nested objects), no annotations, and no output schema, the description is inadequate. It doesn't explain the creation process, validation rules, or what happens upon success/failure, leaving too much undefined 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 only vaguely mentions 'validated properties' without detailing the two parameters (properties and associations). It fails to explain the structure, required fields, or meaning of parameters, offering minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and resource 'contact', specifying it's a new contact creation with validated properties. It distinguishes from sibling tools like crm_update_contact or crm_batch_create_contacts by focusing on single contact creation, though it doesn't explicitly mention 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 on when to use this tool versus alternatives like crm_batch_create_contacts or crm_create_lead. The description lacks context about prerequisites, such as required permissions or system states, and doesn't specify when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 hints at validation but doesn't specify what happens on validation failure, required permissions, rate limits, or whether the operation is idempotent. For a creation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized and front-loaded, clearly stating the core 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?
Given the complexity (2 parameters with nested objects, 0% schema coverage, no output schema, no annotations), the description is inadequate. It doesn't explain return values, error conditions, or the full scope of parameters, leaving the agent poorly equipped 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 but fails to do so. It mentions 'validated properties' but doesn't explain what properties are available, their formats, or the 'associations' parameter. With 2 parameters (one required) and complex nested structures, the description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('a new lead'), making the purpose understandable. However, it doesn't distinguish this from sibling tools like 'crm_batch_create_leads' or 'crm_create_contact', missing specific differentiation that would warrant 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 batch creation tools or other CRM creation tools. It mentions 'validated properties' but doesn't explain what validation entails or when it might fail, offering minimal usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a 'Get' operation (implying read-only), but doesn't mention authentication requirements, rate limits, pagination behavior (despite 'after' and 'limit' parameters), error conditions, or what 'associations' actually contain. The description is minimal and leaves critical behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose ('Get all associations') and appropriately sized for what it attempts to convey, though it's arguably too brief 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 tool with 5 parameters (including enums), no annotations, and no output schema, the description is insufficiently complete. It doesn't explain the association model, return format, pagination approach, or error handling. The agent would struggle to use this tool effectively without additional context beyond the bare 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 but provides no parameter information. It doesn't explain what 'fromObjectType' and 'toObjectType' represent, what 'associations' consist of, how 'after' works for pagination, or the meaning of 'limit' constraints. With 5 parameters (3 required) and zero schema descriptions, this represents a significant documentation gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('all associations of a specific type between objects'), making the purpose understandable. It doesn't explicitly differentiate from sibling tools like 'crm_list_association_types' or 'crm_get_object', but the specificity of 'associations between objects' provides reasonable 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 'crm_list_association_types' (which lists types rather than instances) or 'crm_get_object' (which retrieves single objects). There's no mention of prerequisites, typical use cases, or comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. 'Get all properties' implies a read-only operation, but doesn't specify whether this returns metadata about properties versus actual property values, whether it's paginated, requires authentication, has rate limits, or what format the output takes. For a tool with 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 extremely concise at just 5 words, with zero wasted language. It's front-loaded with the core purpose and contains no unnecessary elaboration. While it may be too brief for completeness, 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?
Given the tool has no annotations, no output schema, and 0% schema description coverage for its 2 parameters, the description is inadequate. It doesn't explain what 'properties' means in this context (property definitions? property values?), doesn't clarify the relationship between archived filtering and properties array, and provides no behavioral context. For a tool with this level of structured data gaps, the description should do much more heavy lifting.
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 both parameters (archived and properties), and the tool description provides no parameter information whatsoever. The description doesn't explain what 'archived' filters, what 'properties' array should contain, or whether parameters are optional. With low schema coverage and no compensation in the description, this creates significant ambiguity for parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all properties for companies' clearly states the verb ('Get') and resource ('properties for companies'), making the purpose immediately understandable. It distinguishes from other CRM tools that focus on specific companies or other entity types, though it doesn't explicitly differentiate from sibling tools like crm_get_contact_properties or crm_get_lead_properties.
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 whether this retrieves all company properties globally versus for specific companies, or how it differs from other property-related tools like crm_get_company (which might include properties) or crm_create_company_property. 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 full burden but only states it's a read operation ('Get'). It doesn't disclose behavioral traits such as error handling, permissions required, rate limits, or what happens if properties/associations are omitted. Minimal value added 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?
Single sentence, front-loaded with core purpose, no wasted words. Efficiently conveys the essential action without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It lacks details on return values, error cases, and full parameter semantics, making it inadequate 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 description must compensate. It mentions 'specific properties and associations' which hints at the 'properties' and 'associations' parameters, but doesn't explain their formats, optionality, or the enum values for associations. Inadequate compensation for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('a single contact'), specifying it's by ID with properties and associations. It distinguishes from siblings like crm_list_objects or crm_search_contacts by focusing on single retrieval, 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?
No explicit guidance on when to use this tool versus alternatives like crm_get_object or crm_search_contacts. The description implies usage for fetching a specific contact by ID but lacks context 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Get' implies a read operation, but it doesn't specify whether this requires authentication, has rate limits, returns paginated results, or what format the output takes. For a tool with 2 parameters and no output schema, this leaves significant behavioral gaps 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 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 completeness, 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 tool with 2 undocumented parameters, no annotations, no output schema, and multiple similar sibling tools, the description is inadequate. It doesn't explain parameter usage, output format, error conditions, or differentiation from related tools. The brevity comes at the cost of necessary context 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?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions 'all properties' but doesn't explain the 'archived' boolean parameter or the 'properties' array parameter (which appears to allow filtering specific properties rather than getting 'all'). This creates confusion about whether the tool actually returns all properties or can be filtered.
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 properties for leads'), making the purpose understandable. It distinguishes from siblings like crm_get_lead (which gets lead details) and crm_get_lead_property (singular). However, it doesn't explicitly differentiate from crm_get_company_properties or crm_get_contact_properties, which have similar patterns for different 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. It doesn't mention when to use crm_get_lead_properties versus crm_get_lead (which might include properties), crm_search_leads (which might filter by properties), or the batch read tools. There's no context about prerequisites, permissions, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get' implies a read operation, but the description doesn't mention authentication requirements, rate limits, error conditions, or what happens if the object doesn't exist. For a read 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 simple get 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 4 parameters, 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns, how to interpret parameters, or any behavioral constraints. The description should provide more context given the complete 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 for 4 parameters, the description provides no information about any parameters. It doesn't explain what 'objectType' means, what format 'objectId' should be, what 'properties' controls, or what 'associations' does. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'a single CRM object by ID', which is specific and unambiguous. However, it doesn't distinguish this tool from other CRM get tools like crm_get_company, crm_get_contact, etc., which appear to be more specific versions of the same operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 including specific get operations (crm_get_company, crm_get_contact, etc.), the agent has no indication whether this is a generic version to use when object type is known, or whether the specific tools are preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'optional filtering and pagination' which hints at some behavior, but doesn't disclose critical details like whether this is a read-only operation, what permissions are needed, rate limits, error conditions, or the format of returned data. For a list tool with 5 parameters and no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core functionality without unnecessary words. It's appropriately sized for a list tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters (0% schema coverage), no annotations, no output schema, and many sibling alternatives, the description is insufficient. It doesn't explain parameter meanings, return format, behavioral constraints, or differentiation from similar tools. The conciseness comes at the expense of needed contextual information for proper 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?
Schema description coverage is 0%, meaning none of the 5 parameters have descriptions in the schema. The description only vaguely references 'optional filtering and pagination' without explaining what parameters correspond to filtering (properties? archived? objectType?) or pagination (after? limit?). It doesn't add meaningful semantic context 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.
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 understandable. However, it doesn't explicitly distinguish this tool from sibling list/search tools like 'crm_list_association_types', 'crm_search_objects', or other domain-specific list tools (e.g., 'calls_list', 'emails_list'), which would require more specific differentiation to earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools including 'crm_search_objects' and domain-specific list tools, there's no indication of when this general list tool is preferred over search tools or other list variants, leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
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: what permissions are required, whether updates are reversible, how conflicts are handled, what happens to unspecified properties, or what the response contains. For a mutation tool with zero annotation coverage, this represents 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 maximally concise - a single sentence with no wasted words. It's front-loaded with the essential action and target, making it immediately understandable at a basic level despite its other deficiencies.
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 a complex nested object), 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens during the update, what validation occurs, what errors might be returned, or how to interpret results. The description fails to provide the contextual completeness needed for safe and effective tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for all 3 parameters, the description provides no additional semantic information about objectType, objectId, or properties. The description doesn't explain what constitutes a valid objectId, what the 'custom' objectType option means, or what format the properties object should take. 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 ('Update') and target ('existing CRM object'), providing a specific verb+resource combination. However, it doesn't differentiate this tool from its many siblings 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 that perform similar CRM update operations (crm_update_company, crm_update_contact, crm_update_lead, crm_batch_update_objects), there's no indication of when this general 'object' update is preferred over the more specific tools or batch operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states 'Create' which implies a write/mutation operation, but doesn't mention permissions required, rate limits, whether emails are actually sent vs. stored as drafts, error handling for partial failures, or what the response contains. This is a significant gap 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, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a tool name that already conveys the domain ('emails') and operation type ('batch_create').
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 (0% schema coverage), no annotations, and no output schema, the description is severely inadequate. It doesn't explain what constitutes a valid email record, how associations work, what statuses mean, or what happens after creation. The agent lacks critical context for successful tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. The complex nested schema with 17+ properties and associations is completely undocumented in the description. The agent must infer parameter meaning from property names alone, which is insufficient for proper tool invocation.
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 email records') and resource ('email records'), and specifies the batch nature ('in a single request'). It distinguishes from the singular 'emails_create' sibling tool by emphasizing batch creation. However, 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 implies usage for batch creation scenarios but provides no explicit guidance on when to use this vs. singular creation ('emails_create') or other batch operations. There's no mention of prerequisites, limitations, or alternative tools for different 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 full burden but only states it's a read operation. It lacks details on permissions required, rate limits, pagination, error handling for invalid IDs, or what data is returned (e.g., full email content vs. metadata). This is inadequate for a batch tool with complex input structure.
Agents need to know what a tool does to the world before calling it. Descriptions 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, making it easy to scan and understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (batch operation with nested input objects), lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like performance, limitations, or return format, leaving significant gaps for an AI 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 description must compensate but adds nothing about parameters. It doesn't explain that 'inputs' is an array of objects with 'id', 'properties', and 'associations', or their purposes (e.g., 'properties' for specific fields, 'associations' for related data). This leaves 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 verb ('Read') and resource ('multiple email records'), specifying it's a batch operation ('in a single request'). It distinguishes from individual read tools like 'emails_get' by emphasizing batch capability, though it doesn't explicitly contrast with 'emails_list' or 'emails_search' for broader queries.
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_get' (for single emails), 'emails_list' (for listing all emails), or 'emails_search' (for filtered searches). The description implies batch reading but doesn't specify use cases like efficiency for multiple known IDs.
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 critical behavioral traits like whether this requires specific permissions, if updates are atomic or partial, rate limits, error handling for invalid inputs, or what happens to existing properties not mentioned. 'Update' implies mutation but lacks safety or operational details.
Agents need to know what a tool does to the world before calling it. Descriptions 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 understandable despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch mutation tool with 1 parameter (but complex nested schema), no annotations, and no output schema, the description is inadequate. It doesn't address behavioral risks, parameter usage, expected outputs, or error conditions. The completeness gap is significant given the tool's complexity and 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?
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 numerous nested properties like 'hs_email_subject' with their constraints. The description fails to provide any semantic context beyond the schema's raw structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') 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, though it doesn't explicitly contrast with sibling batch tools like 'emails_batch_create' 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. It doesn't mention prerequisites like authentication, when batch updates are preferable to individual updates, or how it differs from other batch operations like 'emails_batch_create' or 'emails_batch_archive' in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Create a new email record' implies a write operation but doesn't disclose behavioral traits such as required permissions, whether it sends emails or just stores records, rate limits, or what happens on failure. This leaves significant gaps for a mutation 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 with zero waste. It's front-loaded and appropriately sized for its minimal 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.
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 2 parameters, nested objects, 0% schema coverage, no annotations, and no output schema), the description is incomplete. It doesn't address behavioral aspects, parameter meanings, or output expectations, making it inadequate for guiding an agent in correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions no parameters, while the input schema has 2 parameters (properties and associations) with complex nested structures. The description adds no meaning beyond the schema, failing to explain what properties or associations entail, resulting in inadequate 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 'Create a new email record' clearly states the verb ('Create') and resource ('email record'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like emails_batch_create or emails_update, which would require mentioning it's for single email creation versus batch operations or updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. Given siblings like emails_batch_create (for batch operations) and emails_update (for modifications), the agent lacks explicit direction on choosing this tool for single email creation, nor does it mention 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 states the tool retrieves details but doesn't mention whether this is a read-only operation, what permissions are required, how errors are handled, or the format of returned data. This leaves significant gaps for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded and appropriately sized for a basic retrieval operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 3 parameters with 0% schema coverage, no annotations, and no output schema, the description is insufficient. It fails to explain parameter usage, behavioral traits, or return values, making it incomplete for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate by explaining parameters. It mentions 'a specific email' which hints at the 'emailId' parameter but doesn't clarify what 'properties' or 'associations' arrays do, leaving two parameters undocumented and their purposes 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 verb ('Get') and resource ('details of a specific email'), making the purpose understandable. However, it doesn't distinguish this from sibling tools like 'emails_list' or 'emails_search' that also retrieve email information, missing 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 'emails_list' for multiple emails or 'emails_search' for filtered searches. It lacks any context about prerequisites, error conditions, 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 full burden for behavioral disclosure. It states this is a 'Get' operation which implies read-only behavior, but doesn't specify authentication requirements, rate limits, error conditions, or what format/details are returned. 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 that gets straight to the point with zero 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 no annotations, 0% schema description coverage, and no output schema, the description is insufficiently complete. It doesn't explain what 'details' are returned, how to interpret the engagementId, or how this tool differs from similar engagement-related operations. The minimal description leaves too many contextual gaps 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, providing no documentation for the 'engagementId' parameter. The description doesn't compensate by explaining what an engagementId is, where to find it, its format, or validation rules. This leaves the single required parameter completely undocumented beyond its name and type.
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 details') and resource ('a specific engagement'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'engagement_details_get_associated' or explain what 'details' specifically means compared to other engagement-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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' or 'engagement_details_get_associated'. It doesn't mention prerequisites, appropriate contexts, or what distinguishes this retrieval operation from other engagement-related operations in the sibling tool list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's an update operation, implying mutation, but lacks details on permissions, side effects, error handling, or response format. This is inadequate for a batch 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 front-loaded with the core action and resource, 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?
For a batch mutation tool with no annotations, 0% schema coverage, and no output schema, the description is incomplete. It lacks essential context such as behavioral traits, parameter explanations, and usage scenarios, 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 meetings' but doesn't explain the 'inputs' parameter structure, required fields, or property meanings. The description adds minimal value beyond what the schema provides, failing to clarify parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('multiple meetings'), making the purpose understandable. It distinguishes from single-meeting updates by specifying 'multiple meetings in a single request,' though it doesn't explicitly differentiate from sibling tools like 'meetings_update' or batch operations for other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 implies batch functionality but doesn't specify prerequisites, constraints, or recommend it over single updates or other batch tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a read operation ('Get'), which is helpful, but doesn't disclose behavioral traits like authentication needs, rate limits, error handling, or what details are returned. For a tool with 3 parameters and no output schema, 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 no wasted words. It's front-loaded with the core purpose, 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 3 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain parameters, return values, or behavioral context, leaving the agent with insufficient information to use the tool effectively beyond basic intent.
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 doesn't mention any parameters, leaving all 3 (meetingId, properties, associations) unexplained. It fails to compensate for the schema's lack of descriptions, missing crucial context like what 'properties' or 'associations' refer to.
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 unambiguous. It doesn't explicitly differentiate from sibling tools like 'meetings_list' or 'meetings_search', but the specificity of 'a specific meeting' implies it requires a meeting ID rather than listing or searching.
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 'meetings_list' or 'meetings_search'. The description implies it's for retrieving details of a known meeting, but doesn't state prerequisites (e.g., needing a meeting ID) or compare to other retrieval methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'List all meetings' implies a read-only operation, but it doesn't mention pagination behavior, rate limits, authentication requirements, or whether this returns all meetings or a subset. The mention of 'optional filtering' is vague about implementation details.
Agents need to know what a tool does to the world before calling it. Descriptions 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 6 words, front-loading the core purpose with no wasted words. Every word earns its place, though this conciseness comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the filtering parameters, return format, pagination, or how it differs from sibling tools like 'meetings_search'. The agent would struggle to use this tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 5 parameters, the description must compensate but fails to do so. It mentions 'optional filtering' but doesn't explain what parameters control filtering (e.g., 'after', 'createdAfter', 'properties'). The schema shows date and property filtering parameters that are completely undocumented in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all meetings with optional filtering' clearly states the verb ('List') and resource ('meetings'), and specifies scope ('all' with 'optional filtering'). However, it doesn't distinguish from sibling tools like 'meetings_search' or 'meetings_get' which might offer different filtering capabilities or scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'meetings_search' or 'meetings_get' from the sibling list. It mentions 'optional filtering' but doesn't specify what types of filtering are available or when this tool is preferred over other meeting-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool archives/deletes notes, implying a destructive mutation, but lacks critical behavioral details: whether archiving is permanent or reversible, permission requirements, rate limits, error handling for invalid IDs, or the response format. The parenthetical '(delete)' adds some clarity but is insufficient for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It front-loads the core action ('Archive (delete) multiple notes') and adds the operational context ('in a single request') concisely. 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 destructive batch operation with no annotations, 0% schema coverage, and no output schema, the description is incomplete. It lacks essential context: behavioral traits (permanence, permissions), parameter details (ID format, limits), error handling, and response expectations. The description does not adequately compensate for the missing structured information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'multiple notes' which hints at the 'noteIds' array parameter, but provides no semantics: what format the IDs should be, constraints (e.g., maximum array size), or if they must belong to the same workspace. The description adds minimal 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 ('Archive (delete)') and resource ('multiple notes'), and specifies the batch operation ('in a single request'). It distinguishes from the singular 'notes_archive' sibling by emphasizing the batch capability. However, it doesn't explicitly contrast with other batch operations like 'notes_batch_create' or 'notes_batch_update'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., note IDs must exist), when batch archiving is preferred over individual archiving, or how it differs from other batch operations like 'notes_batch_update'. The context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it's a creation operation. It doesn't disclose behavioral traits like whether this requires specific permissions, if it's idempotent, rate limits, error handling for partial failures, or what happens on success. 'Create' implies mutation, but details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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?
Given the complexity (1 parameter with nested objects), no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't address parameter meanings, behavioral context, or output expectations, making it inadequate for a batch creation tool with rich input structure.
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%, and the description provides no information about parameters. It doesn't explain what 'inputs' should contain, the structure of note properties (like 'hs_note_body'), or associations. The description fails to compensate for the schema's lack of descriptions, leaving parameters 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 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' beyond the verb 'create'.
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_create' for single notes or other batch operations. It mentions 'multiple notes' but doesn't specify thresholds, prerequisites, or performance considerations for batch creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it's a read operation, implying it's non-destructive, but doesn't disclose behavioral traits like authentication needs, rate limits, error handling, or response format. The description is minimal and lacks essential context for a 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 and appropriately sized for its content, though it could benefit from more 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 (batch operation with nested object parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain how to structure requests, what data is returned, or any limitations, 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 notes' but doesn't explain the 'inputs' parameter structure, what 'id' refers to, or the purpose of 'properties' and 'associations' arrays. The description adds minimal value beyond the schema, failing to clarify parameter meanings.
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'), specifying it's a batch operation ('in a single request'). It distinguishes from individual note tools like 'notes_get' but doesn't explicitly differentiate from other batch read tools for different resources (e.g., 'calls_batch_read', 'emails_batch_read').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'notes_get' (for single notes) or 'notes_list' (for listing all notes). The description implies batch functionality but doesn't provide 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 states 'Update multiple notes' which implies a write/mutation operation, but fails to describe critical traits: whether it requires specific permissions, if updates are atomic or partial, what happens on errors (e.g., all-or-nothing vs. partial updates), rate limits, or response format. For a batch mutation tool with zero annotation coverage, this is a significant gap in safety and operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste: 'Update multiple notes in a single request'. It is front-loaded with the core action and scope, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch mutation tool with no annotations, 0% schema description coverage, and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., error handling, permissions), parameter meanings, and expected outputs, making it inadequate for safe and effective use by an AI agent in a complex environment with 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?
The input schema has 1 parameter ('inputs') with 0% description coverage, and the description adds no parameter semantics beyond implying it takes multiple notes. It doesn't explain the structure of 'inputs' (an array of objects with 'id' and 'properties'), the meaning of properties like 'hs_note_body', or required fields. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('multiple notes'), and specifies the scope ('in a single request'), which distinguishes it from single-note updates. However, it doesn't explicitly differentiate from sibling tools like 'notes_update' or 'notes_batch_archive', leaving some ambiguity about when to choose this specific batch 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?
The description provides no guidance on when to use this tool versus alternatives like 'notes_update' for single notes or 'notes_batch_archive' for batch deletions. It mentions 'in a single request' which hints at efficiency for multiple updates, but lacks explicit when-to-use or when-not-to-use instructions, prerequisites, or named 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 the full burden of behavioral disclosure. It states this is a 'Get' operation, implying it's read-only, but doesn't specify authentication requirements, rate limits, error conditions, or what 'details' includes. 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 no wasted words. It's front-loaded with the core purpose and appropriately sized for a simple 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 (3 parameters, 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't explain what 'details' include, how to use the optional parameters, or what the tool returns. For a tool with undocumented parameters and no structured guidance, this leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 3 parameters (noteId, properties, associations) are documented in the schema. The description only mentions 'a specific note,' which hints at noteId but doesn't explain the optional properties or associations parameters. 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.
Purpose4/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 doesn't differentiate from sibling tools like 'notes_list' or 'notes_search' that also retrieve note information, so it's not fully specific about being for a single identified note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing a noteId), when to choose this over 'notes_list' or 'notes_search', or any context about its role in the broader toolset.
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. 'List all notes' implies a read operation, but it doesn't mention pagination behavior, rate limits, authentication requirements, or what happens when no filters are applied. The description is too minimal for a tool with 5 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 extremely concise - a single 7-word sentence that's front-loaded with the core purpose. There's zero wasted verbiage 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 tool with 5 parameters, 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the filtering options, return format, pagination, or how to interpret results. The agent would struggle to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but only mentions 'optional filtering' without explaining what parameters exist or their purposes. The 5 parameters (limit, after, properties, associations, archived) are completely undocumented in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all notes with optional filtering' clearly states the verb ('List') and resource ('notes'), and specifies scope ('all notes with optional filtering'). It doesn't explicitly differentiate from sibling tools like 'notes_search' or 'notes_get', but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'notes_search' or 'notes_get' from the sibling list. There's no mention of prerequisites, performance characteristics, 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 full burden for behavioral disclosure. 'Update an existing note' implies a mutation operation but doesn't disclose any behavioral traits: no information about permissions required, whether updates are reversible, rate limits, error conditions, or what the response contains. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 4 words, front-loaded with the core action. There's zero wasted language or redundancy. While it's arguably too brief for a mutation tool with complex parameters, it earns full marks for conciseness as every word contributes to the core meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 2 parameters (including nested objects), 0% schema description coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain what can be updated, how to format updates, what happens on success/failure, or provide any context about the note system. The agent lacks sufficient information 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 but fails to do so. It mentions no parameters at all, while the input schema shows 2 required parameters (noteId and properties) with nested properties. The description doesn't explain what noteId should be, what properties can be updated, or the meaning of hs_note_body, hs_timestamp, and hubspot_owner_id 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 'Update an existing note' clearly states the verb (update) and resource (note), making the purpose immediately understandable. It distinguishes from sibling tools like notes_create, notes_get, and notes_archive by specifying it's for existing notes. However, it doesn't specify what aspects can be updated (e.g., body, timestamp, owner) which would make it more 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a noteId), when to use notes_update vs notes_batch_update, or what happens if the note doesn't exist. The agent must infer usage from the tool name and input 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 indicates this is a destructive operation (moving to recycling bin implies removal from active state) but doesn't specify whether this is reversible, what permissions are required, or what happens to associated data. 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 communicates the core functionality without unnecessary words. It's appropriately sized for a simple operation and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't address critical context like whether the operation is reversible, what confirmation or response to expect, error conditions, or how this differs from deletion versus archiving.
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 the undocumented parameter. While it mentions 'ID' as the identifier, it doesn't specify the format of 'productId' (e.g., numeric, string, GUID) or provide any examples. The description adds minimal value beyond what's implied by the parameter name itself.
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'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'products_batch_archive' or 'crm_archive_object', which appear to serve similar archiving functions for different resource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'products_batch_archive' for multiple products or other archiving tools for different resource types. The description only states what the tool does without context about appropriate use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks critical behavioral details. It states this is an update operation (implying mutation) but doesn't disclose permissions required, whether changes are reversible, error handling for partial failures in batch updates, rate limits, or what the response looks like. 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 immediately specifies the identification methods. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (batch update operation with nested objects), lack of annotations, 0% schema description coverage, and no output schema, the description is incomplete. It doesn't address behavioral aspects, parameter details, error handling, or response format, leaving significant gaps for the agent to operate 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 but adds minimal parameter semantics. It mentions 'idProperty query param' (which isn't in the schema's top-level properties) and implies batch processing via 'inputs' array, but doesn't explain the structure of 'inputs' objects, required fields like 'id' and 'properties', or what properties can be updated. The description fails to adequately clarify the complex nested parameter structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('update') and resource ('batch of products'), and specifies identification methods ('by internal ID, or unique values specified by the `idProperty` query param'). However, it doesn't explicitly differentiate from sibling tools like 'products_update' (single update) or 'products_batch_create' (batch creation), which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'products_update' for single updates or 'products_batch_create' for batch creation. The description mentions the identification method but doesn't explain use cases or prerequisites, 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?
No annotations are provided, so the description carries full burden. It states this is a read operation, implying it's non-destructive, but doesn't disclose any behavioral traits like authentication needs, rate limits, error handling for invalid IDs, or whether it returns partial results. For a batch operation with 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, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it immediately clear without unnecessary elaboration, though this conciseness comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a batch operation with 1 parameter (a nested array of objects), 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the input format, expected output, or any constraints, leaving too much for the agent to infer from the schema alone.
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 doesn't. It mentions 'multiple tasks' but provides no details about the 'inputs' parameter structure, such as that each input requires an 'id' and can optionally include 'properties' and 'associations' arrays. The description adds no value beyond what's inferred from the name, leaving parameters largely 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 ('Read multiple tasks') and resource ('tasks'), making the purpose immediately understandable. However, it doesn't differentiate this batch operation from individual task reading tools like 'tasks_get' or 'tasks_list' among the siblings, which would require mentioning efficiency benefits or specific use cases.
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 'tasks_get' (single task read), 'tasks_list' (list all tasks), and 'tasks_search' (filtered search), there's no indication that this is for bulk retrieval of specific tasks by ID, leaving the agent to guess based on 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 the full burden of behavioral disclosure. While 'Archive (delete)' implies a destructive mutation, it doesn't specify whether archiving is permanent, reversible, or affects related data. No information about authentication requirements, rate limits, error conditions, or response format is provided, which is inadequate for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just four words, front-loading the essential action and resource. Every word earns its place with zero wasted text, 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 destructive mutation tool with no annotations, no output schema, and a parameter that needs explanation, the description is incomplete. It identifies the basic operation but lacks critical context about behavior, consequences, parameter usage, and alternatives. The agent would struggle to use this tool correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 one required parameter (callId) with 0% description coverage. Since the schema provides the parameter structure but no semantic context, the baseline is 3. The description doesn't compensate by explaining what 'callId' represents or where to obtain it, leaving a gap 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 action ('Archive (delete)') and resource ('a call record'), making the purpose immediately understandable. It distinguishes this from sibling tools like 'calls_get' or 'calls_update' by specifying the destructive archival operation. However, it doesn't explicitly differentiate from 'calls_batch_archive' which handles multiple calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'calls_batch_archive' for multiple calls or 'calls_update' for modifications. There's no mention of prerequisites, permissions required, or consequences of archiving, leaving the agent with insufficient context for appropriate tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the destructive action ('Archive (delete)') which is critical, but lacks details on permissions required, whether deletion is permanent or reversible, rate limits, error handling for partial failures, or what happens to associated data. The batch nature is mentioned but without behavioral specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with zero waste. Front-loaded with the core action and resource. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive batch operation with no annotations, 0% schema coverage, and no output schema, the description is inadequate. It misses critical context: parameter documentation, behavioral details (permissions, reversibility), output expectations, and differentiation from siblings. The conciseness comes at the cost of completeness.
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 doesn't mention the 'callIds' parameter at all, leaving the single required parameter undocumented. No format, constraints, or examples are provided. Baseline would be lower, but the tool has only one parameter, making the gap slightly less severe.
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 the scope 'in a single request'. It distinguishes from 'calls_archive' by specifying batch operation, though not explicitly naming the sibling. The parenthetical '(delete)' adds clarity about the destructive nature.
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' for single records or other batch operations. The description implies batch context but doesn't provide prerequisites, limitations, or comparative advice 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 of behavioral disclosure. It states this is a 'Get' operation, implying read-only behavior, but doesn't clarify aspects like authentication requirements, rate limits, pagination, or what 'all' entails (e.g., whether 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 action ('Get all subscription definitions') without unnecessary words. It earns its place by clearly stating the tool's purpose in minimal terms.
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 behavioral traits (e.g., read-only confirmation, error handling), parameter usage, and return values, making it inadequate for a tool that likely returns a list of subscription definitions.
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 'all subscription definitions' but doesn't reference the 'archived' parameter in the input schema. With 0% schema description coverage and 1 parameter, the description adds no specific parameter semantics beyond the general scope. However, since there's only one optional parameter, the baseline is 4, but the description doesn't compensate for the lack of schema details, warranting a 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 ('Get') and resource ('all subscription definitions for the portal'), making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'communications_get_subscription_status' or 'communications_get_preferences', which handle 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or compare it to sibling tools like 'communications_get_subscription_status' or 'communications_get_preferences', leaving 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?
No annotations are provided, so the description carries full burden. It mentions 'Archive (delete)' which implies a destructive operation, but doesn't disclose critical behavioral traits like whether archiving is permanent or reversible, what permissions are required, if there are rate limits, or what happens to associated data. For a destructive tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just four words, front-loading the key action and resource. Every word earns its place with zero waste, 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 destructive tool with 2 parameters, 0% schema description coverage, no annotations, and no output schema, the description is incomplete. It doesn't address behavioral implications, parameter meanings, usage context, or expected outcomes. The conciseness comes at the expense of necessary context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'objectType' or 'objectId' represent, their formats, or the meaning of the enum values. The baseline is 3 since there are only 2 parameters, but the description fails to provide any semantic context beyond what's 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 ('Archive (delete)') and resource ('a CRM object'), making the purpose immediately understandable. It distinguishes from sibling tools like 'crm_update_object' or 'crm_get_object' by specifying the destructive action, though it doesn't explicitly contrast with batch archive 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 is provided on when to use this tool versus alternatives. With multiple sibling tools like 'crm_batch_archive_objects' for batch operations and 'crm_archive_association' for related objects, the description offers no context about single-object vs. batch usage or prerequisites for archiving.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a create operation (implying mutation) but doesn't disclose behavioral traits like required authentication, rate limits, error handling for partial failures, or whether it's idempotent. The description is minimal and lacks critical context 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, clear sentence with zero wasted words. It's front-loaded with the core purpose and efficiently conveys the batch nature. Every word earns its place, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (batch creation with nested parameters), lack of annotations, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't explain input semantics, behavioral expectations, or output format, 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?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'multiple companies' but doesn't explain the 'inputs' parameter structure, nested fields (e.g., properties, associations), or required fields. It adds minimal value beyond the schema's structure, baseline 3 due to low coverage but insufficient compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create multiple companies') and resource ('companies'), and specifies it's a batch operation ('in a single request'). It distinguishes from single-create tools like 'crm_create_company' by emphasizing batch capability, though it doesn't explicitly contrast with other batch tools like '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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., required permissions), limitations (e.g., batch size limits), or compare it to other batch tools (e.g., 'crm_batch_create_contacts' for contacts instead of companies). Usage is implied only by the tool name.
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 whether it's idempotent, requires specific permissions, has rate limits, returns partial results on failure, or what happens on invalid inputs. 'Update multiple leads' implies mutation but lacks critical operational details.
Agents need to know what a tool does to the world before calling it. Descriptions 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 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?
Given the complexity (batch update operation with nested schema), no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It lacks information on behavior, error handling, return values, and usage context, making it inadequate for an AI agent to use effectively without guesswork.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description has 0 parameters (it doesn't explicitly list any), and schema description coverage is 0%, but the input schema is rich with nested properties. The description implies batch processing with 'inputs' but doesn't detail parameter meanings. However, with 0 parameters in the description, the baseline is 4 as it doesn't add semantic value beyond the schema's structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update multiple leads in a single request' clearly states the action (update) and resource (leads), but it's vague about scope and doesn't distinguish from siblings like 'crm_batch_update_contacts' or 'crm_update_lead'. It specifies 'multiple' and 'single request' which adds some specificity, but lacks detail on what 'update' entails compared to other 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. It doesn't mention prerequisites, when to choose batch update over individual updates (e.g., 'crm_update_lead'), or any constraints like rate limits or permissions. The description alone offers no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is an update operation, implying mutation, but doesn't disclose critical behavioral traits like permissions required, whether updates are partial or full, error handling for invalid inputs, or rate limits. This leaves significant gaps for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action and efficiently conveys the batch nature of the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a batch update operation with no annotations, 0% schema description coverage, and no output schema, the description is inadequate. It lacks details on behavior, error handling, and output format, making it incomplete 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'multiple CRM objects' and 'single request', which hints at the 'inputs' array parameter, but doesn't explain the 'objectType' enum or the structure of 'inputs' (e.g., that each item needs 'id' and 'properties'). The description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('multiple CRM objects'), making the purpose evident. However, it doesn't distinguish this tool from sibling batch update tools like 'crm_batch_update_companies' or 'crm_batch_update_contacts', which are more specific variants.
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_batch_update_companies', 'crm_update_object'), there's no indication of when batch updating generic objects is preferred over more specific or single-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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions retrieving 'specific properties and associations', implying a read-only operation, but doesn't clarify permissions, rate limits, error handling, or response format. For a tool with no annotation coverage, this is insufficient to guide safe and effective use.
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 and key parameters. There's no wasted verbiage, and it directly addresses what the tool does. It could be slightly more structured by explicitly listing parameter roles, but it's appropriately concise for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a CRM tool with 3 parameters, 0% schema description coverage, no annotations, and no output schema, the description is incomplete. It lacks details on authentication, error cases, return values, and how to interpret 'properties' and 'associations' arrays. This makes it inadequate for reliable agent use without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds some meaning by referencing 'specific properties and associations', which aligns with the 'properties' and 'associations' parameters in the schema. However, with 0% schema description coverage, it doesn't fully compensate by explaining parameter formats, constraints, or examples. The baseline is 3 because the description provides minimal but relevant context 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 'Get' and resource 'a single lead by ID', making the purpose evident. It adds specificity with 'with specific properties and associations', which helps distinguish it from generic get operations. However, it doesn't explicitly differentiate from sibling tools like 'crm_get_object' or 'crm_search_leads', which could retrieve similar 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?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools like 'crm_get_object', 'crm_search_leads', and 'crm_batch_read_objects', there's no indication of prerequisites, constraints, or comparative use cases. 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?
No annotations are provided, so the description carries the full burden. It states this is a list operation, implying it's likely read-only and non-destructive, but doesn't confirm this or disclose other behavioral traits like authentication requirements, rate limits, pagination, or what the output looks like. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core purpose and efficiently conveys the essential information 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 has no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It adequately states what the tool does but fails to provide necessary context about behavior, parameters, or output. For a tool with two required parameters and no structured documentation, more detail is needed to make it fully usable.
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 'for a given object type pair', which aligns with the two parameters (fromObjectType and toObjectType) in the schema. However, schema description coverage is 0%, so the description doesn't add details about what these parameters mean beyond their names. It doesn't explain the enum values or the relationship between the two object types. Baseline 3 is appropriate as the description provides minimal context but doesn't fully 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 ('List') and resource ('association types') with the specific scope 'for a given object type pair'. It distinguishes from sibling tools like crm_get_associations or crm_create_association by focusing on listing types rather than instances. However, it doesn't explicitly differentiate from other list tools in the CRM category.
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 guidance by mentioning 'for a given object type pair', implying it's used when you need to know what association types exist between two object types. However, it offers no explicit when-to-use guidance, no prerequisites, and no alternatives (e.g., when to use this vs. crm_get_associations which retrieves actual associations).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is an update operation but doesn't cover critical aspects like required permissions, whether updates are idempotent, error handling, or what happens to unspecified properties. The mention of 'validated properties' hints at validation 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.
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 front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, 0% schema description coverage, and no output schema, the description is insufficient. It doesn't explain what 'validated' means, what the tool returns, error conditions, or how it differs from similar update tools. The agent lacks critical context for proper 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?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'validated properties' which loosely relates to the 'properties' parameter but doesn't explain what validation means or provide any details about the 'companyId' parameter. It adds minimal semantic value beyond the schema's structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('an existing company'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like crm_update_contact or crm_update_lead, which have similar update patterns for different 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 like crm_batch_update_companies or crm_update_object. It mentions 'validated properties' but doesn't explain what validation entails or any prerequisites for successful updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Update' implies a mutation, but it doesn't specify permissions required, whether changes are reversible, validation behavior for 'validated properties', error handling, or response format. The phrase 'validated properties' hints at validation but lacks detail on what validation entails or failure modes.
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 words or redundancy. However, it could be more front-loaded with critical details like parameter requirements or behavioral traits.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (mutation tool with nested properties, no annotations, no output schema, and 0% schema description coverage), the description is insufficient. It doesn't address key aspects like what 'validated properties' means, how updates are applied, error conditions, or response expectations. For a tool that modifies data, this leaves 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?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'validated properties' which loosely corresponds to the 'properties' parameter, but doesn't explain the structure, required fields, or the 'contactId' parameter. It adds minimal semantic value beyond what's inferable from the schema's property names and types.
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 contact'), making the purpose immediately understandable. It distinguishes from sibling tools like crm_create_contact by specifying 'existing contact' and from crm_batch_update_contacts by being singular. However, it doesn't explicitly mention what 'validated properties' means or how it differs from other update tools like crm_update_object.
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 contactId), compare to batch operations like crm_batch_update_contacts, or indicate when to use crm_update_contact versus crm_update_object. 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 but offers minimal behavioral insight. 'Update' implies mutation, but it doesn't disclose permissions needed, whether updates are partial or full, validation behavior beyond 'validated properties', error handling, or rate limits. The mention of 'validated properties' hints at some validation 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.
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 a basic tool description, though it could be more 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?
For a mutation tool with no annotations, 0% schema description coverage, no output schema, and complex nested parameters, the description is inadequate. It lacks details on behavior, error cases, return values, and usage context, leaving 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.
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: it implies 'leadId' identifies the lead and 'properties' contain validated updates. However, it doesn't explain what 'validated' means, the structure of properties, or provide examples. With 2 parameters (one nested), the baseline is 3 as the schema defines them, but the description compensates poorly for the 0% 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 action ('Update') and resource ('an existing lead'), making the purpose understandable. It distinguishes from creation tools like 'crm_create_lead' by specifying 'existing', but doesn't differentiate from other update tools like 'crm_batch_update_leads' or 'crm_update_object'.
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 a lead ID), when batch updates might be preferable, or how this differs from other update tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates a destructive action ('Archive (delete)') which is helpful, but lacks details on permissions needed, whether deletion is permanent or reversible, rate limits, error handling, or response format. The description is minimal and misses critical behavioral context for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive batch tool with no annotations, 0% schema coverage, and no output schema, the description is inadequate. It lacks details on behavioral traits (e.g., irreversible deletion), parameter specifics, error cases, and what the tool returns. The context signals indicate high complexity that isn't addressed.
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 the parameter is for 'multiple email records' but doesn't specify the format of 'emailIds' (e.g., IDs, email addresses) or constraints (e.g., max batch size). The description adds some meaning by linking 'emailIds' to 'email records', but falls short of fully documenting the single parameter.
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'), and specifies it's a batch operation ('in a single request'). It distinguishes from the singular 'emails_archive' sibling by emphasizing 'multiple' and 'batch', though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'emails_archive' for single emails or other batch operations. It mentions the batch nature but doesn't specify prerequisites, constraints, or comparative use cases with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While 'archive (delete)' implies a destructive operation, it doesn't disclose critical behavioral traits: whether this is permanent deletion or reversible archiving, what permissions are required, whether associated data is also affected, or what the response looks like. The parenthetical '(delete)' adds some clarification but remains ambiguous about the actual 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 - just three words. Every word earns its place: 'archive' specifies the action, '(delete)' clarifies the nature of the operation, and 'an engagement' identifies the resource. There's zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't explain the consequences of archiving, what data is affected, whether the operation can be undone, or what to expect as a response. The agent would be operating with significant uncertainty about this tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The description doesn't mention the 'engagementId' parameter at all, nor does it explain what format this ID should be in or where to obtain it. With only one parameter, this is a significant gap, but the tool's purpose is still somewhat inferable from 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)') and resource ('an engagement'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'crm_archive_object' or 'engagement_details_get', which would require more specificity about what distinguishes this particular engagement archive 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?
The description provides no guidance on when to use this tool versus alternatives. With multiple archive tools in the sibling list (calls_archive, emails_archive, meetings_archive, etc.), there's no indication of when this specific engagement archive tool is appropriate versus other deletion/archive operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is an archive/delete operation, which implies it's destructive, but doesn't clarify if deletion is permanent, reversible, or has side effects. No information about permissions, rate limits, or what happens to associated data is provided, 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 4 words, with zero wasted language. It's front-loaded with the core action and resource, making it immediately scannable. Every word earns its place, achieving maximum 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?
For a destructive operation with no annotations and no output schema, the description is incomplete. It doesn't explain what 'archive' means operationally, what the response looks like, or potential errors. Given the tool's complexity (permanent data modification) and lack of structured documentation, more context is needed for safe 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 no parameters, while the schema has 1 parameter (meetingId) with 0% description coverage. Since schema_description_coverage is 0%, the description should compensate but doesn't. However, with only 1 parameter, the baseline is higher than for complex tools. The description implies the tool acts on a meeting, which loosely relates to the meetingId parameter.
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 meeting'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'meetings_batch_archive' or other archive tools for different resources, 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. There's no mention of prerequisites (like needing a meeting ID), when to choose batch archiving instead, or how this differs from other meeting operations like 'meetings_update' or 'meetings_get'. The agent receives no 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 indicates a destructive action ('Archive (delete)') but lacks details on permissions required, whether deletion is permanent or reversible, rate limits, error handling for partial failures, or response format. 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 waste. It's front-loaded with the core action and resource, making it easy to parse quickly, which is ideal 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 tool's complexity (batch destructive operation), lack of annotations, no output schema, and minimal parameter guidance, the description is incomplete. It fails to address critical aspects like behavioral traits, error handling, or return values, 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'multiple meetings' and 'meetingIds', aligning with the single parameter in the schema (an array of strings). However, with 0% schema description coverage, it doesn't add meaningful details like ID format, array size limits, or validation rules. The baseline is 3 since the schema covers the parameter structure, but the description doesn't compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Archive (delete) multiple meetings') and resource ('meetings'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'meetings_archive' (singular) or other batch operations, which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing meeting IDs), compare it to 'meetings_archive' for single meetings, or specify use cases for batch operations, leaving the agent without contextual usage cues.
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. 'Archive (delete)' suggests a destructive operation, but doesn't clarify if this is permanent deletion, soft archival with recovery options, what permissions are required, whether it affects associated data, or what the response looks like. 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 maximally concise - a single phrase that communicates the core action. There's zero waste or redundancy. The front-loading is perfect since the entire description fits in one glance. 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 destructive operation with no annotations, no output schema, and incomplete parameter documentation, the description is inadequate. It doesn't address critical questions: Is the action reversible? What happens to the note? What permissions are needed? What does success/failure look like? The agent lacks sufficient context to use this tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no parameter information beyond what's implied by the action. With 0% schema description coverage and one required parameter (noteId), the description doesn't explain what format noteId should be, where to find it, or any constraints. However, with only one parameter, the baseline is higher than for multi-parameter tools, and the schema at least defines the type as string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Archive (delete)') and resource ('a note'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'notes_batch_archive' or 'notes_update' - the parentheses around 'delete' suggest an equivalence but don't clarify if this is permanent deletion versus soft archival.
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 for notes (notes_batch_archive, notes_update, notes_get, etc.), there's no indication of whether this is for single notes versus batches, whether it's reversible, or what prerequisites might exist. 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 full burden but offers minimal behavioral insight. It states the action is 'Archive (delete)' which implies destructive mutation, but doesn't clarify if this is reversible, what permissions are required, whether archiving differs from permanent deletion, or what happens to associated data. For a destructive batch operation, this is inadequate disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that efficiently communicates the core functionality without unnecessary words. It's front-loaded with the essential information and wastes no space on 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 no annotations and no output schema, the description is insufficient. It doesn't address critical context like what 'archive' means operationally, whether there are confirmation steps, what the response contains, error handling for invalid IDs, or rate limits. The agent lacks necessary 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 mentions 'by ID' which aligns with the 'productIds' parameter in the schema, adding minimal context about the parameter's purpose. However, with 0% schema description coverage, the description doesn't compensate by explaining format requirements, ID sources, or batch size limits. The baseline is appropriate given the single parameter, but more detail would be helpful.
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. It distinguishes from sibling 'products_archive' by specifying batch operation, though it doesn't explicitly contrast with other product tools like 'products_batch_update' or 'products_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 'products_archive' (single product) or 'products_batch_update' (modify instead of archive). There's no mention of prerequisites, consequences, or typical use cases for batch archiving versus individual operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 read operation, implying it's non-destructive, but doesn't mention any behavioral traits such as rate limits, authentication needs, error handling, or what happens if IDs are invalid. The description lacks details on return format, pagination, or performance characteristics.
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 functionality. It's front-loaded with the main purpose and avoids unnecessary fluff. However, the second sentence is slightly redundant with the first, and it could be more structured by explicitly listing parameter roles.
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, 3 required), 0% schema coverage, and no output schema, the description is incomplete. It doesn't explain what the tool returns, how to handle the array parameters, or the interaction between productIds and idProperty. For a batch read tool with multiple inputs, 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%, so the description must compensate for undocumented parameters. It only explains the idProperty parameter ('to retrieve records by a custom unique value property'), leaving productIds, properties, and propertiesWithHistory unexplained. This adds minimal value beyond the schema, failing to clarify the purpose or usage of most parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: reading a batch of products using internal IDs or unique property values. It specifies the verb ('Read'), resource ('products'), and scope ('batch'), distinguishing it from sibling tools like products_read (singular) and products_list (list all). However, it doesn't explicitly differentiate from products_search, which might also retrieve products by criteria.
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 by mentioning two retrieval methods (by internal ID or unique property values via idProperty), but it doesn't provide explicit guidance on when to use this tool versus alternatives like products_read (single product), products_list (list all), or products_search (search by criteria). No exclusions or prerequisites 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 for behavioral disclosure. It mentions the tool returns a copy of the created object including ID, which is useful. However, it doesn't address critical aspects like required permissions, whether this is a mutating operation (implied but not stated), error conditions, rate limits, or side effects. For a creation tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core action and return value without unnecessary words. It's appropriately sized for a basic creation tool, though it could be slightly more informative given the complexity of the nested parameter 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's complexity (1 parameter with nested object containing 6 properties), no annotations, no output schema, and 0% schema description coverage, the description is insufficient. It doesn't explain the parameter structure, available properties, validation rules, or what the returned object contains beyond 'including the ID'. For a creation tool with rich parameter requirements, this leaves too much undefined.
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 'properties' but doesn't explain what properties are available or their semantics. It doesn't add meaningful information about the nested object structure or the specific fields like name, price, sku, etc. Baseline is 3 when schema does heavy lifting, but here the schema lacks descriptions, and the description doesn't compensate adequately.
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'), specifying that it creates a product with given properties and returns the created object. It distinguishes from sibling tools like products_list or products_read by focusing on creation, though it doesn't explicitly contrast with products_batch_create for bulk 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. It doesn't mention prerequisites like authentication, compare with batch creation tools for efficiency, or indicate scenarios where this single-create tool is preferred over batch operations. 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds value by specifying that it's a partial update, that read-only and non-existent properties cause errors, and that empty strings clear properties. However, it lacks details on permissions, rate limits, side effects, or response format, leaving 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and follows with important behavioral notes in two sentences. It's efficient with no wasted words, though it could be slightly more structured by separating usage guidelines from constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (mutation tool with nested objects), no annotations, no output schema, and 0% schema coverage, the description is incomplete. It covers basic behavior but misses critical context like error handling details, authentication needs, return values, and how it differs from sibling update 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 for undocumented parameters. It implies 'productId' and 'properties' parameters but doesn't explain their semantics beyond 'Object identified by ID' and 'properties values'. No details on property names, formats, or constraints are provided, failing to adequately cover the two required 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 ('perform a partial update') and resource ('Object identified by ID'), making the purpose evident. However, it doesn't specify that this is for 'products' (implied by the tool name) or differentiate it from sibling tools like 'products_batch_update' or 'products_update' (if present), which would require more explicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'products_batch_update' or 'products_create'. It mentions error conditions for read-only and non-existent properties, but this is more about behavioral constraints than usage context. No explicit when/when-not or alternative tool references are included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Archive (delete)' implies a destructive mutation, which is helpful, but it doesn't specify whether this is permanent deletion vs soft deletion, permission requirements, side effects, or what happens to associated data. For a destructive operation with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, front-loading the essential action. There's zero wasted language, and every word earns its place by clarifying that 'archive' means 'delete' in this context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is inadequate. It should explain what 'archive' means operationally, whether it's reversible, what permissions are needed, and what the response contains. The current description leaves too many critical questions unanswered.
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 single parameter 'taskId' is undocumented in the schema. The description doesn't mention parameters at all, providing no additional semantic information beyond what's implied by the tool name. However, with only one parameter, the baseline is higher than for multi-parameter tools with poor 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 'Archive (delete) a task' clearly states the verb (archive/delete) and resource (task), making the purpose immediately understandable. It distinguishes from sibling tools like tasks_update or tasks_get by specifying the destructive action. However, it doesn't fully differentiate from tasks_batch_archive, which handles multiple tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., task must exist), when to use batch_archive instead for multiple tasks, or whether archiving is reversible. 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 full burden. It discloses the destructive action ('archive/delete') but lacks critical behavioral details: whether deletion is permanent or reversible, required permissions, rate limits, error handling for invalid IDs, or response format. For a destructive batch tool, this is a significant gap in safety and operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It front-loads the core action ('archive/delete') and scope ('multiple tasks in a single request'), 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?
For a destructive batch tool with no annotations, 0% schema coverage, and no output schema, the description is incomplete. It lacks behavioral transparency, parameter semantics, and usage guidelines needed for safe and effective invocation. The conciseness doesn't compensate for these critical gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds no parameter details beyond implying 'taskIds' are needed. It doesn't explain ID format, array size limits, or validation rules. With one parameter and no schema descriptions, the baseline is 3 as the description minimally compensates by hinting at the parameter's role.
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') with the scope 'in a single request.' It distinguishes from the singular 'tasks_archive' sibling by specifying batch operation, though it doesn't explicitly mention all batch alternatives. 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 'tasks_archive' (for single tasks) or other batch operations. The description implies batch usage but lacks explicit context, prerequisites, or exclusions, leaving the agent to infer usage from naming patterns alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it's an update operation. It doesn't disclose behavioral traits like whether this requires specific permissions, if updates are atomic or partial, error handling for invalid inputs, rate limits, or what happens when some updates fail. 'Update' implies mutation, but no safety or operational context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action ('Update multiple tasks') and adds necessary context ('in a single request'). 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 mutation tool with no annotations, 0% schema description coverage, and no output schema, the description is inadequate. It doesn't cover behavioral aspects (permissions, error handling), parameter details beyond a vague hint, or expected outcomes. The complexity of batch operations demands more context than provided.
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 task updates. However, it doesn't explain the structure of 'inputs' (array of objects with 'id' and 'properties'), the meaning of properties like 'hs_task_priority', or required fields beyond what the schema shows. Baseline 3 is appropriate as the description partially compensates for low schema coverage but leaves significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('multiple tasks'), making the purpose understandable. It distinguishes from single-task updates by specifying 'multiple tasks in a single request', but doesn't explicitly differentiate from other batch operations like 'tasks_batch_create' or 'tasks_batch_archive' in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'tasks_update' for single updates or other batch operations. The description mentions 'multiple tasks' but doesn't specify prerequisites, constraints, or ideal use cases for batch updating 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 indicates a destructive action ('delete') but doesn't specify if the deletion is permanent, reversible, requires specific permissions, or has side effects. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key information ('Archive (delete) an email record') with no wasted words. It's appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permanence, permissions, or error conditions, nor does it explain what happens after archiving or provide usage context relative to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't add parameter details beyond the schema, but with only one parameter (emailId) and 0% schema description coverage, the baseline is high. The tool's name and description imply emailId identifies the email to archive, which is sufficient for minimal parameter 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 email record'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like emails_batch_archive, which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like emails_batch_archive or emails_update. The description lacks context about prerequisites, such as whether the email must exist or be in a specific state, or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a 'Get' operation, implying read-only behavior, but doesn't disclose authentication needs, rate limits, error conditions, or what happens if the company ID doesn't exist. The mention of 'specific properties and associations' hints at selective retrieval but lacks details on default behavior or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero waste. It efficiently conveys the core purpose and key parameters without unnecessary words. Every part earns its place by specifying the action, target, and parameter roles.
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 with 0% schema coverage and no output schema, the description partially compensates by explaining parameter purposes. However, as a read operation with no annotations, it lacks details on authentication, error handling, return format, or pagination. It's minimally adequate but leaves gaps for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that 'companyId' identifies the company, 'properties' specifies which properties to retrieve, and 'associations' indicates related entities like contacts, deals, or tickets. This adds meaningful context beyond the bare schema, though it doesn't detail format or constraints for 'properties' array items.
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 company by ID', specifying it retrieves 'specific properties and associations'. It distinguishes from siblings like crm_search_companies (search vs get by ID) and crm_batch_read_objects (batch vs single). However, it doesn't explicitly contrast with crm_get_object which might serve a similar purpose for generic 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 explicit guidance on when to use this tool versus alternatives is provided. The description implies usage for retrieving a specific company by ID, but doesn't mention when to choose this over crm_get_object, crm_search_companies, or crm_batch_read_objects. No prerequisites, exclusions, or comparative context are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden of behavioral disclosure. While 'Unsubscribe' implies a mutation operation, the description doesn't specify whether this action is reversible, what permissions are required, whether it affects historical data, or what happens if the contact doesn't exist. It lacks important 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 that states the core purpose without unnecessary words. It's appropriately sized for a tool with a clear primary function and gets straight 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 mutation tool with 3 parameters (one required, one with legal/enum values), no annotations, and no output schema, the description is insufficient. It doesn't address the legal compliance aspects suggested by the parameter names, doesn't explain what 'all email communications' encompasses, 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 3 parameters, the description doesn't mention any parameters at all. It fails to explain what 'contactId' represents, or the purpose of the two portalSubscriptionLegalBasis parameters that appear to be related to compliance/legal requirements. The description adds no parameter semantics beyond what the bare schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Unsubscribe') and resource ('a contact from all email communications'), making the purpose immediately understandable. It distinguishes this tool from its sibling 'communications_subscribe_contact' by specifying the opposite operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (managing email subscriptions) but doesn't explicitly state when to use this tool versus alternatives like 'communications_update_subscription_status' or 'communications_update_preferences'. No guidance is provided about prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behavioral traits: pagination behavior (cursor-based), response structure hint (paging.next.after), and that it's a read operation. However, it doesn't mention authentication requirements, rate limits, error conditions, or whether it returns all products or has other constraints. The description adds meaningful context but leaves 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?
Two sentences, front-loaded with core purpose. The first sentence states what the tool does. The second explains parameter usage and response behavior. No wasted words, though the second sentence is somewhat dense. Structure is logical but could be slightly more readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read/list tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description provides adequate basics (purpose, pagination, property selection) but lacks details about authentication, error handling, rate limits, and complete parameter documentation. It's minimally viable but has clear gaps given the context complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 3 parameters, the description must compensate. It explains the purpose of 'properties' ('control what is returned') and 'after' (paging cursor, relates to response structure). It doesn't mention 'limit' parameter at all. The description adds significant value beyond the bare schema, explaining two of three parameters' purposes, though one parameter remains 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 tool's purpose: 'Read a page of products' specifies the verb (read) and resource (products). It distinguishes from sibling tools like products_read (singular) and products_search (filtered search), but doesn't explicitly mention these alternatives. The description is specific about pagination but could be more explicit about differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through pagination and property selection features, suggesting this is for browsing products with control over returned fields. However, it doesn't explicitly state when to use this versus alternatives like products_search (for filtering) or products_read (for single product). No explicit when-not-to-use guidance is provided.
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-shinzo MCP server](https://glama.ai/mcp/servers/amanagarwal13/hubspot-mcp-shinzo/badges/card.svg)](https://glama.ai/mcp/servers/amanagarwal13/hubspot-mcp-shinzo)

Score Badge

Copy to your README.md:

[![hubspot-mcp-shinzo MCP server](https://glama.ai/mcp/servers/amanagarwal13/hubspot-mcp-shinzo/badges/score.svg)](https://glama.ai/mcp/servers/amanagarwal13/hubspot-mcp-shinzo)

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/amanagarwal13/hubspot-mcp-shinzo'

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