HubSpot MCP Server

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It mentions 'Archive (delete)', implying a destructive operation, but doesn't disclose critical behavioral traits such as whether archiving is permanent, reversible, requires specific permissions, or has side effects like removing associated data. This leaves significant gaps for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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 a simple tool, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral implications, return values, error conditions, or how it fits within the broader system (e.g., sibling tools). This leaves the agent with insufficient context for safe and effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description doesn't add parameter details beyond the schema, but with only 1 parameter (callId) and 0% schema description coverage, the baseline is high. The tool name and description imply 'callId' identifies the call to archive, which is sufficient given the minimal parameter count.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Archive') and resource ('a call record'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'calls_batch_archive' or clarify what 'archive' means versus 'delete' in parentheses.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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_archive' or other archive tools for different resources. The description lacks context about prerequisites, permissions, or typical scenarios for archiving calls.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but only states the action ('Archive (delete)') without detailing behavioral aspects. It doesn't specify if the deletion is permanent or reversible, what permissions are required, rate limits, error handling, or what happens to associated data. The parenthetical '(delete)' adds some clarity but is insufficient for a destructive operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core action and resource. There's no wasted verbiage, and it directly communicates the tool's function without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive batch operation with no annotations, 0% schema description coverage, and no output schema, the description is inadequate. It lacks critical details about permissions, consequences, error handling, and response format, leaving significant gaps for an AI agent to safely invoke this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description doesn't mention the 'callIds' parameter at all, and with 0% schema description coverage, it adds no semantic value beyond what the bare schema provides. However, since there's only one parameter and its purpose is somewhat inferable from the tool name, the baseline is 3 as it doesn't actively mislead but 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Archive (delete)') and resource ('multiple call records') with the scope 'in a single request'. It distinguishes from the singular 'calls_archive' sibling by specifying batch operation, though it doesn't explicitly contrast with other batch operations like 'calls_batch_read' or 'calls_batch_update'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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, permissions needed, or compare it to the singular 'calls_archive' or other batch operations like 'calls_batch_read', leaving the agent to infer usage from the name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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, rate limits, error handling for partial failures, or what happens if duplicate records are submitted. For a batch write tool with zero annotation coverage, this is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that communicates the core functionality without unnecessary words. It's appropriately sized for a tool with a clear primary function, though the brevity comes at the cost of completeness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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, no output schema, and a complex input schema (nested objects with required fields and associations), the description is inadequate. It doesn't address success/failure responses, partial batch processing behavior, or provide any examples. The agent would struggle to use this tool effectively without significant trial and error.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description mentions 'multiple call records' which hints at the 'inputs' array parameter, but with 0% schema description coverage and a complex nested schema (containing properties and associations objects), the description adds minimal value. It doesn't explain what constitutes a valid call record, required fields beyond what the schema shows, or the structure of the 'inputs' array. The baseline is 3 since the description provides some context about batch creation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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'), and specifies the operation mode ('in a single request'). It distinguishes from the singular 'calls_create' sibling tool by indicating batch capability. However, it doesn't explicitly contrast with other batch tools like 'calls_batch_update' or 'calls_batch_read'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when batch creation is preferable to individual creation, or how it differs from other batch operations like 'calls_batch_update' or 'calls_batch_read'. There's no mention of prerequisites, constraints, or typical use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a read operation (implying non-destructive), but doesn't address critical aspects like authentication requirements, rate limits, error handling for invalid IDs, whether all records must exist, response format, or pagination. For a batch operation with complex nested parameters, this leaves significant behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core function. Every word earns its place: 'Read' (action), 'multiple call records' (resource and scope), 'in a single request' (operational context). There's no redundancy or unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (batch operation with nested parameters), absence of annotations, and no output schema, the description is insufficiently complete. It doesn't explain the input structure, expected output, error conditions, or behavioral constraints. For a tool that presumably returns multiple records with optional property/association filtering, much more context is needed for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate but provides no parameter information. The schema shows a complex nested structure with 'inputs' array containing objects with 'id', 'properties', and 'associations' fields, but the description doesn't explain what these mean, how to format IDs, what properties can be requested, or what associations do. This leaves parameters largely undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 call records'), and specifies the operational context ('in a single request'). It distinguishes from individual read tools like 'calls_get' by emphasizing batch capability. However, it doesn't explicitly differentiate from other batch tools like 'calls_batch_archive' or 'calls_batch_update' beyond the 'read' verb.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when batch reading is preferable to individual 'calls_get' or 'calls_list', nor does it reference sibling tools like 'calls_batch_read' vs 'notes_batch_read' for different resource types. The agent receives no usage context beyond the basic function.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It states 'Update' implying mutation but doesn't mention required permissions, whether updates are partial or full, if changes are reversible, rate limits, or response format. For a batch mutation tool with zero annotation coverage, this is a significant gap in safety and operational context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to scan and understand quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a batch mutation tool with no annotations, 0% schema description coverage, and no output schema, the description is inadequate. It lacks critical context such as authentication needs, error handling for partial failures, rate limits, and what the tool returns. The schema provides parameter details, but the description fails to add necessary behavioral and operational insights.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description adds minimal value by implying the 'inputs' parameter contains call records to update. However, it doesn't explain the structure of 'inputs' (e.g., array of objects with 'id' and 'properties'), the meaning of properties like 'hs_call_direction', or required fields beyond what the schema shows. Baseline 3 is appropriate as the schema details parameters, but the description doesn't fully compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Update') and resource ('multiple call records'), specifying it's a batch operation ('in a single request'). It distinguishes from the singular 'calls_update' sibling tool by emphasizing batch capability, though it doesn't explicitly contrast with other batch operations like 'calls_batch_create' or 'calls_batch_read'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when 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_update' for single updates or 'calls_batch_create' for creating new records. It mentions 'multiple call records' but doesn't specify thresholds, prerequisites, or error handling for batch operations, 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It states 'create' implies a write operation but doesn't disclose any behavioral traits: no information on permissions required, whether it's idempotent, rate limits, error handling, or what happens on success/failure. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no wasted words. It's appropriately sized for a basic tool, though this conciseness comes at the cost of completeness. Every word earns its place by stating the core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (2 parameters with nested objects, no output schema, no annotations), the description is severely incomplete. It doesn't explain what a 'call record' entails, how to structure inputs, what the tool returns, or any behavioral context. For a creation tool in a rich CRM environment with many siblings, this minimal description is inadequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning no parameters are documented in the schema. The description adds no parameter information beyond the tool name—it doesn't explain the 'properties' and 'associations' parameters, their structure, or required fields like 'hs_call_body' and 'hs_call_title'. With 2 parameters and nested objects, the description 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Create a new call record' restates the tool name 'calls_create' with minimal elaboration. It specifies the verb 'create' and resource 'call record', but doesn't distinguish it from sibling tools like 'calls_batch_create' or other create operations (e.g., 'meetings_create', 'notes_create'). This is borderline tautological rather than providing meaningful differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when 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 'calls_batch_create' for bulk operations, 'calls_update' for modifications, or other creation tools for different entities. 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.

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. It doesn't mention whether this is a read-only operation, what permissions are needed, what happens if the call doesn't exist, or what format/details are returned. For a tool with 3 parameters and no annotation coverage, this is inadequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no wasted words. It's appropriately sized for a basic 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain what details are returned, how parameters affect the response, or any behavioral context needed for proper use. The conciseness comes at the expense of necessary information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 'callId' should be, what 'properties' array controls, or what 'associations' does despite having an enum. The description adds zero value beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Get') and resource ('details of a specific call'), making the purpose understandable. However, it doesn't distinguish this from sibling tools like 'calls_list' or 'calls_search' which also retrieve call information, missing an opportunity for precise differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when 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 mentions 'a specific call' which implies needing a call ID, but doesn't explicitly state this as a prerequisite or compare to sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'optional filtering' which hints at query capabilities, but fails to describe critical behaviors: whether this is a read-only operation, if it supports pagination (implied by 'limit' and 'after' parameters but not explained), what the return format looks like, or any rate limits. For a list tool with 5 parameters, this leaves significant gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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 purpose ('List all calls') followed by a key feature ('with optional filtering'). Every word serves a purpose, making it highly efficient despite its limitations in completeness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 5 undocumented parameters, no annotations, and no output schema, the description is severely inadequate. It doesn't explain what the tool returns, how filtering works, what the parameters mean, or how this differs from similar tools. The minimal description fails to provide the context needed 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning none of the 5 parameters are documented in the schema. The description only mentions 'optional filtering' generically without explaining what parameters are available, what they do, or how to use them. This fails to compensate for the complete lack of schema documentation, leaving parameters essentially undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('List') and resource ('calls'), specifying the action and target. It mentions 'optional filtering' which adds context about functionality. However, it doesn't distinguish this tool from sibling tools like 'calls_search' or 'calls_get', 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'calls_search' or 'calls_get'. There's no mention of prerequisites, limitations, or specific scenarios where this tool is preferred over siblings. The phrase 'optional filtering' is too vague to constitute meaningful usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 calls with specific filters' implies a read-only operation but doesn't mention authentication needs, rate limits, pagination behavior (despite 'limit' and 'after' parameters), or what happens when no results match. It lacks crucial context for safe and effective use.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at 5 words with zero waste. It's front-loaded with the core action and resource. While under-specified, it's not verbose or poorly structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 severely incomplete. It doesn't explain the search functionality's scope, parameter usage, return format, or behavioral constraints needed for a tool with this level of complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for 5 undocumented parameters. 'Search calls with specific filters' only vaguely references 'filters' (matching filterGroups parameter) but doesn't explain the complex filter structure, properties selection, sorting, pagination, or limit constraints. 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Search calls with specific filters' clearly states the verb (search) and resource (calls), but it's vague about what 'specific filters' means and doesn't distinguish this tool from sibling tools like calls_list or other search tools (emails_search, meetings_search, etc.). It provides basic purpose but lacks specificity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like calls_list or other domain-specific search tools. It mentions 'specific filters' but doesn't explain what scenarios require this tool over simpler listing options or when to choose other search tools in the sibling list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 permissions required, whether changes are reversible, rate limits, error handling, or what happens to unspecified properties. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action, making it easy to parse quickly, though this brevity comes at the cost of detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 0% schema description coverage), the description is incomplete. It doesn't explain the update behavior, return values, error cases, or how it differs from batch operations. For a tool that modifies data with rich input structure, more context is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 'update an existing call record' but provides no details on what 'callId' or 'properties' entail, what fields can be updated, or the meaning of nested properties like 'hs_call_direction'. It 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Update an existing call record' clearly states the verb (update) and resource (call record), but it's vague about what specifically gets updated. It doesn't distinguish this tool from sibling tools like 'calls_batch_update' or 'calls_update' vs 'calls_create', leaving the scope ambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like 'calls_batch_update' for multiple updates, 'calls_create' for new records, or 'calls_get' for reading. The description implies usage for updating existing calls but offers no context on prerequisites, limitations, or best practices.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 a read operation ('Get'), which implies it's likely non-destructive, but doesn't confirm safety, permissions required, rate limits, or what the return format looks like. For a tool with zero annotation coverage, this leaves significant behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with zero wasted words. It's perfectly front-loaded with the core purpose, making it easy to parse quickly. Every word earns its place in conveying the essential function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain parameter meanings, return values, behavioral constraints, or differentiation from siblings. The conciseness comes at the cost of necessary context for proper tool selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions 'for a contact' which hints at the 'contactId' parameter, but doesn't explain what 'contactId' represents, its format, or mention the optional 'subscriptionId' parameter at all. This fails to compensate for the schema's lack of descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get') and target ('communication preferences for a contact'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'communications_get_subscription_status' or 'communications_get_subscription_definitions', but the specificity of 'preferences' versus 'status' or 'definitions' 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.

Does the description explain when 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'. There's no mention of prerequisites, use cases, or exclusions, leaving the agent to infer usage from the tool name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 subscription definitions', implying a read-only operation, but doesn't clarify if it's safe (non-destructive), what permissions are required, or how results are returned (e.g., pagination, format). This leaves significant gaps in understanding the tool's behavior 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.

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 with the core action and resource, making it easy to parse quickly, which is ideal for conciseness in tool descriptions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the context: no annotations, no output schema, and low schema description coverage (0%), the description is incomplete. It doesn't explain the parameter's purpose, return values, or behavioral traits like safety or permissions. For a tool with one parameter and no structured support, the description should provide more context to be fully helpful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has one parameter ('archived' of type boolean) with 0% schema description coverage, meaning the schema provides no details on its meaning. The description doesn't mention this parameter at all, failing to compensate for the coverage gap. However, with only one parameter, the baseline is higher, but the lack of any parameter explanation in the description limits the score to the minimum viable level.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 '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 handle related but different data, so it falls short of 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'communications_get_subscription_status' (which retrieves statuses rather than definitions) or 'communications_get_preferences', leaving the agent to infer usage based on naming alone, which is insufficient for clear decision-making.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden for behavioral disclosure. It states a read operation ('Get'), implying it's likely non-destructive, but doesn't specify authentication needs, rate limits, error handling, or output format. For a tool with no annotations, 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (2 required parameters, no output schema, no annotations), the description is incomplete. It lacks details on parameter semantics, behavioral traits, and output expectations, making it insufficient for an agent to confidently 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning parameters 'subscriptionId' and 'contactIds' are undocumented in the schema. The description mentions 'subscription status for multiple contacts', which hints at the purpose of 'contactIds' but doesn't explain what 'subscriptionId' represents, expected formats, or constraints. It adds minimal value beyond the parameter names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'subscription status for multiple contacts', which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'communications_get_preferences' or 'communications_get_subscription_definitions', which reduces it from 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage from the tool name alone among many sibling tools in communications and other domains.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 ('subscribe') which implies a write/mutation operation, but doesn't mention permission requirements, whether this is reversible (though 'communications_unsubscribe_contact' exists as sibling), rate limits, or what happens if the contact is already subscribed. The description is minimal and lacks important behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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 scannable. 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.

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 enum), no annotations, and no output schema, the description is inadequate. It doesn't explain the legal basis parameters, doesn't describe what 'all email communications' entails, and provides no information about return values or error conditions. The agent would struggle to use this tool correctly based on the description alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 aligns with 'contactId', but doesn't explain the two portalSubscriptionLegalBasis parameters at all. For a tool with 3 parameters (one with complex enum values), the description adds minimal semantic 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.

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 distinguish from sibling tools like 'communications_unsubscribe_contact' or 'communications_update_preferences', but the verb 'subscribe' provides inherent differentiation from those operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when 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 typical usage scenarios, leaving the agent to infer context from the tool name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. While 'Unsubscribe' implies a mutation operation, the description doesn't specify whether this is reversible, what permissions are required, whether it affects historical data, or what happens if the contact doesn't exist. For a mutation tool with zero annotation coverage, 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for the tool's apparent complexity and front-loads the core functionality without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with 3 parameters (including complex enum-based parameters), 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the legal basis parameters, doesn't describe what happens after unsubscription, and provides no context about error handling or system behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage for all 3 parameters, the description provides no information about what 'contactId', 'portalSubscriptionLegalBasis', or 'portalSubscriptionLegalBasisExplanation' mean or how they should be used. The description mentions 'a contact' which vaguely relates to 'contactId', but doesn't explain the legal basis parameters at all, leaving critical parameters undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Unsubscribe') and resource ('a contact from all email communications'), making the purpose immediately understandable. It distinguishes this tool from sibling tools like 'communications_subscribe_contact' and 'communications_update_subscription_status' by focusing on complete opt-out from all communications.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when 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' for partial unsubscriptions or 'communications_update_preferences'. It doesn't mention prerequisites, error conditions, or when this operation is appropriate versus other subscription management tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. While 'Update' implies a mutation operation, the description doesn't disclose any behavioral traits: no information about permissions required, whether this is reversible, rate limits, or what happens to existing preferences not mentioned. 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.

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 with the essential information about what the tool does.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 compensate for the missing structured information about parameters, behavior, or return values. 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.

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 have descriptions in the schema. The description adds no parameter information beyond what's implied by the tool name ('communication preferences for a contact' hints at contactId and preferences). It doesn't explain the complex nested preferences object with its enums (status, legalBasis) or the relationship between subscriptionId parameters at different levels.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 ('communication preferences for a contact'), providing specific verb+resource. However, it doesn't distinguish this tool from sibling tools like 'communications_update_subscription_status' or 'communications_subscribe_contact', which appear to handle similar communication preference operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools dealing with communications preferences (communications_update_subscription_status, communications_subscribe_contact, communications_unsubscribe_contact), there's no indication of when this specific update tool is appropriate versus those other options.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 indicates a batch update operation but doesn't disclose whether this requires special permissions, what happens on partial failures, whether changes are reversible, or any rate limits. The description is insufficient 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero wasted words. It's perfectly front-loaded and appropriately sized for the tool's apparent complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a batch mutation tool with 2 parameters (including a complex array structure), 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns, error handling, or important behavioral aspects like whether all updates must succeed or if partial updates are allowed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'subscription status for multiple contacts' which hints at the 'updates' array parameter but doesn't explain the 'subscriptionId' parameter at all or provide any details about the structure of update objects (contactId, status, legalBasis fields). 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Update') and target ('subscription status for multiple contacts'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'communications_subscribe_contact' or 'communications_unsubscribe_contact', which appear to handle single-contact operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, appropriate contexts, or comparison to sibling tools like 'communications_subscribe_contact' for single updates or 'communications_update_preferences' for different types of updates.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. While 'archive/delete' implies a destructive operation, the description doesn't clarify whether this is reversible, what permissions are required, what happens to related data, or what the response looks like. This leaves significant behavioral 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise - a single sentence that gets straight to the point with zero wasted words. It's perfectly front-loaded with the core action and resource.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive operation with 4 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what constitutes an 'association', what archiving/deleting means in this context, or provide any 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage and 4 parameters (2 with enums), the description provides no information about what the parameters mean or how they should be used. The schema shows object types and IDs, but the description doesn't explain what an 'association' consists of or how these parameters identify it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('archive/delete') and resource ('association between two objects'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'crm_batch_archive_associations' or 'crm_archive_object', which would require more specific scope information.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like batch operations or other archive tools. With numerous sibling tools available (including 'crm_batch_archive_associations'), the lack of differentiation leaves the agent without clear selection criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Archive (delete)' implies a destructive operation, it doesn't clarify whether this is reversible, what permissions are required, whether it's a soft or hard delete, or what happens to associated data. For a destructive operation with zero annotation coverage, this is inadequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is perfectly concise - a single sentence that communicates the essential action and target. There's no wasted language or unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive operation with no annotations and no output schema, the description is insufficient. It doesn't address critical behavioral aspects like reversibility, permissions, or what constitutes successful completion. The agent would need to guess about important operational characteristics.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds no parameter information beyond what's in the schema (objectType and objectId). With 0% schema description coverage, the description doesn't compensate by explaining what these parameters mean or how they should be used. However, the parameter names are self-explanatory, so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Archive (delete)') and resource ('a CRM object'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'crm_batch_archive_objects' or other archive tools for specific object types like 'companies_archive' or 'contacts_archive', which would be needed 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. With many sibling tools including batch operations and specific object type archives, the agent receives no help in selecting this single-object archive tool over other options.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but only states the action ('archive (delete)') without behavioral details. It doesn't disclose if this is irreversible, requires specific permissions, has rate limits, returns confirmation, or affects related data. For a destructive batch operation, 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly despite its brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive batch operation with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It lacks critical context about parameters, behavioral implications, error handling, and output format, 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'fromObjectType', 'toObjectType', or 'inputs' represent, their enums, or the structure of the 'inputs' array. With 3 undocumented parameters, the description fails to provide meaningful semantics beyond the tool name.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('archive (delete)') and resource ('multiple associations') with the scope 'in a single request'. It distinguishes from the singular 'crm_archive_association' sibling by specifying batch operations, though it doesn't explicitly contrast with other batch tools like 'crm_batch_create_associations'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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, error handling, or compare with other batch operations like 'crm_batch_archive_objects' or singular 'crm_archive_association', leaving the agent to infer usage from the name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 objects, implying a destructive mutation, but lacks critical details: whether archiving is permanent or reversible, required permissions, rate limits, error handling for partial failures, or confirmation prompts. The parenthetical '(delete)' suggests permanence but isn't explicit about consequences.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core action ('Archive (delete) multiple CRM objects') and adds operational context ('in a single request'). There is zero redundancy or unnecessary elaboration—every word serves a purpose. It's appropriately sized for a tool with a straightforward name and two parameters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive batch operation with 2 parameters (0% schema coverage), no annotations, and no output schema, the description is incomplete. It lacks essential context: parameter semantics, behavioral traits (permanence, permissions, errors), output expectations, and differentiation from siblings. The conciseness comes at the cost of adequacy, leaving significant gaps for safe and correct usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'objectType' represents (the enum values like 'companies', 'contacts'), what 'objectIds' should contain (e.g., CRM IDs), format requirements, or constraints (e.g., maximum batch size). The description's mention of 'CRM objects' loosely relates to 'objectType' but provides no actionable details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 CRM objects') with the operational context ('in a single request'). It distinguishes from single-object operations like 'crm_archive_object' by emphasizing 'multiple' and 'batch' nature. However, it doesn't explicitly differentiate from other batch archive tools for different resource types (e.g., 'crm_batch_archive_associations').

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when batch archiving is preferable to individual archiving ('crm_archive_object'), nor does it clarify the relationship with sibling tools like 'crm_batch_archive_associations' or domain-specific batch archives (e.g., 'calls_batch_archive'). No prerequisites, limitations, or performance considerations are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a creation operation but doesn't mention whether it requires specific permissions, if it's idempotent, what happens on partial failures, rate limits, or response format. For a batch mutation tool with zero annotation coverage, this leaves critical behavioral traits undocumented.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is maximally concise with a single clear sentence that front-loads the essential action. 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a batch creation tool with 3 parameters (including complex nested structures), 0% schema description coverage, no annotations, and no output schema, the description is severely inadequate. It doesn't explain what associations are, how they differ from regular objects, what the expected response looks like, or any error conditions - leaving too many gaps for effective tool use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 'associations' are, what 'fromObjectType' and 'toObjectType' represent, or the structure of 'inputs' array. With 3 parameters (including complex nested objects) completely undocumented, the description fails to add meaningful semantics beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 scope ('in a single request'), which is a specific verb+resource combination. It distinguishes from single-association creation tools like 'crm_create_association' by emphasizing batch capability, though it doesn't explicitly mention sibling differentiation beyond the 'batch' aspect.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'crm_create_association' for single associations or other batch tools. There's no mention of prerequisites, performance considerations, or error handling for batch operations, 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.

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 creates companies but doesn't mention required permissions, whether creation is idempotent, error handling for partial failures, rate limits, or what happens on success. For a mutation tool with zero annotation coverage, this leaves critical behavioral aspects unspecified.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a tool with a self-explanatory name and follows front-loading principles by stating the core functionality immediately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex batch creation tool with 1 parameter (but deeply nested structure), 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the input format, behavioral constraints, or expected outcomes, 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for undocumented parameters. The description mentions 'multiple companies' which hints at an array input, but doesn't explain the 'inputs' parameter structure, required fields, or the meaning of nested properties like 'associations'. It adds minimal value beyond what's inferable from the tool name.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Create multiple companies') and resource ('companies'), making the purpose immediately understandable. It distinguishes from single-company creation tools like 'crm_create_company' by specifying 'in a single request', though it doesn't explicitly differentiate from other batch creation tools like 'crm_batch_create_contacts'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, limitations, or compare it to single-company creation or other batch operations. The agent must infer usage from the tool name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 lacks critical behavioral details: whether this requires specific permissions, if it's idempotent, rate limits, error handling for partial failures, or what the response contains. 'Create multiple contacts' implies mutation but doesn't elaborate on consequences.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex mutation tool with 1 parameter (but deeply nested structure), 0% schema coverage, no annotations, and no output schema, the description is severely inadequate. It doesn't address parameter semantics, behavioral traits, error handling, or output expectations, leaving significant gaps for agent understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate but provides no parameter information. It doesn't explain the 'inputs' array structure, required fields like 'properties', or optional associations. The complex nested schema (with 18+ property fields and associations) remains undocumented beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Create multiple contacts') and resource ('contacts') with the specific context of batch processing ('in a single request'). However, it doesn't differentiate from sibling tools like crm_create_contact or crm_batch_create_companies, which would require explicit comparison.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like crm_create_contact (single contact creation) or other batch tools (crm_batch_create_companies). The description implies batch usage but doesn't specify scenarios, prerequisites, or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but offers minimal behavioral insight. It confirms a write operation ('Create') but doesn't disclose permissions needed, rate limits, error handling for partial failures, or what the response contains. For a batch mutation tool, this lack of context is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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 context, 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.

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 inadequate. It lacks details on behavioral traits, parameter usage, error handling, and response format, leaving the agent under-informed for a complex mutation operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description adds no parameter details beyond implying an array input for 'multiple leads'. It doesn't explain the 'inputs' structure, required fields like 'properties', or optional ones like 'associations'. The schema provides rich detail, but the description doesn't compensate for the coverage gap, resulting in a baseline score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Create multiple leads') and resource ('leads') with the specific context of batch processing ('in a single request'). It distinguishes from single-create tools like 'crm_create_lead' by emphasizing batch capability, though it doesn't explicitly differentiate from other batch 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, limitations, or compare it to single-create ('crm_create_lead') or other batch tools (e.g., 'crm_batch_create_companies'), leaving the agent to infer usage from the name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It states this is a creation tool ('Create'), implying it's a write/mutation operation, but doesn't disclose behavioral traits like required permissions, rate limits, error handling for partial failures, or whether it's idempotent. For a batch write tool with zero annotation coverage, this is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero waste. It's front-loaded with the core action ('Create multiple CRM objects') and adds necessary context ('in a single request'). Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (batch write operation with 2 parameters, 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't explain parameters, behavioral constraints, or output format. For a tool that creates multiple objects with nested structures, more guidance is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 'CRM objects' and 'single request', but doesn't explain the two parameters ('objectType' and 'inputs') or their structure. The description adds minimal value beyond what's inferred from the name, 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Create') and resource ('multiple CRM objects'), specifying it's a batch operation ('in a single request'). It distinguishes from single-object creation tools like 'crm_create_object' by emphasizing 'multiple' and 'batch', but doesn't explicitly contrast with other batch tools like 'crm_batch_create_companies'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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', 'crm_batch_create_contacts'), the description doesn't explain when this generic batch tool is preferable over type-specific ones or single-object creation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It claims a 'Create' operation, which implies mutation, but the tool name suggests reading. This inconsistency fails to disclose behavioral traits like whether it's read-only, requires permissions, handles errors, or returns data, making it inadequate 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no wasted words. It's front-loaded and appropriately sized for its content, though the brevity contributes to its inadequacy in other dimensions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 a misleading description, the tool definition is highly incomplete. It lacks essential details on behavior, parameters, and usage, making it insufficient for effective agent operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so parameters are undocumented in the schema. The description adds no information about any parameters (e.g., objectType, objectIds, properties), failing to compensate for the coverage gap. This leaves the agent with no semantic understanding of inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Create multiple CRM objects in a single request' states a verb ('Create') and resource ('CRM objects'), but it's misleading given the tool name 'crm_batch_read_objects' and sibling tools like 'crm_batch_create_objects' that suggest this is a read operation, not a create operation. This creates confusion rather than clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 CRM tools (e.g., crm_batch_create_objects, crm_batch_update_objects, crm_get_object, crm_list_objects), the description offers no context on use cases, prerequisites, or distinctions, leaving the agent to guess.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 'update' implying mutation but fails to describe critical aspects like required permissions, whether updates are partial or full, error handling for invalid inputs, or rate limits. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded with the core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a batch mutation tool with no annotations, 0% schema description coverage, and no output schema, the description is inadequate. It lacks details on behavior, parameters, error handling, and output format, leaving the agent poorly equipped to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 explain the 'inputs' array structure, the 'id' and 'properties' fields, or the specific properties that can be updated (e.g., name, domain). This leaves the agent with only the raw schema to interpret.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('update') and resource ('multiple companies'), making the purpose evident. However, it doesn't distinguish this tool from its sibling 'crm_batch_update_objects' or 'crm_batch_update_contacts', which perform similar batch updates on different entity types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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_company' (single update) or other batch tools. The description merely states what it does without context on appropriate use cases or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's an update operation, implying mutation, but doesn't cover critical aspects like required permissions, whether changes are reversible, rate limits, error handling for partial failures, or what the response looks like. This is a significant gap for a batch mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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, clearly stating the core functionality without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a batch update tool with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It lacks details on behavior, error handling, response format, and usage context, making it inadequate for safe and effective tool invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description mentions 'multiple contacts' which hints at the 'inputs' array parameter, but with 0% schema description coverage, it doesn't explain the structure of 'inputs' (e.g., that each item requires 'id' and 'properties' objects) or the specific fields within 'properties'. It adds minimal value beyond what the schema already defines through its properties.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'crm_batch_update_companies' or 'crm_update_contact', which would require mentioning it's specifically for contacts in batch mode.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when batch updates are preferred over single updates (e.g., 'crm_update_contact'), or any limitations, 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. 'Update multiple leads' implies a write operation, but it doesn't disclose critical behavioral traits: whether it's atomic, what happens on partial failures, required permissions, rate limits, or what the response contains. This is inadequate for a mutation tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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 concept and front-loads the core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 doesn't address behavioral aspects, return values, error handling, or usage 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description mentions 'multiple leads' which hints at the array structure of the 'inputs' parameter, but schema description coverage is 0% and the description doesn't explain the nested 'id' and 'properties' structure or the meaning of individual fields. It adds minimal value beyond what's implied by the tool name.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('update') and resource ('multiple leads'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'crm_batch_update_companies' or 'crm_batch_update_contacts', which have identical descriptions except for the resource type.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when 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_lead' (single update) or other batch tools. There's no mention of prerequisites, performance considerations, or error handling for batch operations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It states 'Update multiple CRM objects' which implies a write/mutation operation, but doesn't disclose behavioral traits like required permissions, whether updates are atomic/partial, error handling for failed items, rate limits, or what the response contains. This is inadequate for a batch mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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 any wasted words. It's appropriately sized and front-loaded with the core functionality.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a batch mutation tool with 2 parameters (one with enum), 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't address key contextual aspects like what object types are supported (though hinted in schema), update behavior, error handling, or output format, 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.

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 what 'objectType' is, the structure of 'inputs' items, or the meaning of 'properties' within them. The description adds minimal value beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Update multiple') and resource ('CRM objects') with the scope 'in a single request', which is specific and informative. However, it doesn't explicitly distinguish this tool from sibling batch update tools like crm_batch_update_companies or crm_batch_update_contacts, which would require a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. With many sibling tools including specific batch updates (e.g., crm_batch_update_companies) and single-object updates (e.g., crm_update_object), the agent has no indication of when this general batch tool is preferred over more specific ones.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure but fails to do so. It doesn't indicate whether this is a mutating operation (implied by 'Create'), what permissions are required, if there are rate limits, what happens on failure, or the expected output format. This leaves the agent with insufficient information to invoke the tool safely and effectively.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with no wasted words. It is front-loaded with the core action and resource, making it efficient and easy to parse, 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a 5-parameter mutation tool with no annotations, 0% schema description coverage, and no output schema, the description is inadequate. It doesn't explain the tool's behavior, parameter meanings, or expected outcomes, leaving significant gaps for an AI agent to understand and use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, meaning none of the 5 parameters are documented in the schema. The description adds no information about parameters, such as explaining what 'fromObjectType' and 'toObjectType' represent, the format of IDs, or the structure of 'associationTypes'. This fails to compensate for the lack of schema documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the action ('Create') and resource ('association between two objects'), which provides a basic understanding. However, it lacks specificity about what an 'association' entails in this CRM context and doesn't distinguish this tool from sibling tools like 'crm_batch_create_associations' or 'crm_create_object', 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention when to choose this over 'crm_batch_create_associations' for bulk operations or 'crm_create_object' for creating the objects themselves. The description offers no context about prerequisites 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but only mentions 'validated properties' without explaining what validation entails, error handling, permissions required, or mutation effects. This leaves significant behavioral gaps for a creation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that is front-loaded with the core action. However, it could be more structured by explicitly mentioning key parameters or usage context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with 2 parameters (including nested objects), 0% schema coverage, no annotations, and no output schema, the description is inadequate. It lacks details on input semantics, behavioral traits, and expected outcomes, leaving the agent poorly informed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate but only vaguely references 'validated properties' without detailing the 2 parameters (properties and associations) or their nested structures. It fails 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the action ('Create') and resource ('new company'), which is clear but basic. It doesn't specify what distinguishes it from siblings like 'crm_batch_create_companies' or 'crm_create_object', making it somewhat vague in context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as batch creation tools or other CRM create operations. The description lacks any context about prerequisites, timing, or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure but fails to do so. It states 'Create' implies a write operation but omits critical details: whether this requires admin permissions, if it's idempotent, potential side effects (e.g., affecting existing data), rate limits, or error handling. This leaves the agent uninformed about the tool's behavior 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with no wasted words, making it highly concise. It is front-loaded with the core action, though this brevity comes at the cost of completeness, as it lacks necessary details for effective tool use.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (11 parameters, 5 required), lack of annotations, 0% schema description coverage, and no output schema, the description is severely incomplete. It does not compensate for the missing structured data, failing to provide usage context, parameter explanations, behavioral traits, or output expectations, making it inadequate for agent guidance.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, meaning none of the 11 parameters are documented in the schema. The description adds no parameter information beyond the tool name, failing to explain what 'name', 'label', 'type', or other parameters mean, their formats, or how they interact. This is inadequate for a tool with many parameters, especially required ones.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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) with minimal elaboration, making it tautological. It specifies the verb ('Create') and resource ('company property') but lacks detail on what a 'company property' entails or how it differs from similar tools like crm_create_contact_property or crm_create_lead_property, offering no sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., required permissions), context for creation (e.g., during company setup), or comparisons to sibling tools like crm_get_company_properties or batch operations, leaving the agent with no usage direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. 'Create' implies a write operation, but the description doesn't mention required permissions, whether the operation is idempotent, what happens on validation failure, or what the response contains. 'Validated properties' hints at validation but lacks specifics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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 create operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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, complex nested parameters, and 0% schema description coverage, the description is inadequate. It doesn't explain the association parameter, validation specifics, error conditions, 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description mentions 'validated properties' which loosely relates to the 'properties' parameter, but with 0% schema description coverage and 2 parameters (one being a complex nested object), it adds minimal value. The baseline is 3 since the schema provides structure but no descriptions, and the tool description doesn't meaningfully compensate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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. However, it doesn't differentiate from sibling tools like crm_batch_create_contacts or crm_create_lead, which would require explicit comparison to achieve 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.

