commsharbor

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

With no annotations present, the description carries full behavioral burden. It discloses one valuable trait — the key is revealed exactly once, implying it cannot be retrieved later — but omits other relevant behaviors such as the credential's security sensitivity, required permissions to create it, or what the response will contain.

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?

A single nine-word sentence with zero waste; verb and resource are front-loaded and the critical once-only reveal behavior earns its place. This is appropriately sized for a simple 3-param tool.

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 no output schema, the description should clarify the return value; 'reveal it once' hints at the secret key being returned but never states the response contents. It also leaves scopes semantics and the irrecoverability of a lost key underspecified, though the flat 3-param complexity keeps the gaps moderate.

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 already documents name and organization_id (67% coverage); only the scopes array is undocumented. The word 'scoped' hints that the scopes parameter restricts permissions, adding marginal meaning beyond 'array of strings', but no format, valid values, or examples are given.

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 a specific verb ('create') and resource ('scoped API key'), and clearly differentiates from sibling tools commsharbor_api_key_revoke and commsharbor_api_keys. The 'reveal it once' qualifier adds a defining characteristic that further pins down exactly what this tool does.

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 given on when to use this tool vs alternatives, no when-not-to-use conditions, and no mention of counterpart tools like revoke or list. Usage context is only weakly implied by the verb and resource rather than 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Revoke' implies an invalidating or destructive action, but the description does not state whether revocation is permanent, whether active integrations will be affected, or whether any special permissions are required. For a destructive operation, this is a meaningful transparency gap.

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

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

The description is a single five-word sentence with zero filler or redundancy. It is front-loaded and every word carries meaning. There is no unnecessary structure or repetition of schema properties.

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 two-parameter tool with complete schema coverage, the description is minimally viable: the agent knows the action and the input schema supplies the required arguments. However, because this is a revoke/destructive operation with no annotations and no output schema, the description should ideally state consequences like irreversibility or impact on existing API usage. The missing behavioral context keeps it from being fully complete.

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 100%, and both parameters already have clear descriptions: 'API key ID' and 'Active organization ID'. The tool description adds no additional parameter meaning, but the schema already handles this dimension adequately. Baseline 3 is appropriate because the schema, not the description, does the work.

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 'Revoke an API key' uses a specific verb and resource, making the basic purpose immediately clear. It also distinguishes this tool from sibling tools like api_key_create and api_keys, since revoke is a distinct action. However, it adds little beyond what the tool name already communicates and does not mention the organization scoping involved.

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 gives no guidance on when to use this tool instead of alternatives such as commsharbor_api_key_create or commsharbor_api_keys. It does not state conditions, prerequisites, or exclusions. An agent must infer usage entirely from the name and input schema.

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 disclosure burden. It usefully reveals that secrets are not returned and 'List' signals a read-only operation. However, it does not mention authentication requirements, pagination, or behavior on invalid organization IDs.

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: five words, front-loaded verb and resource, with no filler or repetition. Every word adds value.

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 one-parameter list operation with no output schema, the description is nearly complete. It states what is returned (API keys) and an important exclusion (secrets). Additional detail about pagination or response shape would be useful but is not critical for such a simple read 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?

The schema already describes the only parameter (organization_id) with 100% coverage, so the description adds no parameter-level information. This meets the baseline for a fully schema-documented 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 states a specific verb ('List') and resource ('API keys'), with a meaningful qualifier 'without secrets' that distinguishes it from the sibling create/revoke tools. An agent can immediately understand what the tool does without inspecting 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 intended use case is evident from the description, but no explicit guidance is provided about when to use this tool versus commsharbor_api_key_create or commsharbor_api_key_revoke. There are no exclusions or alternative conditions 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 the full burden of behavioral disclosure. It only states that this is a creation operation and adds no context about response format, duplicate handling, whether `filter` is required for saved_segments, side effects, or validation behavior. The description effectively restates what the tool name already implies, offering no behavioral depth beyond it.

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 six words, front-loaded, and entirely free of redundancy. Every word earns its place, which is good for conciseness, though the extreme brevity borders on under-specification rather than disciplined economy.

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 creation tool with a nested filter object, no output schema, and no annotations, this definition is incomplete. An agent cannot learn how to structure `filter`, whether `kind` changes required inputs, or what the response contains. The definition provides no bridge to likely follow-up tools like audience_get or audience_members.

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 75% with descriptions for organization_id, name, and kind; the description reinforces the kind values via 'audience or saved segment' but adds little beyond the schema. The `filter` nested object is undocumented in both the schema and the description, leaving an agent unsure how to structure it. Given the 75% coverage, baseline 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 states a specific verb and resource: 'Create an audience or saved segment.' The two kinds map directly to the `kind` parameter, and the create verb clearly distinguishes it from siblings like audience_delete, audience_get, and audience_update. However, it does not explicitly name alternatives or differentiate itself from close operations like audience_member_add.

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 given about when to use this tool versus alternatives. With over 100 siblings including audience_update, audience_delete, and audience_member_add, an agent receives no decision criteria for choosing this tool. There is no mention of prerequisites, context, 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, and 'Delete an audience' does not carry it. It confirms the destructive nature honestly, but reveals nothing about irreversibility, cascading effects on audience members, permission requirements, or the expected response. The word 'delete' prevents a score of 1, but the burden is otherwise unmet.

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 three-word sentence has zero waste, but the brevity reflects under-specification rather than disciplined editing. For a destructive operation with no annotations and no output schema, a single clause is not an appropriately sized description.

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?

With no output schema and no annotations, the description must carry the contextual load, and it does not. For a destructive tool with a closely related sibling (commsharbor_audience_member_remove), an agent needs to know whether deleting an audience also removes its members, whether the action is reversible, and what outcome to expect. All of this is missing.

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 100%, with both audience_id and organization_id already described in the input schema ('Audience ID' and 'Active organization ID'). The description adds nothing about parameters, so the baseline of 3 is appropriate — the schema does the heavy lifting.

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 a specific verb ('Delete') and resource ('an audience'), and the destructive verb clearly differentiates it from sibling tools like commsharbor_audience_create, commsharbor_audience_get, and commsharbor_audience_update. However, it essentially restates what the tool name already implies, adding no detail about scope or operation semantics.

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. In particular, an agent gets no help distinguishing it from commsharbor_audience_member_remove (removing individual members) or commsharbor_audience_update (modifying an audience instead of destroying it). No conditions, 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Read' signals a non-mutating operation, but nothing is disclosed about error behavior when the audience doesn't exist, what fields the response contains, whether audience members are included, or any permission prerequisites beyond the two IDs. The description adds only the minimal safety implication of 'read' and nothing more.

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?

At three words, the description has zero waste and is maximally front-loaded — the verb and resource appear immediately. It reads as a complete, grammatical utterance rather than a tautology. However, it borders on under-specification, which prevents a 5; brevity here may be cutting into content that should exist.

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?

The tool is a simple getter with two fully documented parameters, but there is no output schema and no annotations, so the description is the only source of behavioral and return-value information. It does not state what the response contains, how it differs from listing via commsharbor_audiences, or what happens on not-found. For an agent choosing among 130+ siblings — several of which operate on audiences — this is under-specified.

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 100% — both audience_id and organization_id have descriptions in the schema. The tool description 'Read one audience' adds no parameter-level meaning beyond what the schema already provides. Per the baseline rule, with high schema coverage, a 3 is appropriate even without additional param detail in the description.

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 'Read one audience' states a specific verb (read), resource (audience), and cardinality (one), which clearly implies a singular get operation. The word 'one' implicitly differentiates it from the plural sibling commsharbor_audiences. However, it doesn't explicitly distinguish itself from other audience-related siblings, and the description is so terse that it relies on the tool name for most of the 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?

No guidance is provided on when to use this tool versus alternatives such as commsharbor_audiences (list), commsharbor_audience_members, or commsharbor_audience_update. Given the enormous sibling list (130+ tools) and several similar audience tools, the description provides no context for selection. There are no usage conditions, exclusions, or alternative references.

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 discloses only the core mutation (adding a member) but does not state what happens when the contact is already a member, whether dynamic audience IDs are rejected, what error conditions apply, or what the result confirms. A mutation tool with zero annotation coverage needs more behavioral context than this.

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?

