HubSpot MCP Server

Overview Schema Related Servers Score Discussions

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 with no ambiguity, as tools are organized by resource type (calls, communications, crm, emails, etc.) and action (create, get, update, archive, batch operations). Overlap is intentional, with batch vs. single operations clearly distinguished, and different resources (e.g., calls vs. emails) are well-separated.
Naming Consistency5/5
Tool names follow a highly consistent pattern throughout: resource_action (e.g., calls_create, crm_get_company) or resource_batch_action (e.g., emails_batch_update). Minor variations like 'list' vs. 'search' are consistent within contexts, and the structure is predictable across all 112 tools.
Tool Count2/5
With 112 tools, the count is excessive for an MCP server, likely overwhelming for agents. While the tools cover many HubSpot resources, the sheer volume suggests over-engineering; a more focused set (e.g., 20-30 tools) would be more manageable without losing essential functionality.
Completeness5/5
The tool set provides comprehensive CRUD and lifecycle coverage across multiple HubSpot domains (calls, communications, CRM objects, emails, engagements, meetings, notes, products, tasks). Each resource type includes create, read, update, archive, list, search, and batch operations, leaving no obvious gaps for agent workflows.
Average 2.7/5 across 112 of 112 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- 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?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails completely. It doesn't indicate whether this is a mutating operation, what permissions might be required, whether it's idempotent, what happens on success/failure, or any rate limits. 'Create a new meeting' implies a write operation but provides no behavioral details.
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 three words, this is under-specification rather than effective conciseness. The description is front-loaded but provides so little information that it fails to be helpful. Every word earns its place, but there are far too few words to be useful.
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. A create operation with multiple required fields and complex associations needs much more explanation about what data is expected, how the meeting will be created, and what the result will be. The description provides none of this 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 mentions no parameters at all, while the input schema has 2 complex parameters (properties and associations) with 0% schema description coverage. The schema shows required fields like hs_timestamp, hs_meeting_title, hs_meeting_start_time, and hs_meeting_end_time, but the description provides zero guidance about what these mean or how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new meeting' is a tautology that restates the tool name 'meetings_create' without adding specificity. It doesn't explain what kind of meeting is being created, what system it's for, or how it differs from sibling tools like 'calls_create' or 'tasks_create' in the same server.
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 prerequisites, when this tool is appropriate versus other meeting-related tools (like 'meetings_update' or 'meetings_batch_create'), or any contextual constraints 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 full burden. The description claims a 'Create' operation which contradicts the tool name 'read_objects' - this inconsistency creates fundamental confusion about whether this is a read or write operation. No behavioral traits like permissions needed, rate limits, or response format are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that's technically concise, but this conciseness comes at the cost of being misleading and incomplete. While it's front-loaded, the single sentence doesn't earn its place by providing accurate or helpful 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 tool with 5 parameters, 0% schema coverage, no annotations, no output schema, and numerous sibling alternatives, the description is completely inadequate. It provides contradictory information about the tool's purpose and offers no guidance on usage, parameters, or behavior - leaving the agent with insufficient information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 5 parameters, the description provides no information about any parameters. It doesn't explain what 'objectType' enum values mean, what 'propertiesWithHistory' does, how 'idProperty' is used, or the purpose of 'objectIds' and 'properties' arrays. The description fails completely to compensate for the schema coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create multiple CRM objects in a single request' which is a tautology that essentially restates the tool name 'crm_batch_read_objects' with a contradictory verb ('Create' vs 'read'). This creates confusion rather than clarifying purpose. It fails to distinguish from sibling tools like crm_batch_create_objects or crm_batch_update_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?
No guidance is provided about when to use this tool versus alternatives. With numerous sibling tools for CRM operations (batch create, batch update, individual reads, searches), the description offers no context about appropriate use cases, prerequisites, or distinctions from similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the action ('Create') without addressing permissions, side effects, rate limits, or response format. This is inadequate for a mutation tool with 11 parameters, as it omits critical 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—a single sentence with no wasted words. It is front-loaded and to the point, though this brevity contributes to its inadequacy in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, no annotations, no output schema, 0% schema coverage), the description is severely incomplete. It lacks purpose differentiation, usage guidelines, behavioral details, and parameter explanations, making it insufficient for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description adds no information about any parameters (e.g., explaining 'name', 'type', 'options'), failing to compensate for the schema gap. With 11 parameters, this leaves the agent guessing about their meanings and usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new lead property' restates the tool name with minimal elaboration, making it a tautology. It specifies the verb ('Create') and resource ('lead property') but lacks detail on what a 'lead property' entails or how it differs from similar tools like crm_create_company_property or crm_create_contact_property, failing to distinguish from siblings.
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 (e.g., crm_create_company_property, crm_create_contact_property), 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 states 'Create a new note' which implies a write operation but doesn't specify permissions required, whether it's idempotent, rate limits, error handling, or what the response contains. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence 'Create a new note', which is front-loaded and wastes no words. While this brevity contributes to under-specification, it scores high on conciseness as every word directly states the tool's action without fluff.
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 output schema, no annotations), the description is completely inadequate. It doesn't explain the note's purpose, required inputs like 'hs_note_body', how associations work, or what happens after creation. For a create operation with undocumented parameters and no behavioral context, this fails to provide necessary information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters, while the input schema has 2 parameters with 0% schema description coverage and complex nested structures. The agent must infer that 'properties' contains note content and 'associations' links to other entities, but the description provides no semantic context, leaving parameters completely undocumented beyond their schema structure.
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' is a tautology that restates the tool name 'notes_create' without adding specificity. It mentions the verb 'create' and resource 'note' but provides no details about what a note entails in this context or how it differs from similar tools like 'notes_batch_create' or 'engagement_details_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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or compare it to sibling tools like 'notes_batch_create' for bulk operations or 'notes_update' for modifications, 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 offers nothing beyond the basic action. It doesn't mention whether this is a read-only operation, what permissions might be required, whether results are paginated, what format results return, or any rate limits or constraints. This leaves the agent with no understanding of 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 maximally concise with just two words. While this represents severe under-specification, from a pure conciseness perspective, there is zero wasted language or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex search tool with 6 parameters (including nested filter objects), no annotations, and no output schema, the description is completely inadequate. It provides no information about the tool's purpose beyond its name, no usage guidance, no behavioral context, and no parameter semantics. This leaves the agent unable to effectively use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 6 parameters and 0% schema description coverage, the description provides no information about any parameters. The schema defines complex filtering capabilities (filterGroups with multiple operators), sorting, pagination, and field selection, but the description 'Search products' gives no hint about these capabilities or how to use them effectively.
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 restates the tool name without adding meaningful context. It specifies the verb 'search' and resource 'products' but provides no detail about scope, functionality, or how it differs from sibling tools like 'products_list' or 'products_read'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. There are multiple sibling tools for products (archive, batch operations, create, list, read, update), but the description offers no indication of when search is appropriate versus list or read operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers no behavioral information. It doesn't disclose whether this is a read-only operation, what permissions are needed, how results are returned (pagination, format), rate limits, or error conditions. This leaves the agent with critical gaps in understanding tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (4 words) but under-specified rather than efficiently informative. While front-loaded, it lacks necessary detail, making this brevity a deficiency rather than a strength for tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 5 parameters, 0% schema coverage, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what the tool returns, how to structure complex filters, or provide any context needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning all 5 parameters are undocumented in the schema. The description only vaguely mentions 'specific filters' without explaining any parameters like filterGroups, properties, limit, after, or sorts. It fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search tasks with specific filters' states the action (search) and resource (tasks) but is vague about scope and lacks differentiation from sibling tools like 'tasks_list' or 'tasks_get'. It doesn't specify what makes this search distinct from other task-related 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 'tasks_list' or 'tasks_get'. The description mentions 'specific filters' but doesn't explain what scenarios warrant filtered search over simpler listing operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Create a new call record' implies a write operation but doesn't disclose any behavioral traits such as required permissions, whether the creation is idempotent, what happens on failure, or what the response contains. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence, 'Create a new call record', which is front-loaded and wastes no words. However, this conciseness comes at the cost of completeness, as it lacks necessary details for effective tool use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 severely incomplete. It doesn't cover parameter meanings, behavioral context, usage guidelines, or expected outcomes, making it inadequate for an AI agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description provides no information about the 2 parameters (properties and associations) or their nested structures. It doesn't explain what 'properties' includes (e.g., call details like title, body) or how 'associations' work, failing 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 call record' clearly states the verb ('Create') and resource ('call record'), which is better than a tautology. However, it doesn't differentiate from sibling tools like 'calls_batch_create' or specify what distinguishes a 'call record' from other engagement types in the system, making it 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 like 'calls_batch_create' for multiple records or 'calls_update' for modifications. It doesn't mention prerequisites, dependencies, or typical use cases, leaving the agent with no contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the action ('Search') without mentioning permissions, rate limits, pagination behavior, or what happens when no results are found. For a search tool with complex parameters, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just 5 words, front-loaded with the core action. There's zero wasted language, though this brevity comes at the cost of completeness. Every word earns its place in conveying the basic purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters with nested structures, 0% schema coverage, no annotations, no output schema), the description is completely inadequate. It doesn't explain parameter usage, return values, behavioral constraints, or how this differs from sibling tools. For a search tool with this level of complexity, the description provides minimal useful 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 none of the 5 parameters are documented in the schema. The description mentions 'specific filters' but doesn't explain any parameters like 'filterGroups', 'properties', 'limit', 'after', or 'sorts'. 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 meetings with specific filters' clearly states the verb ('Search') and resource ('meetings'), but it's vague about scope and doesn't distinguish from sibling tools like 'meetings_list' or 'meetings_get'. It lacks specificity about what kind of search this performs compared to alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'meetings_list' or 'meetings_get'. The description mentions 'specific filters' but doesn't explain what scenarios warrant this search tool over simpler listing tools, leaving the agent with no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 but only states the basic action. It does not cover critical aspects like whether this is a read-only operation, potential side effects, authentication needs, rate limits, or pagination behavior, which are essential 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, efficient sentence with no wasted words. It is appropriately sized and front-loaded, though its brevity contributes to inadequacy in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 5 parameters with 0% schema coverage, no annotations, no output schema, and no sibling differentiation, the description is severely incomplete. It does not provide enough information for an agent to understand how to use the tool effectively or what to expect in return.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'specific filters' but does not explain any of the 5 parameters (filterGroups, properties, limit, after, sorts) or their semantics. With 0% schema description coverage, the description fails to compensate, leaving parameters undocumented and unclear in purpose.
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' with minimal elaboration, making it tautological. It specifies the resource ('notes') and action ('search') but lacks detail about what kind of search or what 'specific filters' entail, failing to distinguish it from sibling tools like 'notes_list' or other search 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?
No guidance is provided on when to use this tool versus alternatives. It does not mention sibling tools such as 'notes_list' for unfiltered listing or 'notes_get' for retrieving a single note, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Create' implies a write/mutation operation, but the description doesn't mention permission requirements, whether this is a destructive operation, rate limits, or what happens on success/failure. For a creation tool with 11 parameters and no annotation coverage, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 5 words. It's front-loaded with the essential action and resource. There's no wasted language or unnecessary elaboration, making it efficient for quick understanding of the basic purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 11 parameters (5 required), 0% schema description coverage, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what a company property is, how it's used, what the parameters mean, what the tool returns, or any behavioral considerations. This leaves the agent with insufficient context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 11 parameters have descriptions in the schema. The tool description provides absolutely no information about what the parameters mean, their purposes, or how they should be used. This leaves all parameter semantics undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new company property' clearly states the verb ('Create') and resource ('company property'), but it's somewhat vague about what a 'company property' entails. It distinguishes from sibling tools like crm_create_company or crm_create_contact_property by specifying the resource type, but doesn't explain the functional difference between company properties and other entity 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?
No guidance is provided about when to use this tool versus alternatives. While the name suggests it's for creating company properties specifically, there's no mention of prerequisites, when this operation is appropriate, or how it relates to similar tools like crm_create_contact_property or crm_create_lead_property.
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 'Create a new CRM object' without mentioning permissions required, whether the operation is idempotent, rate limits, error handling, or what happens upon success. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is appropriately sized for its limited content and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 (3 parameters with nested objects, no annotations, no output schema), the description is severely incomplete. It doesn't explain parameter meanings, behavioral traits, return values, or differentiation from siblings, 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%, meaning none of the 3 parameters are documented in the schema. The description adds no information about parameters like 'objectType', 'properties', or 'associations', failing to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb ('Create') and resource ('new CRM object'), which provides a basic understanding of the tool's function. However, it doesn't specify what constitutes a 'CRM object' or differentiate this tool from its many siblings (e.g., crm_create_company, crm_create_contact, crm_create_lead), leaving the purpose somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With numerous sibling tools for creating specific CRM objects (companies, contacts, leads) and batch operations, the description offers no context on appropriate use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description mentions 'optional filtering' but doesn't explain what happens when filters are applied versus omitted, whether results are paginated, what the default sort order is, or what permissions are required. For a list operation with 5 parameters, 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 extremely concise at just 6 words, which is efficient for a basic list operation. It's front-loaded with the core purpose. However, given the complexity (5 parameters, no schema documentation, many sibling tools), this brevity comes at the cost of completeness rather than representing optimal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the context of 5 undocumented parameters, no annotations, no output schema, and numerous sibling tools, the description is inadequate. A list operation with filtering capabilities needs more explanation about what data is returned, how filtering works, pagination behavior, and differentiation from search operations. The current description leaves too many questions unanswered for effective tool selection and use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 5 parameters, the description provides minimal help. It mentions 'optional filtering' which hints at the existence of parameters but doesn't explain what any parameter does, what 'limit' controls, what 'after' means, what 'properties' refers to, what 'associations' includes, or what 'archived' toggles. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all calls with optional filtering' clearly states the verb ('List') and resource ('calls'), which establishes the basic purpose. However, it doesn't specify what constitutes a 'call' in this context or differentiate meaningfully from sibling tools like calls_search or calls_get. The phrase 'optional filtering' is vague about what filtering options exist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools like calls_search, calls_get, and calls_batch_read, the agent receives no indication of when this list operation is appropriate versus when to use search, get single records, or batch operations. There's no mention of prerequisites, typical use cases, 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, the description carries full burden but provides minimal behavioral insight. 'Create' implies a write operation, but it doesn't disclose permissions needed, whether associations are reversible, rate limits, error handling for partial failures, or what the response contains. For a batch mutation tool, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action ('Create multiple associations') and adds useful context ('in a single request'). However, it's overly concise given the tool's complexity, leaving critical gaps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (batch mutation with 3 parameters, nested objects in 'inputs', no output schema, and no annotations), the description is incomplete. It doesn't explain what associations are, how they work, error scenarios, or return values. For a batch create operation in a CRM context, this lacks necessary detail.
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 doesn't explain what 'fromObjectType' and 'toObjectType' enums represent, the structure of 'inputs' array, or the meaning of 'associationCategory' and 'associationTypeId'. The description fails to clarify parameter purposes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Create multiple associations') and scope ('in a single request'), which clarifies the batch nature. However, it doesn't specify what 'associations' are in this CRM context or differentiate from sibling tools like 'crm_create_association' (singular) or 'crm_batch_create_objects' (general 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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., existing objects to associate), compare to 'crm_create_association' for single associations, or specify use cases like bulk linking contacts to companies. The description 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 the full burden of behavioral disclosure. 'Get all properties for leads' implies a read operation, but it doesn't specify whether this requires authentication, has rate limits, returns paginated results, or handles errors. For a tool with zero annotation coverage, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action, making it easy to parse quickly. However, it's arguably too concise given the lack of parameter and usage details, which impacts 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 (2 parameters with 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't explain parameters, return values, or behavioral traits. For a read operation in a CRM context with sibling tools, more detail 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?
The input schema has 2 parameters (archived and properties) with 0% description coverage, meaning the schema provides no semantic information. The description 'Get all properties for leads' doesn't mention these parameters at all, failing to compensate for the schema gap. It doesn't explain what 'archived' filters or what 'properties' array contains, leaving 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 all properties for leads' clearly states the verb ('Get') and resource ('properties for leads'), making the purpose understandable. However, it's somewhat vague about scope ('all' could mean all properties in the system or all properties for specific leads), and it doesn't differentiate from sibling tools like crm_get_lead or crm_get_company_properties. This is adequate but has clear gaps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools for CRM operations (e.g., crm_get_lead, crm_get_company_properties, crm_batch_read_objects), but the description doesn't mention any context, prerequisites, or exclusions. This leaves the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'search' which implies a read-only operation, but does not disclose behavioral traits such as authentication needs, rate limits, pagination behavior (implied by 'limit' and 'after' parameters but not explained), or what happens on errors. The description is minimal and lacks critical operational context for a tool with complex parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a single sentence, front-loaded with the main action. There is no wasted text, but it may be overly terse given the tool's complexity. It efficiently states the tool's function without unnecessary elaboration, though more detail could improve clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, 0% schema coverage, no annotations, no output schema), the description is incomplete. It does not explain the search mechanism, result format, error handling, or how to interpret parameters like 'after' for pagination. For a search tool with nested filtering logic, this minimal description leaves significant gaps in understanding how 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?
Schema description coverage is 0%, so the description must compensate. It mentions 'company-specific filters' which loosely relates to the 'filterGroups' parameter, but does not explain any of the 5 parameters (filterGroups, properties, limit, after, sorts) or their semantics. The description adds minimal value beyond the schema, failing to clarify how filters work or what properties can be used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search companies with company-specific filters' clearly indicates a search operation on companies, but it's vague about what 'company-specific filters' means. It distinguishes from non-company tools but not clearly from sibling tools like crm_search_contacts or crm_search_leads. The purpose is understandable but lacks specificity about the search scope or capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools available (e.g., crm_search_contacts, crm_search_leads, crm_search_objects), the description does not indicate whether this is for company-specific searches only, what contexts it applies in, or any prerequisites. Usage is implied by the name but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'search' which implies a read operation, but doesn't disclose behavioral traits like whether it's paginated, rate-limited, requires authentication, returns partial data, or has performance characteristics. The description adds minimal value beyond the basic operation 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 extremely concise at 5 words with zero waste. It's front-loaded with the core action. However, this conciseness comes at the cost of being under-specified for a tool with 5 parameters and complex filtering capabilities.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 description coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain the complex filtering system, pagination (limit/after), sorting, or what properties can be returned. 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?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions 'contact-specific filters' which hints at the filterGroups parameter, but doesn't explain the 5 parameters (filterGroups, properties, limit, after, sorts) or their semantics. It fails to compensate for the complete lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb ('search') and resource ('contacts'), which provides a basic purpose. However, it's vague about what 'contact-specific filters' means and doesn't distinguish this tool from sibling tools like crm_search_companies or crm_search_leads, which have identical descriptions except for the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention sibling search tools for other resources (companies, leads, objects) or clarify if this is the primary contact search method versus other contact-related tools like crm_get_contact or crm_list_objects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it searches with filters. It doesn't disclose behavioral traits such as whether it's read-only, pagination behavior (implied by 'limit' and 'after' parameters but not explained), rate limits, authentication needs, or what the output looks like. This leaves significant gaps for a search tool with complex parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a simple statement, though it could be more informative. The structure is straightforward but lacks depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, nested objects in schema, no output schema, and no annotations), the description is incomplete. It doesn't explain parameter usage, output format, or behavioral context, making it inadequate for guiding an AI agent effectively with this tool's rich input schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but only mentions 'lead-specific filters' vaguely. It doesn't explain the meaning or usage of any parameters (filterGroups, properties, limit, after, sorts), leaving them undocumented. This fails to add 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 leads with lead-specific filters' states the verb ('search') and resource ('leads'), but it's vague about what 'lead-specific filters' means and doesn't distinguish this tool from sibling search tools like crm_search_companies or crm_search_contacts. It provides basic purpose but lacks specificity about scope or differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like crm_search_objects or crm_get_lead. The description implies it's for searching leads, but there's no mention of prerequisites, limitations, or comparison to other search methods in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Search' implies a read-only operation, but the description doesn't confirm this or mention any side effects, authentication requirements, rate limits, or pagination behavior. It doesn't describe what happens when no results are found or how results are structured. For a complex search tool with 6 parameters, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 5 words, which is efficient. However, this conciseness comes at the cost of completeness - it's arguably under-specified rather than optimally concise. The single sentence is front-loaded with the core purpose but lacks necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex search tool with 6 parameters, 0% schema description coverage, no annotations, and no output schema, the description is severely incomplete. It doesn't explain the search scope, result format, error conditions, or how this differs from sibling search tools. The agent would struggle to use this tool effectively 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 description must compensate for the lack of parameter documentation. The description mentions 'using filters' which only hints at one parameter (filterGroups) out of six. It doesn't explain objectType choices, properties selection, limit constraints, pagination via 'after', or sorting options. The description adds minimal value beyond what's already evident from parameter names 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 the tool searches CRM objects using filters, which is a clear verb+resource combination. However, it doesn't distinguish this from sibling tools like crm_search_companies, crm_search_contacts, and crm_search_leads, which appear to be more specific versions of the same functionality. The purpose is understandable 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 the more specific search tools (crm_search_companies, crm_search_contacts, crm_search_leads) or the broader crm_list_objects. There's no mention of prerequisites, alternatives, or when-not-to-use scenarios. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Create' which implies a write operation, but doesn't address permissions, side effects, error handling, or response format. This is inadequate for a mutation tool with complex parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at 4 words, which is efficient but borders on under-specification. It's front-loaded with the core action but lacks necessary detail. While not wasteful, it sacrifices completeness for 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 creation tool with no annotations, 0% schema description coverage, no output schema, and complex nested parameters, the description is severely incomplete. It doesn't explain what gets created, how to use the parameters, what happens on success/failure, or how this differs from batch operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The tool description doesn't mention any parameters, failing to compensate for the coverage gap. With 2 parameters (properties and associations) that include nested objects and required fields, this leaves the agent guessing about their purpose and usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new email record' clearly states the verb ('Create') and resource ('email record'), but it's generic and doesn't distinguish this from sibling tools like emails_batch_create or emails_update. It provides basic purpose but lacks specificity about what kind of email record or 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 like emails_batch_create or emails_update. The description doesn't mention prerequisites, constraints, or typical use cases, leaving the agent without context for selection among similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get details' which implies a read-only operation, but doesn't specify permissions required, rate limits, error handling, or what the response format looks like (e.g., JSON structure). For a tool with 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence with no wasted words, making it easy to parse. However, it's arguably too concise given the lack of detail needed for a tool with three parameters and no annotations, slightly under-specifying rather than being optimally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, 0% schema coverage, no annotations, no output schema), the description is incomplete. It fails to explain parameter semantics, behavioral traits like error cases or response format, and usage context relative to siblings, making it inadequate for an agent to confidently invoke the tool without additional 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 for undocumented parameters. It mentions 'specific email' which hints at the emailId parameter but doesn't explain its format or source. It doesn't address the properties or associations parameters at all, leaving their purpose and usage unclear despite three total 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 details of a specific email' clearly states the verb ('Get') and resource ('email'), making the basic purpose understandable. However, it lacks specificity about what 'details' entail and doesn't distinguish this tool from potential sibling email tools (like emails_list or emails_search) beyond the 'specific' qualifier, which is somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an email ID), exclusions (e.g., not for bulk operations), or direct comparisons to sibling tools like emails_list or emails_search, 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 the full burden. It mentions 'search' and 'filters' but fails to disclose behavioral traits such as whether this is read-only, requires authentication, has rate limits, returns paginated results, or what happens on errors. For a search tool with complex parameters, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 appropriately sized for a basic statement, though it lacks depth. Every word earns its place, but it's under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't explain the search behavior, return format, error handling, or parameter usage, leaving the agent with insufficient information to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description only vaguely mentions 'specific filters' without explaining the 5 parameters (filterGroups, properties, limit, after, sorts) or their semantics. It adds minimal value beyond the schema, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search emails with specific filters' clearly states the verb ('Search') and resource ('emails'), but it's vague about what 'specific filters' entails. It doesn't distinguish this tool from sibling email tools like emails_list or other search tools (e.g., calls_search, meetings_search), missing specificity about filtering capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like emails_list or other search tools (e.g., calls_search). The description implies filtering but doesn't specify use cases, prerequisites, or exclusions, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states it 'creates' without disclosing behavioral traits. It doesn't mention permissions needed, whether creation is idempotent, error handling, or what happens on success (e.g., returns an ID). For a mutation tool with complex inputs, this lack of transparency 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 a single, efficient sentence with no wasted words. It's front-loaded with the core action, though it could be more informative. The brevity is appropriate but borders on under-specification 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 (3 parameters with nested objects, no output schema, no annotations), the description is incomplete. It doesn't address what an 'engagement' is, how to use the input fields, or what to expect after creation. For a create operation with rich 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 but adds no parameter information. It doesn't explain what 'engagement', 'associations', or 'metadata' mean, their required fields, or how to structure them. With 3 parameters and nested objects, this leaves the agent guessing about input semantics.
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 verb ('create') and resource ('engagement'), but is vague about what 'engagement' means or what 'details' encompass. It doesn't distinguish from sibling tools like 'engagement_details_update' or 'calls_create', leaving the agent to infer the specific purpose from the name alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 agent must deduce from sibling names (e.g., 'engagement_details_update' for updates, 'calls_create' for call-specific creations) without explicit direction. There's no mention of prerequisites, constraints, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation ('Get'), but doesn't specify permissions, rate limits, pagination behavior (despite 'limit' and 'offset' parameters), or what 'engagements' include. This leaves significant gaps in understanding how the tool behaves beyond basic retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it appropriately concise. However, it lacks front-loading of critical details (e.g., parameter context), which slightly reduces its effectiveness despite the 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 (7 parameters, 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't explain what 'engagements' are, how filtering works with parameters like 'activityTypes', or the return format, leaving the agent under-informed for proper tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only mentions 'an object' (hinting at 'objectType' and 'objectId'), but doesn't explain the other 5 parameters like 'startTime', 'endTime', 'activityTypes', 'limit', or 'offset'. This fails to add meaningful semantics beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all engagements associated with an object' clearly states the verb ('Get') and resource ('engagements associated with an object'), providing a basic purpose. However, it doesn't specify what 'engagements' entail (e.g., calls, emails, tasks) or differentiate from sibling tools like 'engagement_details_get' or 'engagement_details_list', making it somewhat vague and lacking sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, exclusions, or compare it to sibling tools such as 'engagement_details_get' or 'engagement_details_list', leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 multiple meetings') without mentioning permissions required, rate limits, error handling, whether it's idempotent, or what the response 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 is 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.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (batch creation with nested objects), lack of annotations, 0% schema description coverage, and no output schema, the description is severely incomplete. It fails to explain behavioral traits, parameter meanings, or expected outcomes, making it inadequate 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning the input schema provides no descriptions for parameters. The tool description adds no information about the 'inputs' parameter, its structure, or the meaning of nested fields like 'properties' and 'associations'. This leaves all parameter semantics undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create multiple meetings') and the scope ('in a single request'), which is specific and distinguishes it from the sibling 'meetings_create' tool that likely creates single meetings. However, it doesn't explicitly mention the resource type (e.g., HubSpot meetings) or differentiate from other batch create tools like 'calls_batch_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 'meetings_create' for single meetings or other batch operations. It lacks context about prerequisites, limitations, or typical use cases, 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 the full burden of behavioral disclosure. 'Get' implies a read-only operation, but the description doesn't specify authentication needs, rate limits, error conditions, or what the return format looks like (e.g., JSON structure). It lacks details on behavioral traits 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, making it appropriately concise. However, it's under-specified rather than optimally structured—it could benefit from front-loading more critical information like parameter requirements or usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the parameters, return values, or behavioral aspects like error handling. For a read operation with multiple optional parameters, this leaves significant gaps for an AI agent to understand how 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?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'specific meeting' which hints at the 'meetingId' parameter, but it doesn't explain the 'properties' or 'associations' parameters at all. It adds minimal value beyond what's inferred from the schema, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific meeting' clearly states the verb ('Get') and resource ('meeting'), but it's vague about what 'details' entails and doesn't distinguish this tool from sibling tools like 'meetings_list' or 'meetings_search'. It provides a basic purpose but lacks specificity about scope or differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing a meetingId), exclusions, or comparisons to sibling tools like 'meetings_list' for multiple meetings or 'meetings_search' for filtered queries. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'List all meetings' implies a read operation, it doesn't specify whether this requires authentication, has rate limits, returns paginated results, or what happens when no meetings exist. The description lacks crucial behavioral context 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise at 6 words, front-loading the core purpose. However, it could be more structured by explicitly mentioning key parameters or distinguishing from siblings, though it avoids unnecessary 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 tool with 5 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain parameter usage, return format, error conditions, or how it differs from similar tools. 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 for all 5 parameters, the description must compensate but fails to do so. 'Optional filtering' vaguely references parameters but doesn't explain what 'after', 'limit', 'createdAfter', 'createdBefore', or 'properties' mean or how they work. The description adds minimal value beyond what the bare schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/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'), making the basic purpose understandable. However, it doesn't differentiate from sibling tools like 'meetings_search' or 'meetings_get', leaving ambiguity about when to use this specific listing tool versus search or retrieval 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. With sibling tools like 'meetings_search' and 'meetings_get' available, the agent receives no indication whether this is for bulk listing, filtered listing, or basic retrieval. The mention of 'optional filtering' is too vague to serve as meaningful usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get' implies a read-only operation, it doesn't specify authentication requirements, rate limits, error conditions, or what happens if the taskId doesn't exist. For a tool with 3 parameters and no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence with no wasted words. It's front-loaded with the core action ('Get details'), making it easy to parse. However, it could be more informative without sacrificing brevity, such as by hinting at 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 (3 parameters, 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't explain the purpose of optional parameters, expected return values, or behavioral constraints. For a tool that retrieves data with configurable options, this leaves 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%, meaning none of the 3 parameters (taskId, properties, associations) are documented in the schema. The description mentions 'details' but doesn't explain what parameters control this—for example, that 'properties' might filter returned fields or 'associations' might include related data. It adds minimal value beyond the schema's structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific task' clearly states the verb ('Get') and resource ('task'), making the purpose understandable. However, it's somewhat vague about what 'details' entail and doesn't distinguish this tool from potential siblings like 'tasks_list' or 'tasks_search' that might also retrieve task information. It's adequate but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. Given the sibling tools include 'tasks_list', 'tasks_search', and 'tasks_get', there's no indication that this tool is specifically for retrieving a single task by ID while others might handle bulk operations or filtering. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'specific filters' but doesn't disclose behavioral traits like whether this is a read-only operation, if it requires authentication, rate limits, pagination behavior (implied by 'limit' and 'after' parameters but not explained), or what the output looks like. For a search tool with complex parameters, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single phrase, front-loaded and zero waste. However, this conciseness comes at the cost of under-specification, but the dimension scores efficiency alone.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 objects, 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't explain parameter usage, behavioral context, or output format, making it inadequate for an AI agent to use this tool effectively 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 description must compensate. It only vaguely mentions 'specific filters', which partially relates to 'filterGroups' but doesn't explain any of the 5 parameters (filterGroups, properties, limit, after, sorts) or their purposes. 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.
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' states the basic action (search) and resource (calls), but it's vague about scope and doesn't distinguish from sibling tools like 'calls_list' or 'calls_get'. It lacks specificity about what kind of search this is (e.g., full-text, filtered listing) compared to alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'calls_list' (which might list all calls without filters) or 'calls_get' (which retrieves a single call). The description implies filtering but doesn't specify use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Update', implying a mutation operation, but fails to disclose critical traits such as required permissions, whether changes are reversible, error handling, 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 front-loaded with the core action and resource, making it easy to parse quickly, though this brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters with nested objects, 0% schema coverage, no annotations, and no output schema), the description is incomplete. It doesn't explain the tool's behavior, parameter meanings, or output, leaving the agent poorly equipped to use it correctly in context 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?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It adds no meaning beyond the schema, failing to clarify what 'contactId', 'subscriptionId', or 'preferences' represent, their formats, or how they interrelate. With 3 parameters and nested objects, 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 'Update communication preferences for a contact' clearly states the verb ('Update') and resource ('communication preferences for a contact'), but it's somewhat vague about what 'communication preferences' entails. It doesn't distinguish this tool from sibling tools like 'communications_update_subscription_status' or 'communications_subscribe_contact', leaving ambiguity about their specific differences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 siblings like 'communications_update_subscription_status' and 'communications_get_preferences', the description lacks any indication of prerequisites, context, or exclusions, 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?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Create' implies a write/mutation operation, but the description doesn't mention permission requirements, whether associations are reversible, rate limits, error conditions, or what happens on success. For a mutation tool with 5 required parameters, this leaves critical behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise - a single sentence with zero wasted words. It's front-loaded with the core purpose. While it's under-specified, what's there is structurally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 5 required parameters (including complex enums and nested objects), no annotations, and no output schema, the description is severely incomplete. It doesn't explain what an 'association' means, doesn't document parameters, doesn't describe behavioral constraints, and provides no usage context. The agent would struggle to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description adds no parameter information whatsoever - it doesn't explain what 'fromObjectType'/'toObjectType' mean, what valid object IDs look like, or how associationTypes work. For 5 required parameters with complex enums and nested objects, this is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create an association between two objects' clearly states the action (create) and resource (association), but it's vague about what an 'association' means in this CRM context. It doesn't distinguish this tool from sibling tools like crm_batch_create_associations or crm_get_associations beyond the basic verb difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when to choose batch operations (crm_batch_create_associations), or how this differs from related tools like crm_list_association_types. Usage context is entirely implied 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 the full burden of behavioral disclosure. It states 'Get all properties for contacts' but doesn't clarify if this is a read-only operation, what permissions are required, whether it returns archived contacts, how results are formatted, or if there are rate limits. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action ('Get all properties for contacts'), making it immediately clear. Every word earns its place, and there's no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the tool's behavior, parameter usage, or return format. For a tool that likely returns structured data about contact properties, more context is needed to guide the agent effectively, especially with no output schema to clarify results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters (archived, properties) with 0% schema description coverage, meaning the schema provides no documentation. The description 'Get all properties for contacts' doesn't mention these parameters at all, failing to compensate for the coverage gap. It doesn't explain what 'archived' filters or what 'properties' array contains, 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 'Get all properties for contacts' clearly states the verb ('Get') and resource ('properties for contacts'), making the purpose immediately understandable. It distinguishes itself from sibling tools like crm_get_contact (which retrieves contact data) and crm_get_company_properties (which targets companies). However, it doesn't specify whether 'all' means all properties across all contacts or for specific contacts, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like crm_get_contact (for contact details) or crm_get_company_properties (for company properties), nor does it specify prerequisites or contexts for usage. 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 for behavioral disclosure. 'Update an existing CRM object' implies a mutation operation but reveals nothing about required permissions, whether the update is partial or complete, validation rules, error conditions, rate limits, or what happens to unspecified properties. For a mutation tool with zero annotation coverage, this leaves critical behavioral aspects undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately front-loaded with the core action and resource. While it lacks necessary detail, what's present is structured concisely 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?
For a mutation tool with 3 required parameters, 0% schema description coverage, no annotations, and no output schema, the description is severely incomplete. It doesn't explain what CRM objects are, what fields can be updated, how updates are processed, what permissions are needed, or what the tool returns. The agent would struggle to use this tool correctly without significant trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for completely undocumented parameters. The description mentions 'CRM object' which loosely relates to the objectType parameter but provides no explanation of what objectType values mean, what objectId format is expected, or what the properties object should contain. With 3 required parameters and no schema descriptions, the description adds minimal semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing CRM object' clearly states the action (update) and resource (CRM object), which is better than a tautology. However, it doesn't specify what constitutes a 'CRM object' or differentiate this tool from its many sibling tools like crm_update_company, crm_update_contact, crm_update_lead, or crm_batch_update_objects. The purpose is understandable but lacks specificity in this crowded namespace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 for updating specific object types (companies, contacts, leads) and batch operations, the agent receives no help in selecting this generic update tool over more specialized ones. There's no mention of prerequisites, constraints, or comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the basic action ('List all emails') without mentioning pagination behavior (though 'limit' and 'after' parameters suggest it), rate limits, authentication requirements, or what happens when no filters are applied. The description doesn't contradict annotations since none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 6 words, front-loading the core purpose. There's no wasted language or unnecessary elaboration, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the return format, pagination behavior, error conditions, or how filtering parameters work. The agent would struggle to use this tool effectively based solely on the description.
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 provides minimal help. It mentions 'optional filtering' which hints at some parameters, but doesn't explain what the 5 specific parameters (limit, after, properties, associations, archived) do or how they relate to filtering. The description doesn't compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all emails with optional filtering' clearly states the verb ('List') and resource ('emails'), but it's vague about scope and doesn't differentiate from sibling tools like emails_search. It doesn't specify whether this lists ALL emails in the system or just those accessible to the current user/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 about when to use this tool versus alternatives like emails_search. The description mentions 'optional filtering' but doesn't explain what filtering capabilities exist or how they compare to the search functionality in emails_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it's an update operation. It doesn't disclose whether this requires specific permissions, whether changes are reversible, what happens to unspecified properties, or what the response looks like. For a 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 extremely concise at just 5 words. It's front-loaded with the core action and contains no unnecessary words. While it may be too brief for completeness, 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 mutation tool with 2 parameters (one being a complex nested object), 0% schema description coverage, no annotations, and no output schema, the description is severely inadequate. It doesn't explain what properties can be updated, what the update operation entails, or what to expect as a result. The agent would struggle to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but provides no parameter information. The description doesn't mention the required emailId parameter or the complex properties object with its many sub-properties. This leaves the agent with no semantic understanding of what parameters are needed beyond what's in the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing email record' clearly states the verb ('Update') and resource ('email record'), but it's quite generic and doesn't differentiate from sibling tools like emails_batch_update or emails_create. It specifies 'existing' which distinguishes from create operations, but lacks specificity about what aspects can be updated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like emails_batch_update, emails_create, or emails_archive. There's no mention of prerequisites, constraints, or typical use cases. 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 for behavioral disclosure. It states 'Update' implying a mutation, but doesn't mention permissions required, whether changes are reversible, rate limits, or what happens to unspecified properties. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is 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?
For a mutation tool with 2 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It fails to address behavioral traits, parameter meanings, or usage context, leaving significant gaps for an AI agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain that 'meetingId' identifies the meeting to update or that 'properties' contains fields like title, body, location, times, outcome, and owner. This leaves both 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 'Update an existing meeting' clearly states the verb (update) and resource (meeting), but it's vague about what specific aspects can be updated. It doesn't differentiate from sibling tools like 'meetings_batch_update' or 'meetings_create', which is a significant gap given the 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 like 'meetings_batch_update' for multiple updates or 'meetings_create' for new meetings. The description lacks context about prerequisites, such as needing an existing meeting ID, which 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?
No annotations are provided, so the description carries the full burden. It states 'Read' which implies a safe operation, but doesn't disclose behavioral traits such as authentication needs, rate limits, error handling, or what happens if the ID is invalid. The description is minimal and lacks necessary context for a tool with 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 with zero waste. It's front-loaded and appropriately sized for its content, though it's under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain the return values, parameter usage, or behavioral context needed for a read operation in a complex CRM-like system with many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'ID' which maps to 'productId', but doesn't explain the 'properties' or 'associations' parameters. The description adds minimal meaning beyond the schema, failing to clarify what these arrays do or how they affect the read operation.
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' states the verb ('Read') and resource ('Object'), but it's vague about what type of object (product) and doesn't distinguish from sibling tools like 'products_get' or 'crm_get_object'. It avoids tautology by not just repeating the name 'products_read', 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 'crm_get_object'. The description implies usage for reading a single product by ID, but offers no 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 for behavioral disclosure. 'Create a new task' implies a write/mutation operation, but it doesn't mention required permissions, whether creation is idempotent, rate limits, or what happens on success/failure. For a mutation 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 extremely concise at just three words. While this brevity comes at the cost of completeness, there's no wasted language or unnecessary elaboration—every word directly contributes to stating the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with complex nested parameters (2 top-level, 1 required), 0% schema description coverage, no output schema, and no annotations, the description is severely inadequate. It doesn't explain what the tool returns, what parameters mean, or behavioral aspects like error handling, making it incomplete 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%, meaning parameter documentation relies entirely on the description. The description mentions no parameters at all, despite the schema having 2 top-level parameters ('properties' and 'associations') with complex nested structures. This fails to compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new task' clearly states the verb ('Create') and resource ('task'), which is better than a tautology. However, it doesn't distinguish this tool from sibling tools like 'tasks_batch_create' or other creation tools in the server, nor does it specify what kind of task system this is for (e.g., CRM 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?
No guidance is provided about when to use this tool versus alternatives like 'tasks_batch_create' for multiple tasks or other task-related tools. The description offers no context about prerequisites, limitations, or appropriate scenarios for this single-task creation tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Create' implies a write operation, but it doesn't specify permissions required, whether it's idempotent, error handling, or what 'validated' means in practice. The mention of 'validated properties' hints at input validation but lacks detail, leaving 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.
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 basic tool definition, though it could be more informative without sacrificing 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 creation tool with no annotations, no output schema, and complex nested parameters, the description is inadequate. It doesn't explain the return value, error conditions, or the meaning of 'associations' parameter, leaving the agent poorly equipped to use this tool effectively in a CRM context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'validated properties' but doesn't explain what properties are available or their semantics. With 0% schema description coverage and 2 parameters (one required), the schema provides structure but no descriptions. The tool's purpose suggests 'properties' includes fields like email or name, but the description fails to clarify this, 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 action ('Create') and resource ('new lead'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'crm_create_contact' or 'crm_create_company', which follow the same pattern for different CRM objects, so it doesn't fully distinguish from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'crm_batch_create_leads' or 'crm_create_contact'. It mentions 'validated properties' but doesn't explain what validation entails or any prerequisites for usage, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 a mutation, but it doesn't disclose permissions needed, whether changes are reversible, rate limits, or error handling. The mention of 'validated properties' hints at input validation but lacks specifics, leaving critical behavioral traits undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/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 fluff. However, it could be more front-loaded with critical details like usage context, but it earns high 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 parameters, no annotations, no output schema), the description is inadequate. It doesn't cover behavioral aspects, parameter details, or output expectations, leaving significant gaps for an agent to safely invoke this tool in a CRM context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
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 updatable, their formats, or constraints beyond the schema. With 2 parameters (leadId and a nested properties object), the description adds little semantic value, leaving the agent reliant solely on the raw 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 target ('an existing lead'), which is specific and distinguishes it from creation tools like 'crm_create_lead'. However, it doesn't explicitly differentiate from other update tools like 'crm_batch_update_leads' or 'crm_update_contact', 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 updates or other CRM update tools. It mentions 'validated properties' but doesn't explain what validation entails or when it applies, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
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 is idempotent, what permissions are required, how failures are handled in batch, rate limits, or what the response contains. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for what it communicates, though it communicates very little beyond the basic purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex batch creation tool with no annotations, 0% schema description coverage, and no output schema, the description is severely incomplete. It doesn't explain the parameter structure, return values, error behavior, or usage context, 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 complex nested schema (with properties like 'hs_note_body', 'hs_timestamp', 'hubspot_owner_id', and 'associations') is completely undocumented in the description, leaving the agent with no semantic understanding beyond raw schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create multiple notes') and scope ('in a single request'), which is specific and actionable. However, it doesn't differentiate from sibling tools like 'notes_create' or 'notes_batch_update', missing explicit sibling distinction that would warrant a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'notes_create' for single notes or other batch operations. There's no mention of prerequisites, performance considerations, or error handling 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 this is 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 crucial operational context for a batch read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the main purpose. However, the second sentence is somewhat redundant, reiterating the idProperty usage without adding new information. Overall, it's efficient but could be more structured to clarify 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, 0% schema coverage, no annotations, no output schema), the description is incomplete. It fails to explain the purpose of most parameters, doesn't describe the return format, and omits behavioral details. For a batch operation with multiple inputs, this leaves 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. It only mentions the 'idProperty' parameter, explaining it's for 'retrieving records by a custom unique value property.' The other three parameters (propertiesWithHistory, productIds, properties) are undocumented in both schema and description, leaving their purpose and usage unclear. 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 tool's purpose: 'Read a batch of products by internal ID, or unique property values.' This specifies the verb ('Read'), resource ('products'), and scope ('batch'), and distinguishes 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 based on criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions retrieving by 'internal ID' or 'unique property values' but doesn't compare to products_read (single product), products_list (all products), or products_search (filtered search). There's no mention of prerequisites, constraints, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'update' implying a mutation, but doesn't address permissions, side effects, error handling, or response format. This is inadequate for a mutation tool with zero annotation coverage, as critical behavioral traits 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 and appropriately sized for the tool's purpose, 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 (mutation tool with nested parameters), lack of annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't cover behavioral aspects, parameter meanings, or 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%, so the schema provides no parameter descriptions. The description doesn't add any parameter details beyond the schema's structure, failing to explain what 'taskId' or 'properties' entail. However, with only 2 parameters and a nested object, the baseline is 3 as the schema defines types and enums, but the description adds no value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing task' clearly states the verb ('update') and resource ('task'), but it's vague about what aspects can be updated and doesn't differentiate from sibling tools like 'tasks_batch_update' or 'tasks_update' (if present elsewhere). It's functional 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_batch_update' or 'tasks_create'. The description doesn't mention prerequisites, such as needing an existing task ID, or context for updates, leaving the agent to infer usage from the 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. It states it's a creation operation but doesn't disclose behavioral traits like required permissions, 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 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 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?
Given the complexity (batch creation with nested objects), lack of annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't address return values, error cases, or provide enough context for safe and effective use of this mutation 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. It mentions 'multiple call records' but provides no details about the 'inputs' parameter structure, required fields, or the nested properties and associations. The description adds minimal value beyond the schema, failing to explain parameter meaning or 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 verb ('Create') and resource ('multiple call records'), specifying it's a batch operation ('in a single request'). It distinguishes from the singular 'calls_create' sibling by emphasizing 'multiple' and 'batch', but doesn't explicitly contrast with other batch operations like 'calls_batch_update' 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 on when to use this tool versus alternatives is provided. The description doesn't mention prerequisites, error handling, or compare it to the singular 'calls_create' or other batch operations like 'calls_batch_update'. It lacks context for choosing this tool 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 this is a read operation, which implies non-destructive behavior, but doesn't disclose important behavioral traits like authentication requirements, rate limits, error handling for invalid IDs, or whether it returns partial results on failures. The description is minimal and lacks 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 that front-loads the core purpose without any wasted words. Every word earns its place by conveying the essential batch read concept.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch read tool with 1 parameter (a complex array structure), 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what data is returned, how to interpret the 'properties' and 'associations' arrays, or any prerequisites for successful execution. The context demands more completeness.
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' which hints at the 'inputs' array parameter, but provides no details about what 'id', 'properties', or 'associations' mean, their formats, or how they affect the read operation. The description adds minimal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read') and resource ('multiple call records') with the efficiency benefit of 'in a single request'. It distinguishes from individual read tools like 'calls_get' by emphasizing batch capability, but doesn't explicitly differentiate from other batch operations like 'calls_batch_archive'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'calls_get' for single records or 'calls_list' for listing all calls. The description implies batch efficiency but doesn't specify thresholds or scenarios where batch reading is preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Get details' implies a read-only operation, it doesn't specify whether this requires authentication, has rate limits, returns structured data, or handles errors. For a tool with 3 parameters and no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 6 words, front-loading the core purpose with zero wasted words. Every word earns its place, making it easy to parse quickly while still communicating the essential action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is insufficiently complete. 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 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?
With 0% schema description coverage for all 3 parameters, the description provides no information about what callId, properties, or associations mean or how they should be used. The description doesn't compensate for this gap at all - it doesn't mention parameters, their purposes, or provide examples. This is inadequate for a tool with multiple 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 'Get details of a specific call' clearly states the verb ('Get') and resource ('a specific call'), making the purpose immediately understandable. It distinguishes from siblings like calls_list (which lists multiple calls) and calls_update (which modifies calls). However, it doesn't specify what kind of details are retrieved or the scope of information returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like calls_list (for multiple calls), calls_search (for filtered searches), or calls_batch_read (for batch operations). There's no mention of 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 critical behavioral aspects like required permissions, whether partial updates are allowed, what happens to unspecified properties, error conditions, or rate limits. For a mutation tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 5 words, with no wasted language. It's front-loaded with the essential 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 mutation tool with no annotations, 0% schema description coverage, no output schema, and complex nested parameters, the description is inadequate. It doesn't explain parameter usage, behavioral constraints, return values, or differentiation from sibling tools. The description fails to compensate for the lack of structured documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning parameters are undocumented in the schema. The description mentions no parameters at all, failing to explain that 'callId' identifies which call to update and 'properties' contains the fields to modify. For a tool with 2 parameters (one being a complex nested object with 9 sub-properties), this is a substantial 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 action ('Update') and resource ('an existing call record'), which is specific and unambiguous. However, it doesn't differentiate this tool from sibling tools like 'calls_batch_update' or 'emails_update', which would require mentioning it's for single call updates specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'calls_batch_update' for multiple calls and 'calls_create' for new calls, there's no indication of when this single-update tool is appropriate versus batch operations or other update tools in the system.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
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, error conditions, or what format the preferences data will be returned in. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a simple retrieval tool and front-loads the essential information about what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters (one required), 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'communication preferences' includes, how results are structured, or provide any context about the subscriptionId parameter. The description leaves too many gaps given the tool's complexity and lack of supporting 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 both parameters (contactId and subscriptionId), the description provides no information about what these parameters mean, their format, or how they affect the query. The description mentions 'contact' which aligns with contactId, but doesn't explain subscriptionId at all. This fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and target resource ('communication preferences for a contact'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'communications_get_subscription_status' or 'communications_get_subscription_definitions', but it's specific enough to understand what data will be retrieved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'communications_get_subscription_status' or 'communications_update_preferences'. There's no mention of prerequisites, context, or relationships with sibling tools, leaving the agent to infer usage patterns from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states what the tool does ('Get subscription status') without mentioning any behavioral traits like whether it's a read-only operation, what permissions are needed, how it handles errors, rate limits, or what format the status information returns. This leaves significant gaps for an agent trying to use it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions 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 tool with two parameters and follows good front-loading principles by immediately stating 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 2 required parameters, 0% schema description coverage, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what the subscription status includes, what the return format looks like, or provide enough parameter context. Given the complexity of subscription systems and the complete lack of structured documentation, this description leaves too many unanswered questions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning neither parameter has any documentation in the schema. The description mentions 'multiple contacts' which hints at the 'contactIds' parameter being an array, but doesn't explain what 'subscriptionId' represents, what format contact IDs should be in, or any constraints on the array size. This minimal information doesn't adequately 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 ('Get subscription status') and target ('for multiple contacts'), providing a specific verb+resource combination. However, it doesn't 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?
The description provides no guidance on when to use this tool versus alternatives. There are related sibling tools like 'communications_get_preferences' and 'communications_update_subscription_status', but the description doesn't mention any context, prerequisites, or exclusions for using this specific tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose if this is a mutation (likely yes), permission requirements, side effects (e.g., email notifications), rate limits, or error conditions. For a tool that modifies subscription states, this lack of transparency is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action and efficiently communicates the basic purpose without unnecessary elaboration, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters (0% schema coverage), no annotations, and no output schema, the description is incomplete. It lacks details on behavior, parameters, return values, and error handling. While concise, it doesn't provide enough context for reliable agent use given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'contactId' refers to, the meaning of 'portalSubscriptionLegalBasis' enum values, or when 'portalSubscriptionLegalBasisExplanation' is needed. With 3 parameters entirely undocumented, the description fails to provide necessary semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Subscribe') and resource ('a contact to all email communications'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'communications_unsubscribe_contact' or 'communications_update_preferences', which would require a more specific comparison to achieve a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., contact must exist), exclusions, or how it relates to sibling tools like 'communications_update_preferences' or 'communications_unsubscribe_contact', 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 full burden but only states the action without behavioral details. It doesn't disclose whether this is a destructive/irreversible operation, what permissions are required, whether it affects historical data, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core functionality without unnecessary words. It's appropriately sized for a tool with a clear primary action, though this conciseness comes at the expense of missing important contextual information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters (including complex enums), no annotations, and no output schema, the description is severely incomplete. It doesn't address behavioral implications, parameter meanings, success/failure outcomes, or differentiation from sibling tools, leaving critical gaps for proper tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but provides no parameter information. It doesn't explain what 'contactId' represents, when the legal basis parameters are required, or what the enum values mean. With 3 parameters (one with complex enum) completely undocumented, the description adds no 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 ('Unsubscribe') and resource ('a contact from all email communications'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'communications_update_subscription_status' or 'communications_update_preferences' which might handle similar subscription modifications, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'communications_update_subscription_status' and 'communications_update_preferences' available, there's no indication whether this tool is for bulk unsubscriptions, irreversible actions, or specific use cases, leaving the agent without contextual 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. 'Update' implies a mutation operation, but the description doesn't specify whether this requires special permissions, whether changes are reversible, what happens to contacts not in the updates array, or any rate limits. It mentions 'multiple contacts' which hints at batch capability, but lacks details about batch size limits or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a tool with a clear primary function, though the brevity comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch mutation tool with 2 parameters (one being a complex array of objects), 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens after the update, what errors might occur, or provide any context about the subscription system. 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 'subscription status for multiple contacts' which hints at the purpose of the updates array, but doesn't explain what subscriptionId represents, what the status enum values mean, or the significance of legalBasis fields. It fails to compensate for the complete lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('subscription status for multiple contacts'), making the purpose immediately understandable. It distinguishes from sibling tools like communications_subscribe_contact and communications_unsubscribe_contact by specifying batch updates rather than single-contact operations. However, it doesn't explicitly mention what system or context these subscriptions belong to.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like communications_subscribe_contact or communications_unsubscribe_contact. It doesn't mention prerequisites, constraints, or typical use cases. The agent must infer usage from the name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'archive (delete)', implying a destructive mutation, but doesn't clarify if this is reversible, requires specific permissions, or has side effects like cascading deletions. More context on the operation's impact is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and resource without unnecessary words. It's appropriately sized 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?
For a destructive mutation tool with 4 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It lacks details on behavior, parameters, and usage context, leaving significant gaps for an AI agent to understand and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'fromObjectType', 'toObjectType', or their IDs represent, leaving all 4 parameters undocumented beyond the schema's basic types and enums.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('archive/delete') and resource ('association between two objects'), making the purpose evident. However, it doesn't differentiate from sibling tools like 'crm_batch_archive_associations' or 'crm_archive_object', which handle batch operations or different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'crm_batch_archive_associations' for multiple associations or 'crm_archive_object' for archiving objects themselves. The description 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 full burden but only states the action ('Archive (delete)') without behavioral details. It doesn't clarify if archiving is permanent or reversible, what permissions are needed, rate limits, or error handling for partial failures in batch operations, leaving significant gaps for a destructive 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, front-loading the core action and scope. Every word earns its place, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive batch tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It lacks details on parameters, behavioral traits, error handling, and output expectations, making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'fromObjectType', 'toObjectType', or 'inputs' represent, their enum values, or how to structure the 'inputs' array for batch processing, failing to bridge the documentation gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Archive (delete) multiple associations') and resource ('associations') with the scope 'in a single request', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'crm_archive_association' (singular) or 'crm_batch_archive_objects', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, compare with 'crm_archive_association' for single deletions, or specify scenarios where batch archiving is preferred over individual 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. It states the tool archives/deletes multiple objects, implying a destructive mutation, but lacks critical details: whether archiving is reversible, what permissions are required, if there are rate limits, or how errors are handled for partial failures in batch operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and scope. There's no wasted verbiage, making it easy to parse quickly while conveying the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive batch operation with no annotations, 0% schema coverage, and no output schema, the description is insufficient. It misses critical context: behavioral traits (e.g., irreversibility, error handling), parameter details, and expected outcomes, leaving the agent under-informed about risks and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'objectType' values mean (e.g., the difference between 'companies' and 'custom'), what format 'objectIds' should be in, or constraints like maximum batch size. 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 action ('Archive (delete)') and target ('multiple CRM objects in a single request'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'crm_archive_object' (singular) or 'crm_batch_archive_associations' (different resource type), which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing object IDs), compare it to single-object archiving tools, or specify use cases for batch operations versus individual deletions.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 batch creation operation. It doesn't disclose critical behavioral traits like whether this requires specific permissions, rate limits, whether it's idempotent, what happens on partial failures, or what the response format looks like.
Agents need to know what a tool does to the world before calling it. Descriptions 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 any wasted words. It's appropriately sized for what it does convey, though it's under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch creation tool with complex nested parameters (17+ properties per company plus associations), no annotations, and no output schema, the description is severely incomplete. It doesn't address error handling, response format, limitations, or provide any context about the CRM system it operates on.
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 company properties, or the meaning of associations. The single undocumented parameter remains completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('multiple companies'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'crm_create_company' or 'crm_batch_create_contacts', 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 single-company creation or batch creation of other entities. There's no mention of prerequisites, performance considerations, or error handling for bulk operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a creation operation but doesn't disclose behavioral traits like whether it's idempotent, what permissions are required, how failures are handled in batch, rate limits, or what the response looks like. This is inadequate for a mutation tool with complex inputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's appropriately sized and front-loaded, efficiently conveying the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (1 parameter with deeply nested structure, 0% schema coverage, no output schema, no annotations), the description is severely incomplete. It doesn't explain the input format, output, error handling, or behavioral context needed for a batch 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 'multiple contacts' which hints at an array input, but provides no details about the structure, required fields, or semantics of the 'inputs' parameter and its nested properties/associations. 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 multiple contacts') and the resource ('contacts'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'crm_create_contact' or 'crm_batch_create_companies' beyond the obvious 'contacts' vs 'companies' difference, missing explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'crm_create_contact' (single contact creation) or other batch tools. It lacks context about prerequisites, performance considerations, or error handling for batch operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it's a creation operation. It doesn't disclose critical behavioral aspects: whether this requires specific permissions, rate limits, error handling for partial failures, what happens on duplicate data, or response format. 'Create' implies mutation but lacks safety/performance context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with zero waste. Every word earns its place: 'Create' (verb), 'multiple' (batch scope), 'CRM objects' (resource), 'in a single request' (operational context). Front-loaded and efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch creation tool with 2 parameters (one complex array), 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the multi-object creation process, parameter requirements, error scenarios, or what constitutes valid CRM objects. 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.
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 mean, the structure of 'inputs' array, or the purpose of 'properties' and 'associations' fields. The description fails to provide any semantic context beyond the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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'), specifying it's a batch operation ('in a single request'). It distinguishes from single-create tools like crm_create_object, but doesn't explicitly differentiate from other batch create tools like crm_batch_create_companies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like crm_batch_create_companies/contacts/leads or crm_create_object. The description implies batch creation but doesn't specify scenarios where batch creation is preferred over individual creation or when to use type-specific batch tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Update' implies a mutation operation, the description doesn't address critical behavioral aspects: whether this requires specific permissions, if updates are atomic or partial, what happens on partial failures, rate limits, or what the response contains. For a batch mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise - a single sentence that communicates the core functionality without any wasted words. It's appropriately sized for what it does convey, though the brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch mutation tool with complex nested parameters (array of objects with required fields), no annotations, no output schema, and 0% schema description coverage, the description is severely inadequate. It doesn't explain the parameter structure, behavioral characteristics, error handling, or expected outcomes. The agent lacks sufficient 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?
The schema has 0% description coverage, so the description must compensate but fails to do so. It mentions 'multiple companies' but provides no information about the required 'inputs' parameter structure, what 'id' represents, what 'properties' can contain, or the meaning of specific fields like 'lifecyclestage'. The agent must rely entirely on the raw schema without semantic guidance.
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 companies'), making the purpose immediately understandable. It distinguishes from single-company update tools by specifying 'multiple companies in a single request', though it doesn't explicitly differentiate from other batch update tools like crm_batch_update_contacts or crm_batch_update_leads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when batch updates are preferable to individual updates, or how it differs from other batch update tools for different CRM objects (contacts, leads, objects). The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Create' implies a write operation, but there's no information about required permissions, whether validation is strict or permissive, what happens on duplicate companies, or what the response contains. The mention of 'validated properties' hints at some validation but doesn't specify what validation occurs or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 6 words, front-loading the essential purpose without any wasted words. Every word earns its place, though this conciseness comes at the cost of completeness for such a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex creation tool with 2 parameters (one being a deeply nested object), 0% schema description coverage, no annotations, and no output schema, the description is severely inadequate. It doesn't explain the parameter structure, expected return values, error conditions, or behavioral constraints that would help an agent use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for its 2 parameters (properties and associations), and the description provides no parameter information beyond 'validated properties.' The complex nested structure with 16+ property fields and association objects remains completely undocumented in the description, leaving the agent with no semantic understanding of what data to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new company'), making the purpose immediately understandable. It distinguishes from other CRM tools by focusing specifically on company creation rather than contacts, leads, or other objects. However, it doesn't explicitly differentiate from batch creation alternatives like 'crm_batch_create_companies'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools for company operations (crm_batch_create_companies, crm_update_company, crm_search_companies), but the description offers no context about single vs batch creation, prerequisites, 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'validated properties' hinting at input validation, but doesn't describe what happens on success/failure, required permissions, rate limits, or whether the operation is idempotent. For a mutation tool with complex parameters, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a tool with a clear primary function, though the brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex mutation tool with 2 parameters (one nested), 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the return value, error handling, or the meaning of 'associations', leaving significant gaps for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 'validated properties' without explaining what properties are available, what 'associations' means, or the structure of nested objects. The description adds minimal value beyond the schema's field names.
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 contact with validated properties' clearly states the action (create) and resource (contact), distinguishing it from sibling tools like crm_update_contact or crm_batch_create_contacts. However, it doesn't explicitly differentiate from other creation tools (e.g., crm_create_company) beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like crm_batch_create_contacts or crm_create_object. The description implies it's for creating single contacts, but lacks explicit context about prerequisites, dependencies, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Create' implies a write/mutation operation, but the description doesn't mention permissions required, whether this operation is idempotent, rate limits, or what happens on success/failure. For a creation tool with 11 parameters and no 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 maximally concise - a single sentence with no wasted words. It's front-loaded with the core action and resource. 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?
Given the complexity (11 parameters, 5 required, creation operation), lack of annotations, and no output schema, the description is insufficient. It doesn't explain what a 'contact property' is in this CRM context, doesn't cover parameter meanings, and provides no behavioral context. 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?
The schema has 0% description coverage, meaning none of the 11 parameters have explanations in the schema. The description adds no parameter information beyond what's implied by the tool name. It doesn't explain what 'contact property' means, what the required parameters represent, or how parameters like 'type' and 'fieldType' differ. This is inadequate for a complex tool with many parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('new contact property'), making the purpose immediately understandable. It distinguishes this tool from sibling tools like crm_create_contact or crm_create_company_property by specifying it's for contact properties specifically. However, it doesn't explicitly differentiate from crm_create_lead_property or crm_create_company_property 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. There's no mention of prerequisites, when this should be used instead of batch operations (like crm_batch_create_objects), or how it relates to other property management tools (like crm_get_contact_properties). 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 a read operation ('Get'). It doesn't disclose behavioral traits like pagination (implied by 'after' and 'limit' parameters), authentication needs, rate limits, error conditions, or what 'associations' entail in the response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it easy to parse. It's front-loaded with the core action, though this brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters (3 required), 0% schema coverage, no annotations, and no output schema, the description is incomplete. It lacks details on usage, parameters, behavior, and output, making it inadequate for an AI agent to reliably invoke the tool 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 but adds no parameter details. It mentions 'specific type' and 'between objects', which loosely map to 'fromObjectType' and 'toObjectType', but doesn't explain the enum values, required 'fromObjectId', or optional pagination parameters, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('associations of a specific type between objects'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'crm_list_association_types' or 'crm_get_object', which could cause confusion about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'crm_list_association_types' or 'crm_get_object'. The description implies a specific use case but doesn't clarify prerequisites, exclusions, 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?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Get' implies a read operation, but the description doesn't address whether this requires authentication, what format the properties are returned in, whether there are rate limits, or if this retrieves property definitions versus property values. For a tool with 2 parameters and no annotation coverage, 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 maximally concise - a single 5-word sentence that states the core purpose without any fluff. It's front-loaded with the essential information, though this brevity comes at the cost of completeness. Every word earns its place in conveying the basic operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters with 0% schema coverage, no annotations, no output schema), the description is inadequate. It doesn't explain what 'properties' means in this context (definitions vs values), doesn't address the parameters, doesn't describe the return format, and doesn't differentiate from sibling tools. For a tool that likely returns structured metadata, this leaves too many open questions for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate but fails to do so. It mentions 'all properties' but doesn't explain the 'archived' boolean parameter or the 'properties' array parameter. The agent cannot understand what these parameters control - whether 'archived' filters companies or properties, or what strings go in the 'properties' array. This leaves both parameters semantically ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all properties for companies' clearly states the verb ('Get') and resource ('properties for companies'), making the purpose immediately understandable. However, it doesn't distinguish this from sibling tools like 'crm_get_company' or 'crm_get_contact_properties' - it's clear what it does but not how it differs from related read operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple CRM read operations available (crm_get_company, crm_get_contact_properties, crm_get_lead_properties, crm_list_objects, etc.), there's no indication whether this retrieves metadata about company property definitions versus actual company property values, or when filtering via the 'archived' or 'properties' parameters is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get' implies a read operation, the description doesn't address important behavioral aspects like authentication requirements, rate limits, error conditions, response format, or whether this is a safe operation. For a tool with 4 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 7 words, front-loading the core purpose without any wasted words. Every word serves a clear purpose in communicating the tool's basic function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It provides only the most basic purpose statement without addressing parameter meanings, behavioral characteristics, or output expectations. The context demands much 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?
With 0% schema description coverage and 4 parameters, the description provides no information about any parameters. It mentions 'by ID' which relates to objectId, but doesn't explain objectType, properties, or associations 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.
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 CRM object by ID'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like crm_get_company, crm_get_contact, or crm_get_lead, which appear to be more specific versions of this generic 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. With many sibling tools available (including specific object-type getters like crm_get_company and batch operations), the description offers no context about when this generic getter is preferable or when other tools should be used instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 'optional filtering and pagination', which hints at read-only behavior, but doesn't clarify if this is a safe read operation, what permissions are needed, or how pagination works (e.g., cursor-based with 'after'). For a list tool with 5 parameters, this is insufficient detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('List CRM objects of a specific type') and adds key features ('with optional filtering and pagination'). There's no wasted wording, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavioral traits, parameter meanings, and output format, which are crucial for an agent to use this tool effectively. 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.
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 all parameters. It only vaguely references 'optional filtering and pagination', without explaining what 'objectType' entails, what 'properties' array does, or how 'archived' affects results. This adds minimal value beyond the bare schema, failing to adequately document the 5 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('CRM objects of a specific type'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'crm_list_association_types' or 'crm_search_objects', which might have overlapping functionality, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'optional filtering and pagination' but provides no explicit guidance on when to use this tool versus alternatives like 'crm_search_objects' or 'crm_batch_read_objects'. There's no mention of prerequisites, exclusions, or specific use cases, leaving the agent with minimal direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions 'validated properties' hinting at input validation, but doesn't disclose mutation effects, permission requirements, error handling, or response format. For a mutation tool, this leaves critical behavioral traits unclear.
Agents need to know what a tool does to the world before calling it. Descriptions 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 an existing company') and adds a qualifying detail ('with validated properties') that adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 2 parameters (including a nested object), 0% schema description coverage, no annotations, and no output schema, the description is insufficient. It doesn't explain the update process, what 'validated' entails, potential side effects, 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.
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 only vaguely references 'validated properties' without explaining what properties are updatable, their formats, or constraints. It fails to compensate for the schema's lack of descriptions, 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 ('an existing company'), making the purpose evident. It distinguishes from sibling tools like crm_create_company by specifying 'existing', but doesn't explicitly differentiate from other update tools like crm_update_contact 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 companyId), compare to batch updates (crm_batch_update_companies), or specify scenarios where this tool is preferred 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 states this is a creation operation but provides no information about permissions required, rate limits, whether emails are actually sent or just stored, what happens on partial failures, or what the response contains. For a mutation tool with complex nested parameters, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core functionality without waste. It's appropriately sized for a tool name that already indicates 'batch_create' functionality, though this conciseness comes at the expense of providing necessary context for proper usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 (including required fields, enums, and associations), no annotations, and no output schema, the description is severely inadequate. It doesn't explain what 'email records' mean in this context, whether this sends emails or just creates records, what validation occurs, or what the response looks like. The agent lacks critical 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?
The input schema has 0% description coverage, meaning all 1 parameter and its complex nested structure are undocumented in the schema. The description mentions 'multiple email records' which hints at the array structure, but provides no details about what constitutes a valid email record, required fields, or the associations parameter. 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.
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 it's a batch operation ('in a single request'). It distinguishes from the singular 'emails_create' sibling tool by emphasizing the batch nature, though it doesn't explicitly contrast with other email batch operations like 'emails_batch_read' or 'emails_batch_update'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when batch creation is preferable to individual creation, what prerequisites might exist, or how it relates to other email tools like 'emails_batch_read' or 'emails_batch_update'. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it's a read operation. It doesn't disclose behavioral traits like whether it's idempotent, rate limits, authentication requirements, error handling for partial failures, or what happens with invalid IDs. 'Read' implies non-destructive, but explicit confirmation would help.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and doesn't include unnecessary details. Every word earns its place in conveying the basic 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 read tool with 1 parameter (a complex nested array), 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the input structure, return format, error behavior, or practical usage context. The agent would struggle to use this 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 description must compensate but provides no parameter information. It doesn't explain what 'inputs' contains, the purpose of 'id', 'properties', or 'associations' arrays, or how to structure the batch request. The single sentence adds no 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 ('Read') and resource ('multiple email records'), and specifies the operation scope ('in a single request'). It distinguishes from individual email reads (like emails_get) but doesn't explicitly differentiate from other batch operations like emails_batch_archive or emails_batch_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like emails_get (for single emails) or emails_list (for listing/filtering). It doesn't mention performance considerations, prerequisites, or limitations compared to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's an update operation but doesn't disclose behavioral traits like required permissions, whether it's idempotent, rate limits, error handling for partial failures, or what happens to unspecified properties. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the core action, zero waste. Every word earns its place by conveying the batch update nature efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch mutation tool with 1 parameter (complex nested array), 0% schema description coverage, no annotations, and no output schema, the description is incomplete. It lacks details on input structure, behavioral expectations, error handling, and output format, 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 email records' which hints at the 'inputs' array parameter, but doesn't explain the structure (id + properties), required fields, or the meaning of properties like hs_email_status enums. 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 ('Update') and resource ('multiple email records'), and specifies it's a batch operation ('in a single request'). It distinguishes from non-batch tools but doesn't explicitly differentiate from other email batch operations like emails_batch_create or emails_batch_archive among the siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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_update (single update) or emails_batch_create (batch creation). The description implies batch updating but doesn't specify prerequisites, constraints, or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it's a list operation with filtering. It doesn't disclose important behavioral traits like whether this is a read-only operation, pagination behavior (implied by limit/offset but not explained), rate limits, authentication requirements, or what happens when no filters are applied. The description is insufficient for a tool with 5 parameters and no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. There's no wasted language or unnecessary elaboration - every word serves the purpose of describing the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain return values, error conditions, or provide enough context for an agent to use this tool effectively compared to sibling engagement tools. The minimal description leaves too many 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%, so the description must compensate but only mentions 'optional filtering' generically. It doesn't explain what the 5 parameters do, how they interact, or provide examples of valid values (e.g., what format for startTime/endTime, what activityTypes are available). The description adds minimal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('engagements') with scope ('all'), providing a specific purpose. However, it doesn't distinguish this tool from sibling tools like 'engagement_details_get' or 'engagement_details_get_associated', 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 mentions 'optional filtering' but provides no guidance on when to use this tool versus alternatives like 'engagement_details_get' (for single engagement) or 'engagement_details_get_associated' (for related engagements). There's no context about prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Update' implies a mutation operation, but the description doesn't specify required permissions, whether changes are reversible, rate limits, error conditions, or what happens to unspecified fields. It lacks critical context for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a basic tool description and front-loads 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 3 parameters, 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain parameter requirements, behavioral implications, or what to expect from the operation. The context demands more comprehensive documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, meaning all 3 parameters are undocumented in the schema. The description mentions 'engagement's details' but doesn't explain what parameters are needed (engagementId, engagement object, metadata) or what fields within engagement can be updated. It fails to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('an existing engagement's details'), making the purpose unambiguous. However, it doesn't distinguish this tool from sibling tools like 'calls_update', 'meetings_update', or 'engagement_details_create', which all involve modifying engagement-related 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. There's no mention of prerequisites (e.g., needing an engagement ID), when not to use it (e.g., for creating new engagements), or how it differs from sibling update tools like 'calls_update' or 'engagement_details_create'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Update' implies mutation, but the description doesn't specify permissions required, whether updates are partial or complete, error handling for invalid inputs, or response format. It mentions 'multiple meetings' but doesn't clarify limits or atomicity of the 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 zero wasted words. It's front-loaded with the core action ('Update multiple meetings') and adds clarifying context ('in a single request'). Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the complex nested parameter structure, behavioral expectations, or return values. The agent lacks critical context about how to use this tool effectively and what to expect from it.
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 required 'id' and 'properties' fields, or the specific properties that can be updated (like hs_meeting_title, hs_meeting_outcome). The agent must rely entirely on the schema without descriptive guidance.
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 meetings'), and specifies it's a batch operation ('in a single request'). However, it doesn't explicitly distinguish this from sibling tools like 'meetings_update' (single meeting update) or 'meetings_batch_create' (batch creation), though the 'batch' prefix provides some implicit 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. It doesn't mention prerequisites (e.g., needing meeting IDs), compare it to single-meeting updates, or indicate appropriate scenarios for batch operations versus individual updates. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Read' implies a non-destructive operation, it doesn't specify whether this requires authentication, rate limits, error handling for invalid IDs, or the response format. For a batch operation with no annotation coverage, this leaves critical behavioral traits undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action ('Read multiple notes') and adds necessary context ('in a single request'). Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 array parameters), lack of annotations, 0% schema description coverage, and no output schema, the description is incomplete. It doesn't address parameter semantics, behavioral traits like error handling, or what the tool returns, leaving significant gaps for an agent 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 parameters are undocumented in the schema. The description mentions 'multiple notes' but doesn't explain the 'inputs' parameter structure, the required 'id' field, optional 'properties' and 'associations' arrays, or their purposes. This fails to compensate for the schema gap, leaving parameter meaning 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 ('Read') and resource ('multiple notes'), making the purpose immediately understandable. It distinguishes itself from single-note operations like 'notes_get' by specifying batch processing. However, it doesn't explicitly differentiate from other batch read tools for different resources (e.g., 'calls_batch_read', 'emails_batch_read'), which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when batch reading is preferable to individual reads (e.g., for efficiency with multiple notes), nor does it reference sibling tools like 'notes_get' for single notes or 'notes_list' for listing all notes. Without this context, an agent might misuse the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 details' implies a read-only operation, but the description doesn't specify authentication requirements, rate limits, error handling (e.g., what happens if noteId is invalid), or whether it returns partial data if properties/associations are omitted. For a tool with three parameters and no 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, front-loaded sentence that directly states the tool's purpose without unnecessary words. Every part ('Get details of a specific note') earns its place by conveying the core action and target. There's no redundancy or fluff, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, 0% schema coverage, no annotations, no output schema), the description is inadequate. It doesn't explain the return format, how optional parameters modify the response, or error conditions. For a tool that retrieves structured data with filtering options, more context is needed to use it effectively without trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the three parameters (noteId, properties, associations) are documented in the schema. The description only implies noteId is needed ('specific note') but doesn't explain what properties or associations are, their formats, or how they affect the output. It adds minimal value beyond the schema, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('details of a specific note'), making the purpose immediately understandable. It distinguishes this from sibling tools like notes_list or notes_search by specifying retrieval of a single note's details rather than listing or searching. However, it doesn't explicitly contrast with notes_batch_read, which might also retrieve note details in bulk.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 prefer notes_list for browsing or notes_search for filtering, or when notes_batch_read might be more efficient for multiple notes. The agent must infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a list operation but doesn't disclose behavioral traits like pagination behavior (implied by 'after' parameter), rate limits, authentication requirements, or what 'all notes' means in terms of access permissions. The description is minimal and lacks important 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 that gets straight to the point. There's no wasted language or unnecessary elaboration - it's appropriately sized for a basic list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the filtering parameters, return format, pagination approach, or operational constraints. The agent would struggle to use this tool effectively without trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'optional filtering' but doesn't explain what parameters are available or their purposes. The 5 parameters (limit, after, properties, associations, archived) are completely undocumented in both schema and description, leaving the agent guessing about their meanings and usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '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 distinguish 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?
No guidance on when to use this tool versus alternatives like notes_search, notes_get, or notes_batch_read. The description mentions 'optional filtering' but doesn't specify what types of filtering are available or when filtering should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a mutation operation ('Update') but doesn't disclose whether this requires specific permissions, what happens to unspecified properties, if changes are reversible, or any rate limits. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that directly states the action. There's no wasted verbiage, making it front-loaded and efficient, 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 mutation tool with 2 parameters (including a nested object), 0% schema description coverage, no annotations, and no output schema, the description is severely incomplete. It lacks essential details about behavior, parameters, and usage context that an agent would need to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter details. It doesn't explain what 'noteId' refers to, what 'properties' contains (e.g., hs_note_body for content), or their formats. The description fails to provide meaningful context beyond what the bare schema structure implies.
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 note'), making the purpose immediately understandable. It doesn't specifically differentiate from sibling tools like 'notes_batch_update' or 'notes_create', but the core action is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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_batch_update' for multiple notes or 'notes_create' for new notes. It also doesn't mention prerequisites such as needing an existing note ID or appropriate permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose whether this is a write operation (implied but not explicit), what permissions are needed, whether it's idempotent, rate limits, error handling, or what happens on partial failures. For a batch creation 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 maximally concise with just four words that directly convey the core function. Every word earns its place, and there's no unnecessary elaboration or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch creation tool with complex nested parameters (0% schema coverage), no annotations, and no output schema, the description is inadequate. It doesn't explain the mutation nature, required fields, validation rules, response format, or error conditions. The agent would struggle to use this tool correctly without significant trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but provides no parameter information. The single 'inputs' parameter and its complex nested structure (array of objects with properties like name, price, sku) are completely undocumented in the description. The description doesn't explain what constitutes a valid product batch or format requirements.
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 ('batch of products'), making the purpose immediately understandable. It distinguishes from sibling 'products_create' by specifying batch operation, though it doesn't explicitly contrast with other batch operations like 'products_batch_update' or 'products_batch_archive'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'products_create' (single creation) or other batch operations. The description doesn't mention 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an update operation (implying mutation) but doesn't mention permissions required, whether updates are atomic/partial, error handling for invalid batches, rate limits, or what the response contains. This is a significant gap for a batch mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for what it covers and front-loads the core action ('Update a batch of products').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 doesn't address behavioral aspects (permissions, atomicity, errors), parameter details beyond a brief mention of 'idProperty', or what to expect in return. The context signals indicate high complexity that isn't adequately covered.
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 'idProperty' but doesn't explain its relationship to the 'id' field in the schema or what 'unique values' means. It doesn't describe the 'inputs' array structure, required 'properties' object, or any of the nested property fields (name, price, etc.). The description adds minimal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('batch of products'), and specifies the identification method ('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', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'products_update' (single update) or 'products_batch_create'. It mentions the 'idProperty' parameter but doesn't explain when to use internal ID versus custom ID property, or any prerequisites for batch operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool archives/deletes multiple tasks, implying a destructive mutation, but lacks details on permissions needed, whether deletion is reversible, rate limits, error handling for invalid IDs, or what the response contains. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive batch operation with no annotations, no output schema, and 0% schema description coverage, the description is insufficient. It lacks critical details like behavioral traits (e.g., irreversibility), parameter semantics, and response format, leaving significant gaps for an AI agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'multiple tasks' which hints at the 'taskIds' array parameter, but doesn't explain the format of task IDs, constraints (e.g., maximum array size), or provide examples. This adds minimal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Archive (delete) multiple tasks') and resource ('tasks'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'tasks_archive' (single task) or 'tasks_batch_update', 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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, limitations, or compare it to sibling tools like 'tasks_archive' (for single tasks) or other batch operations, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a creation operation, implying it's a write/mutation tool, but doesn't disclose behavioral traits like required permissions, whether it's idempotent, error handling for partial failures, rate limits, or what the response contains. The description is minimal and lacks crucial 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 extremely concise with just one sentence and zero wasted words. It's front-loaded with the core purpose. However, this conciseness comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (1 parameter with deeply nested schema, no annotations, no output schema), the description is inadequate. It doesn't explain the input structure, expected behavior, error conditions, or return values. For a batch creation tool with significant schema complexity, this leaves too many 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?
Schema description coverage is 0%, so the description must compensate. It mentions 'multiple tasks' but provides no information about the 'inputs' parameter structure, required fields, or semantics of nested properties like 'hs_task_body', 'hs_task_subject', or 'associations'. The description adds almost no value beyond what's inferred from the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('create multiple tasks') and resource ('tasks'), and specifies it's done 'in a single request', which distinguishes it from single-task creation tools. However, it doesn't explicitly differentiate from sibling batch tools like 'tasks_batch_update' or 'tasks_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 'tasks_create' (for single tasks) or other batch operations. It doesn't mention 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 'Read multiple tasks' which implies a read-only operation, but doesn't disclose behavioral traits like whether it requires authentication, rate limits, error handling for invalid IDs, or if it returns partial results. This leaves significant gaps for a 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 purpose ('Read multiple tasks') and efficiently adds 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?
Given no annotations, 0% schema description coverage, no output schema, and a complex input schema with nested objects, the description is incomplete. It doesn't explain how to use the parameters, what the tool returns, or behavioral aspects like error handling, 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. It mentions 'multiple tasks' but doesn't explain the input structure (e.g., that 'inputs' is an array of objects with 'id', 'properties', and 'associations'). Without this, users might not understand how to format requests, leading to potential errors.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read multiple tasks') and scope ('in a single request'), which is specific and distinguishes it from single-read tools like tasks_get. However, it doesn't explicitly differentiate from other batch read tools for different resources (e.g., notes_batch_read), though the name implies the resource is 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?
No explicit guidance on when to use this tool versus alternatives like tasks_get (for single tasks) or tasks_list (for listing tasks). The description implies batch reading but doesn't specify scenarios where batch reading is preferable, such as 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 the full burden of behavioral disclosure. 'Update multiple tasks' implies a write/mutation operation, but the description doesn't mention permissions required, whether updates are atomic/partial, error handling for failed updates, rate limits, or what the response contains. For a batch mutation 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 extremely concise at just 7 words, with zero wasted language. It's front-loaded with the core action ('Update multiple tasks') and adds only necessary qualification ('in a single request'). Every word earns its place in this minimal description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch mutation tool with 1 parameter (but complex nested structure), 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the request format, response format, error conditions, or operational constraints. The agent would struggle to use this tool correctly without additional context beyond what's provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the input schema has no descriptions for its parameters. The tool description doesn't explain what the 'inputs' array should contain, the structure of task objects, or the meaning of properties like 'hs_task_priority' or 'hs_task_status'. While the schema defines the structure, the description adds no semantic context to help an agent understand how to construct valid requests.
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. However, it doesn't distinguish this tool from its sibling 'tasks_update' (single task update) or other batch operations like 'tasks_batch_create' and 'tasks_batch_read', which would require explicit differentiation for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when batch updates are preferred over single updates (tasks_update), nor does it reference related batch operations like tasks_batch_create or tasks_batch_read. There's no information about prerequisites, constraints, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'List all tasks' implies a read operation, but doesn't disclose pagination behavior (implied by 'limit' and 'after' parameters), rate limits, authentication requirements, or what happens when no tasks exist. 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 just 6 words, front-loaded with the core purpose. Every word earns its place - 'List' (action), 'all tasks' (resource and scope), 'with optional filtering' (key capability). No wasted words or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the filtering parameters, return format, pagination approach, or behavioral constraints. The agent would struggle to use this tool effectively without significant trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 5 parameters, the description provides minimal help. 'Optional filtering' vaguely references the parameters but doesn't explain what 'limit', 'after', 'properties', 'associations', or 'archived' actually do or how they affect the listing. The description doesn't compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all tasks with optional filtering' clearly states the verb ('List') and resource ('tasks'), and specifies scope ('all') with optional filtering. It distinguishes from sibling tools like tasks_get (single task) and tasks_search (search with criteria), but doesn't explicitly differentiate from tasks_batch_read 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?
The description provides no guidance on when to use this tool versus alternatives like tasks_search or tasks_batch_read. It mentions 'optional filtering' but doesn't specify what types of filtering are available or when filtering would be appropriate versus using a different tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 mutation, it doesn't disclose critical behavioral traits: whether archiving is permanent or reversible, what permissions are required, whether it affects associated data, or what the response looks like. For a destructive operation with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single, front-loaded sentence with zero wasted words. Every element ('archive', 'delete', 'call record') earns its place by clarifying the tool's purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is insufficiently complete. It should address behavioral implications (permanence, permissions, side effects) and provide at least minimal parameter guidance. The current description leaves too many critical questions unanswered for safe agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It doesn't mention the 'callId' parameter at all, leaving the single required parameter completely undocumented. However, with only one parameter and the tool name implying its purpose, the baseline is 3 - the description doesn't add value beyond what's inferable from context, but doesn't actively mislead either.
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'), providing specific verb+resource information. However, it doesn't explicitly distinguish this from sibling tools like 'calls_batch_archive' or 'calls_delete' (if present), which would require a 5. The parenthetical '(delete)' adds useful clarification about the nature of archiving.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'calls_batch_archive' (for multiple calls) and 'calls_update' (for modification rather than deletion), the agent needs explicit guidance about single-record archival versus batch operations, but none is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool archives (deletes) multiple call records, indicating a destructive mutation, but lacks critical details: whether deletions are permanent or reversible, required permissions, rate limits, error handling for partial failures, or what the response looks like. This is inadequate for a batch deletion tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and resource without any wasted words. It directly communicates the tool's function in a compact form, 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 deletion tool with no annotations, 0% schema description coverage, and no output schema, the description is insufficient. It lacks details on behavioral traits (e.g., permanence, permissions), parameter semantics (e.g., ID formats), and expected outcomes, leaving the agent poorly equipped to use it correctly 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?
The schema description coverage is 0%, so the description must compensate. It implies the parameter 'callIds' is an array of call records to archive, which adds basic meaning beyond the schema's type definition. However, it doesn't specify format constraints (e.g., ID structure), size limits, or validation rules, leaving gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Archive (delete)') and resource ('multiple call records') with the operational context ('in a single request'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from its sibling 'calls_archive' beyond implying batch capability, which is somewhat inferred but not directly stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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_archive' for single deletions or other batch operations. It mentions 'multiple call records' but doesn't specify thresholds, prerequisites, or error handling for batch operations, leaving the agent without contextual usage rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'update' implying mutation but doesn't disclose behavioral traits like required permissions, whether updates are partial or full, error handling for invalid inputs, or rate limits. This is a significant gap for a batch mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized for its 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 (batch update with nested objects), lack of annotations, and no output schema, the description is inadequate. It doesn't explain what happens on success/failure, return values, or constraints, leaving critical gaps for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond the input schema, which has 0% description coverage. However, the schema is detailed with nested properties and enums, providing structure. The description doesn't compensate for the coverage gap, but the schema's clarity gives a baseline 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 ('Update multiple call records') and scope ('in a single request'), which is specific and distinguishes it from singular update tools like 'calls_update'. However, it doesn't explicitly differentiate from other batch operations like 'calls_batch_create' or 'calls_batch_archive' beyond the verb 'update'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'calls_update' for single updates or 'calls_batch_create' for creating new records. The description only states what it does, not when it's appropriate or any 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 'Get' operation which implies read-only behavior, but doesn't specify whether it returns all definitions at once, supports pagination, requires authentication, has rate limits, or what format the return data takes. The description is minimal and lacks important 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 that states exactly what the tool does without unnecessary 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, no output schema, and minimal parameter documentation, the description is insufficient. It doesn't explain what 'subscription definitions' contain, how results are structured, whether there are access restrictions, or what happens when the 'archived' parameter is used. The context signals indicate significant gaps 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 1 parameter with 0% description coverage. The tool description mentions 'all subscription definitions' but doesn't explain the optional 'archived' parameter's purpose or how it affects results. Since schema coverage is low, the description should compensate but doesn't provide any parameter-specific information beyond the general scope.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get all') and resource ('subscription definitions for the portal'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'communications_get_subscription_status' or 'communications_get_preferences', but the specificity of 'definitions' vs 'status' or 'preferences' provides some implicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'communications_get_subscription_status' and 'communications_get_preferences' available, there's no indication whether this tool should be used for retrieving metadata/configuration versus current state or user settings.
Agents often have multiple tools that could apply. Explicit usage guidance like "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)' clearly indicates a destructive operation, the description doesn't specify whether this is reversible, what permissions are required, whether there are rate limits, or what happens to associated data. For a destructive tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, with zero wasted language. It's front-loaded with the core action and resource, making it immediately scannable and understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description is inadequate. It doesn't explain what 'archive' means operationally (soft delete vs. hard delete), whether the action is reversible, what permissions are needed, or what the response contains. The description fails to provide the 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?
The description mentions 'a CRM object' which implies both objectType and objectId parameters are needed, but adds no specific semantic information beyond what the schema provides. With 0% schema description coverage, the description doesn't compensate by explaining what 'objectType' values mean or how 'objectId' should be formatted. The baseline is 3 since the description at least implies the parameters exist.
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. However, it doesn't differentiate this tool from sibling tools like 'crm_batch_archive_objects' or other archive tools for specific object types, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools including batch archive operations and archive tools for specific object types, there's no indication of when this single-object archive is preferred over batch operations or when to use object-specific archive tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a write operation ('create') but doesn't disclose critical traits like permissions required, whether it's idempotent, error handling for partial failures, rate limits, or what the response contains. For a batch mutation tool, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for the tool's purpose, 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 write operation), lack of annotations, and no output schema, the description is incomplete. It fails to address behavioral aspects, usage context, or response format, leaving the agent under-informed 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'multiple leads' but doesn't explain the parameter structure. The input schema has 1 parameter (inputs) with 0% description coverage, and the description adds no details about the array format, required fields, or the nested properties/associations. However, since the schema is detailed (showing lead properties and associations), the baseline of 3 is appropriate as the schema does the heavy lifting, though the description adds no value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create multiple leads in a single request' clearly states the action (create) and resource (leads), with the batch aspect distinguishing it from single-create tools like crm_create_lead. However, it doesn't explicitly differentiate from other batch create tools (e.g., crm_batch_create_companies, crm_batch_create_contacts), 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. The description doesn't mention prerequisites, limitations (e.g., rate limits, batch size), or comparisons to single-create (crm_create_lead) or other batch operations. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states it's an update operation. It lacks critical behavioral details: whether it's idempotent, permission requirements, rate limits, error handling for partial failures, or what the response contains. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core action and efficiently conveys the batch nature, 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 mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is insufficient. It misses behavioral context, parameter guidance, and output expectations, leaving significant gaps for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description doesn't add parameter details beyond implying an array of contacts. It doesn't explain the 'inputs' structure, required 'id' and 'properties', or the nested property fields. The schema provides full structure, so baseline 3 applies, but the description adds minimal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('multiple contacts'), specifying it's a batch operation ('in a single request'). It distinguishes from single-contact updates like 'crm_update_contact' but doesn't explicitly differentiate from other batch tools like 'crm_batch_update_companies' or 'crm_batch_update_leads'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. It doesn't mention prerequisites, limitations, or compare with single-contact updates or other batch operations, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's an update operation but lacks critical behavioral details: whether it requires specific permissions, if updates are partial or full, error handling for invalid inputs, rate limits, or what the response contains. 'Update' implies mutation, but without safety or outcome context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with a single, clear sentence that front-loads the core purpose. No wasted words or redundant information, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Incomplete for a mutation tool with no annotations and no output schema. The description lacks details on behavioral traits, error handling, response format, and usage context. Given the complexity (batch update with nested properties) and absence of structured data, it should provide more guidance to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds minimal value beyond the schema. It hints at 'multiple leads' and 'single request,' aligning with the 'inputs' array parameter, but doesn't explain parameter structure (e.g., that 'inputs' contains objects with 'id' and 'properties') or provide examples. Baseline is 3 due to low coverage, but description compensation is weak.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update multiple leads') and resource ('leads'), specifying it's a batch operation ('in a single request'). It distinguishes from single-update tools like 'crm_update_lead' but doesn't explicitly differentiate from other batch tools like 'crm_batch_update_companies' or 'crm_batch_update_contacts'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing lead IDs), compare to single-update tools, or specify use cases like bulk edits. The agent must infer usage from the name and context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it's an update operation but doesn't mention critical aspects like whether it's idempotent, requires specific permissions, has rate limits, returns partial successes, or what happens on errors. For a batch mutation tool, this lack of behavioral context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core action, making it easy to parse quickly, 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 mutation with 2 parameters, no annotations, no output schema, and 0% schema description coverage), the description is inadequate. It doesn't explain the object types, input structure, behavioral traits, or output, leaving significant gaps for an AI agent to use it correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The tool description 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' (id and properties). It adds minimal value beyond the schema's structural definition, meeting the baseline for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('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 handle specific object types, whereas this tool supports multiple types via an enum parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 batch updates (e.g., crm_batch_update_companies, crm_batch_update_contacts), there's no indication that this tool is more generic or when to prefer it over type-specific batch updates, nor any prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a read operation ('Get'), which implies it's non-destructive, but doesn't mention authentication requirements, rate limits, error handling, or response format. For a tool with 3 parameters and no annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core functionality without unnecessary words. It's appropriately sized for a simple retrieval tool, though it could be slightly more structured by separating the core purpose from parameter 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 tool with 3 parameters, 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what data is returned, how to interpret the properties/associations arrays, or provide any error handling context. The description should do more to compensate for the lack of structured documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'by ID with specific properties and associations,' which hints at the purpose of the companyId, properties, and associations parameters. However, with 0% schema description coverage, it doesn't explain what format companyId should be, what properties are available, or what 'associations' means in practice. The description adds some semantic value but doesn't fully compensate for the schema coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('a single company by ID'), making the purpose understandable. It also specifies 'with specific properties and associations' which adds detail about what data is retrieved. However, it doesn't explicitly differentiate from sibling tools like crm_get_object or crm_search_companies, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like crm_get_object, crm_search_companies, or crm_batch_read_objects. It doesn't mention prerequisites, error conditions, or typical use cases, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get' implies a read-only operation, the description doesn't clarify authentication requirements, rate limits, error conditions, or what happens if the contact ID doesn't exist. For a retrieval tool with zero annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core functionality without unnecessary words. It's appropriately front-loaded with the main action ('Get a single contact by ID'). While it could potentially be more structured with separate usage notes, it earns high marks for brevity and clarity within its compact form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters (one required), 0% schema description coverage, no annotations, and no output schema, the description is insufficient. It doesn't explain the return format, error handling, or provide enough detail about the parameters to compensate for the missing structured documentation. The agent would struggle to use this tool effectively 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?
Schema description coverage is 0%, meaning none of the parameters have descriptions in the schema. The description mentions 'by ID with specific properties and associations', which hints at the purpose of contactId, properties, and associations parameters. However, it doesn't explain what properties are available, how associations work, or provide examples. This adds some semantic value but doesn't fully compensate for the complete lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'a single contact by ID', making the purpose specific. It also mentions 'with specific properties and associations' which adds detail about what data is retrieved. However, it doesn't explicitly differentiate from sibling tools like crm_get_object or crm_search_contacts, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools like crm_get_object (generic retrieval), crm_search_contacts (filtered search), and crm_list_objects (bulk retrieval), the agent receives no help in selecting this specific contact retrieval tool. The description is purely functional 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 the tool retrieves data ('Get'), implying it's a read operation, but doesn't clarify if it's safe (non-destructive), what happens if the lead ID doesn't exist, whether there are rate limits, or what the output format looks like. For a read tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get a single lead by ID') and adds necessary qualifiers ('with specific properties and associations'). There's no wasted language or redundancy, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't explain what 'properties' and 'associations' mean in practice, what values they accept, or what the tool returns. For a tool that retrieves data with filtering options, 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'by ID with specific properties and associations', which maps to the three parameters (leadId, properties, associations). However, with 0% schema description coverage, the schema provides no details about parameter meanings. The description adds some value by hinting at what properties and associations are for, but doesn't fully compensate for the complete lack of schema documentation, resulting in a baseline 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 ('a single lead by ID') with additional scope ('with specific properties and associations'). It distinguishes from sibling tools like crm_list_objects or crm_search_leads by specifying retrieval of a single lead rather than listing or searching. However, it doesn't explicitly differentiate from crm_get_object which might also retrieve leads, making it slightly less specific than a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use crm_get_lead versus crm_get_object or crm_search_leads, nor does it specify prerequisites like authentication or permissions. The agent must infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'update' and 'validated properties,' hinting at mutation and validation, but lacks critical behavioral details: it doesn't specify required permissions, whether updates are reversible, error handling for invalid data, rate limits, or what the response contains. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded with the core action ('update an existing contact') and includes a key detail ('validated properties') without redundancy. Every part earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, 0% schema coverage, no annotations, no output schema), the description is incomplete. It lacks information on behavioral traits (e.g., side effects, auth needs), parameter meanings, output format, and usage context. For a tool that modifies CRM data, this leaves significant gaps for an AI agent to operate effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'validated properties,' which aligns with the 'properties' parameter in the schema, but adds minimal semantic value beyond the schema's structure. With 0% schema description coverage, the schema provides no descriptions for parameters, yet the tool description doesn't compensate by explaining what 'contactId' is, the format of 'properties,' or the meaning of nested fields like 'lifecyclestage.' The baseline is 3 since the description hints at validation but doesn't detail 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 verb ('update') and resource ('existing contact'), making the purpose evident. It distinguishes from sibling tools like 'crm_create_contact' by specifying 'existing' and from 'crm_batch_update_contacts' by not mentioning batch operations. However, it doesn't explicitly differentiate from other update tools like 'crm_update_company' or 'crm_update_lead', which are similar in structure but target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid contactId), exclusions (e.g., not for creating new contacts), or comparisons to sibling tools like 'crm_batch_update_contacts' for bulk operations or 'crm_update_company' for different entities. Usage is implied by the name but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action ('Archive (delete)') without detailing behavioral traits. It doesn't specify if the action is reversible, what permissions are required, if there are rate limits, or what happens to associated data, leaving significant gaps 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 a single, front-loaded sentence that directly states the tool's purpose without unnecessary words. Every part of the sentence earns its place by specifying the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations, 0% schema coverage, and no output schema, the description is incomplete. It lacks crucial details like error handling, return values, side effects, or usage context, making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description doesn't add any parameter information beyond what the schema implies (emailId is required). It doesn't explain what emailId represents, its format, or where to obtain it, resulting in minimal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Archive (delete)') and resource ('an email record'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like emails_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?
No guidance is provided on when to use this tool versus alternatives like emails_batch_archive or other deletion methods. The description lacks context about prerequisites, permissions, or specific scenarios for application.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool archives/deletes emails, indicating a destructive mutation, but lacks details on permissions required, whether deletion is permanent or reversible, rate limits, or response format. This is inadequate for a destructive operation with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and scope without unnecessary words. Every part of the sentence contributes directly to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive batch operation with no annotations, 0% schema description coverage, and no output schema, the description is incomplete. It doesn't address critical aspects like error handling, confirmation requirements, or what happens to archived emails, leaving significant gaps for safe agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies 'emailIds' parameter by mentioning 'multiple email records', but doesn't specify format, constraints, or valid values. The description adds minimal semantic context 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 email records') with the scope 'in a single request'. It distinguishes from the singular 'emails_archive' sibling by specifying batch operation, though it doesn't explicitly contrast with other email tools like 'emails_batch_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?
No explicit guidance on when to use this tool versus alternatives like 'emails_archive' (for single emails) or other batch operations. The description implies batch processing but doesn't specify prerequisites, constraints, or comparative scenarios with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a destructive action ('Archive (delete)'), which implies mutation, but fails to specify if this is reversible, what permissions are required, or the response format. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste, front-loading the key action and resource. It's appropriately sized for a simple tool, 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 mutation tool with no annotations, no output schema, and low schema coverage, the description is inadequate. It lacks details on behavioral traits (e.g., permanence, error handling), parameter meaning, or usage context, leaving the agent with insufficient information to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description doesn't add any parameter details beyond what the schema implies (e.g., 'engagementId' is required). Since there's only one parameter, the baseline is 4, but the description doesn't explain what an 'engagementId' is or its format, so it's reduced to 3 for minimal value addition.
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'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'crm_archive_object' or 'engagement_details_get', which might handle similar resources differently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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' or other archive tools in the sibling list. The description lacks context about prerequisites, such as needing an existing engagement, or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Get details' implies a read operation, but it doesn't disclose whether this requires authentication, has rate limits, returns structured data or raw content, or what happens if the engagement doesn't exist. For a tool with zero annotation coverage, this leaves critical behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a simple retrieval tool and front-loads 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?
Given the complexity (a read operation with no annotations, 0% schema coverage, and no output schema), the description is insufficient. It doesn't explain what 'details' includes, how results are structured, or error conditions. For a tool in a rich ecosystem with many siblings, this leaves too much undefined for reliable 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 only indicates 'engagementId' is required without explaining what format it expects. The description adds no parameter details beyond implying an engagement ID is needed. Since there's only one parameter, the baseline is 4, but the description doesn't compensate for the coverage gap, so 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific engagement' clearly states the verb ('Get') and resource ('engagement'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'engagement_details_get_associated' or 'engagement_details_list', which would require more specificity about what 'details' means in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'engagement_details_get_associated' and 'engagement_details_list', there's no indication whether this tool retrieves basic metadata, full records, or something else, leaving the agent to guess based on 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 for behavioral disclosure. While 'archive (delete)' implies a destructive mutation, it doesn't clarify whether this is reversible, what permissions are needed, whether it affects associated data, or what happens after archival. The parenthetical '(delete)' adds some clarity but leaves many behavioral questions unanswered 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 three words, with zero wasted language. It's front-loaded with the core action and resource, making it immediately scannable. 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 and no output schema, the description is insufficient. It doesn't explain what 'archive' means operationally, whether data is recoverable, what permissions are required, or what the tool returns. The presence of sibling tools like meetings_batch_archive suggests this is part of a larger system where more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no parameter information beyond what's implied by the tool name. With 0% schema description coverage and 1 parameter (meetingId), the description doesn't explain what format the meetingId should be, where to find it, or provide any examples. However, since there's only one required parameter and the tool name suggests it's for meetings, the baseline is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('archive (delete)') and resource ('a meeting'), making the purpose immediately understandable. It distinguishes itself from other meeting tools like meetings_get or meetings_update by focusing on archival/deletion. However, it doesn't explicitly differentiate from meetings_batch_archive, which handles multiple meetings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like meetings_batch_archive for multiple meetings or other archive tools for different resources. There's no mention of prerequisites, permissions required, or typical use cases for archiving meetings versus other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool archives/deletes meetings, implying a destructive mutation, but doesn't disclose critical behavioral traits: whether archiving is permanent/reversible, what permissions are required, if there are rate limits, how errors are handled in batch operations, or what the response contains. For a destructive batch tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action ('archive/delete') and scope ('multiple meetings in a single request'). There's no wasted language, and it immediately communicates the core functionality without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a destructive batch mutation tool with no annotations, 0% schema description coverage, and no output schema, the description is incomplete. It lacks essential context: error handling for partial failures, response format, permissions, idempotency, or side effects. The description alone is insufficient for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'multiple meetings' which aligns with the 'meetingIds' array parameter, adding context that it accepts multiple IDs. However, with 0% schema description coverage (no schema descriptions for parameters), the description doesn't compensate by explaining the ID format, constraints (e.g., minimum/maximum array size), or examples. The baseline is 3 since it adds some meaning but doesn't fully address the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('archive/delete') and resource ('multiple meetings'), and specifies it's a batch operation ('in a single request'). It distinguishes from the singular 'meetings_archive' sibling tool by emphasizing the batch nature. However, it doesn't explicitly contrast with other batch tools like 'meetings_batch_create' or 'meetings_batch_update' beyond the archive action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing meeting IDs), when batch archiving is preferable to individual archiving, or what happens if some meetings can't be archived. With multiple sibling tools including singular 'meetings_archive' and other batch operations, this lack of context is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates this is a destructive operation ('delete'), which is helpful, but doesn't mention whether the archive is reversible, what permissions are required, whether there are rate limits, or what happens to associated data. For a destructive 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 extremely concise at just three words, with zero wasted language. It's front-loaded with the essential information (archive/delete action on a note). 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 destructive operation with no annotations, no output schema, and minimal parameter documentation, the description is insufficient. It doesn't explain what 'archive' means operationally, whether it's permanent or reversible, what the response looks like, or any error conditions. Given the complexity of a destructive operation, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters, while the schema has one required parameter (noteId) with 0% schema description coverage. The description doesn't add any parameter information beyond what's in the schema. With one parameter and no schema descriptions, the baseline would be lower, but since there's only one parameter, the agent can reasonably infer it's the note to archive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Archive (delete)') and resource ('a note'), making the purpose immediately understandable. It distinguishes this tool from other note-related tools like notes_create or notes_update by specifying the destructive action. However, it doesn't explicitly differentiate from notes_batch_archive, which is a sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools for notes (notes_batch_archive, notes_update, notes_get, etc.), but the description doesn't indicate when this single-note archive operation is preferred over batch operations or other note management tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 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 a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and resource. There is no wasted verbiage, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive batch operation with no annotations and no output schema, the description is incomplete. It lacks critical behavioral details (e.g., safety, response format) and usage context, making it inadequate 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%, but the description implies the parameter 'noteIds' is an array of note identifiers to archive. However, it doesn't specify format constraints (e.g., UUIDs, maximum array size) or validation rules, leaving gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Archive (delete)') and resource ('multiple notes'), distinguishing it from singular operations like 'notes_archive'. However, it doesn't explicitly differentiate from other batch operations on notes (e.g., 'notes_batch_create', 'notes_batch_update'), which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'notes_archive' (for single notes) or other batch operations. The description mentions 'multiple notes' but doesn't clarify thresholds, prerequisites, or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Update multiple notes' which implies a mutation operation, but doesn't disclose behavioral traits such as required permissions, whether updates are atomic or partial, error handling for invalid inputs, rate limits, or what happens to existing note properties not mentioned. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. 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 (batch mutation tool with 1 parameter but nested array structure), lack of annotations, 0% schema description coverage, and no output schema, the description is inadequate. It doesn't explain input semantics, behavioral implications, or output expectations, leaving too much undefined for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'multiple notes' which hints at the 'inputs' array parameter, but doesn't explain the structure (e.g., 'id' and 'properties' fields) or required fields like 'hs_note_body'. The description adds minimal value beyond the schema, which documents parameters but without descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update multiple notes') and scope ('in a single request'), which is specific and distinguishes it from single-note operations like 'notes_update'. However, it doesn't explicitly differentiate from other batch operations like 'notes_batch_create' or 'notes_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 'notes_update' (for single notes) or 'notes_batch_create' (for creating notes). The description implies batch processing 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. It states the action is a move to recycling bin (implying soft deletion/reversibility), but doesn't disclose permissions needed, whether it's synchronous/asynchronous, rate limits, or what happens to associated data. For a destructive operation with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with zero waste—clearly states action, target, and destination. Every word earns its place, and the structure is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description is insufficient. It doesn't cover success/error responses, side effects, or system behavior post-archiving. Given the complexity and lack of structured data, more context is needed for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that 'productId' identifies the object to archive, adding meaning beyond the bare schema. However, it doesn't specify the ID format (e.g., numeric, UUID) or where to find it, leaving some ambiguity. With one parameter partially clarified, this meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Move') and target ('Object identified by ID'), specifying it goes 'to the recycling bin'. It distinguishes from siblings like products_batch_archive (batch operation) and products_update (modification rather than archiving). However, it uses generic 'Object' rather than 'Product', slightly reducing 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 explicit guidance on when to use this tool versus alternatives like products_batch_archive (for multiple products) or products_update (for modifications). The description implies archiving a single product, but doesn't clarify prerequisites, recovery options, or when archiving is appropriate versus deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool archives/deletes products, which implies a destructive mutation, but doesn't clarify if this is reversible, what 'archive' means operationally, whether there are rate limits, or what permissions are required. 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 that front-loads the core action. Every word earns its place: 'archive (delete)' clarifies the action, 'batch' indicates scope, 'products' specifies the resource, and 'by ID' hints at the parameter. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive batch operation with no annotations, no output schema, and 0% schema description coverage, the description is insufficient. It doesn't explain what happens after archiving, whether there's confirmation or error handling, or how this differs from other archive operations. The context demands more complete guidance 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. It mentions 'by ID' which clarifies the purpose of the productIds parameter, adding some semantic value. However, it doesn't explain the format of IDs, whether they must exist, or any constraints on batch size. With one parameter and partial clarification, this meets the baseline for adequate but incomplete 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 ('a batch of products by ID'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'products_archive' (singular) or 'crm_batch_archive_objects' (similar batch operation on 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. It doesn't mention when batch archiving is preferred over individual archiving (products_archive), what happens to archived products, or any prerequisites like permissions. The sibling list shows multiple archive tools, but no differentiation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the tool returns a copy of the created object including ID, which adds some context about output behavior. However, it lacks critical details such as required permissions, whether the operation is idempotent, error handling, or any rate limits—important for a creation tool with mutation implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and outcome with zero wasted words. It directly communicates the tool's purpose and result 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 creation tool with no annotations, no output schema, and low schema description coverage (0%), the description is incomplete. It lacks details on error cases, authentication requirements, side effects, and how to interpret the returned object. The mention of returning the object with ID is helpful but insufficient for full contextual 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 'properties' as the input but doesn't elaborate on what specific properties are expected or their semantics. With 0% schema description coverage and 1 parameter (a nested object), the schema provides the structure but no descriptions. The description adds minimal value beyond the schema, meeting the baseline of 3 since it at least references the 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 ('Create a product') and the resource ('product'), specifying that it creates with given properties and returns the created object with ID. However, it doesn't differentiate from sibling tools like 'products_batch_create' or 'products_update', which would require explicit comparison for 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?
No guidance is provided on when to use this tool versus alternatives like 'products_batch_create' for multiple products or 'products_update' for modifications. The description only states what the tool does, not when it should be selected over other options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a destructive operation ('delete'), which is helpful, but doesn't clarify whether archiving is permanent/reversible, what happens to associated data, if permissions are required, or what the response looks like. For a destructive 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 extremely concise with just three words, front-loading the essential action and resource. Every word earns its place, and there's no wasted text or redundancy. The parenthetical clarification of 'delete' adds valuable context efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations, no output schema, and 0% schema description coverage, the description is inadequate. It identifies the action but doesn't cover behavioral implications, parameter guidance, or result expectations. Compared to sibling tools in the same domain (like tasks_batch_archive), this leaves the agent with insufficient context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the single parameter 'taskId' is undocumented in the schema. The description doesn't mention this parameter at all, providing no guidance on format, source, or constraints. However, with only one required parameter and the tool name implying its purpose, the baseline is appropriate despite the lack of parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('archive (delete)') and resource ('a task'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'tasks_batch_archive' or explain what 'archive' means in this context, but the verb+resource combination is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'tasks_batch_archive' or 'tasks_update' to mark a task as completed instead of archived. The description doesn't mention prerequisites, permissions needed, or consequences of archiving, leaving the agent without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a list operation (implying read-only), but doesn't disclose behavioral traits like pagination, rate limits, authentication requirements, error conditions, or what 'available' means (e.g., system-defined vs. custom). For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('List all available association types') and specifies the key constraint ('for a given object type pair'). There's no wasted verbiage, repetition, or unnecessary elaboration—every word serves the function of clarifying the tool's scope.
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 no annotations, no output schema, and 2 parameters with enums but 0% schema description coverage, the description is minimally adequate. It covers the basic purpose and parameter intent but lacks details on behavior, output format, error handling, or integration with sibling tools. For a read operation with structured inputs, it meets the baseline but doesn't provide enough context for robust agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but both parameters have enums that clearly define allowed values. The description adds context by explaining these parameters represent 'object type pairs', which helps interpret 'fromObjectType' and 'toObjectType'. However, it doesn't clarify what 'custom' means in the enums or provide examples of typical pairs, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('association types') with the specific scope 'for a given object type pair'. It distinguishes itself from sibling tools like 'crm_get_associations' by focusing on listing types rather than actual associations. However, it doesn't explicitly differentiate from other list operations like 'crm_list_objects' 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, related tools like 'crm_get_associations' or 'crm_create_association', or scenarios where listing association types is appropriate versus listing actual associations. The agent must infer usage from the name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 effectively describes the mutation nature ('partial update'), error conditions ('read-only and non-existent properties will result in an error'), and special behavior ('Properties values can be cleared by passing an empty string'). However, it lacks information about permissions, rate limits, or what happens to unspecified properties.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that each add value. The first sentence states the core purpose, and the second provides important behavioral details about errors and value clearing. There's no wasted verbiage.
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 mutation tool with no annotations, no output schema, and 0% schema description coverage, the description provides adequate basic information about what the tool does and some error conditions. However, it lacks details about the response format, authentication requirements, and complete parameter documentation, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It implies that 'productId' identifies the object and 'properties' contains the fields to update, but doesn't explain the structure of the properties object or the meaning of specific fields like 'hs_product_type'. The description adds some context but doesn't fully 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 ('perform a partial update') and resource ('Object identified by ID'), making the purpose specific and understandable. However, it doesn't explicitly differentiate this from sibling tools like 'products_update' vs 'products_batch_update' or 'products_create', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'products_batch_update' or 'products_create' from the sibling list. It mentions error conditions for read-only/non-existent properties, but this is behavioral rather than usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that this is a read operation (implied by 'Read'), describes pagination behavior with the 'after' cursor, and mentions response structure ('paging.next.after'). However, it doesn't cover important behavioral aspects like rate limits, authentication requirements, error conditions, or whether it's idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized at two sentences. The first sentence states the core purpose, and the second explains key parameters and response behavior. There's no wasted text, though the second sentence is somewhat dense and could be structured more clearly.
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 paginated list tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is moderately complete. It covers the pagination mechanism and field selection, but lacks information about response format beyond the cursor, error handling, sorting, default behaviors, or relationship to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 3 parameters, the description compensates well. It explains that 'properties' controls what is returned (field selection), and 'after' is a paging cursor token that appears in the response. It doesn't explain 'limit' (though its meaning is somewhat obvious), but provides meaningful context for 2 of 3 parameters beyond basic schema 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 tool's purpose as 'Read a page of products' with the verb 'Read' and resource 'products', and specifies it returns a page rather than all products. However, it doesn't explicitly differentiate from sibling tools like 'products_read' (singular) or 'products_search' (filtered search), which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'products_search' or 'products_read'. It mentions controlling what is returned via the 'properties' parameter, but this is a feature explanation rather than usage context. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kozo93/hubspot-mcp'

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