Does the description explain when 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 entity creation tools. It mentions 'validated properties' but doesn't explain what validation entails or when it might fail.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action 'create' without detailing permissions required, side effects (e.g., impact on existing contacts), rate limits, or response format. For a mutation tool with 11 parameters and no annotations, this is a significant gap in transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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. Every word earns its place, but the description is under-specified rather than concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (11 parameters, 5 required, no output schema, and no annotations), the description is completely inadequate. It lacks purpose differentiation, usage guidelines, behavioral context, and parameter explanations, making it insufficient for an agent to understand or invoke the tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 explaining what 'name', 'label', 'type', or other fields mean in the context of contact properties. This leaves all parameters semantically undefined, failing to compensate for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Create a new contact property' restates the tool name (crm_create_contact_property) with minimal elaboration, making it tautological. It specifies the verb 'create' and resource 'contact property' but lacks detail on what a contact property is or how it differs from similar tools like crm_create_company_property or crm_create_lead_property, failing to distinguish from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, context, or exclusions, such as when to create a contact property versus using existing properties or other CRM tools like crm_create_contact. This leaves the agent without direction for appropriate tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 hints at validation ('validated properties') but doesn't specify what validation entails, error handling, permissions required, or whether the operation is idempotent. For a creation tool with 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no wasted words. It's appropriately sized for a basic tool description, though it could benefit from being more informative while maintaining brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (2 parameters with nested objects, 0% schema coverage, no annotations, no output schema), the description is inadequate. It doesn't explain parameter usage, validation details, return values, or behavioral traits, leaving the agent poorly equipped to use this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the description must compensate. It mentions 'validated properties' but doesn't explain the 'properties' or 'associations' parameters, their structure, or validation rules. With 2 parameters (one required) and complex nested objects, this minimal description fails to add meaningful semantic context beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 lead'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'crm_batch_create_leads' or 'crm_create_contact', which have similar creation purposes but target different resources or batch operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'crm_batch_create_leads' for bulk operations or 'crm_create_contact' for different entity types. It mentions 'validated properties' but doesn't explain validation rules or prerequisites, 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. 'Create' implies a write/mutation operation, but the description doesn't mention permission requirements, whether this affects existing leads, what happens on duplicate property names, or what the response looks like. For a creation tool with 11 parameters and no annotation coverage, this is a significant behavioral information gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at just 4 words, with no wasted language. It's front-loaded with the core action and resource. While this conciseness comes at the cost of completeness, the structure itself is efficient with every word carrying essential meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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), complete lack of annotations, 0% schema description coverage, and no output schema, the description is completely inadequate. A creation tool with this many configuration options needs significantly more context about parameter meanings, behavioral implications, and expected outcomes to be usable by an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description provides zero information about any of the 11 parameters. With schema description coverage at 0% and no parameter guidance in the description, the agent has no semantic understanding of what 'name', 'label', 'type', 'fieldType', 'groupName', or any other parameters mean or how they should be used. This is particularly problematic for parameters with enums ('type' and 'fieldType') where the description offers no context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Create a new lead property' clearly states the verb ('Create') and resource ('lead property'), making the basic purpose understandable. However, it doesn't distinguish this tool from similar sibling tools like 'crm_create_company_property' or 'crm_create_contact_property' - it only specifies the resource type but not how it differs from other property creation tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. With multiple CRM property creation tools in the sibling list (company_property, contact_property, lead_property), there's no indication of when lead properties specifically should be created, what prerequisites might exist, or how this relates to other CRM operations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Create' implies a write/mutation operation, but the description doesn't address critical behavioral aspects: required permissions, whether the operation is idempotent, what happens on failure, rate limits, or what the response contains (since no output schema exists). 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with just four words. It's front-loaded with the core action ('Create a new CRM object') and contains no wasted words. While this brevity contributes to clarity, it also leads to underspecification in other dimensions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (3 parameters with nested objects, no annotations, no output schema), the description is incomplete. It doesn't explain what a 'CRM object' is, how to use the parameters, what happens after creation, or how this tool relates to its many siblings. For a mutation tool with significant parameter complexity and no structured documentation support, the description provides inadequate context for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 (objectType, properties, associations) are documented in the schema. The description adds no parameter information beyond the tool name—it doesn't explain what 'objectType' values mean, what 'properties' should contain, or how 'associations' work. With low schema coverage, the description fails to compensate, leaving parameters largely unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Create a new CRM object' states the verb ('Create') and resource ('CRM object'), making the purpose clear at a basic level. However, it's vague about what constitutes a 'CRM object' and doesn't distinguish this tool from its many siblings (e.g., crm_create_company, crm_create_contact, crm_batch_create_objects). The description lacks specificity about the scope of objects it can create.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. With numerous sibling tools like crm_create_company, crm_create_contact, and crm_batch_create_objects, there's no indication of when this generic 'create object' tool is preferred over the more specific ones or the batch version. No prerequisites, exclusions, or context for usage are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 'Get all associations' but doesn't disclose behavioral traits like pagination (implied by 'after' and 'limit' parameters), rate limits, authentication needs, or what 'associations' entail. The description is minimal and lacks critical operational context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for its content, though it 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.

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 many sibling tools, the description is incomplete. It lacks details on return values, error handling, pagination behavior, and distinctions from other tools, making it inadequate for effective agent use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 type' which loosely relates to 'fromObjectType' and 'toObjectType', but doesn't explain parameter meanings, relationships (e.g., 'fromObjectId' as the source object), or usage of 'after' and 'limit' for pagination. The description adds minimal value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get all associations of a specific type between objects' clearly states the verb ('Get') and resource ('associations'), but it's vague about scope and doesn't differentiate from sibling tools like 'crm_list_association_types' or 'crm_get_object'. It specifies 'specific type' but doesn't clarify what that means in context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. With many sibling tools like 'crm_list_association_types', 'crm_get_object', and 'crm_search_objects', the description offers no context about prerequisites, typical use cases, or distinctions from other association-related tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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, implying read-only behavior, but doesn't disclose any behavioral traits like authentication requirements, rate limits, error conditions, or what happens if the company ID doesn't exist. The mention of 'specific properties and associations' hints at optional filtering but lacks detail on defaults or constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core purpose ('Get a single company by ID') and adds qualifying details ('with specific properties and associations'). There's no wasted language, though it could be slightly more structured with bullet points for clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., company object structure), error handling, or prerequisites. For a read operation with three parameters, more context is needed to use it effectively without trial and error.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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), adding semantic meaning to all three parameters. However, it doesn't provide format details (e.g., what property names are valid) or usage examples, leaving gaps in understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and resource 'a single company by ID', specifying it retrieves 'specific properties and associations'. It distinguishes from siblings like crm_search_companies (search) and crm_batch_read_objects (batch operations). However, it doesn't explicitly contrast with 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like crm_search_companies (for finding companies without an ID) or crm_batch_read_objects (for multiple companies). It mentions retrieving 'specific properties and associations' but doesn't explain when to include them versus using other tools for associations/properties.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get all properties' implies a read-only operation, but it doesn't specify permissions required, rate limits, pagination, or what 'all' entails (e.g., all properties globally or per company). The description lacks critical behavioral details needed for safe and effective use, especially for a tool that might return large datasets.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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. Every word earns its place by conveying essential information without redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 2 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't address parameter meanings, behavioral traits like data scope or limitations, or return format. For a tool that could involve complex data retrieval, this leaves significant gaps in understanding how to use it effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 2 parameters (archived, properties) with 0% description coverage, meaning the schema provides no semantic information. The description doesn't mention these parameters at all, failing to compensate for the schema gap. It doesn't explain what 'archived' filters or what 'properties' array contains, leaving parameters undocumented and ambiguous.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get all properties for companies' clearly states the verb ('Get') and resource ('properties for companies'), making the purpose immediately understandable. It distinguishes from sibling tools like crm_get_company (which gets company details) and crm_get_contact_properties (which focuses on contacts). However, it doesn't specify what 'properties' means (e.g., custom fields, attributes), 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.

