HubSpot MCP

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 they are organized by resource type (e.g., calls, crm, emails) and action (e.g., create, get, update, batch operations). Overlap is minimal and intentional, such as list vs. search for filtering options, which are clearly differentiated in descriptions.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, with a clear structure of resource_action (e.g., calls_create, crm_get_company). Minor variations like 'archive' vs. 'delete' in descriptions are consistent within contexts, and batch operations are uniformly prefixed with 'batch_'.
Tool Count2/5
With 111 tools, the count is excessive and feels heavy for the HubSpot CRM domain, likely leading to cognitive overload for agents. While the tools cover many resources, the high number suggests over-fragmentation rather than a well-scoped set, making it difficult to manage efficiently.
Completeness5/5
The tool surface provides complete CRUD/lifecycle coverage across all major HubSpot resources (calls, communications, CRM objects, emails, engagements, meetings, notes, products, tasks), including batch operations and specific functionalities like subscriptions and associations. No obvious gaps exist for the CRM domain.
Average 2.7/5 across 111 of 111 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but provides none. It doesn't mention whether this is a write operation (implied by 'create' but not confirmed), what permissions are required, whether it's idempotent, what happens on failure, or what the response format might be. For a mutation tool with complex nested parameters, this is critically inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with only three words, this is a case of harmful under-specification rather than effective brevity. The description is too short to be useful for a tool with complex parameters and multiple sibling alternatives. Every word earns its place, but there are far too few words to serve the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation operation, 2 parameters with nested objects, 0% schema description coverage, no annotations, no output schema), the description is completely inadequate. It fails to address any of the critical information needed to understand how to use this tool effectively, what it returns, or how it differs from related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero information about parameters despite having 2 parameters with 0% schema description coverage. The input schema shows complex nested objects with properties like 'hs_timestamp', 'hs_meeting_title', 'hs_meeting_start_time', and 'associations', but the description doesn't mention any of these required or optional fields, their purposes, or formatting requirements.
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 essentially restates the tool name 'meetings_create'. While it correctly identifies the verb ('create') and resource ('meeting'), it provides no additional specificity about what constitutes a meeting in this context or how it differs from other meeting-related tools like 'meetings_batch_create' or 'meetings_update'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. With multiple sibling tools including 'meetings_batch_create', 'meetings_update', and 'meetings_delete', there is no indication of when this single-create operation is appropriate versus batch operations or other meeting-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Search products' reveals nothing about whether this is a read-only operation, what permissions are required, whether it's paginated, what the return format is, or any rate limits. For a 6-parameter search tool with complex filtering capabilities, this is critically inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just two words, but this is under-specification rather than effective brevity. While it's front-loaded (the entire description is the purpose), it fails to provide necessary context. The structure is minimal but not helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters with nested filterGroups object, 0% schema coverage, no annotations, no output schema), the description is completely inadequate. A search tool with advanced filtering capabilities needs explanation of parameter usage, return format, pagination behavior, and relationship to other product tools. The current description provides none of this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 6 parameters have descriptions in the schema. The tool description 'Search products' adds absolutely no information about what parameters are available, what they mean, or how to use them. This leaves all parameters (query, limit, after, sorts, properties, filterGroups) completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search products' is a tautology that merely restates the tool name. It doesn't specify what kind of search (full-text, filtered, etc.), what resource scope (all products, specific catalog), or how it differs from sibling tools like 'products_list' or 'products_read'. While the verb 'search' is clear, the description lacks specificity and 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 Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools for products (products_list, products_read, products_search) with no indication of when search is preferred over list or read. No prerequisites, context, or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the action ('create') without addressing critical aspects like required permissions, whether this is a mutating operation, potential side effects, error conditions, or response format. For a tool with 11 parameters and no output schema, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is 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. No structural issues are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, 5 required, no schema descriptions, no output schema, and no annotations), the description is woefully incomplete. It does not explain what a company property is, how it's used, what the parameters mean, or what to expect upon creation. This leaves the agent with insufficient information to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 11 parameters have descriptions in the schema. The tool description adds no information about any parameters, their purposes, or how they interact (e.g., the relationship between 'type' and 'fieldType', or what 'options' array contains). This fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new company property' restates the tool name (crm_create_company_property) almost verbatim, making it tautological. While it identifies the verb ('create') and resource ('company property'), it lacks specificity about what a 'company property' entails or how it differs from similar tools like crm_create_contact_property or crm_create_lead_property 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 Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The sibling list includes related tools like crm_get_company_properties and crm_create_contact_property, but the description offers no context on prerequisites, dependencies, or appropriate scenarios for creating a company property versus other property types.
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 any details on permissions required, side effects (e.g., if it affects existing leads), rate limits, or response format. This is inadequate for a mutation tool with 11 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 no wasted words. It is front-loaded and appropriately sized for its minimal content, though this conciseness comes at the cost of detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, 5 required, no schema descriptions, no annotations, no output schema), the description is severely incomplete. It does not explain the tool's purpose in depth, usage context, behavioral aspects, or parameter meanings, making it inadequate for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 11 parameters are documented in the schema. The description adds no information about parameters, such as what 'name', 'label', or 'type' represent, or how they differ (e.g., 'type' vs 'fieldType'). It fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 about what a lead property is or how it differs from other CRM properties like company or contact properties, which are mentioned in sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing a lead first), exclusions, or comparisons to sibling tools like crm_create_company_property or crm_create_contact_property, 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.
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 mentions 'search' and 'filters,' failing to describe whether this is read-only, paginated, rate-limited, requires authentication, or returns structured data. For a search tool with 5 parameters and no annotations, this is a critical omission.
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 the tool's name, though it could benefit from more detail given the complexity. The brevity is a strength but leads to under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, nested filter structures, no output schema, and no annotations), the description is severely incomplete. It doesn't explain the search behavior, result format, error handling, or how to construct queries. For a tool with rich input schema but zero documentation, this is inadequate.
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 like filterGroups, properties, limit, after, and sorts are undocumented in the schema. The description adds no semantic details about these parameters—it doesn't explain what filterGroups are, how to use properties for field selection, or what 'after' means for pagination. It fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search leads with lead-specific filters' states the verb ('search') and resource ('leads'), but is vague about what constitutes 'lead-specific filters' and doesn't distinguish from sibling tools like crm_search_companies or crm_search_contacts. 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 like crm_get_lead (for single lead retrieval) or other search tools for different CRM objects. The description implies filtering but doesn't specify use cases, prerequisites, or exclusions, leaving the agent without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fails to disclose any behavioral traits: it doesn't indicate if this is a read-only operation, what permissions are needed, whether it's paginated, rate-limited, or what the output format 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 a single, efficient sentence with zero wasted words. It's appropriately sized and front-loaded, though this conciseness comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters with nested objects, 0% schema coverage, no annotations, no output schema), the description is completely inadequate. It doesn't explain the tool's behavior, parameter usage, output, or differentiation from siblings, leaving the agent with insufficient information to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'specific filters' but doesn't explain any of the 5 parameters (filterGroups, properties, limit, after, sorts) or their semantics. It fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search calls with specific filters' states the basic action (search) and resource (calls), but is vague about scope and lacks differentiation from sibling tools like 'calls_list' or 'calls_get'. It doesn't specify what kind of search this is (e.g., full-text, filtered, advanced) or how it differs from other call-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'calls_list' or 'calls_get'. The description mentions 'specific filters' but doesn't explain what scenarios warrant this tool over simpler listing tools, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description only states 'Search notes with specific filters' - it doesn't mention whether this is a read-only operation, what permissions are needed, whether it's paginated, what the output format is, or any rate limits. This is inadequate for a search tool with complex filtering capabilities.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single 5-word phrase. While this represents under-specification rather than ideal conciseness, it contains no wasted words and is front-loaded with the core action. Every word earns its place, though more content would be beneficial.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex search tool with 5 parameters (including nested filter structures), no annotations, no output schema, and 0% schema description coverage. The minimal description fails to provide necessary context about filtering capabilities, return format, pagination, or behavioral characteristics. It's completely inadequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 5 parameters have descriptions in the schema. The description mentions 'specific filters' which hints at the 'filterGroups' parameter, but provides no details about what properties can be filtered, how to structure filter groups, or what the other parameters (properties, limit, after, sorts) do. This leaves most parameters completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search notes with specific filters' states the basic action (search) and resource (notes), but lacks specificity about what kind of search it performs or how it differs from sibling tools like 'notes_list'. It doesn't clearly distinguish itself from other search tools in the system (e.g., 'calls_search', 'emails_search').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'notes_list' or other search tools. The description doesn't mention prerequisites, appropriate contexts, or exclusions. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 provides minimal behavioral information. It states it's a creation operation but doesn't mention permissions required, whether it's idempotent, what happens on failure, or what the expected response format might be. 'with details' hints at richer input but doesn't clarify behavioral implications.
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 being under-specified for such a complex tool with multiple parameters and many sibling alternatives.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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, 0% schema description coverage, and complex nested parameters, the description is severely inadequate. It doesn't explain what constitutes a successful creation, what data is returned, or how to handle the various parameter structures. The minimal description fails to provide necessary context for proper tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 3 complex parameters (engagement, associations, metadata), the description provides almost no parameter guidance. 'with details' vaguely references the engagement parameter but doesn't explain what details are expected, what associations mean, or how metadata is used. The description fails to compensate for the complete lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the basic action ('Create a new engagement') but lacks specificity about what distinguishes it from other engagement tools. It mentions 'with details' which hints at richer data than a basic create, but doesn't clearly differentiate from sibling tools like 'engagement_details_update' or 'calls_create'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. With multiple sibling tools for creating engagements (e.g., calls_create, emails_create, tasks_create), the description offers no context about when this general 'engagement_details_create' is preferred over more specific creation 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 doesn't disclose whether this is a read-only operation, whether it requires authentication, what the return format looks like, whether it supports pagination, or any rate limits. The mention of 'optional filtering' hints at some behavior but lacks specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point. However, it's arguably too concise given the complexity of 5 undocumented parameters and lack of sibling differentiation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters (0% schema coverage), no annotations, no output schema, and many sibling alternatives, the description is incomplete. It doesn't explain the tool's behavior, parameter usage, or differentiation from similar tools, 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?
With 0% schema description coverage for 5 parameters, the description doesn't compensate at all. It mentions 'optional filtering' but doesn't explain what parameters control filtering (limit, after, properties, associations, archived) or their meanings. The schema provides structure but no semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all calls with optional filtering' clearly states the verb ('List') and resource ('calls'), but it's vague about scope and doesn't distinguish from sibling tools like calls_search or calls_get. It mentions 'optional filtering' but doesn't specify what kind of filtering is available.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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_search, calls_get, or other list tools (emails_list, meetings_list, etc.). The description mentions 'optional filtering' but doesn't clarify when this tool is appropriate versus more specialized search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Create' which implies a write/mutation operation, but doesn't mention permissions required, whether creation is idempotent, rate limits, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - just 4 words. While this is efficient, it's arguably under-specified rather than appropriately concise. There's no wasted language, but it lacks necessary detail. The structure is simple and front-loaded with the core action, but doesn't provide enough substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters (including complex nested objects), 0% schema description coverage, no annotations, and no output schema, the description is severely incomplete. It doesn't explain what CRM objects are, what properties they can have, how associations work, or what the tool returns. 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.
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 doesn't mention any parameters, so it adds no semantic information beyond what the schema provides. With 3 parameters (including complex nested objects), this leaves the agent with no guidance on what 'objectType', 'properties', or 'associations' mean or how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb ('Create') and resource ('new CRM object'), which is clear but basic. It doesn't distinguish this tool from sibling tools like 'crm_create_company', 'crm_create_contact', etc., which are more specific versions of object creation. The purpose is understandable but lacks specificity about what makes this tool unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools for creating specific CRM objects (e.g., 'crm_create_company', 'crm_create_contact'), the description doesn't explain if this is a generic fallback, when to prefer it over specific tools, or any prerequisites. This leaves the agent guessing about appropriate usage contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states a read operation ('Get'), but doesn't disclose behavioral traits like authentication needs, rate limits, error conditions, pagination, or what 'all properties' entails (e.g., default vs. custom). The description is too minimal to guide safe or 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, straightforward sentence with zero waste. It's front-loaded and appropriately sized for its limited content, though this conciseness comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, 2 parameters, no output schema, and moderate complexity (CRM tool), the description is incomplete. It lacks details on parameters, behavior, output format, and usage context. For a tool that likely interacts with lead data, this minimal description is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It doesn't explain the two parameters ('archived' and 'properties') at all—no mention of what 'archived' filters, what 'properties' array should contain, or if they're optional. The description adds no meaning beyond the bare schema, 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' states the basic action (get) and resource (lead properties), but lacks specificity about scope or format. It doesn't distinguish from sibling tools like 'crm_get_lead' (which presumably gets lead data) or 'crm_get_contact_properties' (same action for different resource). The purpose is clear but generic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing a lead ID, though none appears in parameters), nor comparison to similar tools like 'crm_get_lead' or 'crm_search_leads'. The description implies it retrieves properties, but doesn't clarify context or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions 'specific filters' but doesn't disclose pagination behavior (implied by 'limit' and 'after' parameters), rate limits, authentication requirements, or what constitutes a successful search. For a search tool with complex 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 with just 5 words, which is efficient. However, it's arguably under-specified rather than optimally concise—it could benefit from one more clarifying phrase without becoming verbose. The structure is straightforward but lacks front-loading of critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters with nested objects, 0% schema coverage, no output schema, no annotations), the description is incomplete. It doesn't explain the search scope, result format, error conditions, or how parameters interact. For a tool with this level of parameter complexity, the description should provide more contextual guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but fails to do so. It mentions 'specific filters' which loosely relates to 'filterGroups', but doesn't explain the 5 parameters (filterGroups, properties, limit, after, sorts) or their purposes. The description adds minimal value beyond the schema's structural definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search emails with specific filters' states the basic action (search) and resource (emails), but is vague about scope and lacks differentiation from sibling tools like emails_list. It doesn't specify what kind of search this is (full-text, metadata, etc.) or how it differs from other email-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like emails_list or other search tools. The description mentions 'specific filters' but doesn't explain what scenarios warrant this tool over simpler listing options or how it relates to sibling search tools for other resources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It implies a read-only operation ('Get'), but doesn't specify authentication needs, rate limits, error conditions, or what the return format looks like (since no output schema exists). This is inadequate for a tool with potential complexity in data 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, straightforward sentence with no wasted words, making it easy to parse. However, it's arguably too concise given the lack of supporting annotations and schema descriptions, bordering on under-specification rather than optimal 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 tool with no annotations, 0% schema description coverage, and no output schema, the description is insufficient. It doesn't explain what 'details' entail, how to handle errors, or provide usage context, leaving critical gaps for an AI agent to operate effectively in a complex environment 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?
The schema description coverage is 0%, so the description must compensate for parameter documentation. It mentions 'a specific engagement' which hints at the 'engagementId' parameter, but provides no details on format, constraints, or where to obtain it. This adds minimal value beyond the bare schema, failing to address the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific engagement' clearly states the verb ('Get') and resource ('engagement'), making the basic purpose understandable. However, it lacks specificity about what 'details' include and doesn't differentiate from sibling tools like 'engagement_details_list' or 'engagement_details_get_associated', leaving ambiguity 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. The description doesn't mention prerequisites (e.g., needing an engagement ID), exclusions, or comparisons to sibling tools like 'engagement_details_list' for multiple engagements or 'engagement_details_get_associated' for related data, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'optional filtering' which hints at query capabilities, but doesn't disclose critical behavioral traits like whether this is a read-only operation, pagination behavior (implied by limit/offset parameters but not explained), rate limits, authentication requirements, or what 'engagements' encompasses. The description is too minimal for a tool with 5 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (7 words) and front-loaded with the core purpose. However, it's arguably too brief given the tool's complexity—it sacrifices necessary detail for brevity. Every word earns its place, but more words might be needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters with 0% schema coverage, no annotations, no output schema, and multiple sibling tools, the description is incomplete. It doesn't explain what 'engagements' are, how filtering works, what the tool returns, or how it differs from similar tools. For a list operation with filtering capabilities, this leaves too many gaps for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions 'optional filtering' generically without explaining what the 5 parameters (limit, offset, startTime, endTime, activityTypes) actually do, their relationships, or formatting requirements. The description adds almost no semantic value beyond what's inferable from parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all engagements with optional filtering' clearly states the verb ('List') and resource ('engagements'), but it's somewhat vague about what 'engagements' specifically refers to in this context. It doesn't distinguish this tool from sibling tools like 'engagement_details_get' or 'engagement_details_get_associated', leaving ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'engagement_details_get' (for single engagements) and 'engagement_details_get_associated' (likely for related engagements), there's no indication of when this list tool is preferred or what its specific use cases are.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Get' which implies a read operation, but doesn't disclose behavioral traits like whether it requires authentication, rate limits, error handling, or what happens if the meeting doesn't exist. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that's front-loaded with the core action. There's no wasted text, but it's arguably too concise given the lack of detail needed for the 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, 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't explain parameter meanings, return values, or behavioral context, making it inadequate for an agent to use the tool effectively without additional guesswork.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'specific meeting' which hints at the 'meetingId' parameter, but doesn't explain the 'properties' or 'associations' parameters at all. The description adds minimal value beyond what's implied by the tool name, failing to address the undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific meeting' clearly states the verb ('Get') and resource ('meeting'), but it's vague about what 'details' include and doesn't differentiate from sibling tools like 'meetings_list' or 'meetings_search'. It's adequate but lacks specificity about scope or content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'meetings_list' for multiple meetings or 'meetings_search' for filtered results. The description implies usage for a single meeting but doesn't specify prerequisites or exclusions, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'optional filtering' but doesn't describe what the tool returns (e.g., format, pagination), whether it's read-only or has side effects, or any performance characteristics like rate limits. For a tool with 5 parameters and no annotations, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point without unnecessary words. It's appropriately sized for a basic listing tool, though it could benefit from being slightly more informative given the lack of other documentation. 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?
Given the tool has 5 parameters with 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns, how parameters work, or behavioral characteristics. For a filtering tool with multiple date parameters and a properties array, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 5 parameters have descriptions in the schema. The description mentions 'optional filtering' but doesn't explain what parameters are available, what they do, or how they interact. It doesn't compensate for the complete lack of parameter documentation in the schema, leaving all parameters semantically undefined.
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 this tool from sibling tools like 'meetings_search' or 'meetings_get', leaving ambiguity about when to use this specific listing tool versus alternatives. The purpose is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'meetings_search' or 'meetings_get' from the sibling list. It mentions 'optional filtering' but doesn't specify what types of filtering are available or when filtering should be used. There's no mention of prerequisites, limitations, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers nothing beyond the basic action. It doesn't mention whether this is a write operation (implied by 'Create'), what permissions are needed, whether it's idempotent, what happens on failure, or what the response contains. This is inadequate for a tool with complex nested parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise with just three words that directly state the core function. There's no wasted language or unnecessary elaboration, making it efficient for initial understanding despite its limitations 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?
For a creation tool with no annotations, 0% schema description coverage, complex nested parameters, and no output schema, the description is completely inadequate. It doesn't explain what gets created, how to structure the input, what the response looks like, or any behavioral characteristics. This leaves the agent with insufficient information to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero information about parameters, while the schema has 0% description coverage and 2 parameters with complex nested structures. The agent would have no guidance about what 'properties' and 'associations' mean, what 'hs_note_body' represents, or how to structure the association objects. This leaves critical gaps in understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('a new note'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'notes_batch_create' or 'engagement_details_create', which would require more specific context about what type of note creation this handles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'notes_batch_create' and 'engagement_details_create' available, there's no indication whether this is for single note creation, what prerequisites might exist, or when batch operations would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action ('create') without mentioning permissions required, rate limits, whether the operation is idempotent, error handling for partial failures, or what the response contains. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to scan and understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch creation tool with no annotations, 0% schema description coverage, and no output schema, the description is severely incomplete. It lacks details on behavior, parameters, return values, error handling, and usage context, 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description provides no information about parameters. It doesn't explain that 'inputs' is an array of product objects with properties like 'name', 'price', or 'sku', leaving all parameter semantics undocumented. This fails to compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a batch of products' clearly states the verb ('create') and resource ('products'), and the 'batch' modifier distinguishes it from the sibling 'products_create'. However, it doesn't specify what constitutes a 'product' in this context or differentiate from other batch creation tools like 'crm_batch_create_objects'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication needs), compare to single-product creation ('products_create'), or specify scenarios where batch creation is preferred over individual calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions deletion (a destructive operation) but doesn't disclose critical behavioral traits like whether deletions are permanent, require specific permissions, have rate limits, or provide confirmation responses. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and scope, 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 (batch deletion with 3 parameters, no annotations, no output schema, and 0% schema coverage), the description is incomplete. It lacks details on parameters, behavioral implications, error handling, and output expectations, 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It doesn't explain any parameters—'fromObjectType', 'toObjectType', or 'inputs'—leaving their meanings (e.g., object types like 'companies' or 'contacts', and association structures) 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 states the action ('Delete multiple associations') and scope ('in a single request'), which is clear but basic. It distinguishes from non-batch operations but doesn't explicitly differentiate from sibling tools like 'crm_batch_delete_objects' or 'crm_delete_association', leaving ambiguity about when to choose this specific batch tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'crm_delete_association' (single deletion) and 'crm_batch_delete_objects' (batch deletion of objects, not associations), the description lacks context for selection, such as efficiency for bulk operations or prerequisites like existing associations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is an update operation (implying mutation) but doesn't disclose behavioral traits like required permissions, whether updates are atomic or partial, error handling for failed updates, rate limits, or what the response contains. For a batch mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized and front-loaded with the core purpose. Every word earns its place by conveying key information about batch operations and CRM objects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch mutation tool with 2 parameters (0% schema coverage), no annotations, and no output schema, the description is incomplete. It doesn't explain parameter usage, behavioral expectations, error handling, or output format. Given the complexity of batch updates and lack of structured documentation, the description should provide more context to be truly helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'multiple CRM objects' which hints at the 'inputs' array parameter, but doesn't explain the 'objectType' parameter, the structure of 'inputs' (with 'id' and 'properties'), or what values 'properties' can contain. The description adds minimal value beyond what's inferable from the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update multiple CRM objects in a single request' clearly states the action (update) and resource (CRM objects), but it's vague about scope and doesn't distinguish from siblings like crm_batch_update_companies, crm_batch_update_contacts, or crm_update_object. It specifies 'multiple' and 'single request' which adds some specificity, but lacks detail on what types of objects or how they're identified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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. With many sibling tools including specific batch update tools (crm_batch_update_companies, crm_batch_update_contacts, crm_batch_update_leads) and single-object updates, the description offers no context about when this generic batch update is preferred over more specific ones or what prerequisites might exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action without disclosing behavioral traits. It doesn't mention whether this is a mutating operation, what permissions are required, how errors are handled, or what the response looks like. For a creation tool with 5 required parameters, this leaves critical gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a basic tool description and gets straight to the point without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 5 required parameters, 0% schema description coverage, no annotations, and no output schema, the description is severely incomplete. It doesn't explain what an association is, how it's used, what happens after creation, or provide any context beyond the minimal verb-noun pairing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'fromObjectType'/'toObjectType' enums represent, what 'associationTypes' array contains, or how IDs are formatted. The description fails to provide meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '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 its sibling 'crm_batch_create_associations' or 'crm_delete_association', leaving ambiguity about when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like batch operations or when associations are appropriate. The description doesn't mention prerequisites, constraints, or typical use cases, leaving the agent to infer usage from parameter 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?
No annotations are provided, so the description carries full burden. 'Get' implies a read operation, but it doesn't disclose behavioral traits like whether it requires authentication, has rate limits, returns paginated results, or what happens if parameters are omitted. For a tool with 2 parameters and 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 with no wasted words. It's front-loaded with the core purpose and appropriately sized for what it conveys, though it could benefit from additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain parameter usage, return values, error conditions, or behavioral constraints. For a data retrieval tool in a CRM context, this leaves too many unknowns for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions 'all properties' but doesn't explain the two parameters ('archived' and 'properties') at all. It fails to compensate for the lack of schema descriptions, leaving parameters completely 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 contacts' clearly states the verb ('Get') and resource ('properties for contacts'), making the purpose understandable. However, it's somewhat vague about scope ('all' could mean all properties in the system vs. all for specific contacts) and doesn't differentiate from sibling tools like 'crm_get_contact' or 'crm_get_company_properties' beyond the contact focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'crm_get_contact' (gets contact data) and 'crm_get_company_properties' (gets company properties), there's no indication of when retrieving contact properties specifically is appropriate versus other data retrieval methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'search' and 'filters' but doesn't disclose behavioral traits like whether this is a read-only operation, what permissions are required, if there are rate limits, pagination behavior (implied by 'limit' and 'after' parameters but not explained), or what the output looks like. For a search tool with 5 parameters and no output schema, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that gets straight to the point. There's no wasted language or redundancy. It's front-loaded with the core action (search companies) and includes a key constraint (company-specific filters). Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters with nested objects, 0% schema coverage, no output schema, no annotations), the description is inadequate. It doesn't explain the search functionality, parameter usage, expected output, or behavioral constraints. For a tool that likely returns a list of companies with filtering, sorting, and pagination, the description provides too little context for an agent to use it correctly without extensive 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 only mentions 'company-specific filters' which loosely relates to the 'filterGroups' parameter but doesn't explain any of the 5 parameters (filterGroups, properties, limit, after, sorts) or their semantics. The description adds minimal value beyond what the schema's structure provides, failing to clarify what these parameters mean or how to use them effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search companies with company-specific filters' states the verb (search) and resource (companies) but is vague about scope and differentiation. It mentions 'company-specific filters' but doesn't clarify what distinguishes this from other search tools like crm_search_contacts or crm_search_leads. The purpose is understandable but lacks specificity about what makes this search unique to companies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With sibling tools like crm_get_company, crm_list_objects, and other search tools (crm_search_contacts, crm_search_leads), the description offers no context about when this search is appropriate versus simpler retrieval methods. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the search functionality without mentioning whether this is a read-only operation, how results are returned (e.g., pagination via 'after' parameter), rate limits, authentication requirements, or what happens when no matches are found. For a search tool with complex parameters, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a search tool and front-loads the core functionality. 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 search tool with 5 parameters (including complex nested structures), 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the search logic, result format, pagination behavior, or error conditions. The agent would struggle to use this tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 5 parameters have descriptions in the schema. The description mentions 'contact-specific filters' which hints at the filterGroups parameter, but doesn't explain any of the other parameters (properties, limit, after, sorts) or their relationships. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool searches contacts with filters, which is a clear verb+resource combination. However, it doesn't distinguish this from sibling tools like crm_search_companies or crm_search_leads, which have identical descriptions except for the resource type. The phrase 'contact-specific filters' is somewhat redundant since the tool name already indicates contacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention sibling tools like crm_get_contact (for single contact retrieval) or crm_list_objects (for unfiltered listing), nor does it specify prerequisites or appropriate contexts for searching versus other contact operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose whether this is a read-only operation, what permissions are required, whether results are paginated, rate limits, or what format the results take. For a search tool with 6 parameters and no output schema, this leaves critical behavioral aspects undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 5 words with no wasted language. It's front-loaded with the core action, though this brevity comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex search tool with 6 parameters, 0% schema description coverage, no output schema, and no annotations, the description is severely incomplete. It doesn't explain the search capabilities, result format, pagination, or how this differs from sibling search tools, leaving the agent with insufficient context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 6 parameters, the description provides no information about any parameters. It doesn't explain what 'objectType' accepts, how 'filterGroups' work, what 'properties' returns, what 'limit' controls, what 'after' is for pagination, or how 'sorts' functions. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search CRM objects using filters' states the verb ('Search') and resource ('CRM objects'), but is vague about scope and differentiation. It doesn't specify what types of objects are searchable or how this differs from sibling search tools like crm_search_companies, crm_search_contacts, and crm_search_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 is provided about when to use this tool versus the more specific sibling search tools (crm_search_companies, crm_search_contacts, crm_search_leads). The description doesn't mention prerequisites, alternatives, or exclusions for this general search 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. It mentions 'list all emails' which implies a read-only operation, but doesn't specify whether this requires authentication, what permissions are needed, whether results are paginated, or any rate limits. The description is too minimal to provide adequate 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 6 words. It's front-loaded with the core purpose and wastes no words. While it may be too brief for adequate documentation, it scores perfectly on conciseness as every word contributes to the meaning without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, 0% schema description coverage, no annotations, and no output schema, the description is insufficient. It doesn't explain the return format, error conditions, authentication requirements, or how the filtering parameters work. The minimal description doesn't provide enough context for an agent to use this tool effectively given its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning none of the 5 parameters have descriptions in the schema. The tool description only mentions 'optional filtering' in general terms without explaining what specific parameters are available (limit, after, properties, associations, archived) or their purposes. The description fails to compensate for the complete lack of parameter documentation in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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'), making the basic purpose understandable. However, it doesn't differentiate this tool from sibling tools like 'emails_search' or 'emails_get', leaving ambiguity about when to use each. The purpose is clear but lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'emails_search' or 'emails_get'. It mentions 'optional filtering' but doesn't specify what types of filtering are available or when this tool is preferred over other listing/search tools. No explicit when/when-not instructions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it's an update operation, implying mutation, but doesn't cover permissions, side effects, error handling, or response format. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for its limited content, though this conciseness comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't address behavioral traits, parameter meanings, or usage context, leaving critical 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 emailId or the properties object, leaving all parameters undocumented. This fails to provide meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing email record' clearly states the action (update) and resource (email record), but it's generic and doesn't differentiate from sibling tools like emails_batch_update or emails_create. It lacks specificity about what aspects of an email 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?
No guidance is provided on when to use this tool versus alternatives like emails_batch_update for multiple emails, emails_create for new emails, or emails_archive for deletion. The description doesn't mention prerequisites, such as needing an existing emailId.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'update' implies a mutation, it doesn't specify whether this requires specific permissions, what happens on partial failures, if there are rate limits, or the response format. For a batch mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—'Update multiple meetings in a single request' is front-loaded and directly conveys the core functionality. 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 updates with nested objects), lack of annotations, 0% schema description coverage, and no output schema, the description is incomplete. It doesn't address behavioral risks, parameter details, or output expectations, leaving critical gaps for an agent to understand and use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 meetings' but doesn't explain the 'inputs' array structure, required 'id' and 'properties' fields, or the nested properties like 'hs_meeting_title'. It fails to compensate for the schema's lack of descriptions, leaving key parameter meanings unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update multiple meetings in a single request' clearly states the verb ('update') and resource ('meetings'), and specifies it's a batch operation. However, it doesn't distinguish this tool from sibling tools like 'meetings_update' (single meeting update) or 'meetings_batch_create' (batch creation), leaving the differentiation implicit rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing meeting IDs), compare it to 'meetings_update' for single updates, or specify scenarios where batch updates are appropriate (e.g., bulk modifications). Without this context, an agent might misuse it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'search' and 'filters' but doesn't disclose behavioral traits like whether it's read-only, pagination behavior (implied by 'limit' and 'after' in schema), rate limits, authentication needs, or what happens on no matches. The description is minimal and lacks essential operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, though it may be too concise given the tool's complexity and lack of supporting annotations or schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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, nested objects in schema, no annotations, no output schema), the description is inadequate. It doesn't explain return values, error conditions, or how to interpret results. The minimal description fails to provide enough context for effective tool use, especially with 0% schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 references 'specific filters' without explaining parameters like 'filterGroups', 'properties', 'limit', 'after', or 'sorts'. No details on parameter meanings, formats, or examples are provided, leaving significant gaps in understanding.
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 specifies 'with specific filters' which adds some context but remains generic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'meetings_list' or 'meetings_get' is provided. The description implies filtering capabilities but doesn't specify use cases, prerequisites, or exclusions, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a 'get' operation, implying read-only behavior, but doesn't disclose permissions, error handling, or response format. For a tool with no annotations, this is insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded and efficiently conveys the core purpose, though it lacks depth due to its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with 0% schema coverage, no annotations, no output schema, and sibling tools, the description is incomplete. It doesn't explain parameters, return values, or usage context, making it inadequate for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'details of a specific note' but doesn't explain the three parameters (noteId, properties, associations) or their purposes. This leaves key input 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 'Get details of a specific note' clearly states the action (get) and resource (note), but it's vague about what 'details' includes and doesn't differentiate from sibling tools like notes_list or notes_search. It's adequate but lacks specificity about scope or content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like notes_list or notes_search. The description implies it's for retrieving a single note by ID, but there's no explicit comparison or context for selection among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Update an existing note' implies a mutation operation, but it doesn't specify permissions needed, 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, though this conciseness comes at the cost of detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 2 parameters (including a nested object), 0% schema coverage, no annotations, and no output schema, the description is incomplete. It lacks essential details about behavior, parameters, and usage context, making it insufficient for reliable 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 by explaining parameters. It mentions no parameters at all, leaving both 'noteId' and the nested 'properties' object (with fields like 'hs_note_body') undocumented. This fails to add meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing note' clearly states the verb ('Update') and resource ('note'), but it's vague about what specifically gets updated. It doesn't differentiate from sibling tools like 'notes_batch_update' or 'notes_archive', which is a missed opportunity for clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'notes_batch_update' and 'notes_archive' available, there's no indication of use cases, prerequisites, or exclusions, leaving the agent to guess based on naming 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 'Read,' which implies a safe, read-only operation, but doesn't confirm this or add any context about permissions, rate limits, error handling, or what the output looks like (e.g., format, fields returned). For a tool with three parameters and no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence, 'Read an Object identified by ID,' which is front-loaded and wastes no words. It directly states the core action without unnecessary elaboration, making it efficient for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't explain the tool's scope (products vs. general objects), parameter usage, behavioral traits, or output format. For a read operation with multiple optional parameters, this lacks essential context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning none of the three parameters (productId, properties, associations) are documented in the schema. The description only mentions 'ID,' which corresponds to 'productId,' but doesn't explain the optional 'properties' and 'associations' arrays—what they filter, their purpose, or valid values. This leaves most parameters undocumented and unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Read an Object identified by ID' states a clear verb ('Read') and resource ('Object'), but it's vague about what type of object—it could refer to any entity in the system. It doesn't specify that it's for products, which is implied by the tool name but not explicitly stated in the description. This creates ambiguity compared to sibling tools like 'crm_get_object' or 'products_get' (if it existed).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 'products_list' for browsing multiple products or 'products_batch_read' for batch operations. There's no context about prerequisites, such as needing a valid product ID, or exclusions, like not being suitable for creating or updating products.
Agents often have multiple tools that could apply. Explicit usage guidance like "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. 'Create a new task' implies a write operation, but it doesn't specify permissions needed, whether creation is idempotent, rate limits, error handling, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, with no wasted language. It's front-loaded with the core action, though this brevity comes at the cost of completeness. Every word earns its place by stating the essential function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 parameters with nested objects, no output schema, and no annotations), the description is inadequate. It doesn't explain the input structure, return values, error conditions, or behavioral traits. For a create operation with significant parameter complexity, more context is needed to guide effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description adds no information about the 2 parameters (properties and associations), their purposes, or how to structure them. With low coverage and no compensation in the description, this fails to provide meaningful parameter guidance beyond what's inferred from the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 specify what kind of task or distinguish it from sibling tools like tasks_batch_create, which creates multiple tasks at once. The purpose is clear but lacks differentiation from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like tasks_batch_create for bulk operations or tasks_update for modifications. It doesn't mention prerequisites, context, or exclusions, leaving the agent with no usage instructions beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 ('Get'), which is helpful, but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or what happens if the task doesn't exist. For a tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's appropriately sized for a simple retrieval tool and front-loads the core purpose effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with 0% schema coverage, no annotations, no output schema, and multiple sibling tools, the description is incomplete. It doesn't explain what details are returned, how to use optional parameters, or differentiate from other task-related tools. For this complexity level, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 3 parameters, the description doesn't add any parameter semantics. It mentions 'specific task' which hints at taskId, but doesn't explain the optional 'properties' and 'associations' arrays or their purposes. The description fails 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.
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 action (get) and resource (task), but it's vague about what 'details' include and doesn't distinguish from sibling tools like tasks_list or tasks_search. It's adequate but lacks specificity about scope or output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like tasks_list or tasks_search. The description implies it's for retrieving a single task by ID, but this is inferred from the parameter name rather than explicit usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Search' implies a read-only operation, but the description doesn't clarify whether this is safe (non-destructive), what permissions might be needed, whether results are paginated, or what the response format looks like. It mentions 'specific filters' but doesn't explain how filtering works or any limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just 5 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?
Given the complexity (5 parameters, nested filtering logic, no output schema, and no annotations), the description is inadequate. It doesn't explain the search functionality, parameter interactions, result format, or behavioral aspects. For a tool with rich filtering capabilities and multiple parameters, this minimal description 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?
The schema has 5 parameters with 0% description coverage, meaning all parameters are undocumented in the schema. The description only vaguely mentions 'specific filters', which corresponds to the 'filterGroups' parameter but doesn't explain the other 4 parameters (properties, limit, after, sorts) or provide any syntax, format, or usage details. It adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search tasks with specific filters' clearly states the verb ('Search') and resource ('tasks'), but it's vague about what 'specific filters' means and doesn't distinguish this tool from sibling tools like 'tasks_list' or 'tasks_get'. It provides a basic purpose but lacks specificity about what makes this search tool unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'tasks_list' or 'tasks_get'. The description mentions 'specific filters' but doesn't explain what scenarios require filtering versus simple listing. There's no mention of prerequisites, alternatives, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it's an update operation. It doesn't disclose behavioral traits like whether it requires specific permissions, what happens on partial updates, if changes are reversible, rate limits, or response format. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, 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?
For a mutation tool with 2 parameters (including a nested object), 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain what fields can be updated, required permissions, error handling, or return values, 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 schema provides no parameter descriptions. The description adds no parameter semantics beyond implying taskId and properties are needed. It doesn't explain what properties can be updated (e.g., priority, status, due date) or their formats, 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 'Update an existing task' clearly states the action (update) and resource (task), but it's vague about what can be updated and doesn't differentiate from sibling tools like tasks_batch_update or tasks_archive. It provides basic purpose but lacks specificity about scope or fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like tasks_batch_update for multiple tasks or tasks_create for new tasks. The description implies usage for updating tasks but offers no context about prerequisites, error conditions, or sibling tool distinctions.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 'create' implies a write operation, the description doesn't disclose critical behavioral traits: whether this requires specific permissions, rate limits, whether contacts are created synchronously or asynchronously, error handling for partial failures, or what the response contains. For a batch mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for conveying the core functionality without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch creation tool with complex nested parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain the parameter structure, expected response format, error handling, or operational constraints. 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.
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 parameter information beyond implying an array input. The complex nested schema with 17+ property fields and association objects is completely undocumented in the description. With low schema coverage, the description fails to compensate by explaining parameter meanings, formats, or 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 'Create multiple contacts in a single request' clearly states the verb ('create') and resource ('contacts'), with the 'multiple...in a single request' indicating batch functionality. It distinguishes from non-batch contact creation tools like 'crm_create_contact', but doesn't explicitly differentiate from other batch creation tools like 'crm_batch_create_companies' or 'crm_batch_create_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 is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, limitations, or when batch creation is preferred over single-contact creation. With many sibling tools available, the agent receives no help in selecting this specific batch contact 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?
No annotations are provided, so the description carries full burden. 'Delete' implies a destructive mutation, but it doesn't disclose critical behaviors like whether deletion is permanent, requires specific permissions, has side effects (e.g., cascading deletions), or returns confirmation. 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, direct sentence with zero wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive deletion), lack of annotations, no output schema, and 0% schema coverage, the description is incomplete. It doesn't cover behavioral traits, parameter meanings, or expected outcomes, leaving significant gaps for the agent to operate safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters, but schema coverage is 0% with 1 required parameter (engagementId). The description doesn't add any parameter semantics beyond what the schema provides (just the parameter name). However, with only 1 parameter, the baseline is 4, but it's reduced to 3 because the description fails to explain what 'engagementId' represents or its format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete an engagement' clearly states the action (delete) and resource (engagement), which is better than a tautology. However, it doesn't specify what an 'engagement' is in this context or distinguish it from similar deletion tools like 'meetings_delete' or 'crm_delete_object' in the sibling list, 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. It doesn't mention prerequisites (e.g., needing an engagement ID), exclusions, or compare it to sibling tools like 'engagement_details_get' or batch deletion 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 full burden for behavioral disclosure. It states this is a read operation but doesn't mention permissions required, rate limits, pagination behavior, error handling, or what happens with invalid IDs. The description lacks crucial context about how the batch operation behaves (e.g., partial successes, ordering of results).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that directly address the tool's purpose. It's front-loaded with the core functionality. However, the second sentence is somewhat redundant with the first and could be more 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 read tool with 4 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the return format, error conditions, authentication requirements, or how the batch operation scales. The description leaves too many open questions about a non-trivial batch operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description only mentions the idProperty parameter and vaguely references 'internal ID' and 'unique property values' without explaining the inputs array structure, what properties/propertiesWithHistory arrays contain, or how these parameters interact. Four parameters exist with zero documentation in schema, and the description adds minimal semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a batch of products using internal IDs or unique property values, which is a specific verb+resource combination. It distinguishes from sibling tools like products_list or products_search by focusing on batch retrieval by IDs/properties rather than listing or searching. However, it doesn't explicitly contrast with products_read (singular read) or products_batch_create/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 products_list, products_search, or products_read. It mentions the idProperty parameter but doesn't explain when batch reading by IDs is preferable to other retrieval methods. No exclusions, prerequisites, or comparison to sibling tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool creates and returns an object with ID, which is basic behavioral info, but lacks details on permissions, error handling, side effects, or rate limits. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the action and outcome efficiently. It avoids unnecessary words, though it could be slightly more detailed given the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 1 parameter (a nested object), 0% schema description coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain the properties structure, return format beyond 'object with ID', or behavioral context needed for safe 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%, and the description only vaguely refers to 'given properties' without explaining what properties are available (e.g., name, price) or their semantics. It doesn't compensate for the lack of schema descriptions, leaving parameters largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'product', specifying it creates with given properties and returns the object with ID. It distinguishes from sibling tools like products_list or products_update by focusing on creation, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like products_batch_create or other creation tools in the sibling list. The description implies usage for creating a single product but doesn't mention prerequisites, constraints, or comparison with batch operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states it creates records in a single request. It doesn't disclose behavioral traits such as permissions needed, rate limits, error handling, whether it's idempotent, or what happens on partial failures. For a mutation tool with complex nested inputs, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action. There is zero waste, and it appropriately conveys the batch nature without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested objects, no output schema, 0% schema coverage, and no annotations), the description is incomplete. It doesn't address return values, error cases, or the semantics of the intricate input structure, 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 but adds no parameter semantics. It doesn't explain the 'inputs' array structure, nested 'properties' and 'associations', required fields, or enum values. The description fails to provide meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('create') and resource ('multiple call records'), making the purpose evident. It distinguishes from 'calls_create' by specifying batch capability, though it doesn't explicitly contrast with other batch operations like 'calls_batch_update' or '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 on when to use this tool versus alternatives like 'calls_create' (for single records) or other batch tools. The description implies batch creation but lacks explicit usage context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a read operation, implying it's non-destructive, but doesn't disclose behavioral traits like rate limits, authentication requirements, error handling for invalid IDs, or whether it returns partial results on failures. The description is too minimal for a batch operation with complex input.
Agents need to know what a tool does to the world before calling it. Descriptions 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 avoids 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?
Given the complexity of a batch read tool with 1 parameter (a nested array of objects), 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain input format, output expectations, error behavior, or usage context, leaving significant gaps for an AI agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'multiple call records' but doesn't explain the 'inputs' parameter structure, what 'id' represents, or the purpose of 'properties' and 'associations' arrays. The description adds minimal semantic value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read multiple call records') and scope ('in a single request'), which is specific and distinguishes it from single-read tools like calls_get. However, it doesn't explicitly differentiate from other batch operations like calls_batch_create or calls_batch_update, 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 calls_get (for single reads) or calls_list (for filtered lists). It mentions 'multiple call records' but doesn't specify thresholds or scenarios where batch reading is preferred over individual calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a creation tool, implying mutation, but doesn't cover permissions, side effects, response format, or error handling. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized and front-loaded, clearly stating the core action 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 no annotations, 0% schema description coverage, no output schema, and complex nested parameters, the description is insufficient. It doesn't address behavioral aspects, parameter meanings, or usage context, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about parameters. It doesn't mention the 'properties' and 'associations' parameters or their purposes, leaving the agent to infer from the schema alone. This fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('a new call record'), making the tool's purpose evident. However, it doesn't differentiate from sibling tools like 'calls_batch_create' or 'calls_update', which would require specifying this is for single-record creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'calls_batch_create' for multiple records or 'calls_update' for modifications. The description lacks any context about prerequisites, timing, or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it 'gets details' without disclosing behavioral traits like whether it's read-only, requires authentication, returns partial/full data, or has rate limits. It's minimally informative for a tool with 3 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a basic get operation and front-loads the core purpose immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what details are returned, how parameters modify output, or behavioral context needed for proper 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 'callId', 'properties', or 'associations' mean or how they affect the output, leaving all 3 parameters semantically undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('details of a specific call'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'calls_list' or 'calls_search' which also retrieve call information, missing full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'calls_list' for multiple calls or 'calls_search' for filtered searches. It lacks any context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool updates records, implying mutation, but fails to mention critical aspects like whether changes are reversible, authentication requirements, rate limits, or error handling. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded and directly states the tool's action, making it highly concise and well-structured for its minimal content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 parameters with nested objects), lack of annotations, and no output schema, the description is insufficient. It does not explain parameter usage, behavioral traits, or return values, making it incomplete for effective tool invocation by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning parameters are undocumented in the schema. The description adds no information about the 'callId' or 'properties' parameters, their formats, or the nested properties within 'properties'. It does not compensate for the lack of schema documentation, falling short of 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 verb ('Update') and resource ('an existing call record'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'calls_batch_update' or 'calls_create', which would require more specificity to reach a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'calls_batch_update' for multiple updates or 'calls_create' for new records. It also lacks prerequisites like required permissions or call existence, offering minimal usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states 'Get' implies a read operation, but doesn't specify if it's safe, idempotent, or has side effects. No information on permissions, rate limits, error conditions, or response format is included, which is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a simple retrieval tool and front-loads the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'communication preferences' entail, how parameters interact, what the return value looks like, or behavioral considerations. 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.
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 'contact' which maps to 'contactId', but doesn't explain what 'subscriptionId' is or how these parameters relate to getting preferences. The description adds minimal semantic value beyond what's inferable from parameter 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 clearly states the verb 'Get' and the resource 'communication preferences for a contact', making the purpose specific and understandable. It doesn't explicitly differentiate from sibling tools like 'communications_get_subscription_status' or 'communications_get_subscription_definitions', but the focus on '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 like 'communications_get_subscription_status' or 'communications_get_subscription_definitions'. It doesn't mention prerequisites, context, or exclusions, leaving the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a read-only operation ('Get'), but doesn't disclose whether it's safe, has rate limits, returns paginated results, or handles errors. For a tool with two required parameters and 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 with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a straightforward tool. Every word earns its place by conveying essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 required parameters, no output schema, no annotations), the description is incomplete. It doesn't explain what the tool returns, how to interpret the status, error conditions, or performance characteristics. For a batch query tool with no structured support, 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 schema provides no parameter documentation. The description mentions 'subscription status for multiple contacts', which hints that 'contactIds' should be an array of contact identifiers and 'subscriptionId' identifies a specific subscription, but it doesn't clarify format, constraints, or examples. This partial compensation is insufficient 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 'subscription status for multiple contacts', making the purpose unambiguous. It distinguishes from sibling tools like 'communications_get_preferences' and 'communications_get_subscription_definitions' by focusing on contact-level status rather than definitions or preferences. However, it doesn't explicitly differentiate from similar batch operations in other domains (e.g., 'calls_batch_read'), so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use this versus 'communications_get_preferences' or 'communications_get_subscription_definitions', nor does it specify prerequisites like required permissions or valid subscription/contact IDs. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'subscribe' implies a write/mutation operation, the description doesn't address permission requirements, whether this is reversible (though 'communications_unsubscribe_contact' exists), rate limits, error conditions, or what happens if the contact is already subscribed. It provides 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, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately understandable without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters (0% schema coverage), no annotations, and no output schema, the description is inadequate. It doesn't explain the legal basis parameters, doesn't describe what happens on success/failure, and provides minimal behavioral context. The agent would struggle to use this tool correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions 'contact' which maps to 'contactId', but doesn't explain the two portalSubscription parameters at all. For a tool with 3 parameters (one required, one with an enum), this leaves significant gaps in understanding what values to provide and why.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Subscribe') and resource ('a contact to all email communications'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'communications_unsubscribe_contact' or 'communications_update_preferences', but the verb 'subscribe' inherently distinguishes it from those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'communications_update_preferences' or 'communications_update_subscription_status'. It doesn't mention prerequisites, constraints, or appropriate contexts for subscription versus preference management.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('Unsubscribe') which implies a mutation, but doesn't mention permissions required, whether the change is reversible, rate limits, or what happens to existing subscriptions. For a mutation tool with zero 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 a single, clear sentence with zero wasted words. It's front-loaded with the core action and appropriately sized for the tool's apparent complexity. Every word earns its place in conveying the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters (one with complex enum values), 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the legal basis parameters, return values, error conditions, or behavioral implications. The agent would struggle to use this tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'contact' which hints at 'contactId', but provides no information about the two additional parameters ('portalSubscriptionLegalBasis' and 'portalSubscriptionLegalBasisExplanation') or their purposes. The description adds minimal value beyond what's implied by the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Unsubscribe') and target ('a contact from all email communications'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'communications_update_subscription_status' or 'communications_update_preferences' which might handle similar functionality, 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 like 'communications_update_subscription_status' or 'communications_update_preferences' from the sibling list. It doesn't mention prerequisites, exclusions, or comparative use cases, leaving the agent without contextual decision-making help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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' which implies a mutation, but doesn't mention required permissions, whether changes are reversible, rate limits, or what the response looks like. For a mutation tool with zero annotation coverage, this 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 appropriately sized for a tool with a clear name and follows a subject-verb-object structure that's easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters (including a complex nested object), 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the parameter structure, behavioral implications, or what to expect from the operation. The agent would struggle to use this tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions 'communication preferences for a contact' which hints at the purpose of 'contactId' and 'preferences', but doesn't explain any parameters in detail - not the structure of 'preferences', the meaning of 'subscriptionId', or the legal basis enums. 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 verb ('Update') and resource ('communication preferences for a contact'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'communications_update_subscription_status' or 'communications_subscribe_contact', leaving some ambiguity about when to choose this specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'communications_update_subscription_status' or 'communications_subscribe_contact'. The description lacks context about prerequisites, use cases, or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Update' implies a mutation operation, the description doesn't address critical behavioral aspects like whether this requires specific permissions, what happens if some updates fail, whether changes are reversible, or any rate limits. The mention of 'multiple contacts' hints at batch behavior but lacks operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 5 words, front-loading the essential action and target. Every word earns its place with no redundancy or unnecessary elaboration, making it efficient 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 mutation tool with no annotations, no output schema, 2 parameters (one complex), and 0% schema description coverage, the description is inadequate. It doesn't explain the legal basis requirements shown in the schema, doesn't describe what happens when updating multiple contacts, and provides no information about return values or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 2 parameters (one being a complex array of objects), the description provides no information about what 'subscriptionId' or 'updates' should contain. The schema shows detailed structure with enums for status and legalBasis, but the description doesn't mention these critical semantic elements, leaving parameters largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and target ('subscription status for multiple contacts'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'communications_subscribe_contact' or 'communications_unsubscribe_contact', which appear to handle individual contact 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 about when to use this tool versus alternatives like the individual subscribe/unsubscribe tools. The description mentions 'multiple contacts' which implies batch operations, but doesn't explicitly state this as a distinguishing factor or provide any context about appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Create multiple associations' which implies a write operation, but lacks details on permissions, rate limits, error handling, or what happens on partial failures. For a batch mutation tool, this is a significant gap in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for the tool's complexity, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (batch creation with 3 parameters, no output schema, and no annotations), the description is incomplete. It doesn't cover parameter meanings, usage context, or behavioral traits like mutation effects. This leaves the agent under-informed for a tool that creates multiple data associations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'multiple associations' which hints at the 'inputs' array parameter, but doesn't explain 'fromObjectType', 'toObjectType', or the structure of association types. This leaves key parameters undocumented, failing to add meaningful semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create multiple associations') and resource ('associations'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'crm_create_association' or 'crm_batch_delete_associations', which would require mentioning batch creation specifically versus single creation or deletion 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. It doesn't mention scenarios like bulk operations, efficiency gains over single creation, or prerequisites such as existing objects to associate. Without this, an agent might misuse it or overlook better options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Delete' implies a destructive mutation, the description doesn't mention critical aspects like whether deletions are permanent or reversible, what permissions are required, rate limits, error handling for partial failures, or what happens to associated data. For a destructive batch operation, this represents significant gaps 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 7 words, front-loading the core action ('Delete multiple CRM objects') with the operational context ('in a single request'). Every word serves a purpose with zero redundancy or unnecessary elaboration, making it efficient 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 operation with no annotations, no output schema, and 0% parameter documentation in the schema, the description is inadequate. It doesn't explain what happens after deletion (success indicators, error responses), doesn't clarify parameter usage, and provides no safety warnings or behavioral context that would help an agent use this tool correctly and safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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, the description provides no information about what 'objectType' and 'objectIds' represent or how they should be used. The description doesn't mention the available object types (visible in the schema enum) or explain the format/requirements for object IDs. For a tool with two required parameters, this leaves the agent guessing about proper 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 ('Delete') and resource ('multiple CRM objects') with the operational context ('in a single request'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'crm_delete_object' (singular delete) or other batch operations like 'crm_batch_update_objects', leaving some ambiguity about when to choose this specific batch deletion tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'crm_delete_object' (singular delete), 'crm_batch_delete_associations', and various other batch operations, there's no indication of appropriate use cases, prerequisites, or trade-offs between batch and individual deletion methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Create a new company with validated properties', which implies a write operation but lacks details on permissions needed, whether creation is idempotent, error handling, or response format. The mention of 'validated properties' hints at input validation but doesn't specify rules or outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions 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 ('Create a new company') without unnecessary words. Every part earns its place by adding value about validation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 parameters with nested objects, 0% schema coverage, no output schema, and no annotations), the description is inadequate. It doesn't explain parameter meanings, behavioral traits like error handling, or what 'validated properties' entails, leaving significant gaps for a creation 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 for undocumented parameters. It mentions 'validated properties' but doesn't explain what 'properties' or 'associations' parameters mean, their structure, or validation rules. This leaves key semantics unclear beyond the basic action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value 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 company'), making the purpose evident. However, it doesn't distinguish this tool from its sibling 'crm_batch_create_companies', which also creates companies but in batch mode, leaving room for improvement in sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'crm_batch_create_companies' for multiple companies or 'crm_create_contact' for other CRM entities. It mentions 'validated properties' but doesn't explain what validation entails or prerequisites for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 address permissions needed, whether the operation is idempotent, what validation entails, or what happens on failure. 'Validated properties' hints at some validation but doesn't explain what validation occurs or what errors might result. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 6 words, with zero wasted language. It's front-loaded with the core action ('Create a new contact') and adds a qualifying phrase ('with validated properties'). Every word serves a purpose, making it efficient despite its limitations in completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, 0% schema description coverage, and complex nested parameters, the description is severely incomplete. It doesn't explain what the tool returns, what errors might occur, what validation means, or how to properly structure the parameters. The agent would struggle to use this tool correctly 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?
Schema description coverage is 0%, so the description must compensate for completely undocumented parameters. The description mentions 'validated properties' which loosely relates to the 'properties' parameter, but doesn't explain what 'properties' contains, what 'associations' does, or provide any guidance on parameter usage. With 2 parameters (one required) and complex nested structures, this minimal description is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('contact'), making the purpose unambiguous. It specifies 'new contact' and mentions 'validated properties', which adds some differentiation from generic creation tools. However, it doesn't explicitly distinguish this from sibling tools like crm_batch_create_contacts or crm_create_lead, which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With numerous sibling tools (including batch creation tools and other CRM entity creation tools), the agent receives no help in selecting this specific tool. There's no mention of prerequisites, constraints, or comparison with similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Create' implies a write/mutation operation, but the description doesn't mention whether this requires admin permissions, if properties are immediately available, potential side effects (e.g., affecting existing contacts), or rate limits. For a mutation tool with 11 parameters and no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 4 words, with zero wasted language. It's front-loaded with the core action and resource. While this conciseness comes at the cost of completeness, the structure itself is optimal - every word contributes directly to the purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, 5 required, mutation operation), lack of annotations, 0% schema description coverage, and no output schema, the description is severely incomplete. It doesn't explain what a 'contact property' is in this context, how it differs from regular contact fields, what the parameters mean, or what the tool returns. For a creation tool with this level of complexity, the description should provide much more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, meaning none of the 11 parameters have explanations in the schema. The description provides no parameter information whatsoever - it doesn't mention any of the required fields (name, label, type, fieldType, groupName) or optional parameters. This leaves the agent with only parameter names and types to work with, which is insufficient for proper tool invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the 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. However, it doesn't explicitly differentiate from 'crm_create_lead_property' which has a similar structure but different target entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., required permissions), when to choose batch operations (like 'crm_batch_create_objects'), or how this differs from similar property creation tools for companies or leads. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Create' implies a write/mutation operation, the description doesn't address critical aspects like required permissions, whether the operation is idempotent, what validation entails, error conditions, or what happens on success. The mention of 'validated properties' hints at input validation but lacks specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 6 words, front-loading the core purpose without any wasted words. Every word earns its place, making it easy to parse quickly despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 2 parameters (including complex nested objects), 0% schema description coverage, no annotations, and no output schema, the description is severely inadequate. It doesn't explain what 'validated properties' means, doesn't describe the response format, and provides no behavioral context for a mutation operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 2 parameters (one required), the description provides minimal parameter information. It mentions 'validated properties' which relates to the 'properties' parameter but doesn't explain what validation means or describe the 'associations' parameter at all. The description fails to compensate for the complete lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('a new lead'), making the purpose immediately understandable. However, it doesn't differentiate this from sibling tools like 'crm_batch_create_leads' or 'crm_create_contact', which would require mentioning this is for single lead creation with property validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like batch creation tools or other CRM creation tools. There's no mention of prerequisites, constraints, or comparison with sibling tools, leaving the agent with insufficient context for proper tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a deletion operation, implying it's destructive, but doesn't mention permissions required, whether the deletion is reversible, or what happens if the association doesn't exist. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for what it communicates, though what it communicates is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with 4 required parameters, 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what an 'association' means in this CRM context, what happens after deletion, error conditions, or any behavioral nuances. The agent would struggle to use this tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 4 parameters are documented in the schema. The description provides no information about what 'fromObjectType', 'toObjectType', 'fromObjectId', or 'toObjectId' mean or how they should be used. This leaves the agent guessing about parameter semantics despite the critical nature of these identifiers for the deletion operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('association between two objects'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'crm_batch_delete_associations' or 'crm_delete_object', which would require specifying this is for single associations rather than batches or objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'crm_batch_delete_associations' for multiple deletions or 'crm_delete_object' for removing objects themselves. The description lacks context about prerequisites or typical use cases for association deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Delete' clearly indicates a destructive operation, but it doesn't specify whether deletions are permanent, reversible, or have cascading effects on related data. No information about authentication requirements, rate limits, or error handling is included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It's appropriately front-loaded with the core action and resource, making it efficient for quick understanding without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with 2 parameters (0% schema coverage) and no annotations or output schema, the description is inadequate. It doesn't address critical context like what happens after deletion, error scenarios, or how to identify which objects can be deleted. The description leaves too many open questions for safe tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but provides no parameter information. It doesn't explain what 'objectType' represents (the enum values like 'companies', 'contacts'), what 'objectId' should contain, or how these parameters work together. The description adds zero value 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a CRM object' clearly states the action (delete) and resource (CRM object), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'crm_batch_delete_objects' or 'crm_delete_association', but it's specific enough to convey the core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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_delete_objects' for multiple deletions or 'crm_delete_association' for removing relationships. There's no mention of prerequisites, permissions required, or error conditions that might affect usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a 'Get' operation, implying read-only behavior, but doesn't mention authentication requirements, rate limits, pagination behavior (despite 'after' and 'limit' parameters), error conditions, or what the output looks like. This leaves significant gaps for a tool with 5 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately front-loaded with the core purpose, 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, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the association concept, parameter interactions, expected output format, or behavioral constraints, leaving the agent with insufficient context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'associations of a specific type' means in relation to the 'fromObjectType' and 'toObjectType' parameters, or clarify the purpose of 'after' and 'limit'. This leaves all 5 parameters semantically undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('associations of a specific type between objects'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'crm_list_association_types' or 'crm_get_object', 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. With many sibling tools in the CRM domain, there's no mention of prerequisites, typical use cases, or distinctions from similar tools like 'crm_list_objects' or 'engagement_details_get_associated'.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 specify whether this requires authentication, has rate limits, returns paginated results, or has any side effects. It doesn't describe what format the properties are returned in or whether archived companies are included by default. For a read tool with zero 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 extremely concise at just 5 words, with zero wasted language. It's front-loaded with the core purpose and contains no unnecessary elaboration. While it may be too brief for complete understanding, it achieves perfect conciseness within its limited scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a 2-parameter tool with no annotations, 0% schema description coverage, and no output schema, the description is inadequate. It doesn't explain what 'properties' means in this context (metadata definitions vs. values), doesn't address the two parameters, and provides no behavioral context. For a tool that likely returns structured data about company properties, this leaves too many unanswered 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 2 parameters with 0% description coverage, so the description must compensate. However, the description mentions neither parameter - it doesn't explain what 'archived' does (filter by archived status?) or what 'properties' array contains (specific property names to retrieve?). The description adds no parameter semantics beyond what's inferable from the parameter names themselves, failing to address 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 ('all properties for companies'), making the purpose immediately understandable. It distinguishes from other company-related tools like crm_get_company (which gets company details) and crm_get_contact_properties (which gets contact properties). However, it doesn't specify whether this retrieves metadata about properties or actual property values, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use crm_get_company_properties versus crm_get_company (which might include properties) or crm_search_companies (which might filter by properties). There's no discussion of prerequisites, context, or typical use cases for retrieving company properties.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. It states this is a 'get' operation (implying read-only), but doesn't mention authentication requirements, rate limits, error conditions, response format, or whether it returns full objects or requires property specification. The description doesn't contradict annotations since none exist, but provides inadequate 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 7 words, with no wasted language. It's front-loaded with the core purpose and uses minimal syntax. While it may be too brief for adequate tool understanding, it earns full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, 0% schema description coverage, no annotations, and no output schema, the description is severely incomplete. It doesn't explain what constitutes a 'CRM object', how results are returned, what authentication is needed, or how to interpret parameters. The minimal description fails to provide adequate context for proper tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 4 parameters, the description provides no information about any parameters. It doesn't explain what 'objectType' values mean, what format 'objectId' should be in, what 'properties' controls, or what 'associations' does. The description fails to compensate for the complete lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('a single CRM object by ID'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like crm_get_company, crm_get_contact, or crm_get_lead, which appear to serve similar purposes for specific object types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools like crm_get_company, crm_get_contact, and crm_list_objects, there's no indication of when this generic 'get object' tool is preferred over type-specific getters or list operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Update' implies a mutation operation, but the description doesn't specify permissions required, whether changes are reversible, rate limits, or what happens to unspecified properties. 'Validated properties' hints at validation but doesn't explain validation rules or error behavior. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a basic update operation and front-loads the essential information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, 0% schema description coverage, no output schema, and complex nested parameters, the description is incomplete. It doesn't explain what 'validated' means, doesn't describe the response format, doesn't mention error conditions, and doesn't differentiate from similar tools. The conciseness comes at the expense of necessary contextual information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions 'validated properties' which partially explains the 'properties' parameter, but doesn't clarify what 'companyId' represents or provide any details about the specific properties that can be updated (name, domain, website, etc.). For a tool with 2 parameters and 0% schema coverage, this minimal explanation is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('an existing company'), making the purpose immediately understandable. It distinguishes from sibling tools like crm_create_company by specifying 'existing' rather than new creation. However, it doesn't explicitly differentiate from crm_batch_update_companies or crm_update_object, which could handle similar operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like crm_batch_update_companies, crm_update_object, or crm_update_contact/crm_update_lead. It mentions 'validated properties' but doesn't explain what validation entails or when validation might fail. No prerequisites or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Update' implies a mutation operation, the description doesn't address critical behavioral aspects: what permissions are required, whether updates are partial or complete, how validation works, what happens with invalid properties, or what the response contains. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise - a single sentence with no wasted words. It's front-loaded with the essential 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?
For a mutation tool with 3 parameters (including a nested object), 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It should explain the update behavior, parameter usage, error handling, and relationship to sibling tools. The current description leaves too many contextual gaps for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for all 3 parameters, the description provides no additional parameter information beyond what's in the schema. It doesn't explain what 'objectType' values mean, how 'objectId' is formatted, or what 'properties' should contain. The description fails to compensate for the complete lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('existing CRM object'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its many CRM-related siblings (like crm_update_company, crm_update_contact, etc.), which would require specifying that this is a generic update tool for multiple object types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many specific CRM update tools (crm_update_company, crm_update_contact, crm_update_lead) or batch alternatives (crm_batch_update_objects). There's no mention of prerequisites, error conditions, or appropriate contexts for this generic update versus specialized updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it's a creation operation. It doesn't disclose whether this requires specific permissions, how failures are handled in batch operations, rate limits, whether emails are actually sent or just stored, or what the response format looks like for a batch operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core functionality without unnecessary words. It's appropriately front-loaded with the main 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 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 batch operation semantics, error handling, required fields, or what constitutes a successful creation versus individual failures within the batch.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the 'inputs' parameter structure. It doesn't explain what properties are required for each email, what the associations field does, or how to format the batch array. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('multiple email records') with the batch operation context ('in a single request'). It distinguishes from non-batch email tools but doesn't explicitly differentiate from other batch email tools like emails_batch_update or emails_batch_read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this batch operation versus individual email creation (emails_create) or other batch operations. The description mentions 'multiple email records' but doesn't specify optimal batch sizes, error handling, or prerequisites 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 of behavioral disclosure. While 'Read' implies a safe operation, it doesn't specify whether this is paginated, rate-limited, requires authentication, or what the return format looks like. For a batch operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 any unnecessary details or repetition, 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 read tool with 1 parameter (a complex nested array), 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the parameter structure, return values, error handling, or operational constraints, 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?
The schema has 0% description coverage, meaning none of the parameters are documented in the schema. The description mentions 'multiple email records' but doesn't explain the 'inputs' array structure, what 'id' represents, what 'properties' or 'associations' arrays contain, or how to format requests. It adds minimal value beyond the schema's structural definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Read') and resource ('multiple email records'), and specifies the operational context ('in a single request'). However, it doesn't distinguish this tool from sibling tools like 'emails_get' (single email read) or 'emails_list' (list emails with filtering), which would require explicit differentiation to earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'emails_get' for single emails or 'emails_list' for filtered lists. There's no mention of prerequisites, limitations, or specific use cases that would help an agent choose between batch and non-batch operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an update operation (implying mutation) but doesn't mention permission requirements, whether updates are atomic/partial, error handling for invalid inputs, rate limits, or what happens to existing properties not specified. The description is minimal and lacks critical behavioral context for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's appropriately sized for what it communicates and front-loads the key information (update, batch, email records).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch mutation tool with complex nested parameters (1 top-level parameter containing arrays of objects with 16+ properties), no annotations, and no output schema, the description is inadequate. It doesn't explain what properties can be updated, how to format them, what the response looks like, or error conditions. The agent would struggle to use this tool correctly 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?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description 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 any property fields like 'hs_email_status' or 'hs_email_direction'. For a complex nested parameter structure with 16+ property fields, this is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 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 email tools like 'emails_update', but doesn't explicitly differentiate from other batch email tools like 'emails_batch_create' or 'emails_batch_read'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'emails_update' (single update) or 'emails_batch_create' (batch creation). It doesn't mention prerequisites, constraints, or typical use cases for batch updating versus individual updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states 'create' implies a write operation, but lacks details on permissions, side effects (e.g., whether it sends emails or just stores records), error handling, or response format. For a creation tool with complex nested 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, direct sentence with no wasted words. It's front-loaded and efficiently conveys the core action, though this brevity contributes to gaps in other dimensions. Every word earns its place, making it structurally sound.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters with nested objects, no output schema, and no annotations), the description is incomplete. It doesn't address the rich input structure, expected outcomes, or behavioral traits needed for effective use. For a creation tool with such schema depth, more context is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 'email record' but doesn't explain the two main parameters (properties and associations) or their sub-fields (e.g., subject, status, recipients). This leaves critical input semantics unclear, failing 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new email record' clearly states the verb ('create') and resource ('email record'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like emails_batch_create, which creates multiple email records, or emails_update, which modifies existing records, leaving room for improvement in sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., required fields), compare it to batch operations (emails_batch_create) or update operations (emails_update), or specify use cases (e.g., for single email creation). This lack of context could lead to misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but only states what the tool does ('Get details'). It doesn't mention whether this is a read-only operation, if it requires specific permissions, what error conditions might occur, or how results are formatted, leaving significant gaps for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's appropriately sized for a simple retrieval tool and front-loads the core functionality effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain parameter usage, return values, or behavioral aspects, leaving too much undefined for proper tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning none of the 3 parameters are documented in the schema. The description doesn't explain what 'emailId', 'properties', or 'associations' mean, their expected formats, or how they affect the output, failing to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('details of a specific email'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'emails_list' or 'emails_search' that also retrieve email information, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'emails_list' for multiple emails or 'emails_search' for filtered searches. It lacks context about prerequisites or typical use cases, offering only basic functional information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get all engagements,' implying a read operation, but doesn't mention if it's paginated, requires specific permissions, has rate limits, or what 'associated' entails (e.g., type of association). This leaves significant gaps for a tool with 7 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear 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 (7 parameters, 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't explain parameter meanings, behavioral traits, or output format, making it inadequate for an agent to use the tool effectively 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 schema provides no parameter descriptions. The description mentions 'associated with an object,' which hints at 'objectType' and 'objectId,' but doesn't explain the other 5 parameters (startTime, endTime, activityTypes, limit, offset) or their roles. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('engagements associated with an object'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'engagement_details_get' or 'engagement_details_list', which might retrieve engagements differently, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools like 'engagement_details_get' and 'engagement_details_list', it's unclear if this is for filtering by object or if other tools serve different purposes. No explicit when/when-not or alternative mentions are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Update' implies a mutation operation, but the description doesn't specify what permissions are required, whether the update is partial or complete, what happens to unspecified fields, or any rate limits/constraints. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for what it communicates, though what it communicates is limited.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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, complex nested parameters, and no output schema, the description is severely inadequate. It doesn't explain what fields can be updated, what the response looks like, error conditions, or behavioral constraints - 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 3 parameters (including a complex nested object), the description provides no information about what 'engagementId', 'engagement', or 'metadata' represent or how they should be used. The description doesn't compensate for the complete lack of schema documentation, failing to explain the structure or purpose of any parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('an existing engagement's details'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'engagement_details_create' or 'calls_update', which would require explicit differentiation to earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'engagement_details_create' or batch update tools. It mentions 'existing engagement' which implies a prerequisite but doesn't specify how to identify existing engagements or when to choose this over other update tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool creates meetings but omits critical details: whether this is a mutating operation (implied but not confirmed), permission requirements, rate limits, error handling for partial failures, or what the response looks like. For a batch creation 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: 'Create multiple meetings in a single request.' It is front-loaded and appropriately sized for conveying the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (batch creation with nested parameters), lack of annotations, 0% schema description coverage, and no output schema, the description is incomplete. It doesn't explain the input structure, behavioral traits, or expected outcomes, making it inadequate for an agent to use the tool effectively without additional inference or 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%, meaning parameters are undocumented in the schema. The description adds no information about the 'inputs' parameter or its nested structure (e.g., properties like 'hs_meeting_title', required fields, associations). It fails to compensate for the schema's lack of descriptions, leaving parameters semantically unclear beyond their JSON 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 ('Create') and resource ('multiple meetings'), specifying it's a batch operation ('in a single request'). It distinguishes from individual creation tools like 'meetings_create' by emphasizing batch capability. However, it doesn't explicitly differentiate from other batch tools like 'meetings_batch_update' or 'meetings_batch_archive' beyond the 'create' 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., authentication needs), compare with single-meeting creation ('meetings_create'), or indicate scenarios where batch creation is preferred (e.g., efficiency for bulk operations). Without such context, an agent lacks direction on 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 for behavioral disclosure. 'Delete a meeting' implies a destructive, irreversible operation, but it doesn't specify consequences (e.g., data loss, recovery options), permissions required, or error handling. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, front-loading the core action. There's no wasted language or redundancy, making it efficient for quick comprehension, though this conciseness comes at the cost of detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a destructive delete operation), lack of annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't address critical aspects like return values, error cases, or behavioral nuances, leaving the agent under-informed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about the 'meetingId' parameter beyond what the schema implies. It doesn't explain what a meetingId is, how to obtain it, or format requirements (e.g., UUID, numeric ID). With low coverage, the description fails to compensate for the lack of schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a meeting' clearly states the verb ('Delete') and resource ('a meeting'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'meetings_batch_archive' or 'meetings_update', which could also modify meeting states, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'meetings_archive' or 'meetings_batch_archive' (which are present in sibling tools). There's no mention of prerequisites, permissions, or specific contexts for deletion versus archiving, leaving the agent with insufficient usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Update an existing meeting' implies a mutation operation but provides no information about permissions required, whether changes are reversible, rate limits, error conditions, or what happens to unspecified properties. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise at just three words, with zero wasted language. It's front-loaded with the essential action and resource, making it immediately scannable and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, 0% schema description coverage, no output schema, and complex nested parameters, the description is inadequate. It doesn't address behavioral aspects, parameter meanings, return values, or usage context. The description should provide significantly more information given the tool's complexity and lack of structured documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 2 parameters (one being a complex nested object with 7 sub-properties), the description provides no information about parameters. It doesn't mention 'meetingId' or the 'properties' object, nor does it explain what fields can be updated or their formats. 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 'Update an existing meeting' clearly states the verb ('Update') and resource ('an existing meeting'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'meetings_batch_update' or 'calls_update', which would require more specific 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. With sibling tools like 'meetings_batch_update' and 'meetings_create' available, there's no indication whether this is for single meeting updates, what prerequisites might exist, or when batch operations would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a creation tool but doesn't mention permissions, rate limits, idempotency, error handling, or what happens on partial failures. 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 directly states the tool's core function without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (batch creation with nested objects), lack of annotations, 0% schema coverage, and no output schema, the description is inadequate. It doesn't address behavioral aspects, parameter details, or expected outcomes, leaving critical gaps for a 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 schema provides no parameter descriptions. The description mentions 'multiple notes' but doesn't explain the 'inputs' parameter structure, required fields like 'hs_note_body', or how associations work. It adds minimal semantic value 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 notes') and scope ('in a single request'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'notes_create' (single note creation) or 'notes_batch_update' (batch updates), missing explicit 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 like 'notes_create' for single notes or other batch operations. The description lacks context about use cases, prerequisites, or trade-offs, offering minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a read operation, implying it's non-destructive, but doesn't disclose any behavioral traits like authentication requirements, rate limits, error handling, pagination, or what happens with invalid IDs. For a batch operation with complex input schema, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with zero waste. Every word earns its place: 'Read' (action), 'multiple notes' (resource), 'in a single request' (batch context). No fluff 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?
Incomplete for a batch operation tool with 0% schema coverage and no output schema. The description doesn't explain the complex nested input structure, what properties/associations mean, return format, error behavior, or performance characteristics. Given the schema complexity and lack of annotations/output schema, the description should do much more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'multiple notes' which hints at the 'inputs' array parameter, but doesn't explain the structure of input objects (id, properties, associations) or their purposes. The description adds minimal value beyond what's inferable from the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Read') and resource ('multiple notes'), specifying it's a batch operation ('in a single request'). It distinguishes from individual note tools like notes_get, but doesn't explicitly differentiate from other batch read tools like calls_batch_read or emails_batch_read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like notes_get (for single notes) or notes_list (for listing notes). The description mentions batch reading but doesn't provide context about efficiency trade-offs, prerequisites, or when batch operations are preferred over individual calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it's an update operation (implying mutation) but doesn't cover critical aspects like required permissions, whether updates are atomic or partial, error handling for invalid inputs, rate limits, or what the response contains. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—'Update multiple notes in a single request'—front-loading the core action. It's appropriately sized for the tool's complexity, though brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (batch mutation with nested parameters), lack of annotations, 0% schema description coverage, and no output schema, the description is incomplete. It doesn't address behavioral traits, parameter details, or output expectations, leaving an agent under-informed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It mentions 'multiple notes' but doesn't detail the 'inputs' array structure, required fields (e.g., 'id' and 'properties'), or property specifics like 'hs_note_body'. The description adds minimal value beyond the schema, failing to clarify parameter meanings 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 'Update multiple notes in a single request' clearly states the verb ('update'), resource ('notes'), and scope ('multiple in a single request'), which distinguishes it from sibling tools like 'notes_update' (single note) and 'notes_batch_create' (create rather than update). However, it doesn't explicitly differentiate from 'notes_batch_archive' or other batch operations beyond the verb, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing note IDs), compare it to 'notes_update' for single updates, or specify scenarios where batch updates are preferred (e.g., efficiency for bulk edits). Without such context, an agent might misuse it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a list operation, implying read-only behavior, but doesn't disclose critical details like pagination (implied by 'limit' and 'after' parameters but not explained), rate limits, authentication needs, or what 'archived' filtering entails. The description is too vague to guide an agent on behavioral traits beyond basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and includes a key feature ('optional filtering'). Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain parameter meanings, return values, or behavioral constraints. For a list tool with filtering options, more context is needed to use it effectively, such as what 'notes' are or how filtering works.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 semantics (e.g., 'limit', 'after', 'properties', 'associations', 'archived'). The description adds minimal value beyond the schema, failing to clarify parameter purposes 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 'List all notes with optional filtering' clearly states the verb ('List') and resource ('notes'), and specifies scope ('all notes') with a feature ('optional filtering'). It distinguishes from siblings like notes_get (single note) and notes_search (search with criteria), though not explicitly named. However, it could be more specific about what 'notes' are 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. It mentions 'optional filtering' but doesn't specify when to use notes_list versus notes_search (which appears in siblings) or how filtering differs. No prerequisites, exclusions, or comparison to sibling tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Archive' implies a destructive/mutative operation, but the description doesn't clarify whether this is reversible, what permissions are required, if there are rate limits, or what happens to archived products. It lacks critical details about the mutation's nature and consequences.
Agents need to know what a tool does to the world before calling it. Descriptions 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 action and resource. There's no wasted language or redundancy, making it efficient to parse while still 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 1 parameter, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't address critical aspects like what 'archive' means operationally, error handling, batch limitations, or expected outcomes. The context demands more comprehensive guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions 'by ID' which hints at the 'productIds' parameter's purpose, but doesn't explain what format IDs should be in, if there are constraints on batch size, or what happens if some IDs are invalid. It adds minimal value beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('archive') and resource ('a batch of products by ID'), making the purpose immediately understandable. It distinguishes from individual archive operations by specifying 'batch' but doesn't explicitly differentiate from other batch operations like 'products_batch_update' or 'products_batch_create' among 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 is provided about when to use this tool versus alternatives. The description doesn't mention when to choose batch archive over individual 'products_archive', nor does it specify prerequisites, constraints, or appropriate contexts for use. Sibling tools include both individual and batch operations, but no comparison is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an update operation (implying mutation) but doesn't mention permissions required, whether changes are reversible, rate limits, error handling for invalid batches, or what the response contains. This leaves significant gaps 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 front-loads the core purpose. Every word contributes essential information about what the tool does and how to identify products, with zero wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 like permissions or error handling, provides minimal parameter guidance, and offers no information about return values or side effects, leaving the agent with significant uncertainty.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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' as a query param for alternative identification, but doesn't explain the 'inputs' array structure, the 'id' vs 'idProperty' usage, the 'properties' object fields, or the purpose of 'objectWriteTraceId'. With 1 parameter (inputs) containing complex nested objects, this minimal explanation is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('batch of products'), and specifies identification methods ('by internal ID, or unique values specified by the `idProperty` query param'). However, it doesn't distinguish this tool from sibling tools like 'products_update' (single update) or 'products_batch_create' (batch creation), 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_update' for single updates or 'products_batch_create' for batch creation. The description mentions the 'idProperty' parameter but doesn't explain when to use it versus the default 'id' method, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states the tool archives/deletes tasks, implying a destructive mutation, but lacks details on permissions, reversibility, error handling, or what 'archive' specifically entails (e.g., soft vs. hard delete). The parenthetical 'delete' adds some clarity but is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It front-loads the key action and resource, making it easy to scan. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive batch tool with no annotations, 0% schema coverage, and no output schema, the description is inadequate. It lacks critical context like side effects, return values, error conditions, and usage boundaries, 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 tasks' which hints at the 'taskIds' array parameter, but provides no details on format, constraints, or limits. The description adds minimal meaning 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 action ('archive (delete)') and resource ('multiple tasks') with the scope 'in a single request.' It distinguishes from the singular 'tasks_archive' sibling by specifying batch operation. However, it doesn't explicitly differentiate from other batch operations like 'tasks_batch_update' beyond the verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, constraints, or compare it to the singular 'tasks_archive' or other batch tools. Usage is implied by the name and description 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 the full burden of behavioral disclosure. It states it's a creation tool but doesn't mention permissions required, whether it's idempotent, rate limits, error handling for partial failures, or what the response looks like. For a batch mutation tool, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that directly states the tool's function. There's no wasted language or unnecessary elaboration, making it front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch creation tool with complex nested parameters (1 top-level parameter with deep nesting), no annotations, and no output schema, the description is insufficient. It doesn't address parameter structure, behavioral aspects like error handling, or what to expect upon success. The context demands more explanation than provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and a complex nested parameter structure (inputs array with properties and associations objects), the description provides no information about parameters. It doesn't explain what 'inputs' should contain, the required fields like 'hs_task_body' and 'hs_task_subject', or how to structure associations. This fails to compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('create') and resource ('multiple tasks'), making the purpose evident. It distinguishes from sibling 'tasks_create' by specifying batch capability, though it doesn't explicitly mention how it differs from other batch tools like 'tasks_batch_update' or 'tasks_batch_archive'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'tasks_create' for single tasks or other batch operations. The description implies batch creation but doesn't specify scenarios, prerequisites, or limitations for using this batch approach over individual creations.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 without disclosing behavioral traits. It doesn't mention whether this is safe (non-destructive), what permissions are required, rate limits, error handling, or the format of returned data, leaving significant gaps for a tool with one complex parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose, making it easy to parse quickly, 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 batch read tool with no annotations, 0% schema coverage, no output schema, and one complex nested parameter, the description is inadequate. It lacks details on behavior, parameters, return values, and usage context, making it incomplete for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter information. It doesn't explain what 'inputs' contains (e.g., task IDs, properties, associations), leaving all parameter semantics undocumented. This fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Read') and resource ('multiple tasks'), specifying it's a batch operation ('in a single request'). It distinguishes from individual task reading tools like 'tasks_get' but doesn't explicitly differentiate from other batch operations like 'tasks_batch_archive' or 'tasks_batch_update' among 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 is provided. The description doesn't mention when batch reading is preferred over individual 'tasks_get' or list operations like 'tasks_list', nor does it specify 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is an update operation but doesn't mention whether it requires specific permissions, whether updates are atomic or partial, what happens on partial failures, rate limits, or response format. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a basic tool description and front-loads the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch mutation tool with complex nested parameters (1 parameter with 8+ sub-properties), 0% schema description coverage, no annotations, and no output schema, the description is severely incomplete. It doesn't address behavioral aspects, parameter meanings, error handling, or what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about parameters beyond implying there's an array of task updates. The schema shows complex nested objects with required fields and enums, but the description doesn't explain what 'inputs' contains, the meaning of properties like 'hs_task_priority', or format requirements for dates/IDs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value 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'), specifying it's a batch operation ('in a single request'). It distinguishes from non-batch siblings like 'tasks_update' but doesn't explicitly differentiate from other batch tools like 'tasks_batch_create' or 'tasks_batch_archive'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'tasks_update' for single updates or 'tasks_batch_create' for creating tasks. There's no mention of prerequisites, error handling, or performance considerations for batch operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states this is a list operation with filtering, but doesn't disclose important behavioral aspects like whether this is a read-only operation, pagination behavior (implied by 'limit' and 'after' parameters), rate limits, authentication requirements, or what happens when no filters are applied.
Agents need to know what a tool does to the world before calling it. Descriptions 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. Every word earns its place with no wasted verbiage, though this conciseness comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the tool's behavior, parameter meanings, return format, or how it differs from similar tools. The agent would struggle to use this effectively without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 5 parameters, the description fails to compensate. It mentions 'optional filtering' but doesn't explain what parameters are available, what 'properties' or 'associations' mean in this context, or how filtering actually works. The schema provides structure but no semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('tasks'), making the purpose immediately understandable. However, it doesn't distinguish this from sibling tools like 'tasks_search' or 'tasks_get', which appear to offer similar functionality for retrieving tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'optional filtering' but provides no guidance on when to use this tool versus alternatives like 'tasks_search' or 'tasks_get'. There's no mention of prerequisites, typical use cases, or differentiation from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool archives/deletes multiple calls, implying a destructive mutation, but lacks details on permissions required, whether deletion is reversible, rate limits, or error handling for partial failures. This is inadequate for a destructive batch operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It front-loads the core action and scope, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive batch tool with no annotations and no output schema, the description is insufficient. It doesn't cover critical aspects like return values, error conditions, idempotency, or how it differs from sibling tools. Given the complexity and risk of batch deletions, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only implies 'callIds' are needed without explaining format, constraints, or valid values. The baseline is 3 since the schema fully documents the parameter structure, but the description adds minimal semantic context beyond what's inferable from 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 ('Archive (delete)') and resource ('multiple call records'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from its sibling 'calls_archive' (which likely archives single calls), leaving room for ambiguity about when to choose one over the other.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'calls_archive' (for single calls) or other batch operations. The description mentions 'multiple call records' but doesn't clarify thresholds, prerequisites, or performance implications compared to non-batch methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'update' implying mutation but doesn't disclose behavioral traits like required permissions, whether updates are atomic/partial, error handling for invalid inputs, rate limits, or response format. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's 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 batch mutation tool with no annotations, 0% schema description coverage, and no output schema, the description is incomplete. It lacks details on behavioral context, parameter meanings, error handling, and output expectations, which are critical 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%, but the description adds minimal value by implying an array of inputs for batch updates. It doesn't explain the structure of 'inputs' (each with 'id' and 'properties'), the meaning of properties like 'hs_call_body', or required fields. Baseline 3 is given as it hints at batch semantics but doesn't compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('update multiple call records') and resource ('call records'), distinguishing it from single-update tools like 'calls_update'. However, it doesn't specify what fields can be updated or the scope of 'multiple', leaving some ambiguity compared to siblings 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 explicit guidance on when to use this tool versus alternatives like 'calls_update' (for single updates) or 'calls_batch_archive' (for batch archiving). The description implies batch operations but doesn't specify prerequisites, constraints, or comparative advantages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states a read operation ('Get'), implying it's non-destructive, but doesn't mention permissions, rate limits, pagination, or what 'all' entails (e.g., scope, format). This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, 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 lack of annotations, no output schema, and incomplete parameter documentation (0% coverage with 1 parameter), the description is insufficient. It doesn't explain return values, error conditions, or behavioral nuances, leaving the agent with minimal context for a read operation in a complex 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 schema has 1 parameter with 0% description coverage, and the tool description doesn't mention the 'archived' parameter at all. Since the parameter count is low (1) and the description doesn't compensate for the lack of schema details, the baseline of 3 is appropriate—it neither adds value nor fully addresses 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 ('all subscription definitions for the portal'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'communications_get_subscription_status' or 'communications_get_preferences', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'communications_get_subscription_status' or 'communications_get_preferences'. It lacks context about prerequisites, timing, or exclusions, leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a creation tool, implying mutation, but lacks critical details: it doesn't mention permissions required, whether it's idempotent, error handling for partial failures, rate limits, or what the response contains. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core action and scope, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks behavioral context (e.g., side effects, error handling), usage guidelines, and output details. The schema covers parameters well, but overall context is insufficient for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'multiple companies' but doesn't explain the 'inputs' parameter structure or the nested properties (e.g., 'properties', 'associations'). With 0% schema description coverage, the schema documents parameters thoroughly, so the description adds minimal value beyond implying batch capability. Baseline 3 is appropriate as the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create multiple companies') and the scope ('in a single request'), which is specific and distinguishes it from single-creation tools like 'crm_create_company'. However, it doesn't explicitly differentiate from other batch creation tools (e.g., 'crm_batch_create_contacts'), which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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., authentication), compare it to single-creation tools, or specify scenarios where batch creation is preferred (e.g., efficiency for bulk operations).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a creation operation (implying mutation/write), but doesn't mention permissions required, rate limits, whether it's idempotent, error handling for partial failures, or what the response looks like. For a batch write tool with zero annotation coverage, this 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 directly states the tool's function. There's no wasted language or unnecessary elaboration. It's appropriately sized for conveying 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 batch creation tool with complex nested parameters (multiple properties and associations), no annotations, and no output schema, the description is inadequate. It doesn't address behavioral aspects like error handling, doesn't explain parameter structures, and provides no usage context. The description fails to compensate for the lack of structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It mentions 'multiple leads' which hints at an array input, aligning with the 'inputs' parameter in the schema. However, it doesn't explain the structure of lead objects, required fields, or the 'associations' parameter. The description adds minimal value beyond what's obvious from the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('multiple leads'), specifying it's a batch operation ('in a single request'). It distinguishes from non-batch siblings like 'crm_create_lead', but doesn't explicitly differentiate from other batch create tools like 'crm_batch_create_companies' or 'crm_batch_create_contacts'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention when batch creation is preferable to single creation, nor does it reference other batch tools for different entity types. There's no context about prerequisites, limitations, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions batch creation but doesn't disclose critical traits like whether this is an atomic operation, error handling for partial failures, rate limits, authentication requirements, or what happens on success/failure. For a mutation tool with complex inputs, 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 communicates the core functionality without waste. It's appropriately sized for the tool's purpose and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch creation tool with no annotations, 0% schema description coverage, no output schema, and complex nested parameters, the description is insufficient. It doesn't address behavioral expectations, parameter meanings, error handling, or differentiation from sibling tools, leaving significant gaps for an AI agent to understand proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds no parameter information beyond what's implied by the tool name. It doesn't explain the 'objectType' enum values or the structure of 'inputs' array elements. With 2 parameters (one with enum) and complex nested schemas, the description fails to compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('multiple CRM objects') with the operational context ('in a single request'). It distinguishes from single-object creation tools but doesn't explicitly differentiate from other batch creation tools like crm_batch_create_companies or crm_batch_create_contacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools including specific batch creation tools (e.g., crm_batch_create_companies) and a generic single-object creation tool (crm_create_object), the description offers no context for choosing this multi-object, multi-type batch tool over more specialized 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 but only states it's an update operation. It doesn't disclose behavioral traits like whether this requires specific permissions, if updates are atomic or partial, error handling for failed updates, rate limits, 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'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 batch mutation tool with no annotations, no output schema, and complex nested parameters, the description is insufficient. It lacks critical context about behavior, error handling, permissions, and response format, leaving significant gaps for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'multiple companies' which implies an array input, aligning with the 'inputs' parameter in the schema. However, with 0% schema description coverage and 1 parameter (a complex nested array), the description doesn't add meaningful details about parameter structure, required fields, or property semantics beyond what's obvious from the name. Baseline 3 is appropriate as the schema provides structure but no 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 ('multiple companies'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'crm_batch_update_contacts' or 'crm_batch_update_objects' beyond specifying the 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 like 'crm_update_company' (single update) or other batch update tools for different resources. It mentions 'in a single request' which hints at efficiency but doesn't explicitly state use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a write operation ('Update') but doesn't disclose critical traits like required permissions, whether updates are partial or full, error handling for invalid inputs, rate limits, or what the response contains. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action and efficiently conveys the batch nature. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (batch mutation tool with 1 parameter but deeply nested schema), lack of annotations, and no output schema, the description is insufficient. It doesn't address behavioral aspects like side effects, error handling, or response format, leaving the agent with inadequate context to use the tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description adds no parameter-specific information beyond implying an array of contact updates. It doesn't explain the 'inputs' structure, required 'id' field, or the 'properties' object with its many fields. Baseline 3 applies as it minimally compensates 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 ('Update') and resource ('multiple contacts'), making the purpose immediately understandable. It distinguishes from single-contact update tools by specifying 'multiple contacts in a single request', though it doesn't explicitly differentiate from sibling 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 is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., contact IDs must exist), compare to single-contact updates (crm_update_contact), or specify limitations like batch size constraints. The description only states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'update' implying mutation but doesn't disclose behavioral traits like required permissions, whether updates are atomic or partial, error handling for invalid inputs, rate limits, or what the response contains. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and scope, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, 0% schema description coverage, and no output schema, the description is incomplete. It lacks crucial context like behavioral details, parameter guidance, and expected outcomes, which are essential 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 adds minimal value by implying the 'inputs' parameter is an array of lead updates, but doesn't explain the structure (id and properties) or provide examples. The schema details the nested properties, but the description doesn't clarify semantics beyond the basic concept.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value 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 the scope ('in a single request'), which is specific and distinguishes it from single-update tools like crm_update_lead. However, it doesn't explicitly differentiate from other batch update tools for different resources (e.g., crm_batch_update_companies), though the resource type is implied in the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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_update_lead for single updates or other batch tools for different resources. 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?
No annotations are provided, so the description carries full burden. It mentions retrieving 'specific properties and associations' but doesn't disclose behavioral traits like whether this is a read-only operation, authentication requirements, rate limits, error handling for invalid IDs, or what happens if properties/associations arrays are empty. The description is minimal and leaves critical behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get a single contact by ID') and adds necessary detail ('with specific properties and associations'). There's no wasted verbiage, and every word contributes 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?
Given no annotations, no output schema, and 0% schema description coverage for a 3-parameter tool, the description is incomplete. It covers the basic purpose but lacks details on behavioral traits, parameter usage, error handling, and output format. For a read operation with optional filtering parameters, 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.
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 with specific properties and associations', which maps to the three parameters (contactId, properties, associations), adding meaning about their purpose. However, it doesn't explain parameter formats (e.g., what valid contactId looks like, what properties are available, or how associations work), leaving significant gaps despite the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'a single contact by ID', specifying it retrieves 'specific properties and associations'. It distinguishes from siblings like crm_list_objects or crm_search_contacts by focusing on a single contact retrieval, but doesn't explicitly differentiate from crm_get_object or crm_get_company which follow similar patterns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like crm_search_contacts (for multiple contacts) or crm_get_object (for generic object retrieval). The description implies usage for single contact retrieval but lacks explicit context about prerequisites, error conditions, or comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions retrieving 'specific properties and associations', which hints at optional data inclusion, but doesn't describe authentication needs, rate limits, error handling, or what happens if the lead ID doesn't exist. For a read operation with zero annotation coverage, this leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. Every word earns its place, with no redundant information. It's appropriately sized for a straightforward retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't explain return values, error cases, or provide enough context for the agent to use it effectively without trial and error. For a tool with undocumented parameters and no structured metadata, more guidance is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'by ID with specific properties and associations', which maps to the three parameters (leadId, properties, associations) and clarifies their purpose. However, it doesn't explain parameter formats, constraints, or provide examples. The description adds basic meaning but doesn't fully compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'a single lead by ID', specifying it retrieves 'specific properties and associations'. It distinguishes from sibling tools like crm_list_objects or crm_search_leads by focusing on single-record retrieval. However, it doesn't explicitly differentiate from crm_get_object or other get operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like crm_get_lead_properties, crm_get_associations, or crm_search_leads. The description implies usage for retrieving a specific lead with optional data, but lacks explicit context about prerequisites, error conditions, or comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions 'optional filtering and pagination', it doesn't describe important behavioral aspects like whether this is a read-only operation, what permissions are required, rate limits, error conditions, or the format of returned data. For a listing tool with 5 parameters, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently communicates the core functionality. Every word earns its place - 'List' (action), 'CRM objects' (resource), 'specific type' (key constraint), and 'optional filtering and pagination' (additional capabilities). No wasted words 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 tool with 5 parameters, 0% schema description coverage, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what 'CRM objects' are, what filtering options exist beyond the implied parameters, what the response format looks like, or how pagination works in practice. The agent would need to guess about many important aspects of tool behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'specific type' (mapping to objectType), 'optional filtering' (potentially covering properties and archived), and 'pagination' (covering after and limit). With 0% schema description coverage, this adds some semantic context beyond the bare schema, but doesn't fully explain each parameter's purpose, format, or constraints beyond what's implied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value 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. It distinguishes from other tools by focusing on listing with filtering/pagination, but doesn't explicitly differentiate from sibling tools like 'crm_search_objects' or 'crm_list_association_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 mentions 'optional filtering and pagination' which implies some usage context, but provides no explicit guidance on when to use this tool versus alternatives like 'crm_search_objects' or 'crm_get_object'. There's no mention of prerequisites, limitations, or specific 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 full burden but lacks behavioral details. It mentions 'validated properties' but doesn't explain what validation entails, whether updates are reversible, permission requirements, or error handling. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, 0% schema description coverage, and no output schema, the description is insufficient. It doesn't cover behavioral traits, parameter details, or return values, leaving the agent poorly equipped to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description adds minimal semantics by implying 'contactId' identifies the contact and 'properties' contain validated fields, but it doesn't detail the nested property structure or enum values (e.g., 'lifecyclestage'), leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and target resource ('an existing contact'), making the purpose evident. However, it doesn't differentiate this tool from sibling tools like 'crm_update_company' or 'crm_update_lead', which follow the same pattern for different CRM entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a contact ID), exclusions, or compare it to batch update tools like 'crm_batch_update_contacts', 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 the full burden of behavioral disclosure. It states the tool updates with 'validated properties,' hinting at input validation, but doesn't cover critical aspects like required permissions, whether updates are partial or full, error handling, or mutation effects. 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 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 no annotations, no output schema, and low schema description coverage, the description is incomplete. It lacks details on behavioral traits, usage context, parameter meanings, and expected outcomes, making it insufficient for an agent to reliably invoke the tool without additional context or trial-and-error.
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%, but the description adds minimal value by implying 'validated properties' for the 'properties' parameter, suggesting input validation. However, it doesn't explain the 'leadId' parameter or detail the nested properties structure, leaving most parameter semantics undocumented. The baseline is adjusted due to low coverage, but the description doesn't fully compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('an existing lead'), specifying it's for modification rather than creation. It distinguishes from sibling tools like 'crm_create_lead' by focusing on updates, though it doesn't explicitly differentiate from similar update tools like 'crm_batch_update_leads' or 'crm_update_object'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a lead ID), exclusions, or compare it to batch update tools or other CRM update 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a destructive action ('Archive (delete)') but lacks details on permissions required, whether the action is reversible, rate limits, or what happens to the email (e.g., moved to trash vs. permanent deletion). 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, front-loaded sentence that directly states the action and resource. There is no wasted wording, making it efficient and easy to parse, though this conciseness 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 tool's complexity (a destructive mutation with 1 parameter), lack of annotations, and no output schema, the description is incomplete. It fails to address critical aspects like behavioral traits, parameter details, 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.
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 for undocumented parameters. It implies the parameter 'emailId' by context but doesn't explain its format, source, or constraints. The description adds minimal value beyond the schema, which only shows emailId as a required string, resulting in a baseline score due to incomplete compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Archive (delete)') and resource ('an email record'), making the purpose specific and understandable. It distinguishes from siblings like emails_get or emails_update by focusing on archival/deletion. However, it doesn't explicitly differentiate from emails_batch_archive, which handles multiple emails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing an emailId), exclusions (e.g., not for batch operations), or comparisons to siblings like emails_batch_archive for multiple emails or emails_delete if deletion differs from archiving.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the destructive action ('archive/delete') but doesn't specify whether this is permanent deletion or reversible archiving, what permissions are required, rate limits, error handling for partial failures, or what the response contains. The parenthetical '(delete)' adds some clarity but leaves ambiguity about the actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action. Every word serves a purpose with no wasted verbiage, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive batch operation with no annotations, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't address critical aspects like response format, error conditions, idempotency, or system behavior when processing multiple records. The agent lacks sufficient context to use this tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies the parameter relates to 'multiple email records' but doesn't explain what emailIds represent, their format, or constraints. The description adds minimal value beyond what's inferable from the schema's parameter name and type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('archive/delete') and resource ('multiple email records') with the scope 'in a single request'. It distinguishes from the singular 'emails_archive' sibling tool by specifying batch operation, though it doesn't explicitly mention this distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like the singular 'emails_archive' or other batch operations. The description doesn't mention prerequisites, constraints, or typical use cases for batch archiving versus individual operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action is destructive ('archive/delete'), which is helpful, but lacks critical details like whether archiving is permanent or reversible, what permissions are required, if there are rate limits for batch operations, or what happens if some IDs fail. This leaves significant gaps for a destructive batch operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('archive/delete') and scope ('multiple meetings in a single request'). There's no wasted verbiage, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive batch operation with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It lacks essential context such as error handling, response format, side effects, or prerequisites. The agent would struggle to use this tool correctly without guessing at critical behavioral aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'multiple meetings' which implies the 'meetingIds' parameter, but doesn't add meaningful semantics beyond what the schema already shows (an array of strings). With 0% schema description coverage, the description doesn't compensate by explaining format requirements (e.g., ID structure), size limits, or handling of invalid IDs. The baseline is appropriate given the minimal parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value 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'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'meetings_delete' (single meeting deletion) or 'meetings_batch_update' (batch modification), which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when batch archiving is preferable to individual deletion ('meetings_delete'), nor does it reference related batch operations like 'meetings_batch_update' or 'meetings_batch_create' for 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. It mentions 'archive (delete)', implying a destructive operation, but doesn't specify if this is permanent or reversible, what permissions are required, or what happens to associated data. For a mutation tool with zero annotation coverage, this leaves critical behavioral aspects 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 extremely concise—just three words—and front-loaded with the core action and resource. There's no wasted language, 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 tool's complexity (a destructive operation with one parameter), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral details like permanence, permissions, or error handling, nor does it explain return values or usage context relative to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't explicitly mention parameters, but with only one parameter (noteId) and 0% schema description coverage, it implicitly clarifies that the tool operates on a single note. Since there are zero parameters with descriptions in the schema, the description's focus on a singular note adds meaningful context 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 'Archive (delete) a note' clearly states the action (archive/delete) and resource (note), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'notes_batch_archive' or 'notes_delete' (if that existed), nor does it clarify what 'archive' means versus 'delete' in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are sibling tools like 'notes_batch_archive' for multiple notes and 'notes_delete' (implied by other domains like meetings), but no indication of when to choose this single-note archive over batch operations or other deletion methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool archives (deletes) multiple notes, indicating a destructive mutation, but lacks critical behavioral details: whether archiving is permanent or reversible, what permissions are required, if there are rate limits, how errors are handled for partial failures, or what the response looks like. The description is minimal and doesn't compensate for the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence with zero wasted words. It's front-loaded with the core action and resource. Every word earns its place, making it efficient for quick understanding, 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 destructive batch operation with no annotations, no output schema, and minimal parameter guidance, the description is incomplete. It doesn't address key contextual aspects: the effect of archiving (permanent vs. recoverable), error handling, response format, or integration with sibling tools. The simplicity of the input schema (one parameter) doesn't compensate for the lack of behavioral and output information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'multiple notes' which implies the 'noteIds' parameter, but adds no semantic detail beyond what the schema shows (an array of strings). With 0% schema description coverage, the description doesn't explain what note IDs are, their format, or constraints (e.g., maximum array size). It provides marginal value, but the baseline is 3 since the schema fully defines the parameter structure, even 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 ('Archive (delete) multiple notes') and resource ('notes'), making the purpose evident. It specifies batch operation ('in a single request'), which distinguishes it from single-note operations. However, it doesn't explicitly differentiate from sibling 'notes_archive' (single-note version) or other batch archive tools for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when batch archiving is preferred over single-note archiving ('notes_archive'), nor does it reference other batch operations like 'notes_batch_create' or 'notes_batch_update'. There's no context 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?
No annotations are provided, so the description carries full burden. It mentions the action is 'Move... to the recycling bin' which implies a destructive operation that changes state, but doesn't specify whether this is reversible, what permissions are required, whether it triggers notifications, or what happens to associated data. The description is minimal and lacks important behavioral context for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that directly states the tool's purpose with zero wasted words. The description is front-loaded with the core action and doesn't include any unnecessary information. It's appropriately sized for a simple archival 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 destructive mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after archival, whether the action is reversible, what permissions are needed, or what the response contains. The tool name suggests it archives products specifically, but the description says 'Object' generically, creating ambiguity. More context is needed 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 schema provides no parameter documentation. The description mentions 'ID' which maps to the single 'productId' parameter, giving basic semantic meaning. However, it doesn't specify the ID format, whether it's a numeric ID, UUID, or something else, nor does it explain where to find this ID. The description adds minimal value beyond the parameter name itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Move') and target ('Object identified by ID'), specifying it goes 'to the recycling bin'. It distinguishes from deletion tools by indicating archival rather than permanent removal. However, it's slightly vague about what type of 'Object' it refers to (product vs. other entities).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like permanent deletion tools or batch operations. The description implies it's for moving individual products to recycling, but doesn't mention prerequisites, permissions needed, or when to choose batch_archive instead. Sibling tools include products_batch_archive, but no comparison is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that this is a mutation operation ('partial update'), mentions error conditions for invalid properties, and explains how to clear values (empty string). However, it lacks critical behavioral details like permission requirements, whether changes are reversible, rate limits, or what the response contains.
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 brief (two sentences) and front-loaded with the core purpose. Every sentence adds value: the first states the action, the second provides important behavioral constraints. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 coverage, no output schema, and complex nested parameters, the description is inadequate. It doesn't explain what happens after the update, what properties are valid, error handling beyond the mentioned cases, or how this differs from similar update tools in the sibling list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 2 parameters (productId and properties), the description adds minimal value. It implies 'productId' identifies the object and 'properties' contains fields to update, but doesn't explain what specific properties are updatable, their formats, or constraints beyond the empty string clearing behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('perform a partial update') and resource ('Object identified by ID'), which is specific. However, it doesn't distinguish this tool from sibling tools like 'products_batch_update' or 'crm_update_object', which appear to serve similar update functions in different contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'products_batch_update' or 'products_create'. It mentions error conditions for read-only/non-existent properties, but this is more about input validation than usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates this is a destructive operation ('delete'), but doesn't specify whether archiving is permanent or reversible, what permissions are required, or what happens to associated data. For a destructive tool with zero annotation coverage, this leaves critical behavioral traits undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single phrase that communicates the essential action and target. There's no wasted language, and the parenthetical '(delete)' efficiently clarifies the destructive nature. This is appropriately sized for a simple 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 destructive operation with no annotations and no output schema, the description is inadequate. It doesn't explain what 'archive' means operationally, whether the action can be undone, what the response looks like, or error conditions. Given the complexity of a delete/archive operation and the complete lack of structured metadata, the description should provide more complete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only one parameter (callId) and 0% schema description coverage, the description doesn't add any parameter-specific information beyond what's implied by the tool name. However, for a single-parameter tool where the parameter meaning is obvious from context (callId for a call archive operation), the baseline is appropriately high. The description could have specified format requirements but doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Archive (delete)') and resource ('a call record'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from its sibling 'calls_batch_archive' or other archive tools for different resources, 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 'calls_batch_archive' for multiple calls or 'calls_delete' if it existed. There's no mention of prerequisites, constraints, or typical use cases, leaving the agent with insufficient context for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a 'Get' operation which implies read-only, but doesn't disclose authentication requirements, rate limits, error conditions, or what happens if the company ID doesn't exist. For a read operation 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the core purpose, zero wasted words. Every element ('Get', 'single company', 'by ID', 'specific properties and associations') earns its place by conveying essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description provides basic purpose and parameter mapping. However, it lacks details on return format, error handling, authentication, and doesn't fully compensate for the missing structured documentation. It's minimally adequate but has clear 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?
Schema description coverage is 0%, so the description must compensate. It mentions 'by ID' (mapping to companyId), 'specific properties' (mapping to properties array), and 'associations' (mapping to associations array). This provides basic semantic meaning for all three parameters, but doesn't explain format details, optionality, or the enum values for associations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), resource ('a single company'), and key parameters ('by ID with specific properties and associations'). It distinguishes from sibling tools like crm_search_companies (which searches multiple companies) and crm_list_objects (which lists objects). However, it doesn't explicitly differentiate from crm_get_object, which might be a more generic version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like crm_search_companies or crm_get_object. The description implies it's for retrieving a specific company by ID, but doesn't mention prerequisites, when not to use it, or compare with other get/read tools in the CRM domain.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 a read operation ('List'), implying it's likely non-destructive, but doesn't specify permissions, rate limits, pagination, or error handling. This leaves significant gaps in understanding how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('List all available association types') and includes the key condition. There is no wasted wording, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 parameters with enums, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavior, usage context, and output format, which are needed for a complete understanding in a CRM system with many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'for a given object type pair', which hints at the two parameters (fromObjectType and toObjectType) but doesn't explain their semantics beyond what the schema's enums imply. With 0% schema description coverage, it adds minimal value, but the schema's enums provide clear options, keeping it at a baseline level.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all available association types') with the condition 'for a given object type pair', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'crm_get_associations' or 'crm_batch_create_associations', which might handle similar association concepts 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?
The description provides no guidance on when to use this tool versus alternatives, such as other CRM tools for associations or object listings. It lacks context about prerequisites, dependencies, or typical scenarios for listing association types, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'archive (delete)', implying a destructive operation, but doesn't specify if this is permanent, reversible, requires permissions, or has side effects. For a mutation tool with zero annotation coverage, this leaves critical behavioral traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single phrase with no wasted words. It's front-loaded with the core action, 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 tool's destructive nature (implied by 'delete'), no annotations, no output schema, and incomplete parameter documentation (0% coverage), the description is insufficient. It should address behavioral risks, return values, or usage context to be complete for safe agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't mention parameters, but with only one parameter (taskId) and 0% schema description coverage, the baseline is high. Since there are zero parameters described in either schema or description, and the tool's purpose is straightforward, the description adequately implies the need for a task identifier without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('archive/delete') and resource ('a task'), making the purpose unambiguous. However, it doesn't distinguish this tool from sibling tools like 'tasks_batch_archive' or 'tasks_delete' (if present), which would require explicit differentiation 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 'tasks_batch_archive' or 'tasks_delete' (implied by sibling list). The description merely states what it does without context about prerequisites, constraints, or comparison to other task-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: pagination behavior (cursor-based via 'after' parameter), response structure (paging.next.after property), and that it's a read operation. However, it doesn't mention rate limits, authentication requirements, error conditions, or whether this is a safe operation (though 'Read' implies non-destructive).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey core functionality and key behavioral details. The first sentence states the purpose, the second explains parameter usage and response structure. No wasted words, though the second sentence is somewhat complex and could be split for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read/list tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description provides adequate basics: purpose, pagination behavior, and parameter context for 2 of 3 parameters. However, it lacks details about the 'limit' parameter, error handling, authentication needs, and what a 'product' represents in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for three undocumented parameters. It provides meaningful context for two parameters: 'properties' (controls what is returned) and 'after' (paging cursor token). It doesn't explain 'limit' at all, but does clarify the relationship between 'after' and the response structure, adding significant 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 tool's purpose: 'Read a page of products' specifies both the verb (read) and resource (products). It distinguishes this from other product tools like products_create or products_update by focusing on reading/listing. However, it doesn't explicitly differentiate from products_search or products_read among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through mentioning paging and property selection, suggesting this is for paginated listing with optional field selection. However, it doesn't explicitly state when to use this versus products_search (which appears in siblings) or products_read, nor does it mention any prerequisites or exclusions.
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/BlackSand-Software/hubspot-mcp/badges/card.svg)](https://glama.ai/mcp/servers/BlackSand-Software/hubspot-mcp)

Score Badge

Copy to your README.md:

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

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