A single nine-word sentence with the action verb front-loaded. Every word earns its place, and there is no duplication of schema content or filler material.

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 three-parameter mutation with fully described required parameters, the core is adequately covered. However, with no output schema, the description does not indicate what the call returns on success, how duplicate membership is handled, or whether the static-audience constraint is enforced — gaps an agent needs to know whether re-adding is safe or how to confirm the operation succeeded.

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 100%, with each parameter already described ('CRM contact ID', 'Audience ID', 'Active organization ID'). The description slightly enriches contact_id (must be a CRM contact) and audience_id (must be static) but adds no syntax, format, or relationship details beyond the schema, so the baseline 3 applies.

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 uses a specific verb+resource pair: 'Add a CRM contact to a static audience.' It is readily distinguishable from siblings like commsharbor_audience_member_remove (opposite action) and commsharbor_audience_create (different resource). The 'static audience' qualifier adds precision beyond what the tool name alone conveys.

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 intended action is evident from the verb, but there is no explicit when-to-use or when-not-to-use guidance. It does not distinguish this tool from bulk import workflows (commsharbor_contact_import_*) that could also populate audiences, nor does it state what to do when the audience is dynamic. The 'static audience' phrase is an implied usage condition, but no alternative tool is named.

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 the mutating action but does not clarify whether the CRM contact itself is deleted, whether removal is reversible or idempotent, or what happens if the contact is not already in the audience.

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, front-loaded sentence that states the verb, object, and scope without any filler. 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 low complexity, fully documented required parameters, and lack of an output schema, the one-sentence description plus the input schema is nearly sufficient for safe invocation. It falls short of a 5 only because it does not address side effects, reversibility, or edge cases, especially with no annotations to cover those concerns.

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 100%, and all three parameters already have clear descriptions: CRM contact ID, Audience ID, and Active organization ID. The description adds no meaningful parameter-level detail beyond what the schema provides, so the baseline 3 applies.

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 uses a specific verb ('Remove') with an explicit object ('a CRM contact') and scope ('from a static audience'). This clearly differentiates the tool from sibling tools like commsharbor_audience_member_add, commsharbor_audience_members, and commsharbor_audience_delete.

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 implies the tool is for removing a contact from an audience and narrows the context to static audiences. However, it does not explicitly name alternatives or provide when-not-to-use guidance, such as not using it for dynamic audiences or using commsharbor_audience_member_add to add members.

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, the description carries the full burden of behavioral disclosure. It only says 'List audience contacts' and does not reveal pagination behavior, return format, ordering, or that this is a read-only operation. Minimal value is added beyond the tool name.

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

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

The description is extremely short and free of fluff, but it is under-specified. It earns its place but does not provide enough useful content to be considered well-structured for an agent.

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 list endpoint with required organization_id and audience_id, pagination parameters, and no output schema or annotations, the description is too thin. It does not mention pagination, what contacts are returned, or any practical invocation 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 100%, so the schema fully documents the four parameters. The description adds no additional semantic detail, but this is acceptable given the baseline of 3 when the schema handles parameter 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 'List audience contacts' uses a specific verb and resource, clearly distinguishing it from sibling tools like audience_create or audience_delete. It is somewhat generic compared to audience_member_add/remove, but the intent is clear.

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 commsharbor_audiences or commsharbor_audience_get. The description simply states the function without any context 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, this description carries the full burden of communicating behavior. It makes clear that the operation is a read-only listing and that saved segments are included, but it does not describe pagination behavior, response shape, or any operational boundaries beyond what the schema implies.

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 sentence with no filler and names exactly what the tool returns. It is front-loaded and every word adds 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?

For a simple list operation this is minimally adequate, but there are gaps: no output schema and no annotations exist, and the description does not mention pagination, the response format, or how this relates to sibling audience tools. The schema covers parameters, but the overall context is thin.

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 already fully describes all three parameters (organization_id, limit, cursor) with 100% coverage, so the description adds no parameter-level meaning. This is the appropriate baseline for high schema coverage.

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 uses a specific verb ('List') and names the resources ('audiences and saved segments'), so an agent can tell this is a collection-list operation rather than a single-item get/create/update. It is distinguishable from related siblings like commsharbor_audience_get, though it does not explicitly name an alternative.

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 gives no guidance about when to choose this tool over the related audience tools, and it mentions no exclusions or alternative tools. An agent must infer the use case solely from the word 'List', which is minimal 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?

No annotations are present, so the description carries the full burden of behavioral disclosure. It only says 'Update an audience' and does not explain whether the update is partial or full, what happens to existing data, whether permissions are required, or what the response contains.

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

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

The description is a single terse sentence with no wasted words, but it is so minimal that it provides little value beyond the tool name. It is under-specified for a tool with four parameters and a nested object, rather than appropriately 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?

For a mutation tool with no annotations, no output schema, and an opaque nested 'filter' object, 'Update an audience' leaves the agent without enough information about update semantics, effects, or return behavior. The required IDs are documented in the schema, but the overall definition is incomplete.

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 75%, covering name, audience_id, and organization_id, so the baseline is 3. The description adds no parameter-level meaning beyond the schema, and the nested 'filter' object remains undocumented in both the schema and the description.

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 a specific verb ('update') and resource ('audience'), and the tool name makes it distinguishable from sibling tools like audience_create, audience_get, and audience_delete. However, it does not specify which audience attributes can be updated, so it is clear but 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 is provided about when to use this tool versus related audience tools such as audience_create, audience_get, or audience_delete. There are no conditions, prerequisites, or exclusions mentioned.

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

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

With no annotations provided, the description carries the behavioral transparency burden. It does convey the core behavior—listing audit events—and implies a read-only operation. However, it omits useful behavioral details such as pagination semantics, result ordering, or whether the cursor is required for paginated retrieval.

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 four words long and front-loads the essential action and resource. There is no redundancy, filler, or irrelevant detail; every word contributes to the 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?

For a simple listing tool with fully documented parameters, this is minimally viable: an agent knows what to call and what parameters to provide. Still, the lack of any mention of pagination, response shape, or event scope beyond 'tenant' leaves room for ambiguity about what the returned audit events look like.

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 100%, so the input schema already documents both parameters adequately. The description adds no extra semantic detail beyond the word 'tenant', which hints at the organization scoping but does not meaningfully extend 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 identifies the action ('List') and the resource ('tenant audit events'), making the tool's purpose immediately understandable. It does not explicitly differentiate from siblings, but no other sibling appears to cover audit events, so the risk of confusion is low.

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 phrasing implies this tool is for retrieving tenant audit events, which gives an agent a reasonable sense of when to reach for it. However, it provides no explicit guidance about alternatives, prerequisites, or when not to use it.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the core side effect (an email is sent) but discloses nothing else: no mention that OTPs expire, that sending may be rate-limited, that a previous OTP may be invalidated, or that this step does not itself authenticate the user.

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 tight sentence with no wasted words and the core action front-loaded. It is appropriately lean for a one-parameter tool, though it errs slightly toward under-specification rather than optimal sizing since a second sentence about the follow-up verify step would add high value without bloat.

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?

Complexity is low (one required parameter, no nested objects), but the surrounding structured context is also thin: no annotations and no output schema. The description leaves the agent without essential flow context — there is no indication that authentication is a two-step process, no mention of what the tool returns (request ID, status, etc.), and no error conditions described. For a tool named auth_start, this is a meaningful gap.

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 100%, so the schema already documents the email parameter as 'Login email'. The description adds marginal meaning by clarifying that the OTP is delivered to this address, but this is largely redundant with the tool's own purpose. Baseline 3 is appropriate given the schema carries the heavy lifting.

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 has a specific verb ('Send'), a clear resource ('an OTP'), and a destination ('to an email address'). It clearly states the action. However, it does not differentiate itself from the closely related sibling commsharbor_auth_verify, and it never mentions that this is the first step of a two-step authentication flow.

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?

There is no guidance about when to use this tool. It does not state that this initiates an auth flow that must be completed via commsharbor_auth_verify, does not mention prerequisites (e.g., whether the email must belong to an existing user), and gives no hints about when this is or isn't the right tool relative to its siblings.

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?

There are no annotations, so the description carries the burden of explaining behavior. It does disclose the primary state-changing outcome ('receive a session'), but it does not mention session properties, whether a token is returned, failure behavior, or rate-limit/security implications. It is marginally adequate but not transparent about side effects beyond receiving a session.

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, front-loaded sentence with no filler. It directly conveys the essential action and result in eight words, earning its place without redundancy.

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 two-parameter tool, the description is minimally adequate: it states the purpose and that a session is received. However, it omits the surrounding auth flow context, such as needing to call auth_start first, what a session looks like, and error conditions. These gaps prevent it from being fully context-complete.

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 100%, and both parameters (email, code) are already documented as 'Login email' and 'Six-digit code'. The description adds no parameter-level meaning beyond what the schema provides, so the baseline score of 3 applies.

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 (verify an OTP) and the outcome (receive a session), using a specific verb and resource. It is distinct from the related auth_start sibling by implying the verification step, though it does not explicitly name auth_start or other 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?

The description provides no explicit when-to-use guidance or alternatives. It does not say to call this after auth_start, nor does it describe when not to use it. The usage context is only weakly implied by the tool name and 'Verify an OTP' phrasing.

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 indicating side effects. The word 'Read' clearly signals a read-only, non-mutating operation, which is useful. However, the description does not disclose what the response contains, whether the data reflects current usage, or any authorization/error implications, so it is only minimally transparent.

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?

A single, front-loaded sentence with no filler or redundancy. It states the verb and resource immediately, making it fast for an agent 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?

With no output schema and no annotations, the description could do more to explain what the returned entitlements/available sends look like and how this tool relates to billing_purchase or billing_catalog. However, the tool has only one required parameter and a clear read-only purpose, so it is adequate for basic selection and invocation but lacks richer 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?