Does the description explain when 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_get_contact_properties (for contact properties). There are no prerequisites, exclusions, or context about filtering options like archived status, 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.

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 retrieves data ('Get'), implying a read-only operation, but doesn't disclose behavioral aspects like authentication requirements, rate limits, error conditions, response format, or whether it's idempotent. The description adds minimal context beyond the basic operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with the core purpose. No wasted words or redundant information. Efficiently communicates the essential operation in a compact form.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 3 parameters, 0% schema description coverage, no annotations, and no output schema, the description is insufficient. It doesn't explain the return value format, error handling, or provide enough detail about parameters (especially the 'associations' enum values). 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.

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 'by ID' (mapping to contactId) and 'with specific properties and associations' (hinting at the 'properties' and 'associations' parameters), adding some semantic meaning. However, it doesn't explain what 'properties' or 'associations' represent, their formats, or the enum values for 'associations'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 contact'), and key mechanism ('by ID with specific properties and associations'). It distinguishes from generic retrieval by specifying the ID-based lookup and optional property/association filtering. However, it doesn't explicitly differentiate from sibling tools like 'crm_get_object' or 'crm_search_contacts' which might also retrieve contacts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. The description implies it's for retrieving a known contact by ID, but doesn't mention when to choose this over 'crm_get_object' (which might handle multiple object types) or 'crm_search_contacts' (for unknown IDs). 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Get all properties' implies a read operation, but it lacks details on permissions, rate limits, pagination, or error handling. It doesn't specify if it returns archived contacts by default or how the 'archived' parameter affects results, leaving 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.

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, making it easy to parse quickly. Every word contributes directly to understanding the tool's function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (2 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain return values, parameter usage, or behavioral constraints. For a read operation with undocumented inputs, more context is needed to guide effective tool invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description must compensate for two undocumented parameters ('archived' and 'properties'). However, it adds no parameter semantics beyond implying 'properties' might be fetched. It doesn't explain what 'archived' does or how 'properties' array filters results, failing to bridge the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 action (get) and resource (contact properties), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'crm_get_contact' or 'crm_get_company_properties' beyond the obvious contact focus, 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. There are many sibling CRM tools (e.g., crm_get_contact, crm_get_company_properties, crm_search_contacts), but the description offers no context about use cases, prerequisites, or comparisons, leaving the agent to infer usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a read operation ('Get') but doesn't disclose if it's safe (non-destructive), requires specific permissions, has rate limits, or what happens on errors (e.g., invalid leadId). The mention of 'specific properties and associations' hints at filtering, but lacks details on default behavior or response format. For a read tool with zero annotation coverage, this is inadequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core purpose ('Get a single lead by ID') and adds essential constraints ('with specific properties and associations'). There is no wasted verbiage, repetition, or unnecessary elaboration, 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (3 parameters, no output schema, and no annotations), the description is incomplete. It doesn't cover behavioral aspects like safety or permissions, parameter details beyond hints, or what the output contains (e.g., lead data structure). For a read operation with multiple parameters and no structured guidance, this leaves significant gaps for an agent to operate effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the schema provides no parameter documentation. The description adds some value by mentioning 'by ID' (mapping to leadId) and 'with specific properties and associations' (hinting at the properties and associations parameters), but doesn't explain their formats, optionality, or semantics (e.g., what happens if properties is omitted). It partially compensates for the coverage gap but leaves key details unclear, warranting a baseline score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 lead'), and key constraints ('by ID with specific properties and associations'). It distinguishes from sibling tools like crm_list_objects or crm_search_leads by specifying retrieval of a single entity rather than listing or searching. However, it doesn't explicitly differentiate from crm_get_object or crm_get_lead_properties, which might have overlapping functionality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites like authentication, compare it to similar tools (e.g., crm_get_object for generic retrieval or crm_get_lead_properties for property-specific access), or specify use cases like needing detailed lead data versus just properties. This leaves the agent to infer usage from the name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Get' implies a read operation, but the description doesn't specify whether this requires authentication, has rate limits, returns paginated results, or what format the properties come in. It mentions 'all properties' but doesn't clarify if this includes archived properties (though there's an 'archived' parameter in the schema). For a 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at just 5 words. It's front-loaded with the core action and resource. There's zero wasted language or redundancy. While it may be too brief for completeness, as a standalone statement it's efficiently structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 2 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain what the parameters do, what authentication is needed, what format the properties are returned in, or how this differs from related lead tools. For a tool with this level of complexity and minimal structured documentation, the description should provide more contextual information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the description must compensate but fails to do so. The tool has 2 parameters ('archived' and 'properties'), but the description mentions neither. 'Get all properties for leads' doesn't explain what the 'archived' boolean controls or what the 'properties' array parameter does (likely to filter properties). With low schema coverage and no parameter explanation in the description, this creates significant gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get all properties for leads' clearly states the verb ('Get') and resource ('properties for leads'), making the purpose understandable. However, it's somewhat vague about scope - 'all properties' could mean all property definitions or all property values for specific leads. It doesn't differentiate from sibling tools like crm_get_lead (which gets lead data) or crm_create_lead_property (which creates properties).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. There are multiple CRM-related tools for leads (crm_get_lead, crm_search_leads, crm_batch_read_objects, etc.), but the description offers no context about when this specific property-fetching tool is appropriate versus retrieving lead data directly. No prerequisites, exclusions, or alternatives are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a 'Get' operation which implies read-only behavior, but doesn't confirm whether it's safe, whether it requires authentication, what happens with invalid IDs, or any rate limits. The description is minimal and doesn't provide the behavioral context needed 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at just 7 words. It's front-loaded with the core purpose and contains no unnecessary words. Every word earns its place, making it maximally efficient in terms of word count.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 4 parameters, 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns, how to interpret results, error conditions, or the meaning of any parameters. The minimal description leaves too many gaps for effective tool use given the complexity of the input schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage for all 4 parameters, the description provides no information about what 'objectType', 'objectId', 'properties', or 'associations' mean. The description mentions 'by ID' which hints at objectId, but doesn't explain the enum values for objectType, the purpose of properties filtering, or what associations returns. 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Get') and resource ('a single CRM object by ID'), making the purpose unambiguous. It distinguishes from sibling tools like crm_list_objects (which lists multiple objects) and crm_search_objects (which searches by criteria rather than direct ID lookup). However, it doesn't explicitly mention the specific object types available (companies, contacts, etc.) that are defined in the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like crm_get_company, crm_get_contact, or crm_get_lead (which appear to be specialized versions), nor does it explain when to use this generic tool versus those specific ones. There's also no mention of prerequisites or error conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 ('List') but doesn't specify whether this requires authentication, has rate limits, returns paginated results, or what format the output takes. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every element ('List,' 'available association types,' 'given object type pair') earns its place by contributing essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read operation with 2 parameters and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on authentication needs, return format, error conditions, or how this tool fits within the broader CRM context. Without annotations or output schema, more behavioral context would be helpful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description clarifies that parameters represent 'object type pairs,' which adds meaningful context beyond the schema's enum values. With 0% schema description coverage, this compensation is valuable, though it doesn't explain what 'custom' means or provide examples of typical pairs. The baseline would be lower without this clarification.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('List') and resource ('association types') with specific scope ('for a given object type pair'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'crm_get_associations' or 'crm_batch_create_associations', 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'crm_get_associations' (which retrieves actual associations rather than types) or 'crm_create_association' (which creates associations). There's no mention of prerequisites, typical use cases, or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 filtering and pagination but doesn't specify whether this is a read-only operation, what permissions are required, how rate limits apply, what happens with archived objects, or what the return format looks like. For a list operation with 5 parameters, this leaves significant behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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 list operation, though it could benefit from more detail given the parameter complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 5 parameters, 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain return values, error conditions, authentication requirements, or how parameters interact. Given the complexity and lack of structured documentation, the description should provide much more context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage for 5 parameters, the description must compensate but only vaguely mentions 'optional filtering and pagination.' It doesn't explain what 'objectType' values mean, what 'properties' refers to, how 'after' works for pagination, what 'limit' constraints exist, or how 'archived' affects results. The description adds minimal value beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('List') and resource ('CRM objects of a specific type'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like crm_search_objects or crm_batch_read_objects, which might offer similar functionality with different approaches.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions 'optional filtering and pagination' but provides no guidance on when to use this tool versus alternatives like crm_search_objects or crm_batch_read_objects. There's no mention of prerequisites, performance considerations, or typical use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. 'Search' implies a read operation, but the description doesn't disclose pagination behavior (despite 'limit' and 'after' parameters), rate limits, authentication requirements, or what happens with complex filter queries. The description adds minimal behavioral context beyond the basic operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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. However, it's arguably too concise given the complexity of the tool with 5 parameters and 0% schema coverage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with 5 parameters, 0% schema coverage, no output schema, and no annotations, the description is inadequate. It doesn't explain the complex filtering system, pagination, sorting, or what properties can be returned. The agent would struggle to use this tool effectively without additional documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for 5 undocumented parameters. The description only mentions 'company-specific filters' which vaguely relates to 'filterGroups' parameter. It doesn't explain 'properties', 'limit', 'after', or 'sorts' parameters, nor provide examples of filter syntax or property names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the verb ('search') and resource ('companies'), but is vague about scope and functionality. It mentions 'company-specific filters' but doesn't clarify what this means or how it differs from generic search. Compared to sibling tools like crm_search_contacts and crm_search_leads, the differentiation is minimal.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. There are multiple search tools (crm_search_contacts, crm_search_leads, crm_search_objects) but no indication of when company search is appropriate versus object search or other methods. No mention of prerequisites or limitations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but reveals nothing about behavioral traits. It doesn't mention whether this is a read-only operation, what permissions are needed, pagination behavior, rate limits, error conditions, or what the response looks like. 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.

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 under-specified rather than concise - it lacks necessary detail for a tool with 5 complex parameters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with 5 parameters (including complex nested filterGroups), 0% schema description coverage, no annotations, and no output schema, the description is completely inadequate. It doesn't explain how to construct queries, what properties are available, pagination via 'after', or what results to expect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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' but doesn't explain what filterGroups, properties, limit, after, or sorts parameters do, their formats, or how they interact. This leaves critical search functionality undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Search contacts with contact-specific filters' states the verb (search) and resource (contacts), but is vague about what 'contact-specific filters' means. It doesn't specify what distinguishes this from other search tools like crm_search_companies or crm_search_leads beyond the resource type.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like crm_get_contact, crm_list_objects, or other search tools. The description implies it's for searching contacts, but doesn't specify use cases, prerequisites, or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It only states it 'searches' without disclosing behavioral traits like pagination (implied by 'after' parameter), rate limits, authentication needs, or what happens on no matches. For a search tool with 5 parameters and no annotation coverage, this is inadequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no wasted words. It's appropriately sized and front-loaded, though its brevity contributes to lack of detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 logic, no output schema, and no annotations), the description is incomplete. It doesn't explain parameter usage, return values, error handling, or behavioral constraints, 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so parameters are undocumented in the schema. The description mentions 'lead-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 coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Search leads with lead-specific filters' states the verb ('search') and resource ('leads'), but is vague about what 'lead-specific filters' means. It distinguishes from non-lead search tools like crm_search_companies, but doesn't clarify how it differs from crm_search_objects or other lead tools like crm_get_lead.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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_objects, crm_get_lead, or crm_list_objects. The description implies it's for searching leads, but doesn't specify use cases, prerequisites, or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 a search operation, implying it's likely read-only, but doesn't confirm this or mention any behavioral traits like pagination (implied by 'limit' and 'after' parameters but not explained), rate limits, authentication needs, or what happens with no results. For a search tool with 6 parameters and no annotation coverage, this is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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 ('Search CRM objects'), though it could be more structured by hinting at key parameters. For its brevity, it communicates the basic intent clearly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (6 parameters, nested filter logic, no output schema, and no annotations), the description is incomplete. It doesn't explain the search scope, result format, pagination behavior, or how to interpret parameters like 'objectType' with its enum values. For a tool that likely returns a list of objects, 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.

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 are documented in the schema. The description only mentions 'filters' generically, which corresponds to one parameter (filterGroups), but doesn't explain the other 5 parameters (objectType, properties, limit, after, sorts) or their relationships. It adds minimal value beyond the schema, failing to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Search CRM objects using filters' clearly states the verb ('search') and resource ('CRM objects'), but it's vague about what constitutes a 'CRM object' and doesn't distinguish this tool from its many sibling search tools (e.g., crm_search_companies, 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description offers no guidance on when to use this tool versus alternatives. With siblings like crm_search_companies and crm_search_contacts that target specific object types, there's no indication whether this is a generic search that replaces those or when one might prefer this over more specific tools. No prerequisites or exclusions are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 'validated properties' which hints at input validation, but lacks critical behavioral details: whether this is a mutation (implied by 'Update'), permission requirements, error handling, idempotency, or response format. 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.

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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with 2 parameters (including a complex nested object), 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the update behavior, parameter meanings, validation rules, or what to expect upon success/failure, 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.

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 'validated properties' without explaining what properties are valid, their formats, or constraints. The two parameters (companyId and properties object) are undocumented in both schema and description, leaving semantics unclear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 company'), making the purpose evident. It distinguishes from sibling tools like 'crm_create_company' by specifying 'existing', but doesn't explicitly differentiate from other update tools like 'crm_update_contact' or 'crm_update_lead' beyond the resource name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a companyId), compare to batch update tools like 'crm_batch_update_companies', or specify use cases. The agent must infer usage from the name and context alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is an update operation (implying mutation) and mentions 'validated properties', but doesn't explain what validation entails, whether changes are reversible, what permissions are required, error handling, or response format. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at just one sentence with no wasted words. It's front-loaded with the core purpose ('Update an existing contact') and adds a qualifying detail ('with validated properties'). Every word serves a purpose, making it efficient and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (mutation tool with nested parameters, no annotations, no output schema, and 0% schema description coverage), the description is insufficient. It doesn't explain the update behavior, validation process, error conditions, or what happens to unspecified properties. For a tool that modifies CRM data, more contextual information 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds minimal semantic context beyond the schema. It mentions 'validated properties' which hints at validation for the properties object, but doesn't explain what validation means or provide examples. With 0% schema description coverage and 2 parameters (one being a complex nested object), the description doesn't adequately compensate for the lack of schema documentation, though it at least acknowledges the properties parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Update') and resource ('an existing contact'), making the purpose immediately understandable. It distinguishes from sibling tools like 'crm_create_contact' by specifying 'existing' and from 'crm_batch_update_contacts' by being singular. However, it doesn't explicitly mention what 'validated properties' means or how it differs from other update tools like 'crm_update_object'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a contactId), when not to use it (e.g., for batch operations), or direct comparisons to siblings like 'crm_batch_update_contacts' or 'crm_update_object'. Usage is implied by the name but not explicitly stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions 'validated properties' hinting at input validation, but doesn't disclose critical traits like required permissions, whether updates are partial or full, error handling, or mutation effects. For a write operation, 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.

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's no wasted verbiage, and it directly communicates the tool's function. However, it could be slightly more structured by explicitly separating the two main parameters for clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 with nested parameters), lack of annotations, and no output schema, the description is insufficient. It doesn't address return values, error conditions, or provide enough behavioral context for safe and effective use. The mention of 'validated properties' is a start but doesn't compensate for the overall gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate but only adds limited context. It implies 'validated properties' relates to the 'properties' parameter, suggesting validation occurs, but doesn't explain what validation entails or detail the 'leadId' parameter. With 2 parameters (one complex nested object), the description provides some meaning but falls short of fully clarifying parameter roles and constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 lead'), making the purpose unambiguous. It distinguishes from sibling tools like crm_create_lead (creation vs. update) and crm_batch_update_leads (single vs. batch). However, it doesn't specify what 'validated properties' means, leaving some ambiguity about validation rules.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing lead ID), contrast with crm_update_object for generic updates, or indicate when batch operations (crm_batch_update_leads) might be preferable. Usage is implied but not articulated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It states 'Update' which implies a mutation, but doesn't disclose behavioral traits like required permissions, whether updates are partial or full, idempotency, error handling, or rate limits. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, making it easy to parse quickly without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (mutation with 3 parameters, nested objects, no output schema, and 0% schema coverage), the description is incomplete. It lacks details on usage context, parameter meanings, behavioral expectations, and output, making it inadequate for an agent to confidently invoke this 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.

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 semantic information about the three parameters (objectType, objectId, properties) beyond what's implied by the tool name. It doesn't explain what 'objectType' enums represent, how 'objectId' is formatted, or what 'properties' should contain, 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Update an existing CRM object' clearly states the verb ('Update') and resource ('CRM object'), but it's vague about what constitutes a CRM object and doesn't distinguish it from sibling tools like crm_update_company, crm_update_contact, or crm_batch_update_objects. It provides basic purpose but lacks specificity compared to alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 its many siblings (e.g., crm_update_company for companies, crm_batch_update_objects for multiple updates). The description implies it's for updating existing objects, but doesn't specify prerequisites, constraints, or alternatives, leaving the agent to guess based on context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates this is a destructive operation ('delete'), which is useful, but lacks critical details: whether archival is permanent or reversible, what permissions are required, if there are rate limits, or what the response looks like (success/failure indicators). For a destructive tool with zero annotation coverage, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at four words, front-loading the key action and resource with zero wasted language. Every word earns its place by clarifying the tool's core function without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It misses critical context: parameter details, behavioral implications (permanence, permissions), response format, and differentiation from batch alternatives. The conciseness comes at the cost of necessary completeness for safe agent invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the schema provides no parameter documentation. The description doesn't mention the emailId parameter at all, offering no guidance on format, source, or validation. However, with only one parameter, the baseline is 4, but the description fails to add any semantic value beyond the obvious, so it scores lower at 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Archive (delete)') and resource ('an email record'), making the purpose immediately understandable. It distinguishes itself from sibling tools like emails_get or emails_update by specifying the destructive archival operation. 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.

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), when to choose batch_archive for multiple emails, or what happens after archival (e.g., recovery options). It simply states what the tool does without contextual usage information.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.