The schema fully documents the only parameter as 'Active organization ID', and the description adds little beyond 'tenant', which loosely maps to organization_id. With 100% schema description coverage, the baseline of 3 is appropriate because the description does not need to 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 opens with a clear verb ('Read') and names specific resources ('tenant entitlements and available sends'), which distinguishes it from sibling tools like commsharbor_billing_catalog and commsharbor_billing_purchase by operation and scope. This is a specific, non-tautological purpose statement.

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 gives no explicit guidance on when to use this tool versus the other billing siblings, and it does not mention exclusions or alternatives. The read-only wording implies a use case, but that is not enough to help an agent choose correctly among related billing 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 exist, so the description carries the full behavioral disclosure burden. It does signal a read-only operation, but it does not describe the response format, the scope of the catalog, what 'x402 network' means, or any authentication expectations.

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, front-loaded sentence with no filler or redundant schema repetition. Every word contributes to identifying the action and the resources involved.

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 zero-parameter read-only tool this is minimally viable, but it leaves the meaning of 'x402 network' unstated and gives no sense of the returned catalog structure. It also does not clarify how it relates to the billing and billing_purchase siblings.

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 tool accepts zero parameters and the schema has no properties. With no required inputs, the 0-parameter baseline applies and the description does not need to add parameter-level detail.

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 uses a concrete verb ('Read') and names specific resources ('plans, prices and x402 network'), so the core purpose is clear. It does not explicitly contrast itself with sibling billing tools like commsharbor_billing or commsharbor_billing_purchase, but the catalog/read framing makes it reasonably distinguishable.

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?

There is no guidance about when to use this tool instead of commsharbor_billing or commsharbor_billing_purchase, nor any when-not-to-use conditions. Only the implicit suggestion that plan/price questions map to this catalog.

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, the description carries full burden. It does disclose a non-obvious behavioral trait: the call returns an x402 payment challenge rather than completing the purchase outright, and only conditionally ('when payment is required'). However, it doesn'tsay what happens when no payment is needed, whether any charge is created, or how the flow continues after the challenge.

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?

One sentence with zero filler; the action ('Request a pass or top-up') is front-loaded and the payment-conditioned challenge follows. 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?

For a payment-adjacent operation with no annotations and no output schema, the description is too thin: it doesn'tdescribe the response shape, the no-payment path, or how the x402 challenge is resolved. An agent can'tpredict whether the tool is idempotent-safe or what success looks like.

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 coverage is 67% — the action parameter has no description. The description echoes 'pass' and 'top-up', mapping to the action enum and supplying a little semantics, but doesn'texplain what distinguishes a pass from a top-up. It adds nothing about idempotency_key's role in preventing duplicate charges.

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?

States a specific verb ('Request') and resource ('pass or top-up'), plus the distinctive consequence ('receive the x402 challenge'). Among billing siblings (commsharbor_billing, commsharbor_billing_catalog), this implies the purchase/action role, but it doesn'texplicitly differentiate from them and the 'x402 challenge' jargon is left unexplained.

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 when-to-use guidance, no exclusions, and no mention of alternatives such as commsharbor_billing or commsharbor_billing_catalog. The only usage signal is implied: if you want a pass or top-up, invoke this. An agent gets no help choosing between the three billing 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 the full burden of behavioral disclosure. It only states that a draft is created, providing minimal side-effect context. It does not mention permissions, whether the draft is immediately available, whether it can be edited or launched afterward, or what response is returned.

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 no filler or repetition. It front-loads the core action and resource. However, it may be too terse given the complexity of the operation and the absence of annotations.

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?

This is a creation tool with six parameters, no annotations, and no output schema, so the description should provide more context about the draft lifecycle, validation behavior, or expected result. It only says 'Create a campaign draft' and leaves important operational details unstated.

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 83%, so the input schema already documents five of six parameters. The description adds no parameter-level meaning, but the schema covers most semantics. The optional template_version parameter lacks a description, yet the schema provides a minimum constraint.

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 uses a specific verb ('Create') and a specific resource ('a campaign draft'), which clearly distinguishes it from siblings like campaign_launch, campaign_update, and campaign_get. The word 'draft' conveys that this creates an unsent campaign rather than launching one. It is concise but could be slightly clearer about what a draft entails.

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 implies the tool is used to create a campaign draft, but it does not explicitly say when to use it over campaign_launch or campaign_update, nor does it mention any prerequisites or exclusions. No alternative tools are named, so an agent must infer usage from sibling names and the word 'draft'.

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 available, the description carries the full burden of behavioral disclosure. The word 'Read' implies a read-only operation, but the description does not mention response behavior, required permissions, error cases, or any other operational traits. It adds minimal value beyond the tool name itself.

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, direct sentence with no filler or redundant wording. It is appropriately concise for a simple get-by-id operation, though it could afford a bit more 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?

The two parameters are fully documented in the schema, and the operation is simple enough to infer from the name. However, the description does not clarify the return value, distinguish from campaign_report, or give any usage context. It is minimally adequate but has clear gaps.

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

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

Schema description coverage is 100%, with both campaign_id and organization_id documented in the input schema. The description adds no additional parameter meaning, but the baseline of 3 applies because the schema already fully describes the parameters.

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 a clear verb and resource: 'Read a campaign.' This distinguishes it from mutation tools like campaign_create, campaign_update, and campaign_launch. However, it does not differentiate it from the related campaign_report, which could also be described as reading campaign data.

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 commsharbor_campaigns (listing campaigns) or commsharbor_campaign_report (reading campaign performance). The description gives no context, exclusions, or hints about selecting this tool over its siblings.

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?

Lere are no annotations, so the description carries the disclosure burden. It does communicate two useful behavioral traits—constently idempotent and a 'freeze' side effect—but it doesn't explain what freezing means, what happens on retries, or the campaign's state transition.

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 short sentence with no filler and the core action is stated before the qualifier. The ambiguous 'freeze' term costs a point against maximum clarity, but overall it is efficient.

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 100% schema coverage and relatively simple flat parameters, the description is adequate for basic invocation. However, with no annotations and no output schema, it leaves important context implicit—what 'freeze' does, whether scheduled_for absent means immediate launch, and what the caller should expect in return.

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 100%, so the schema already documents all four parameters. The description only loosely echoes scheduled_for and idempotency_key ('schedule', 'idempotently') and does not clarify that providing scheduled_for selects scheduling vs immediate launch.

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 names a specific action ('launch or schedule') on a specific resource ('campaign'), so an agent can identify the tool's main job. It is reasonably distinguishable from sibling tools like campaign_create and campaign_update because 'launch' signals a lifecycle action, though the word 'freeze' is ambiguous and no sibling is explicitly contrasted.

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 intended use is implied: call tlis tool when a campaign should be launched or scheduled. However, it provides no explicit guidance about prerequisites, when not to use it, or which sibling tool should be selected instead.

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 present, so the description carries the full burden of disclosing behavior. 'Reconcile' does not clarify whether this tool is read-only, performs calculations, or has side effects. It also does not mention what kind of output the agent can expect, whether any state changes occur, or what 'reconcile' concretely produces. This is a major transparency gap for a tool whose name suggests reporting.

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 very short and front-loaded, with no filler. However, it is under-specified rather than concisely complete; six words convey the general subject matter but omit necessary details about the tool's purpose and behavior. It is not bloated, but it does not fully earn its place as a standalone definition.

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?

While the tool has only two parameters and no nested objects, there is no output schema and no annotations, so the description must explain what the tool returns and how it behaves. It does neither. An agent cannot tell whether this is a safe read operation, what shape the reconciliation report takes, or how campaign deliveries and feedback are correlated.

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 100%: both parameters have basic descriptions ('Campaign ID' and 'Active organization ID'). The tool description adds no additional meaning, so it does not improve on the schema. A baseline of 3 is appropriate because the schema already documents both parameters sufficiently for basic invocation.

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 uses a specific verb ('reconcile') and names the resource ('campaign deliveries and feedback'), so it indicates a reporting/analysis action rather than a generic operation. However, 'reconcile' is ambiguous—it could mean generating a comparison report, adjusting records, or checking consistency—and the description does not clearly distinguish this tool from related siblings like commsharbor_campaign_get, commsharbor_delivery_events, or commsharbor_delivery_get.

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 about when to use this tool versus alternatives. With many closely related sibling tools (campaign_get, delivery_get, delivery_events, domain_report), an agent needs some indication of the specific scenario this report addresses, such as matching delivery status against feedback or producing a reconciliation summary. The description implies usage but never states it.

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. 'List' implies a read-only operation, but the description does not mention what the response contains, whether pagination is involved, or how the organization_id parameter scopes results.

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 and front-loaded with no filler. It earns its place by naming the action and resource, though it is arguably too sparse to be maximally useful.

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 no output schema and no annotations, the description is too thin. It does not mention return values, pagination, or how the organization context affects the results, leaving an agent to guess important invocation expectations.

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 100%, so the single organization_id parameter is already documented in the schema. The description adds no parameter-level meaning, so the 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 states a clear verb and resource: 'List campaigns.' This makes it distinguishable in intent from campaign_create, campaign_get, and campaign_update by conveying a collection-level read operation. However, it does not explicitly contrast with campaign_get or describe any scoping/filtering behavior.

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 given about when to use this tool versus sibling tools such as campaign_get, campaign_create, or campaign_report. The intended context must be inferred entirely from the tool name and the plural 'campaigns'.

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 correctly indicates a state-changing operation, but it does not mention consequences such as whether cancel is irreversible, whether pause/resume has restrictions, or what the response looks like. For a mutation tool, this is a meaningful 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 eight words, front-loaded with action verbs, and contains no filler. It is compact and easy to scan quickly, which is exactly what conciseness requires, even though it lacks some contextual depth.

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?

With 8 parameters, no output schema, and no annotations, a single sentence is not enough operational context. The description does not explain which fields can be updated together, how status transitions work, or that campaign_id and organization_id are identifiers while other fields are optional. The schema gives field names but not the behavioral context an agent needs to 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?

Schema description coverage is 88%, so the schema already documents most parameters adequately. The description adds a little meaning by implicitly linking pause/resume/cancel to the status field, but it does not clarify optionality, field combinations, or template_version behavior. The high schema coverage keeps this at baseline 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 names the campaign resource and a set of concrete actions: edit, pause, resume, or cancel. This is reasonably specific and distinguishes the tool from campaign_create, campaign_get, and campaign_launch, but 'edit' is generic and the description does not explicitly differentiate from sibling 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?

There is no guidance on when to use this tool versus alternatives like campaign_launch or campaign_create. The intended use is only implied by the tool name and verbs, with no explanation of boundary cases such as whether setting status to 'running' is the same as launching a campaign.

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 behavioral disclosure burden. It does convey that this is a download and adds a non-obvious expiry constraint, but it does not disclose side effects, behavior after expiration, or error/response expectations.

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 seven-word sentence with no filler or repetition. The action, resource, and timing qualifier are front-loaded, and the schema is left to document 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?

With only two required scalar parameters and no output schema, the description plus schema is nearly complete: the agent knows the required IDs and that the result is a CSV. It could still mention what happens after expiry, but the tool is simple enough that this is not a major gap.

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 100% and both string parameters are already self-explanatory. The description adds no per-parameter meaning, but none is needed; the baseline 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 states a concrete action (Download) and resource (tenant CSV) plus a distinctive time qualifier (before expiry). It is clear on its own, but it does not explicitly differentiate from sibling download/export tools such as commsharbor_contacts_export or commsharbor_data_export_download.

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 phrase 'before expiry' implies the tool should be used while a generated CSV is still valid, providing some usage context. However, it does not contrast this tool with alternatives or state when not to use it, so an agent must infer routing.

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, the description carries the full burden of behavioral disclosure. It only restates the schema's requirement that an idempotency key is mandatory and says nothing about side effects, whether the confirmation triggers processing, reversibility, failure behavior, or what response to expect. The idempotency semantics are implied but not explained.

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 short sentence with the action front-loaded and no filler. It is concise, but it is so terse that it sacrifices substantive context, making it efficient yet minimally informative.

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 there are no annotations and no output schema, the description should provide more context about the import-confirmation workflow, prerequisites, and consequences. It does none of that; an agent must infer almost everything from the tool name and sibling list.

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 100%, so the baseline is 3 even without parameter details in the prose. The description adds no meaning beyond 'mandatory,' which is already captured by the required array; it doesn't clarify key format, generation, or how it relates to the import.

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 a specific action ('Confirm'), a specific resource ('an import'), and highlights the mandatory idempotency key, so an agent can tell this is not a get/preview/list operation. However, it doesn't explain what confirming actually does (e.g., finalizing an import) and doesn't explicitly distinguish it from contact_import_preview or contact_import_get, so it stops short of 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?

There is no guidance about when to use this tool versus siblings like contact_import_preview, contact_import_get, or contact_imports. The word 'Confirm' implies a later stage in an import workflow, but no prerequisites, workflow position, or exclusions are stated, 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. Saying 'List' implies a read operation, but the description does not explain pagination behavior, whether results are stable across calls, what fields appear in error rows, or what 'deterministic' really means for the caller. It adds little beyond the operation name.

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

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

The description is a single succinct sentence with no filler or redundant restatement of the tool name. It sacrifices some helpful context for brevity, which keeps it concise but leaves the description feeling thin.

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 no annotations, no output schema, and a nuanced domain area (import lifecycle), a one-sentence description is not enough. Missing context includes how errors relate to an import, whether errors are final or depend on preview state, and what the response structure looks like.

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 100%, so the schema already documents all four parameters including the meaning of limit, cursor, import_id, and organization_id. The description adds no additional parameter-level semantics, so the 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 names a specific resource (import errors) and action (List), and the phrase 'row-level import errors' differentiates it from sibling tools like contact_import_get and contact_import_preview. However, 'deterministic' is something of a jargon qualifier and the description does not explicitly contrast it with related import tools, so it is not a full 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?

No guidance is given about when this tool should be used versus contact_import_preview, contact_import_get, or contact_import_confirm. There is no stated context such as 'after an import completes' or 'when previewing failed rows,' leaving the agent to infer the intended scenario.

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 only says 'Read,' which conveys a read-only operation, but it does not describe what is returned, whether the import object includes status or error information, or what happens when the import ID is invalid. Minimal value is added beyond the tool name itself.

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 concise sentence with no unnecessary words. It is immediately clear and front-loaded.

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 two-parameter get operation, the description is minimally viable, but it lacks guidance on return values since there is no output schema. It also provides no usage context or behavioral caveats, so an agent must infer most non-parameter details.

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 100%, so both import_id and organization_id are already documented. The description adds no additional parameter-level meaning, which is acceptable given the schema's completeness, hence the baseline score of 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 'Read one contact import' uses a specific verb and resource, and the word 'one' distinguishes this from list-oriented siblings like commsharbor_contact_imports. However, it does not explicitly name alternative tools or clarify how it differs from related import tools such as preview, confirm, or errors.

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?

There is no guidance on when to use this tool versus alternatives. The description implies a single-record retrieval use case but does not state exclusions, prerequisites, or mention sibling tools like commsharbor_contact_imports or commsharbor_contact_import_preview.

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, the description carries the full burden of behavioral disclosure. It only says 'upload and preview'; it does notstate whether contacts are persisted, whether the file is stored, whether any consent data is validated or mutated, or what side effects occur. The 'consent-declared' phrasing hints at CSV requirements but does not clarify the operation's safety or outcome.

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, easy-to-scan sentence with no wasted words. However, for a six-parameter operation with a nested mapping object and no output schema, this is closer to under-specification than deliberate conciseness.

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?

The tool has no output schema, no annotations, and a complex nested mapping parameter, so the description should at least clarify what the preview returns and how the import workflow proceeds. It does not describe success/failure signals, preview contents, or the relationship to contact_import_confirm, leaving significant gaps for an agent to infer.

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 83%, so the schema already covers most parameter meanings: csv size limit, basis, source, captured_at format, and organization_id. The description adds no extra parameter-level context, and the nested 'mapping' object remains undescribed in both schema and description. Baseline 3 is appropriate because the schema handles most of the burden.

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 a specific action ('upload and preview') on a specific resource ('consent-declared CSV'), so an agent can tell this is a pre-import validation step. It does not explicitly differentiate from commsharbor_contact_import_confirm or contact_import_get, but the word 'preview' strongly implies an early, non-committing stage.

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 gives no guidance on when to use this tool versus alternatives like contact_import_confirm, contact_import_errors, or contact_import_get. It does not mention the natural workflow of previewing before confirming an import, so the agent must infer the intended sequencing 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 the full burden of behavioral disclosure. 'List' implies a read operation, but it does not disclose pagination behavior, ordering, filtering, statuses, or what fields are returned for each import. Behavioral transparency is minimal.

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

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

The description is a single, front-loaded sentence with no filler or redundant wording. It is appropriately concise for a list operation, though slightly more context could have been added without harming 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?

For a straightforward paginated list tool, the schema covers the parameters and the description states the core intent, so it is minimally viable. However, with no annotations and no output schema, an agent is left without information about return shape, import statuses, ordering, or how this tool fits with the other contact import tools.

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 fully documents all three parameters with clear descriptions, including the required organization_id, limit with a maximum of 100, and cursor for pagination. The description adds no parameter-level meaning, but the 100% schema coverage sets the baseline 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 states a clear action with a specific resource: 'List contact imports'. The plural 'imports' helps differentiate it from singular operations like commsharbor_contact_import_get, though it does not specify scope, filtering, or relationship to related import 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?

Usage is implied: this is the tool for listing contact imports. However, there is no explicit guidance about when to prefer this over related tools such as contact_import_get, contact_import_errors, or contact_import_preview, nor any discussion of alternatives.

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, the description must carry the behavioral transparency burden. 'Read' clearly signals a non-mutating operation, which is useful, but the description does not disclose what fields are returned, what happens when the contact does not exist, or any organization-scoping behavior beyond the parameter names.

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, focused sentence with no filler. The key verb and resource are front-loaded, making it easy for an agent to quickly parse the tool's 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 two-parameter read operation, the description is reasonably adequate, but the lack of an output schema means the agent is left without any information about the return shape or field names for consent and preference. Given the large sibling toolset, a short note clarifying scope or response structure would improve completeness.

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 100%, with both contact_id and organization_id already documented. The description adds no further parameter-level meaning beyond what the schema provides, so the 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 uses a specific verb, 'Read', with a clear resource: 'consent and preference for a CRM contact'. This makes the tool's purpose immediately understandable and distinguishes it from the write-oriented sibling commsharbor_contact_marketing_put.

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 implies the tool is used to fetch consent/preference data, but it gives no explicit guidance about when to use this tool versus alternatives like commsharbor_contact_marketing_put, commsharbor_preference_get, or commsharbor_crm_contacts_get. There are no exclusions or conditions provided.

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, the description carries the full burden of disclosing behavior. It only states the action and does not explain whether existing consent is overwritten, whether the operation is idempotent, what validation applies to 'basis', what authorization is needed, or what the stored consent record looks like.

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

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

The description is a single, front-loaded sentence with no filler or redundancy. It states the purpose in the fewest possible words, which is appropriate for conciseness even though deeper behavior is missing elsewhere.

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 write operation with no annotations and no output schema, the description is too thin. It does not mention return values, errors, idempotency, legal/compliance caveats, or how this consent record relates to the contact or to marketing send eligibility.

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 100% parameter description coverage, so the baseline is 3. The description adds no parameter-level detail beyond what the schema already provides; the schema already describes each required field adequately.

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 uses a specific verb ('Record') and resource ('permission-based marketing consent'), clearly identifying a write operation for contact marketing consent. It is easily distinguishable from the sibling commsharbor_contact_marketing_get, but it does not explicitly differentiate itself from alternatives or clarify whether this is create-only or upsert semantics.

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 about when to use this tool versus commsharbor_contact_marketing_get, suppression_create, preference_unsubscribe, or other consent-related tools. There are no conditions, exclusions, or prerequisite steps 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, the description must carry behavioral disclosure, and it adds two facts: the export is 'safe' and lasts 'seven-day'. However, 'safe' is undefined, and it does not disclose whether the operation is asynchronous, whether it returns a download ID or URL, whether it overwrites previous exports, or whether special permissions are required. Transparency is partial.

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 sentence with no filler; every word contributes signal: create, safe, seven-day, contact, CSV, export. Key qualifiers are front-loaded and the text is 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?

Despite having only one parameter, this is an export-creation workflow with no output schema and no annotations. The description does not explain what the agent receives after calling it, how the seven-day window affects follow-up, or how the export is later retrieved. Sibling tools like data_export_download indicate a larger workflow that the description leaves unexplained.

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 100% and organization_id is already described as 'Active organization ID'. The description adds no parameter-specific meaning, but for a single obvious parameter the schema carries the burden. A baseline 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 names a specific action — create a contact CSV export — and clearly scopes it to contacts. It is distinct enough at a glance from generic exports, though 'seven-day' is ambiguous and no sibling tool is named to sharpen 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 when-to-use or when-not-to-use guidance. It does not contrast with related tools such as commsharbor_data_export_create, contact imports, or contact retrieval tools. The only implied context is 'use when a contact CSV export is needed', which is effectively circular.

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 behavioral burden. 'Resolve' implies a non-mutating lookup and 'active organization identity' names what is returned, but the description does not clarify whether the result is an ID, slug, or full organization object, or what authentication context is required.

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?

A single sentence with no filler: every word contributes to the purpose. The core concept is front-loaded and nothing extraneous is included.

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?

This is a simple zero-parameter tool, so the description is nearly sufficient. However, with no output schema, it should state the return shape or the exact form of the 'organization identity' and any dependency on an authenticated session; these details are missing.

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 tool has zero parameters and the empty input schema already communicates this completely. Per the zero-parameter baseline, no additional parameter explanation is needed from the description.

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 a concrete verb ('Resolve') and a specific resource ('the active organization identity'), making the tool's purpose clear. It is implicitly distinct from siblings such as commsharbor_me, commsharbor_organizations, and commsharbor_organization_get, but it does not name those alternatives, so it stops short of 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?

There is no guidance about when to call this tool instead of the many related context/lookup tools such as commsharbor_platform_context, commsharbor_me, commsharbor_organizations, or commsharbor_organization_get. The agent is left to infer usage purely from the tool name and a one-line description.

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, the description carries the full burden, but it only states that the tool creates an activity. It does not disclose side effects, required context, permissions, idempotency, or what data is returned.

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 one short sentence, but this is under-specification rather than effective conciseness. It front-loads the action with no supporting context that would help an agent invoke the tool correctly.

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?

A 4-parameter CRM tool with no output schema and no annotations needs more context than 'create CRM activity.' It does not explain what an activity represents, how activity_type should be valued, how deal_id relates to the activity, or what a successful creation looks like.

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 100%, so the baseline is 3, but the parameter descriptions merely repeat the field names ('note', 'deal id', 'activity type', 'organization_id'). The long-form description adds nothing about parameter meaning or constraints, so it does not exceed the baseline.

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 names the exact operation and resource: creating a CRM activity. It is clear enough to distinguish from the delete/get/list/update siblings, though it does not clarify how it differs from the similarly named platform_crm_activities_create variant.

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?

There is no guidance on when to choose this tool over alternatives such as commsharbor_platform_crm_activities_create or the update/list variants. The intended use is only implied by the verb and sibling naming, with no when-to-use or when-not-to-use 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 the full burden of behavioral disclosure. It only says 'delete', implying mutation, but does not mention irreversibility, required permissions, whether related records are affected, or any side effects.

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

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

The description is a single short sentence with no filler. It is concise, though it could have used the space to include a bit more context or scoping 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?

For a destructive operation with no annotations or output schema, the description is too sparse. It does not explain deletion semantics, scoping, or the distinction from the platform-scoped sibling tool, so an agent would not be fully equipped to invoke 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?

Although the schema has descriptions for both parameters, those descriptions merely repeat the parameter names and add no real semantic value. The tool description does not explain the role of organization_id or activity_id, or how they relate to the delete operation.

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 core action, 'delete', and the resource, 'CRM activity', so an agent can tell it is a deletion tool. However, it does not differentiate this from the similarly named commsharbor_platform_crm_activities_delete sibling, so it lacks sibling distinction.

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

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

No guidance is given for when to use this tool versus the platform-scoped delete variant or any other activity-related tool. The agent is left 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, and it says nothing beyond the bare action. It does not state whether the operation is read-only, what happens if the activity does not exist, whether auth is required, or what the response format is. The word 'get' weakly implies a safe read, but no confirmation or edge-case behavior is disclosed.

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?

At three words, the description is under-specified rather than appropriately concise; this is the classic case of under-specification masquerading as brevity. A simple GET with two parameters and two competing sibling families could merit multiple clarifying sentences, and none of that content is present.

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?

The tool has no output schema and no annotations, so the description should clarify return values and distinguish it from commsharbor_crm_activities_list and the platform-scoped variant, but it does neither. The self-explanatory parameter names prevent this from being unusable, but the definition is not complete enough for an agent to confidently select it over its siblings or know what it will receive.

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?

Although schema coverage is nominally 100%, both parameter descriptions are tautologies ('activity_id' describes 'activity_id'), so they add no real semantic value and the baseline-3 condition is not genuinely met. The tool description itself adds nothing about the parameters. An agent can guess that activity_id identifies the activity and organization_id scopes the request, but only because the parameter names are self-evident, not because the description helps.

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?

"get CRM activity" is nearly a verbatim restatement of the tool name commsharbor_crm_activities_get, which the rubric treats as a tautology. It conveys a single-record fetch only because the name already implies it, and it offers no definition of what a CRM activity is. It fails to distinguish itself from nearby siblings like commsharbor_crm_activities_list or commsharbor_platform_crm_activities_get.

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 zero guidance on when to use this tool versus the list, create, update, or delete siblings, or the platform-scoped variant. No context, prerequisites, or alternative tools are mentioned. The agent is left to infer usage purely from the parameter names.

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?

There are no annotations, so the description carries the full behavioral burden. 'list' implies a read operation, but the description does not disclose pagination behavior, cursor/limit semantics, filtering behavior, or what data is returned. For an 8-parameter list tool, this is a significant transparency gap.

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

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

The description is short and free of fluff, but it is under-specified for a tool with eight parameters, filtering options, and pagination. 'list CRM activity' is more of a fragment than a structured description, and the minimalism harms usefulness rather than improving 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 complexity of the input schema, no annotations, and no output schema, the description is severely incomplete. It fails to mention the required organization_id, available filters (deal_id, company_id, contact_id, activity_type), pagination via cursor/limit, or how results relate to other CRM list operations.

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 100%, so the baseline is 3 even though the tool description adds no parameter meaning. However, most parameter descriptions are tautological ('q', 'deal_id', etc.), and the tool description does nothing to clarify them, so no credit beyond baseline is warranted.

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 core action ('list') and resource ('CRM activity'), so the general purpose is clear. However, it does not differentiate from the sibling commsharbor_platform_crm_activities_list, which also lists CRM activity, and it does not mention any scoping like the required organization_id.

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 about when to use this tool versus alternatives such as commsharbor_crm_activities_get, commsharbor_crm_activities_create, or the platform-level list variant. The description implies listing but gives no context on filtering, pagination, or when this list is preferable to other activity 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 bears the full burden of behavioral disclosure, but it only says the tool updates an activity. It does not explain partial-update behavior, whether omitted optional fields are cleared, authentication needs, or side effects.

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

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

The description is short, but the brevity reads as under-specification rather than efficient completeness. For a mutation tool with five parameters and no annotations, a single tautological phrase is not appropriately sized.

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?

This is incomplete for a mutation tool with no annotations and no output schema. It does not state that the optional fields are the fields being updated, that activity_id and organization_id are identifiers, or what result to expect. The complete schema coverage keeps it minimally usable.

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 100%, so the baseline is 3 even though the tool description adds no parameter detail. The schema documents note, deal_id, activity_type, activity_id, and organization_id, but the prose itself provides no extra semantic meaning.

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 CRM activity.' essentially restates the tool name commsharbor_crm_activities_update, adding no information beyond the verb-object pair. It is not misleading, but it is a tautology and does not clarify scope, effect, or which fields are updatable.

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 given about when to use this tool versus the many sibling activity-related tools such as commsharbor_crm_activities_create, commsharbor_crm_activities_get, or commsharbor_platform_crm_activities_update. Prerequisites and selection criteria are entirely absent.

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, the description carries the full burden of behavioral disclosure, but it only says 'create CRM company.' It does not mention side effects, duplicate handling, idempotency, permissions, or response behavior. This is minimal transparency for a mutating 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 extremely concise and wastes no words, with the core action front-loaded. It is arguably too terse for the complexity of the tool, but as a conciseness measure it is efficient and free of filler.

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?

The tool has four parameters, two required ones, no annotations, and no output schema, yet the description only says 'create CRM company.' It omits what organization_id refers to, how domain and website relate to the company, and what the caller should expect after creation. An agent can guess the basic action but lacks enough context for confident 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 100%, so the baseline is 3 even without parameter details in the description. However, the schema descriptions are mostly tautological ('name', 'domain', 'website', 'organization_id'), adding little real semantic value. The description contributes no additional parameter-level meaning.

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 a clear verb and resource: 'create CRM company.' The intent is unambiguous and distinct from sibling update/list/delete operations on companies. It does not explicitly contrast with sibling create tools, but the resource type is specific enough.

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?

There is no guidance on when to use this tool versus alternatives such as commsharbor_crm_companies_update or commsharbor_crm_companies_list. It also does not mention prerequisites, such as needing an existing organization_id, or any related workflow context. The agent must infer usage entirely from the tool name.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'delete' and does not mention irreversibility, cascading effects, permissions, or side effects. The destructive nature is implied but not elaborated.

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, front-loaded sentence with no redundant wording. It says exactly what the tool does in the fewest possible words.

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?

This is a simple delete tool with two required, fully described parameters, so the description together with the schema is minimally sufficient for invocation. However, it lacks context about return behavior, permanence, or any constraints, despite having no output schema or annotations.

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 100%, so both required parameters are already documented. The description adds no additional meaning about how company_id and organization_id relate or should be used, but the schema sufficiently covers the basics.

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 and resource: 'delete CRM company.' It is specific enough to distinguish this delete operation from create, get, list, and update siblings, though it adds no scope or nuance beyond the tool name.

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

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

No guidance is provided about when to use this tool versus alternatives, such as platform_crm_leads_delete or crm_companies_update. The description simply states the action without context, exclusions, or references 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 the full burden, but 'get CRM company' only restates the operation and adds no behavioral detail about return shape, errors, permissions, or side-effect-free guarantees. It does at least convey that this is a retrieval rather than a mutation, but barely beyond the name.

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?

At four words, it is extremely brief, but this is under-specification rather than effective conciseness: there is no structured statement of purpose, scope, or constraints. A single bare clause does not earn its place as a useful specification.

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?

No annotations, no output schema, and a one-clause description leave the agent without information about the return value, error behavior, or whether organization_id scopes the company lookup. The two required parameters are visible in the schema, but the surrounding context is incomplete for a tool call.

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 100%, so the baseline is 3 even though the parameter descriptions merely repeat the parameter names ('company_id', 'organization_id'). The tool description itself adds no extra meaning such as the relationship between the two IDs or how they are used.

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 verb 'get' plus resource 'CRM company' clearly specifies a read operation targeting a single company, distinguishing it from siblings like crm_companies_list, create, update, and delete. However, it does not elaborate on what is returned or that lookup is by the two identifiers, so it stops short of a fully rich purpose statement.

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?

There is no guidance about when to choose this tool over alternatives; it does not mention crm_companies_list for bulk retrieval or note prerequisites such as having valid company and organization IDs. The agent must infer usage from the tool name and schema.

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 discloses only that companies are listed — nothing about pagination despite the cursor/limit parameters, result ordering, the filtering behavior of q, or how results are scoped to the organization.

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?

Three words with zero waste and the action front-loaded. But this is under-specification rather than effective conciseness — the single sentence fails to say anything meaningful about a 4-parameter tool's behavior.

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?

With no annotations and no output schema, the description is the only behavioral source and it is nearly empty. The required organization_id and ambiguous q parameter are effectively undocumented, and the result shape is undisclosed. The schema's limit/cursor entries are the only real contributions.

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 100%, so the baseline is 3. The tool description itself adds nothing about parameters. While limit and cursor have genuinely informative schema descriptions, q and organization_id are tautological ("q" and "organization_id"), so the schema only partially compensates.

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?

"list CRM company." identifies the verb (list) and resource (CRM company), which distinguishes it from sibling company CRUD operations (create/get/update/delete). However, it is grammatically awkward (singular "company" for a list operation) and provides no detail about scope or what a company record contains.

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 over alternatives. It does not mention the required organization_id scoping, the distinction from commsharbor_crm_companies_get, or the platform-level list variants (e.g., commsharbor_platform_crm_leads_list). An agent must infer usage entirely from the tool name.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It merely says 'update' and does not clarify whether this is a partial update, whether unspecified fields are preserved, what permissions are needed, whether the operation is idempotent, or what response behavior to expect.

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 short sentence, so it is structurally compact, but it is under-specified rather than meaningfully concise. It does not earn its place beyond rephrasing the tool name.

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 five parameters, required identifiers, no annotations, and no output schema, this description is far from complete. The agent cannot infer the effect of omitting name/domain/website, the response shape, or any constraints around the identifiers.

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 coverage is 100%, and the property names like name, domain, website, company_id, and organization_id are self-explanatory at a basic level. However, the schema descriptions are trivial labels, and the tool description adds nothing about which optional fields are actually updatable or how partial updates behave.

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 'update' and the resource 'CRM company', so an agent can tell this is a mutation of a company record. However, it mostly restates what the tool name already encodes and adds no scope, updatable fields, or distinguishing context versus the many sibling CRM 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?

There is no guidance about when to use this tool versus commsharbor_crm_companies_create, commsharbor_crm_companies_delete, commsharbor_crm_companies_get, or commsharbor_crm_companies_list. No prerequisites, alternatives, or exclusions are mentioned; the only hint is the verb 'update', which is already in the tool name.

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 'create CRM contact,' which reveals the basic mutation but does not mention response behavior, duplicate handling, organization scoping, or consequences of the create 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 highly concise and free of filler, delivering the core action in three words. It is not padded, though it could have been slightly more informative without harming 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?

For a mutation tool with no annotations and no output schema, the one-sentence description is thin. It does not state what the create operation returns, whether existing contacts with the same email are affected, or that organization_id is required beyond what the schema already lists. More context is needed given the many sibling CRM and import tools.

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 100%, so the parameters (email, company_id, first_name, organization_id) are already documented in the input schema. The description adds no additional meaning about formats, constraints, or relationships between parameters, so the baseline of 3 applies.

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 CRM contact' uses a specific verb and resource, clearly stating the tool's function. It distinguishes this tool from siblings like crm_contacts_update, crm_contacts_delete, and crm_contacts_list by specifying the create action on a contact.

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?

There is no guidance about when to use this tool versus alternatives such as commsharbor_contact_import_confirm for bulk imports or commsharbor_crm_contacts_update for modifying existing contacts. The description provides no exclusions, prerequisites, or context to help an agent choose correctly.

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, the description carries the burden for behavioral disclosure, but 'delete CRM contact' only conveys that a destructive mutation occurs. It does not state whether deletion is permanent, whether it cascades to related records such as activities or deals, which permissions are required, or what the success response is.

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 four-word sentence with no filler and the action verb is front-loaded. It is concise to the point of being terse, but it does not waste any words.

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 an irreversible mutation tool with no annotations and no output schema, this is incomplete. An agent cannot know whether the delete is soft or hard, what happens to associated CRM data, or what indicates a successful delete, so extra context such as 'permanently removes' or 'cannot be undone' 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?

The schema covers both parameters at 100%, so the baseline is 3. The descriptions 'contact_id' and 'organization_id' are tautological and the tool description adds no further parameter meaning, but an agent can still infer that organization_id scopes the deletion and contact_id identifies the record.

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 'delete' and the resource 'CRM contact' directly, so an agent can tell this operation apart from crm_contacts_get/list/create/update. It is clear, though it does not go beyond the tool name to explain what 'CRM contact' means or how this relates to the platform_crm_contact 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 when-to-use or when-not-to-use guidance is provided. The description does not mention confirming the contact exists first, nor does it contrast this tool with crm_contacts_update or any archive/soft-delete alternative.

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 disclosing behavior. It only restates the operation implied by the tool name ('get') and adds no detail about return shape, not-found behavior, organization scoping, or whether any side effects occur. The description is too thin to meaningfully inform an agent beyond what the name already suggests.

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 short, front-loaded sentence with no filler or redundant words. Every word contributes to identifying the operation and resource. It could be more informative without becoming bloated, but as far as conciseness goes it is efficient.

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 two-parameter retrieval tool, the description is minimally viable: an agent can infer that the tool fetches a CRM contact and that organization_id and contact_id are needed. However, with no output schema and no annotations, the absence of explicit return or error behavior is a noticeable gap. It is adequate but not complete.

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 100%, so the baseline is 3 even though the tool description adds nothing about parameters. The property descriptions are tautological ('contact_id' and 'organization_id'), but the names are self-explanatory and the required fields clearly identify the target contact. The tool description provides no additional semantic meaning 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 uses a specific verb and resource: 'get CRM contact.' This clearly indicates retrieval of a single CRM contact and is distinguishable from sibling tools like create, update, delete, and list operations. It does not explicitly differentiate from closely related get variants, but the singular resource plus required contact_id makes intent reasonably clear.

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 gives no guidance on when to choose this tool over alternatives such as commsharbor_crm_contacts_list, commsharbor_crm_contacts_create, or commsharbor_crm_contacts_update. It does not mention context, exclusions, or when a sibling tool would be more appropriate. An agent must infer usage purely from naming conventions.

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 says 'list', which hints at a read operation, but it does not disclose pagination behavior, required organization scoping, potential filters, or anything about the response shape.

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 very short and free of filler, but it is under-specified for a tool with five parameters and pagination. It is concise in length but not appropriately informative.

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?

With no annotations, no output schema, and pagination/filter parameters, this list endpoint needs at least a sentence about result format, pagination, or scoping. The one-sentence description leaves an agent guessing about how to correctly invoke and page through the 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?

Schema coverage is nominally 100%, so the baseline applies. The description itself adds no meaning beyond the schema, and several schema descriptions are tautological ('q', 'company_id', 'organization_id'), though 'limit' and 'cursor' are adequately described.

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 a clear verb ('list') and resource ('CRM contact'), making the basic operation understandable. However, it largely restates the tool name and does not add distinguishing detail relative to sibling tools like crm_contacts_get or crm_contacts_export.

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?

There is no guidance about when to use this tool versus alternatives such as crm_contacts_get, crm_contacts_export, or platform_crm_leads_list. The only implied context is 'when you want a list', with no conditions, exclusions, or 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?

Annotations are absent, so the description carries the full burden of behavioral disclosure. It signals mutation via 'update' but does not clarify whether this is a partial update, whether omitted optional fields are cleared, whether the contact must already exist, what permissions are needed, or what the response contains.

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

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

The description is short and free of filler, but it is under-specified rather than appropriately concise. A six-word phrase that essentially restates the tool name does not provide enough structure or content for a five-parameter mutation tool.

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?

This is a mutating tool with five parameters, no output schema, and no annotations, so the description needs to supply meaningful context. It does not explain when to use it, what behavior to expect, what the return value is, or any edge cases, leaving the agent to rely almost entirely on the bare 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?

The input schema covers 100% of the parameters with at least minimal descriptions, so the baseline is 3. The description itself adds no extra semantic detail about parameters such as email uniqueness, field overwrite behavior, or relationships between organization_id and contact_id.

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 'update' and the resource 'CRM contact,' which clearly identifies the core action and distinguishes it from sibling tools like create, get, list, and delete for CRM contacts. However, it adds almost no detail beyond what the tool name already conveys, so it is clear but not richly informative.

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?

There is no guidance on when to use this tool versus alternatives such as com...crm_contacts_create, com...crm_contacts_get, or com...crm_contacts_delete. The word 'update' implies modifying an existing contact, but the description does not mention prerequisites, exclusions, or situations where a different CRM tool would be more appropriate.

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

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

No annotations are provided, so the description carries the full burden. It only restates that the tool creates a deal and does not disclose whether valid pipeline/stage references are required, what side effects occur, whether the operation is idempotent, or what response the caller can expect.

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 short sentence with no filler or structural waste. It is easy to parse, though the brevity borders on under-specification rather than effective conciseness.

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?

With six parameters, four required, no annotations, and no output schema, the description is insufficiently complete. An agent cannot infer valid value sources, required relationships among the parameters, or what successful creation returns.

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 100%, so the schema already documents all six parameters. The description adds no further meaning about parameter relationships, value_minor units, currency format, or how organization_id, pipeline_id, and stage_id interact.

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 the resource ('CRM deal'), making the core purpose clear. It distinguishes from sibling get/list/update/delete tools via the create verb, though it does not define the deal scope beyond the tool name.

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

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

No guidance is provided about when to use this tool versus alternatives such as crm_deals_update, crm_deals_list, or platform_crm_deals_create. There is also no mention of preconditions like needing an existing organization, pipeline, or stage.

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, and it only states the word 'delete.' It does not mention whether the deletion is permanent or reversible, whether it cascades to related records, what permissions are required, or what response to expect.

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 short sentence with no wasted words, but it is under-specified rather than appropriately concise. It provides no information beyond what the tool name already conveys, so the sentence does not earn meaningful value.

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 far too thin. It does not explain the role of organization_id, the consequences of deleting a deal, error behavior, or any safety considerations, leaving an agent with only the raw parameter names to infer how to call 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 100%, so the parameter names are each documented in the schema, even if only by echoing the parameter name. The tool description itself adds no parameter-level meaning, but the high schema coverage justifies the baseline score of 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 'delete CRM deal' is essentially a word-for-word expansion of the tool name commsharbor_crm_deals_delete. It names the action and resource clearly but adds no distinguishing detail, scope, or qualifier, and does not help differentiate it from sibling delete 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 such as commsharbor_crm_contacts_delete, commsharbor_crm_activities_delete, or other CRM delete tools. There are no conditions, exclusions, or hints about prerequisites for deletion.

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 CRM deal.' does not explain the response format, error behavior, authentication requirements, or side-effect-free read behavior. It adds no behavioral context beyond what the tool name already implies.

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 short and front-loaded, but this is under-specification rather than effective conciseness. It contains no filler, yet it also fails to provide useful context beyond the tool name.

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 two required parameters, no annotations, and no output schema, the description is insufficiently complete. It does not mention return value shape, not-found behavior, or the role of organization_id, leaving an agent to infer most behavior from the name and parameter names 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 100% for both required parameters, reaching the high-coverage baseline. However, the schema descriptions are just 'deal_id' and 'organization_id', and the tool description adds no extra meaning about why both are required or how they relate. The baseline of 3 applies, but the description itself contributes no parameter clarity.

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 a clear verb and resource: 'get CRM deal.' It unambiguously identifies the operation as retrieving a single CRM deal, and the singular 'deal' distinguishes it from list-style operations. It does not explicitly describe how it differs from sibling tools, but the core purpose is not 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?

The description gives no guidance on when to use this tool versus alternatives like commsharbor_crm_deals_list, commsharbor_crm_deals_update, or commsharbor_crm_deals_delete. There are no prerequisites, exclusions, or scenario-based selection cues.

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 bears the full burden of behavioral disclosure. It only says 'list CRM deal' and does not describe return format, pagination behavior, filtering semantics, organization scoping, or whether the operation is read-only. It adds minimal behavioral context beyond the tool name.

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

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

The description is short, but brevity here reflects under-specification rather than disciplined conciseness. It is a single vague phrase with no structured breakdown of behavior, filters, or usage context, so it does not earn a higher score.

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?

With 7 parameters, no output schema, and no annotations, a one-phrase description is inadequate. The agent is not told which parameters are filters, that organization_id is required, what the list contains, or what the response shape looks like. The description leaves too many essential details unresolved.

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?

Although schema coverage is nominally 100%, most parameter descriptions are tautological (e.g., 'q': 'q', 'status': 'status', 'organization_id': 'organization_id'). The tool description adds no explanation of how parameters interact, what filters mean, or how cursor pagination works, so the agent is left with unhelpful placeholder semantics.

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 a specific action ('list') on a specific resource ('CRM deal'), which distinguishes it from sibling tools like crm_deals_get, crm_deals_create, and crm_deals_update. However, it is terse and uses singular 'deal' rather than describing a collection, so it does not fully articulate scope or response behavior.

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?

There is no guidance on when to use this tool versus alternatives, no mention of prerequisites, and no context about filtering or pagination. An agent must infer usage purely from the tool name and schema.

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 behavioral burden. 'Update' signals mutation, but the description does not disclose permissions, partial-update semantics, side effects, or whether an existing deal must already exist.

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 very short and has no wasted words, but this is under-specification rather than effective conciseness. A single generic sentence is not appropriately sized for a 7-parameter mutation tool.

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 7 parameters, no annotations, and no output schema, the description should explain update behavior, required identifiers, and how it differs from sibling tools. It provides none of that, leaving an agent to infer the full contract.

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 100%, so the baseline is 3 even though the tool description adds no parameter meaning. The schema's property descriptions are mostly tautological ('title: title'), and the description does not clarify that organization_id and deal_id identify the target deal.

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 a clear verb ('update') and resource ('CRM deal'), so an agent can tell this is a mutation operation on deals. However, it is generic and does not distinguish this tool from similar siblings like commsharbor_crm_deals_create or commsharbor_platform_crm_deals_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?

There is no guidance about when to use this tool versus alternatives such as deal creation, listing, or retrieval. No context, prerequisites, or exclusions are provided to help an agent choose correctly.

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 'create CRM pipeline' only restates the obvious action. It does not mention side effects, required preconditions like an existing organization, validation behavior, idempotency, or what the response contains.

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

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

The description is a single efficient sentence with no fluff, which is good, but it is also under-specified. It earns its place without wasted words, yet it is not sufficiently informative for the tool it describes.

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 no annotations, no output schema, and several parameters, this description is too thin. It omits behavioral context, the meaning of stages, and return expectations, leaving the agent to rely almost entirely on the name and 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?

Schema coverage is 67%, but the existing descriptions are unhelpful tautologies: 'name' and 'organization_id'. The tool description adds nothing about parameters, and the optional 'stages' array is left entirely unexplained. The schema provides structure, but the description does not compensate for the missing semantic detail.

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 CRM pipeline' names a specific verb and resource, and it clearly differentiates this tool from sibling pipeline tools like commsharbor_crm_pipelines_get, list, update, and delete. It is minimal but genuinely states what the tool does.

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, no prerequisites, and no exclusions. An agent has to infer from the tool name and sibling list that this is the creation action; there is no explicit context about when to choose create over update or delete.

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. Saying 'delete' implies a destructive operation, but the description does not state whether deletion is permanent or reversible, whether it cascades to associated stages or deals, whether it is idempotent, or what permissions are required. For a destruction tool this is a significant gap.

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

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

The description is three words with zero wasted content, and the action is front-loaded. However, it is so minimal that it borders on under-specification — there is no information beyond what the tool name already conveys, so the description earns little independent value.

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?

With no output schema, no annotations, and only a terse description, the tool is incomplete for a destructive operation. An agent would not know what the call returns on success/failure, whether deletion is permanent or cascades, or any safety considerations. The simple 2-parameter schema lowers the bar, but a deletion tool should disclose side effects.

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 100% (both pipeline_id and organization_id have descriptions), so the schema already documents the parameters. The description adds no additional meaning about how the parameters relate (e.g., that pipeline_id is scoped within organization_id or how to obtain valid IDs). Baseline 3 applies because the schema carries the load.

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 'delete CRM pipeline.' uses a specific verb (delete) and resource (CRM pipeline), clearly identifying the operation. It inherently distinguishes from sibling tools like commsharbor_crm_pipelines_create, _get, _list, and _update, since 'delete' states the exact action. However, it gains no additional precision from the title (null) and offers no elaboration on what a pipeline deletion entails.

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, exclusions, or distinguish this from other delete tools in the sibling set (e.g., crm_pipelines_delete vs crm_stages_delete vs crm_deals_delete). An agent must infer usage entirely from the tool name.

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

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

With no annotations provided, the description carries the full burden of disclosing behavior. 'Get' implies a read-only operation, but the description does not explain what is returned, whether authentication is required, how errors are handled, or any side effects. This is minimal 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 short and contains no fluff, but it is under-specified. A single sentence that only repeats the resource name is concise in length but not in content, leaving important context about scope and behavior unstated.

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 no output schema and no annotations, the description should state what the tool returns or what 'get' means in terms of response behavior. It does not mention return shape, data included, or any caveats. The two required parameters are clear from the schema, but the overall definition is incomplete for an agent invoking it blindly.

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 100%, so the schema already documents both parameters. The description itself adds no semantic detail beyond the schema, but the parameter names 'pipeline_id' and 'organization_id' are self-explanatory in context. This meets the baseline for a get-by-ID operation.

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 a clear verb ('get') and a specific resource ('CRM pipeline'), and the singular form distinguishes it from sibling 'commsharbor_crm_pipelines_list'. However, it does not explicitly say that it retrieves a single pipeline by pipeline_id, and it largely restates the tool name without adding detail.

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 gives no guidance on when to use this tool versus alternatives such as list, create, update, or delete. There is no mention of prerequisites, how it differs from the list operation, or any conditions that would make this tool the right choice.

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. 'list CRM pipeline' only restates the obvious read-oriented action and fails to disclose behavior around pagination, cursor usage, limit defaults, search filtering via 'q', or output shape.

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 short and front-loaded, with no wasted words. It is appropriately sized for a simple list operation, though it borders on under-specification by omitting useful 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?

With no output schema, no annotations, and a four-parameter input schema, a one-line description is not enough. The agent is left without return-value expectations, pagination behavior, or clarification of what 'pipeline' means in this CRM 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 100%, so the baseline is 3 even though the description adds no parameter-level detail. The schema already names organization_id, q, limit, and cursor, but their descriptions are terse (e.g., 'q' and 'organization_id'), so the description could have added meaningful semantics but did not.

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 uses a specific verb ('list') and identifies the resource ('CRM pipeline'), which distinguishes it from sibling operations like create, get, update, and delete. It could be slightly clearer by saying 'pipelines' plural and noting what scope is returned, but the core purpose is unambiguous.

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

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

The description gives no guidance on when to use this tool versus the many sibling tools. It does not mention that this should be used to retrieve multiple pipelines rather than a single pipeline via commsharbor_crm_pipelines_get, nor does it explain any filtering or pagination 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 the full burden of behavioral disclosure. It only states 'update,' which implies mutation, but does not explain whether this is a partial or full update, whether stages are replaced, what permissions are needed, or what the response is. This is minimal transparency and leaves important behavioral details unknown.

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 short, but it is under-specified rather than efficiently structured. It is a single fragment that mostly restates the tool name, so it does not earn its place by adding useful information. There is no structure that helps an agent parse what is being updated or how.

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?

With no annotations and no output schema, the description alone is the only narrative context, and it is far from complete. It does not explain the update semantics, the role of the four parameters, or what the agent should expect after calling the tool. The required parameters in the schema help, but the overall definition is insufficient for confident 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 schema descriptions are mostly tautological ('name': 'name', 'pipeline_id': 'pipeline_id'), and the stages parameter has no description. The tool description does not mention any parameters or clarify that name and stages are the updatable fields while organization_id and pipeline_id identify the target. At 75% schema description coverage, the existing descriptions add little real semantic value.

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 a clear verb and resource ('update CRM pipeline'), so an agent can tell this is a mutation tool for pipelines. However, it does not specify what aspects of the pipeline can be updated, such as name or stages, and it largely restates the tool name without adding meaningful detail. It is not misleading, but it is vague about scope.

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

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

The description gives no guidance on when to use this tool versus the many sibling tools such as commsharbor_crm_pipelines_create, commsharbor_crm_pipelines_delete, or commsharbor_crm_pipelines_get. There is no mention of prerequisites, required existing pipeline, or when not to use this tool. The only implied usage is the verb 'update.'

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 explaining behavior. It only says 'create CRM stage,' which conveys mutation but nothing about required relations, idempotency, duplicate handling, default positioning, or what happens after creation. This is minimal disclosure for a write 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 extremely compact with no filler or redundant phrasing. It is front-loaded with the action and object. It does sacrifice useful context for brevity, but for pure conciseness and simple structure it is effective.

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 5-parameter creation tool with no annotations and no output schema, the description is far too thin. It does not explain that a stage belongs to a pipeline, that organization and pipeline identifiers are required, what optional fields like position and probability mean, or what the expected result is. The schema captures parameter names but not the operational context needed to confidently call the 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?

Schema description coverage is 100%, so the baseline is 3 even though the description adds no parameter-level meaning. The parameter descriptions are largely just field-name repetitions, but the required fields organization_id, pipeline_id, and name are at least listed. The description itself does not explain why these are needed or how position and probability behave.

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 a clear action and resource: 'create CRM stage.' This is a specific verb and object that distinguishes the tool from stage retrieval, update, deletion, and list operations. However, it adds no detail beyond what the tool name itself already communicates, so it stops short of 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 gives no guidance about when to use this tool versus alternatives, such as crm_stages_update or crm_pipelines_create. There is also no mention of prerequisites like needing an existing pipeline before creating a stage. Usage context is left entirely to the agent's inference.

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 disclosing behavior. It only says 'delete', which implies a destructive operation, but it does not state whether the deletion is permanent, whether it cascades to related deals, or what side effects or permissions are involved.

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 short and contains no fluff, but it is so minimal that it borders on under-specification. There is no structure beyond a single terse sentence, so it is appropriately concise but not meaningfully informative.

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 mutation with no annotations, no output schema, and three required identifiers, the description is incomplete. It fails to mention what happens to the stage's associated data, whether the deletion is reversible, or how the three IDs scope the 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 100%, so the baseline is 3 even though the description adds no parameter-level meaning. The individual parameter descriptions in the schema merely repeat the parameter names and do not explain relationships or constraints beyond the three required IDs.

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 specific verb 'delete' and the resource 'CRM stage', which clearly differentiates it from the sibling stage tools like create, get, list, and update. However, it is a near-verbatim restatement of the tool name and omits the organizational/pipeline context implied by the required parameters.

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?

There is no guidance about when to use this tool instead of the other CRM stage operations, and no prerequisites or conditions such as whether the stage must be empty, whether deals need to be reassigned, or if deletion is restricted. The only usage signal is the verb 'delete' itself.

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