Support Agent Admin by Nova (CIVAI)

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

With no annotations, the description carries the full burden, and it does disclose two real side effects: scans are marked interrupted and the schedule lock is released. It stops short of describing permission requirements, whether the action is reversible, or how partial failures across multiple scan_ids are handled.

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 short sentence with the action front-loaded and the parenthetical side effects right behind it. No filler, every clause 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 an un-annotated mutation tool with no output schema and no parameter documentation, the description covers the core effect but leaves permissions, return behavior, and parameter meaning unaddressed. Adequate at the top level, incomplete in the 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 0% and the description says nothing about agent_id, scan_ids, or reason. The names are partly self-explanatory, but with three completely undocumented parameters the description adds no semantic value beyond the schema.

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

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

States a specific verb+resource (stop scans) with a scope qualifier ('stuck running') that separates it from delete_scans and continue_scan. It does not explicitly name those siblings, so differentiation is by implication rather than direct contrast.

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?

'Stuck running scans' implies the trigger condition, so the agent can infer when this applies rather than delete_scans or continue_scan. However there is no explicit when-not guidance and no named alternative, leaving the agent to reason about which of the several scan-control tools to pick.

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. It signals a mutation ('assign or remove') but says nothing about required permissions, whether removal destroys linkage, or what happens if the account is already assigned.

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. It is efficient, though its terseness is part of the under-specification problem rather than an asset here.

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 0% parameter documentation, the description is too thin — it omits the assign/remove toggle semantics and any safety or permission context.

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

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

Schema description coverage is 0% and neither parameter is explained. Critically, the description implies a remove mode but never states that instagram_account_id is optional and that omitting it performs removal — exactly the semantic an agent needs.

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 pair and resource ('Assign or remove Instagram account on agent'), and the resource name cleanly distinguishes it from sibling tools like admin__assign_telegram_account and admin__assign_x_account. It falls short of 5 because the dual assign/remove mode is not explained.

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

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

No guidance on when to use this tool versus siblings such as admin__list_channel_accounts or the other assign_* tools, and no indication of prerequisites (e.g., the account must already exist). It also never clarifies how 'remove' is triggered, which is the key usage decision.

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 for a mutation tool. It never states whether removal is triggered by omitting jiji_account_id or by some other flag, what happens to an existing Jiji binding on reassignment, or whether the change is reversible.

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 short sentence, front-loaded, with no filler. However its brevity comes from under-specification rather than economy: the one sentence raises the 'remove' path without explaining it.

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 mutation tool with no annotations, no output schema, and 0% schema coverage, the description leaves the core invocation semantics undocumented. An agent cannot safely determine how to unbind an account from this definition alone.

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

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

Schema description coverage is 0% for both parameters, so the description must compensate and does not. The critical ambiguity — how to invoke the 'remove' half of the stated purpose — is left unresolved; jiji_account_id is presumably optional-but-required-for-removal, yet nothing in the text or schema says so.

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 pair (assign/remove) and resource (Jiji account on agent), and the channel name 'Jiji' distinguishes it from the parallel assign_instagram_account / assign_telegram_account siblings. It stops short of naming which sibling to prefer or how the two operations differ.

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 prerequisites (e.g., must the account exist in list_channel_accounts first?), and no indication of which sibling to use for other channels. The dual assign/remove purpose also has no stated condition for selecting one over the other.

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. It states a mutation happens but not what removal requires, whether smtp_account_id omission triggers removal, whether the operation is idempotent or reversible, or what permissions are needed. The dual assign/remove semantics are the single most important behavior and are left unstated.

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 short sentence with no filler, but its brevity is under-specification rather than economy. It is appropriately front-loaded but too thin for a mutating 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 no annotations, no output schema, and 0% parameter coverage, the description should explain the assign-vs-remove trigger and expected effects. None of that is present, leaving the agent to guess at invocation semantics.

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

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

Schema description coverage is 0% and the description adds no meaning for either parameter. Critically, it never explains that omitting smtp_account_id is presumably what performs the 'remove' half of the operation — the one piece of semantics an agent needs most.

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?

Names a verb pair and resource ('Assign or remove SMTP account') plus the target ('on agent'), so the domain is identifiable. However, it conflates two opposite operations without saying how each is triggered, and it does nothing to distinguish itself from the many sibling assign_* tools. Minimum viable but vague on the core mechanic.

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 prerequisites, and no mention of alternatives such as admin__list_channel_accounts for discovering accounts or admin__update_agent for other agent changes. The agent must infer context entirely from the 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 says assign or remove, without stating permissions, side effects, idempotency, what happens to an existing assignment, or whether removal requires a specific parameter value.

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 single sentence is concise and front-loaded with the operation and resource. However, it is arguably too terse for a mutation tool with meaningful parameter semantics, so it falls short of ideal structure.

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

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

Given no annotations, no output schema, and 0% schema description coverage on a two-parameter mutation tool, the description is not complete enough. It omits critical operational details about removal behavior, parameter roles, and 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 0%, so the description needed to compensate for the two undocumented parameters. It does not explain that agent_id is required, that telegram_account_id is optional, or how omitting or setting telegram_account_id relates to assigning versus removing.

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 pair (assign or remove) and resource (Telegram account on agent). The platform-specific name and sibling set make the intended target clear, though the description does not explicitly differentiate itself from other assign_* tools beyond the platform.

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?

It gives no guidance on when to use this tool versus alternatives such as list_channel_accounts or other assign_* siblings. It also does not explain prerequisites or how removal is triggered, leaving usage context entirely to 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?

With no annotations, the description carries full behavioral burden, yet it only states the operation type. It omits permissions required, side effects, reversibility, and how the assign vs remove mode is determined, leaving significant transparency gaps for a mutation tool.

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

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

A single, front-loaded sentence with no wasted words. Its brevity is appropriate structurally, though the content itself is under-specified rather than overly verbose.

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

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

Given no annotations, no output schema, and 0% schema coverage, the description is incomplete for a two-parameter mutation tool. It should define usage context, parameter behavior, and expected outcomes, but covers only the bare 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 coverage is 0%, so the description should compensate but does not. It loosely references an agent and an account, but does not explain required vs optional parameters or the critical semantic of how removal is triggered (likely by omitting whatsapp_account_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 gives a specific verb ('assign or remove') and resource ('WhatsApp Web account') with a clear target ('agent'). It distinguishes this tool from sibling assign tools by naming the channel, but offers no further differentiation or explanation of the dual assign/remove 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 when-to-use guidance, prerequisites, or alternative comparisons are provided. The channel name implicitly routes the agent, but there is no explicit direction on when to select this tool over the other assign_*_account 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?

No annotations are provided, so the description carries the full burden. It does disclose one non-obvious behavioral constraint ('One agent per handle') and the operational consequence of the assignment (inbound DMs and replies), but it is silent on replacement semantics (does assigning overwrite a prior account?), permissions, and reversibility, which matter for a mutation.

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?

Two short sentences, zero filler, and the core action is front-loaded. The parenthetical is terse to the point of mild ambiguity, but nothing is wasted.

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 no-annotation mutation tool with 0% parameter documentation and no output schema, the description leaves too much unspecified: ownership/replacement behavior, error cases for the one-per-handle rule, and what the two IDs refer to. An agent could invoke it syntactically but not confidently.

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 0% and the description never explains either parameter. It is unclear what omitting the optional x_account_id means (clear the binding vs. use a default), and agent_id is not characterized beyond being required. The description does not compensate for the documentation gap.

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

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

States a specific verb+resource ('Assign main X account on agent') and adds the functional scope '(inbound DMs and replies)' and the 'main' qualifier that helps distinguish it from admin__assign_x_campaign_account. It stops short of explicitly naming that sibling, but an agent can reasonably tell the two apart.

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

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

No explicit when-to-use, prerequisites, or alternative-routing guidance. The only usage-adjacent hint is the constraint 'One agent per handle', which implies a precondition but does not say what to do if the handle is already assigned or when to prefer this tool over the campaign-account variant.

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, and it does disclose two useful traits: the assignment is outbound-only and it borrows the login from another agent's main account. However, it says nothing about required permissions, whether the borrow is reversible, error/conflict behavior, or what happens to the source account.

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 telegraphic sentence with zero waste, front-loading the action and the key behavioral qualifier immediately. Nothing redundant or padded.

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 only 33% schema description coverage across three parameters, this description is too thin to fully specify behavior. It is missing permissions, side effects, and selection guidance, which the structured data does not supply.

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 33%, so the description must compensate, but it mentions no parameter names or formats. The 'borrows login from another agent's main account' phrase loosely gestures at move_main_to_agent_id, yet that behavior is already documented in the schema field, so nothing is added.

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 and resource ('Assign campaign X account') and adds scope qualifiers ('outbound only, borrows login'). It distinguishes itself conceptually from admin__assign_x_account via the 'campaign' and 'borrows' framing, but never names the sibling explicitly, leaving the contrast to inference.

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, when-not-to-use, or alternative routing is given. With a dozen near-identical assign_* siblings (assign_x_account, assign_instagram_account, etc.), the description provides no condition that tells an agent which one to pick.

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

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

No annotations are provided, so the description carries full disclosure burden. It does mention that files are deleted along with sessions, which is useful extra destructive context, but it omits irreversibility, required permissions, bulk limits, auth requirements, and any confirmation or recovery behavior.

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

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

The description is a single, front-loaded sentence with no wasted words. It is appropriately concise, though its brevity leaves it under-informative for a destructive bulk operation.

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

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

The tool is a destructive bulk operation with no annotations, no output schema, and 0% parameter documentation. The description acknowledges file deletion but does not cover required parameters, safety warnings, or return behavior, leaving substantial gaps for correct invocation.

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

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

Schema description coverage is 0%, and the description does not mention either required parameter ('agent_id' or 'visitor_ids'), their expected format, scope, or any constraints. It fails to compensate for the total lack of parameter documentation in the schema.

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

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

The description states a specific verb ('Delete'), resource ('multiple visitor sessions'), and an important side effect ('and their files'). It is clear enough to distinguish from single-session or other delete tools, though it does not explicitly contrast with siblings like admin__delete_agent or admin__delete_scans.

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 prerequisites, and no exclusions. The phrase 'Delete multiple visitor sessions' implies bulk deletion, but the agent is left to infer all usage context.

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

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

With no annotations, the description carries the full behavioral burden but discloses almost nothing: it does not say whether messages are actually sent, whether the action is reversible, what permissions are required, or how rate limits or errors are handled. For a bulk outbound action, this is a severe 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 single sentence is front-loaded and short, but it is under-specified rather than concise. It omits critical context that a caller needs, so brevity here costs more than it saves.

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 four-parameter bulk action with no annotations, no output schema, and 0% schema description coverage, the description is completely inadequate. An agent cannot safely or accurately invoke this tool from the definition alone.

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

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

Schema description coverage is 0%, and the description mentions no parameters. It does not explain required fields agent_id and message, nor the distinction between filter_by and visitor_ids, leaving all four parameters semantically undocumented.

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

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

The description largely restates the tool name: 'Bulk follow-up' echoes 'bulk_followup', adding only 'to filtered visitors'. It does not specify what a follow-up action entails (send message, email, sequence step) or distinguish this tool from siblings like admin__send_followup, admin__compose_bulk_draft, or admin__preview_followup_email.

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, prerequisites, or alternatives are provided. The phrase 'to filtered visitors' hints at a targeting mode but gives no instruction on when to prefer this over admin__send_followup or how filter_by and visitor_ids interact.

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, and 'Merge' is the only behavioral disclosure — implying additive rather than replacing labels. It says nothing about permission requirements, batch-size limits, agent scoping, or what happens to invalid visitor_ids, which are material for a bulk mutation.

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 zero filler. It is efficient, though the brevity is partly under-specification rather than tight writing.

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 bulk mutation tool with no annotations, no output schema, and 0% documented parameters needs far more than one sentence. An agent cannot determine label format, idempotency, or failure behavior for bad visitor_ids from this definition.

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

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

Schema description coverage is 0% for 3 parameters, so the description must compensate and does not. The words 'labels' and 'multiple visitor sessions' loosely map to two params, but the array-of-objects structure of labels and the role of agent_id are left entirely undocumented.

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

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

States a specific verb (merge labels) and resource (visitor sessions) with a scope qualifier (multiple), which is clear on its own. It never names the sibling set_session_labels or update_session_label, so the agent must infer the singular-vs-bulk distinction from the word 'multiple' alone.

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, when-not-to-use, or alternative is given despite close siblings (set_session_labels, update_session_label, bulk_delete_sessions). The word 'merge' hints at additive semantics but this is never contrasted with a replace-style 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?

With no annotations, the description carries the full burden. It usefully identifies what is destroyed (seen handles and WA progress state), but says nothing about whether clearing is recoverable, whether it forces a full rescan, what permissions are required, or what the response contains. For a destructive mutation this is a notable 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?

A single clause-free sentence that names verb, resource, and scope up front. Nothing extraneous.

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 destructive, unannotated, no-output-schema mutation with one undocumented parameter and no when-to-use or safety context. The description is too thin for the tool's blast radius.

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

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

Schema description coverage is 0% and the sole required parameter (agent_id) is never referenced in the description — no mention of what an agent id is here or whether it accepts a name/slug. The description adds no parameter meaning beyond the bare schema.

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

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

The description gives a clear verb ('Clear') plus a specific resource ('Leads Discovery scan cache') and even names the internal state affected ('seen handles / WA progress'). It does not, however, differentiate itself from adjacent scan siblings like admin__delete_scans or admin__continue_scan, so the reader cannot fully disambiguate from name alone.

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 statement of when to clear the cache versus alternatives (delete_scans, continue_scan, run_scan) or what precondition/state motivates a reset. Usage is only inferable 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 behavioral burden, but it does not say whether a draft is persisted or sent, whether the operation is reversible, what permissions/agent state are required, or how the bulk scope is determined. 'AI-compose ... (agent voice only)' hints at generation and a voice constraint but leaves all consequential behavior undocumented.

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

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

One short sentence with no filler and the operation front-loaded. It is efficient, though the brevity here reflects under-specification rather than disciplined concision.

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-flavored, AI-driven bulk operation with no annotations, no output schema, and an undocumented required parameter, the description is far too thin. An agent lacks enough information to invoke it correctly or predict its effect.

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 single required parameter agent_id has 0% schema description coverage and is never mentioned or explained in the description. An agent cannot tell from either source what agent_id identifies or how it affects the bulk composition.

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 verb ('compose') and a resource ('bulk follow-up draft'), which is more than a tautology, and 'bulk'/'shared' loosely distinguishes it from the sibling admin__compose_draft. However, it never explains what 'shared' means, which sessions/agents the draft applies to, or how this differs functionally from admin__bulk_followup, so the scope stays 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?

There is no when-to-use guidance and no reference to alternatives such as admin__compose_draft, admin__bulk_followup, or admin__preview_followup_email. The only constraint offered ('agent voice only') is a mode restriction, not usage context.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that this does not send, but omits whether the draft is persisted, what permissions are required, and whether composition consumes quota/rate limits.

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 wasted words; the core action and the key constraint (does not send) both appear immediately.

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

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

For a 2-parameter tool with zero annotation coverage, no output schema, and 0% schema descriptions, one sentence is insufficient. It neither describes the generated draft's nature nor the parameters an agent must supply.

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 0% for both parameters, so the description must compensate. 'one visitor session' loosely maps to visitor_id, but agent_id is entirely unexplained and no format/ID semantics are provided for either.

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?

Names a specific verb (compose) and resource (draft reply) scoped to a single visitor session, and the 'does not send' clause distinguishes it from admin__send_message and the bulk variant admin__compose_bulk_draft. The parenthetical '(Zap; ...)' is cryptic and adds no clarity.

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

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

Usage is only implied: 'one visitor session' hints at the single-session case versus compose_bulk_draft, and 'does not send' implies sending is a separate step, but no alternative tool is named and no when-not guidance is given.

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. 'Continue' implies resumption of a paused operation, but the description does not state permissions required, what side effects occur (e.g., contacts gathered, messages sent), reversibility, or what the response contains. Only the barest behavioral signal is present.

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 zero filler; the core action leads and the clarifying parenthetical follows. Efficient, though the brevity contributes to the coverage gaps elsewhere rather than being purely a virtue.

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 four-parameter, three-required operation with no annotations, no output schema, and 0% schema description coverage, the description is too thin. It does not explain the parameters, the behavior on success or failure, or how the paused state was created, so an agent lacks what it needs to invoke this reliably.

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

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

Schema description coverage is 0% for all four parameters, so the description must compensate and largely does not. It hints at the concept behind selected_resources ('groups or IG/X targets') but never specifies the expected string format, and it is silent on scan_id, agent_id, and max_contacts_per_group. This leaves most parameters semantically opaque.

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 and resource ('Continue a scan') and adds a qualifying clause that the scan was 'paused for selection', which differentiates it from run_scan. It also names the resource types (WhatsApp/Telegram groups, IG/X targets), giving a clear sense of scope. No explicit sibling comparison, but the paused-scan qualifier effectively separates it.

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 'paused for selection' implies the precondition for use — a previously paused scan awaiting group/target selection — which is real context. However, it never explicitly says when to use this versus run_scan, get_scan, or list_scan_results, nor what to do if no scan is paused. Usage is implied 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 full behavioral disclosure burden. It does not explain side effects, default values, required-field implications, whether the agent becomes active immediately, or permission/auth requirements for a 33-parameter creation tool.

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

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

The single sentence is front-loaded and wastes no words. It is as concise as possible, though its brevity exacerbates gaps captured in other dimensions.

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

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

For a complex creation tool with 33 parameters, no annotations, and no output schema, the description is far too sparse. It does not explain required inputs, defaults, channel behavior, visibility, allow-list semantics, or what creating an agent actually sets up.

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 only 33% for 33 parameters, and the description adds no parameter meaning at all. It neither identifies the required title/contact_option roles nor clarifies high-impact optional fields like allow_list, auto_reply_allowed_channels, or outreach templates.

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 a new Support Agent" for CRM/outreach. It distinguishes creation from sibling operations like get/update/delete/list by verb, but does not explicitly name alternatives or boundary conditions.

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 update_agent, generate_agent_preview, or other siblings. It also omits prerequisites such as required account/channel setup or when a new agent should be created.

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 burden. It adds one genuine behavioral detail — that the discovery window widens within a run only — but says nothing about side effects of creating a recurring job, required permissions, idempotency, or what happens on conflicts with existing schedules.

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?

Front-loaded with the action and mode, followed by the one nuance worth explaining. Dense but no filler; the trailing clause about window widening is the only slightly awkward construction.

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 14-parameter mutation tool with no annotations, no output schema, and 0% schema coverage needs far more than two documented params. An agent cannot correctly populate frequency, run_hour_utc, auto_outreach, or the relax_target_filter_after_runs field from this description.

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

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

Schema description coverage is 0% across 14 parameters, and the description documents only two nested discovery params (max_post_age_days, post_age_relax_steps) — well specified with ranges and defaults, but the remaining twelve (channel, frequency, run_hour_utc, auto_import, auto_outreach, source_scan_at, max_leads_per_run, relax_target_filter_after_runs, etc.) get no meaning at all.

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 and resource: 'Create an auto-scan schedule', with the two schedule flavors (Import Only or Message now outreach) named. It is clearly distinguishable from siblings like update_scan_schedule or trigger_scan_schedule by the verb, though it never names those alternatives explicitly.

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 create a schedule versus running a one-off scan, or when to use update_scan_schedule instead. The parenthetical offers the two modes but does not say which conditions select which, leaving the agent to infer prerequisites and timing rules.

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. It usefully discloses irreversibility via 'Permanently', which is a key behavioral trait for a destructive operation. However, it omits other important details such as permission requirements, side effects on related data, or confirmation behavior.

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

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

The description is a single, front-loaded sentence with zero wasted words. Every part earns its place, and the destructive intent is communicated immediately.

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

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

For a destructive mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is too sparse. It states permanence but lacks critical context such as required permissions, cascading effects, or what the operation 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 coverage is 0%, so the description must compensate, but it only indirectly implies that the required 'agent_id' identifies the Support Agent. It adds no format, source, or constraints for the parameter, leaving the schema to speak for itself.

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 ('Permanently delete') and resource ('Support Agent'), making the action unmistakable. It clearly distinguishes itself from sibling tools like create_agent, get_agent, and update_agent without needing to name them.

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 explicit guidance on when to use this tool versus alternatives, nor any prerequisites or warnings beyond the word 'permanently'. The implication is that it deletes an agent, but no context about when that is appropriate is given.

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 for a mutation operation. It does not disclose whether deletion is irreversible, what permissions are required, what happens to associated data, or whether the operation is idempotent. Only the verb 'Delete' conveys the action.

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

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

The single sentence is brief but under-specified rather than concise. It omits essential context, so the minimal structure does not earn its place by providing usable guidance.

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 two required parameters, no annotations, and no output schema, the description is drastically incomplete. It lacks information about permissions, side effects, error handling, and confirmation behavior.

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

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

Schema description coverage is 0% and the description does not mention the two required parameters (agent_id, attachment_id) at all. It adds no meaning beyond the parameter names themselves.

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 'Delete' and resource 'agent KB attachment', distinguishing it from other delete siblings like admin__delete_agent and admin__delete_scans. It does not clarify the scope of 'KB attachment' beyond 'one', but the core action 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 on when to use this tool versus alternatives such as admin__regenerate_attachment, admin__get_attachment_content, or admin__list_attachments. No prerequisites or conditions are 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?

No annotations are provided, so the description carries the full burden. It does disclose one meaningful behavioral trait — the destructive scope excludes schedules — but says nothing about permanence, whether results/attachments tied to the scan are also removed, required permissions, or whether the operation is reversible.

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 well-formed sentence with the destructive action front-loaded and the key scoping caveat attached; no filler words or restated boilerplate.

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 destructive tool with no annotations, no output schema, and 0% parameter coverage needs more than one sentence. It omits permissions, irreversibility, side effects on related data, and the meaning of both required parameters, leaving the agent under-informed for a delete operation.

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

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

Schema description coverage is 0% and the two required parameters (agent_id, scan_ids) are undocumented in the schema. The description only hints that scan_ids is plural ('one or more scan runs') and never explains agent_id's role or the id format, so it fails to compensate for the coverage gap.

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

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

States a specific verb (Delete) and resource (completed scan runs), and explicitly carves out the boundary versus the sibling admin__delete_scan_schedule by noting it 'does not delete schedules.' An agent can distinguish it from delete_scan_schedule without inspecting either 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 parenthetical 'does not delete schedules' implicitly routes the agent to delete_scan_schedule for schedule removal, which is useful. However, there is no explicit when-to-use statement, no precondition (e.g. scans must be completed/not running), and no mention of related tools like list_scans for discovering scan_ids.

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 for a destructive mutation, yet it says nothing about irreversibility, required permissions, or side effects on running scans. Only the bare fact of deletion is conveyed.

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 short sentence with no filler, appropriately front-loaded. It is efficient, though its brevity is partly the cause of the missing behavioral detail scored 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 destructive tool with no annotations, no output schema, and fully undocumented parameters, the description is too thin. It should at minimum clarify scope and consequences of the deletion.

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

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

Schema description coverage is 0% for two required parameters, so the description must compensate and does not. It provides no meaning for agent_id or schedule_id, leaving the agent to guess their format and relationship.

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+resource (delete an auto-scan schedule), which is clear enough for an agent to identify the operation. It does not, however, differentiate itself from siblings like create_scan_schedule, update_scan_schedule, or trigger_scan_schedule beyond the verb.

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

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 the closely-named siblings, no prerequisites, and no note about whether an in-progress or pending scan is affected. The agent must infer usage entirely from the 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 behavioral burden. It usefully discloses a side effect (stopping IG/WA follow-ups), but says nothing about reversibility, required permissions, or what state change 'ended' represents for the visitor.

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 short sentence that is front-loaded with the action and effect. No waste, though it is terse to the point of under-specification rather than optimal brevity.

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

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

For a two-required-parameter mutation tool with no annotations, no output schema, and no parameter documentation, the description is too thin. It omits reversibility, resulting state, and how the effect interacts with the resume counterpart.

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

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

Schema description coverage is 0%, so the schema documents nothing about agent_id or visitor_id. The description adds no meaning for either parameter, leaving the agent to guess their format and 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?

States a specific verb+resource ('Mark visitor conversation ended') and adds the concrete consequence '(stops IG/WA follow-ups)'. This distinguishes it from the paired sibling admin__resume_conversation, though it never names that 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?

No when-to-use, when-not-to-use, or prerequisite guidance is given. The parenthetical hints at intent, but the obvious alternative (admin__resume_conversation) and the conditions for picking either are left entirely to 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. It discloses the return shape ('csv_content in result'), which is helpful, but says nothing about permissions, export size limits, whether the export is synchronous, or what happens with large result sets.

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 tightly written sentence with the key facts front-loaded: action, resource, format, and return value. Nothing is wasted and no padding 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?

With five undocumented parameters, no annotations, and no output schema, the description should do more. It covers the return payload conceptually but leaves the parameter semantics and operational behavior almost entirely unspecified, which is a significant gap for an export 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 0%, so all five parameters rely on the description for meaning. The description only hints at filtering generally; it does not explain filter_by syntax, date formats for created_from/created_to, or what agent_id scopes. The enum on contact_type is the only self-documenting 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 gives a specific verb+resource+format: 'Export filtered contacts as CSV'. This clearly distinguishes it from the sibling admin__import_contacts and from list_* tools, though it does not name an alternative explicitly.

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 versus admin__import_contacts or the various list_* session tools, nor any mention of prerequisites. The word 'filtered' implies filtering is optional, but no conditions 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. 'Preview' hints the result is not saved, but the description never confirms there are no side effects, whether an LLM call incurs latency/cost, whether the result is deterministic, or whether anything is persisted.

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 tight sentence that front-loads the action and lists outputs compactly. No filler, though it is arguably under-specified rather than optimally concise.

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

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

With no annotations and no output schema, the description should clarify that the generated title/instructions/context are returned for review rather than saved. It names the outputs, which is helpful, but leaves the persistence and side-effect questions open for a generation 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 0% for two required params. The description maps business_description as the generation source, which adds real meaning, but business_name's role is unexplained and no format, length, or content guidance is given for either string.

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?

Specific verb ('AI-generate') plus clearly enumerated outputs (agent title/instructions/context) and a stated input source (business description). It reads distinctly from admin__create_agent by framing this as generation rather than persistence, though it never explicitly contrasts the two.

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 word 'preview' implies this is a non-persisting step before admin__create_agent, which is useful implied guidance, but there is no explicit statement of when to use this versus create_agent or update_agent, nor any prerequisite note.

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 and does well: it discloses that the output is owner-executed, per-channel, budget-divided, and that Nova does not touch the ad account. It stops short of explicitly stating read-only behavior or describing the return shape, but the operational boundary is clear.

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?

Two tightly packed sentences, front-loaded with the output format and followed by the usage condition. There is no filler and no repetition of structured fields.

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 and no output schema, the description successfully conveys the output nature and when to use it. However, it leaves the required agent_id and the leads_target parameter unaddressed, which is a meaningful gap at 33% schema coverage.

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 only 33%, and the description does not compensate. The channel parameter is already documented in the schema and is only echoed by 'per channel'; agent_id (required) and leads_target are left unexplained in both schema and 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 deliverable: an ad plan rendered as tap-by-tap steps per channel in the owner's words with the budget pre-divided. It is distinguishable from a raw plan by emphasizing executable steps, but it does not explicitly name the sibling get_ad_plan, so differentiation is implicit rather than stated.

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?

It gives a clear usage condition: use this when the owner wants to run the ads themselves. The clause 'Nova never touches their ad account' also implies the boundary versus tools that act on accounts. No explicit alternative is named, so it falls short of full when/when-not 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?

No annotations are provided, so the description carries the full load and does reasonably well: it declares the tool is read-only, that nothing is launched and no money moves, and it discloses the degenerate return case status=no_evidence when scans lack evidence. It does not cover auth/ownership requirements or rate limits, so it falls short of a 5.

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 sentences, front-loaded with what the output contains, then the safety profile, then the edge case. Dense and mostly waste-free, though 'three things to film' is a bit colloquial for a 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?

With no output schema and no annotations, the description does the necessary work: it outlines the returned content, the read-only guarantee, and the no_evidence status. It is slightly thin on how account_mode changes which plan is produced, but an agent has enough 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 coverage is already 75% and nested objects are absent, so the baseline is 3. The description adds only one real semantic link — that spend and reach are derived from a lead target — while the more consequential account_mode enum and country default are explained solely by the schema.

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

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

The description states concretely what the tool produces: a plan of three things to film, each citing a count from the agent's own leads, plus spend and reach for a lead target. That is far more specific than the name alone and implicitly separates it from the sibling admin__get_ad_guide (a guide, not a plan). The verb is implied rather than stated, but the resource and its contents are 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?

Usage is only implied: you call it when you want an ad plan derived from existing scans. There is no explicit statement of when to prefer it over admin__get_ad_guide or admin__suggest_targets, and no stated prerequisites (e.g. that scans must exist first), though the no_evidence clause hints at that precondition.

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 hints at the returned content (chat/public/iframe links) but says nothing about required permissions, whether the returned links are sensitive/published state, or any rate limits. For a fetch tool with zero annotation coverage this is thin.

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 tightly worded sentence with the resource and return payload front-loaded. No waste, though brevity comes at the cost of the missing guidance noted 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 one-parameter read tool the description is minimally adequate — it names the resource and the salient returned fields. With no annotations and no output schema it should ideally disclose permissions and more of the return shape.

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

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

Schema description coverage is 0% and the description never mentions agent_id or its format (UUID, slug, numeric). While a single 'agent_id' is fairly self-evident, the description adds no meaning beyond the bare schema.

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

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

States a specific verb ('Return') and resource ('full agent metadata') and enumerates what is included (chat/public/iframe links). It implicitly distinguishes the singular get_agent from the sibling list_agents, though it never explicitly names how it differs from get_agent_analytics or list_agents.

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 prerequisites, and no alternatives named. The agent must infer from the name alone that this fetches a single agent by id rather than listing agents or fetching analytics.

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, yet it says nothing about permissions, read-only nature, response volume, or whether top_visitors_limit truncates results. Only the bare hint of a summary payload 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?

One short, front-loaded sentence with no filler, which is structurally sound, but at this length the terseness shades into under-specification rather than genuine 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 no output schema and no annotations, the description should describe the returned payload more concretely; 'totals + top visitors' leaves unclear which totals and which fields come back, so an agent cannot plan how to consume the result.

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

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

Schema description coverage is 0% for both parameters. The parenthetical 'top visitors' loosely implies top_visitors_limit, and 'one agent_id' implies agent_id is the target, but there is no format, constraint, or default information to compensate for the empty 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?

It names a resource (one agent_id) and the payload (totals + top visitors), but 'Pipeline overview' is ambiguous jargon — it does not say what pipeline or what metrics, and it never distinguishes itself from siblings like get_agent, get_discovery_analytics, or list_top_agents.

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 prerequisites, and no mention of when to prefer this over get_agent or get_discovery_analytics. With three closely-named analytics/agent siblings, an agent has 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?

No annotations exist, so the description carries the full behavioral burden. It usefully discloses the two possible return forms (markdown conversion or schema summary), but says nothing about permissions, side effects, or the relationship between the two branches.

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 efficient sentence with no filler. It is front-loaded with the verb and resource, though the 'converted markdown or database schema summary' clause is slightly dense without explaining how the branching is chosen.

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 tool with no output schema, no annotations, and 0% schema coverage, the description is thin: it explains the return form but not the parameters or selection between the two content types. Minimum viable but with 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 0%, so the description must compensate for both undocumented parameters (agent_id, attachment_id). It mentions neither, leaving the agent to infer their meaning purely from parameter names.

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

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

States a specific verb (read) and resource (one attachment's content), and even names the two content forms returned (converted markdown vs database schema summary). This distinguishes it from siblings like admin__list_attachments, admin__delete_attachment, and admin__regenerate_attachment, though it does not explicitly name them.

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 versus admin__list_attachments or admin__regenerate_attachment, no prerequisites, and no exclusions. Usage is only implied by the verb 'Read'.

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, and one sentence does not cover it. 'Open' is behaviorally ambiguous — it could mean a pure read, could imply marking the chat as opened, or could create a session — and the description says nothing about side effects, permissions, or what is returned on a match vs. no match.

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 that front-loads the action and resource, with no filler. It is efficient, though its brevity comes at the cost of the missing detail noted 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 6-parameter tool with 17% schema coverage, no annotations, and no output schema, one sentence is inadequate. An agent is left guessing about identifier precedence, agent_id's role, and whether the operation has 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 coverage is only 17% (just 'contact' documented). The description hints at the identity keys (visitor_id, email, phone, contact handle) but does not map them to the actual parameter names (visitor_email, whatsapp_no, instagram_username) or explain precedence when several are supplied, and it never mentions the required agent_id. It adds partial value but does not compensate for the coverage gap.

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

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

States a specific verb and resource ('Open a lead chat') and enumerates the lookup keys (visitor_id, email, phone, contact handle) that an agent can use to identify which chat. It falls short of distinguishing itself from siblings like admin__list_sessions or admin__send_message, and 'open' is slightly at odds with the 'get' verb in the name, leaving the retrieval semantics a bit ambiguous.

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

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

There is no explicit when-to-use or when-not-to-use guidance and no alternative tools are named. The closest thing to guidance is the list of accepted identifiers, which implies lookup usage but never states context or prerequisites.

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

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

With no annotations, the description carries the full behavioral burden. It implies a safe read, but says nothing about permission requirements, behavior when no configuration exists (defaults vs. error), or whether results are per-agent. For a settings-fetch tool with zero annotation coverage this is a real 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?

A single short sentence with no padding and the resource front-loaded. It is appropriately sized, though its brevity borders on under-specification rather than 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 simple one-parameter getter this is close to adequate, and no output schema exists so the description should hint at return values, which it does loosely via 'settings'. However, the meaning of agent_id and the unconfigured-case behavior are absent, leaving notable gaps.

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

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

Schema description coverage is 0% and the single parameter agent_id is documented nowhere. The description does not explain what agent_id refers to, its format, or whether it can be omitted, so it fails to compensate for the missing schema documentation.

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

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

States a specific verb (Read) and resource (CRM unreplied digest email settings), which is clearly distinct from the write-side sibling admin__update_crm_unreplied_alert_config. It does not explicitly name that sibling, so differentiation relies on the agent inferring read vs. update from the verb.

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

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

There is no statement of when to use this tool, no prerequisites, and no mention of the paired admin__update_crm_unreplied_alert_config tool. The only signal is the verb 'Read', leaving context entirely to 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?

With no annotations, the description carries the full behavioral burden and falls short: it implies a read but never confirms it, and says nothing about permissions, what 'sourced-leads' measures, or the shape of the result. It adds almost no behavioral context 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?

A single tight sentence with the resource front-loaded and the format hint appended economically. No waste, though brevity here shades into under-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?

For an analytics endpoint with no annotations, no output schema, and 0% schema description coverage, the description is too thin. It leaves return values, window semantics, and sibling differentiation 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 coverage is 0%, so the description must compensate. It usefully clarifies the window format ('7d', '30d') that the bare string schema omits, but the required agent_id and the window's allowed values/behavior remain undocumented.

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

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

States a specific verb+resource ('Get sourced-leads analytics') scoped to an agent, which is more precise than the name alone. However, it never distinguishes itself from the closely related sibling admin__get_agent_analytics, leaving the agent to guess which analytics tool applies.

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 parenthetical '(window e.g. 7d, 30d)' gestures at how to call it but gives no when-to-use guidance or condition selecting it over admin__get_agent_analytics. No exclusions or prerequisites are stated.

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

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. It implies a read-only retrieval and notes that the result includes a progress log, but it does not disclose authorization requirements, behavior when the run is not found, or any other operational traits.

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 wasted words. For a simple retrieval tool, this is an appropriately concise structure.

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

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

Given no annotations, no output schema, and 0% schema description coverage, the description is too thin. It communicates the basic action and that a progress log is returned, but leaves required parameter semantics and key behavioral details 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 0%, so neither parameter is documented in the schema. The description mentions 'one follow-up run,' which weakly hints at run_id, but does not explain agent_id, run_id, or how the two identifiers are used together.

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, resource, and scope: 'Get one follow-up run with progress log.' This clearly distinguishes retrieving a single run from listing runs or resuming a run, though it does not explicitly name the sibling tools it differs from.

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 alternatives such as admin__list_followup_runs or admin__resume_followup_run. The implied usage is retrieval of a single run, but no conditions, exclusions, or alternatives 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. It discloses the response contents (status, progress, leads) but says nothing about pagination mechanics, auth/permission requirements, or how 'paginated' interacts with the query. For a read tool with zero annotation coverage, this is thin.

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 tight sentence with no waste, and the primary purpose is front-loaded. It is efficient, though its brevity is partly the source of the missing 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?

With 4 parameters, no annotations, no output schema, and 0% schema coverage, the description is too sparse. It neither documents parameters nor explains pagination behavior for a tool whose core promise is paginated leads.

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 0%, so the description must compensate for four undocumented parameters. 'Paginated leads' only loosely hints at limit/offset, and scan_id/agent_id are never explained. Most parameter meaning is left to inference.

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+resource ('Get one scan') and lists what's returned (status, progress, leads), which distinguishes it from the plural sibling admin__list_scans. It does not clearly differentiate from admin__list_scan_results, which also concerns scan leads, but the 'one scan' scope 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 explicit when-to-use guidance and no alternatives named. The agent must infer that this fetches a single scan by id rather than using list_scans or list_scan_results. No prerequisites or context given.

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, and it discloses nothing: not whether this is idempotent, what happens to duplicates, what permissions are required, whether it is reversible, or what the result looks like. For a bulk mutation touching an agent's contact list, this is a serious 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?

It is a single short sentence, but the brevity stems from under-specification rather than economy. The one line could comfortably carry channel/format guidance that is entirely absent.

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 at 0% coverage, no annotations, and no output schema, everything an agent needs to invoke this correctly is missing. The description does not compensate for any structured-data 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 0% across 7 parameters, and the description supplies no parameter meaning at all. It never explains the channel enum, the required agent_id, or how emails/contacts/whatsapp_numbers/telegram_usernames/instagram_usernames relate to the selected channel.

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 verb and resource ('import contacts') plus a target ('onto an agent'), so the basic action is identifiable. However, it says nothing to distinguish it from close siblings such as admin__import_leads or admin__export_contacts, and the ambiguous phrasing 'onto an agent' leaves the exact operation 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?

There is no when-to-use guidance, no prerequisites, and no mention of the alternative import tool (admin__import_leads). An agent must guess the context 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, the description carries full behavioral burden. It reveals only that the tool writes leads into the CRM and that an outreach mode exists, but says nothing about permissions, reversibility, side effects of 'immediate' outreach, or rate limits.

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 tight sentence with the action front-loaded and the parameter hint in a parenthetical. No wasted words, though brevity here shades into under-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?

For a 5-parameter mutation tool with no annotations, no output schema, and zero schema description coverage, the description is far too thin to call correctly. It needs to explain required identifiers and the consequence of each outreach mode.

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 0% across 5 parameters, so the description must compensate. It only enumerates the outreach values ('none|immediate|bulk_followup'); agent_id, scan_id, lead_ids, and label are left entirely undefined in both schema and prose.

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 and resource: 'Import discovered leads into the agent CRM.' An agent understands the core action, though it does not distinguish itself from the sibling admin__import_contacts, which is a near-neighbor.

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 indication of when to use this versus admin__import_contacts or when to pick each outreach mode beyond listing the values. No prerequisites such as needing a prior scan are stated.

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

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

With no annotations, the description carries the full burden. It usefully discloses an authorization constraint ('owner only'), but says nothing about what the invitation actually does (email sent, pending acceptance), idempotency, or error behavior if the user is already a collaborator.

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 compact sentence that front-loads the verb and resource with zero filler. Nothing wasted.

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 zero parameter documentation, the description is too thin. It omits the role values, the effect of the invocation, and the outcome the caller should expect.

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

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

Schema description coverage is 0% across 3 parameters. The description only implies email ('by email') and agent ('on an agent'); the role parameter and its viewer/operator/editor/admin enum values are never explained, so the description does not compensate for the coverage gap.

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

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

Clear specific verb (Invite) plus resource (a Nova user as a collaborator on an agent), so an agent knows this grants collaboration access. It does not explicitly contrast itself with siblings like update_agent_collaborator or remove_agent_collaborator, but 'invite ... by email' is distinct 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?

The '(owner only)' qualifier implies a prerequisite, but there is no explicit when-to-use guidance, no when-not, and no routing to alternatives such as update_agent_collaborator or transfer_agent_owner. Usage must be inferred.

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 and does well: it discloses that the cap is debited before creation, no ad is created above the cap, and it never writes creative. It omits failure/refund behavior and idempotency, which keeps it from a 5.

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?

Four tight sentences, front-loaded with the core action and spend constraint. No filler or repetition.

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

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

Given the tool's complexity, the description covers the critical safety and prerequisite details well. It leaves some gaps around return values and failure behavior, especially with no output schema, but is largely complete for correct 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 coverage is 82%, so the schema already documents most parameters. The description reinforces cap semantics but does not add much beyond the schema's own cap_minor description for the remaining 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?

States a specific verb and resource ("Run one ad on one channel") plus scope (spend cap). It is clearly distinguishable from siblings such as get_ad_plan, list_ad_plans, and stop_ad_plan.

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?

Provides clear prerequisites: the spend cap must be owner-approved and a connected ad account is required. It does not explicitly name alternative tools or when-not-to-use cases, but the context is strong enough for selection.

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

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

With no annotations, the description carries the behavioral burden and does well: it explicitly says "Reads only," discloses newest-first ordering, and names the returned fields (cap, channel, running/stopped). It does not mention pagination, result limits, or authorization requirements.

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 well-packed sentence with no wasted words. Scope, ordering, returned fields, and read-only behavior are front-loaded and easy 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?

For a simple one-parameter read-only list tool with no output schema, the description gives enough context to understand scope, ordering, returned fields, and safety. It would be stronger with pagination or result-limit details, but the core invocation context is present.

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

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

Schema description coverage is 0%, and the single parameter agent_id is undocumented in the schema. The description implies that agent_id scopes results to "this agent," which adds useful meaning, but it does not clarify the expected identifier format or where the agent ID comes from.

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 resource and scope: every ad already launched by this agent, returned newest first with cap, channel, and running/stopped status. It distinguishes a read-only listing from sibling actions like launch_ad_plan and stop_ad_plan, though it does not explicitly contrast with get_ad_plan.

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 by "every ad this agent has already launched" and "Reads only," which makes clear this is for inspecting existing ad plans rather than launching or stopping them. However, it does not explicitly say when to use this versus get_ad_plan for a single plan, or mention prerequisites for agent_id.

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 supplied, so the description carries the full behavioral burden. It does disclose the key authorization constraint (owner only), but says nothing about the read-only nature, result shape, pagination, or what happens when the caller is not the owner.

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 tight sentence with the action front-loaded. Minor cost: the trailing "(owner only)" is slightly ambiguous as to whether it restricts the caller or the listed members, but nothing is wasted.

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 one-parameter read tool with no output schema and no annotations, the definition is minimally adequate. It omits what fields a collaborator record contains and any failure behavior, which an agent would otherwise have to discover by calling it.

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

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

Schema description coverage is 0% for the single required parameter agent_id, so the schema contributes only a string type. The phrase "a support agent" implies agent_id identifies the target agent, but no format, source, or example is 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?

"List team members with access to a support agent" gives a specific verb (List) and a specific resource (collaborators on one agent), which distinguishes it from sibling admin__list_agents. It does not explicitly name the collaborator-management siblings (invite/remove/update_agent_collaborator), but the scope 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 parenthetical "(owner only)" states a caller precondition, which is useful usage context, but the description never names alternatives or contrasts listing with managing collaborators. Usage is only implied from the verb.

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 burden. It implies a read but says nothing about pagination, result ordering, result caps, or what fields each agent record contains — all relevant for a list endpoint with zero structured coverage.

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

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

A single tight sentence with no filler and the scope constraint front-loaded. Appropriately sized, though brevity here partly reflects under-specification rather than discipline.

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 an entirely undocumented order_by parameter. For a list tool whose only job is to return agent records, the description leaves ordering behavior and return shape unaddressed.

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 0% and the description never mentions the sole parameter, order_by. With only one parameter and no schema documentation at all, the description should at minimum note accepted sort values or the default order; it adds nothing.

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 (List) and resource (Support Agents) with a scope qualifier (for the signed-in owner). It is clear what the tool does, though it never differentiates itself from near-siblings like admin__get_agent or admin__list_top_agents.

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 and no mention of alternatives. An agent cannot tell from this text whether to reach for list_agents versus get_agent or list_top_agents, even though both appear in the sibling list.

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

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

No annotations are provided, so the description carries the full burden. 'List' implies a read-only operation, but the description says nothing about pagination, result ordering, permissions required, or what happens when the agent has no attachments. Minimal behavioral disclosure.

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

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

A single short sentence with no filler, and the resource and scope are front-loaded. It is efficient, though its brevity is partly under-specification rather than discipline.

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

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

For a simple read tool with one required parameter, zero schema descriptions, no annotations, and no output schema, the description should at least clarify the parameter's meaning and expected return shape. It leaves the agent with little to act on beyond the name.

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 0% and the single parameter agent_id has no description. The phrase 'on a Support Agent' weakly implies agent_id identifies the agent, but adds no format, scope, or constraint detail beyond the parameter name itself.

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 gives a specific verb ('List') and resource ('knowledge-base attachments') scoped to a Support Agent, which is clear enough to distinguish it from siblings like get_attachment_content or delete_attachment. It does not, however, explicitly contrast itself with those 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?

There is no guidance on when to use this tool versus alternatives such as admin__get_attachment_content or admin__list_agents. No prerequisites, no context about when listing attachments is 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 does disclose one behavioral trait not in structured data: it returns only 'available' (i.e., assignable) accounts, hinting at a filter. However it omits what makes an account unavailable, whether results are scoped to the agent, and any pagination or return-format detail.

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 tight sentence, front-loaded with the verb and resource, with the channel enumeration appended economically. Every element 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 simple one-parameter list tool with no annotations and no output schema, the description is only minimally sufficient. It leaves open what 'available' means, what agent_id does, and what the caller receives, which an agent would need to call it confidently.

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

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

Schema description coverage is 0% and the single required parameter agent_id is undocumented in both schema and description. The description never mentions agent_id or explains why an agent identifier is needed to list channel accounts, so it fails to compensate for the coverage gap.

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

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

States a specific verb and resource ('List available channel accounts') and enumerates the channel types (IG, X, Telegram, SMTP). It distinguishes itself from the assign_* siblings by being the list/read side of the same workflow, though it never names an alternative tool explicitly.

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 'for assignment' implies the context in which this is used (discovering accounts before calling an assign_* tool), but there is no explicit when-to-use, when-not-to-use, or named alternative. Usage is left to 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?

With no annotations, the description must carry the full behavioral burden. 'List' implies a read operation, but the description does not state that it is read-only, whether it requires special permissions, or what the status output contains beyond channel 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 front-loaded sentence with no redundant or wasted language. It efficiently presents the action, resource, scope, and target in one pass.

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

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

For a simple read tool with one required parameter and no output schema, the description identifies the channels and target agent, but it does not fully compensate for the missing parameter documentation or explicitly confirm the read-only nature. It is minimally sufficient but leaves 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 0%, so the single agent_id parameter is undocumented in the schema. The description's phrase 'for a support agent' partially ties agent_id to a support agent identifier, but it does not clarify the expected format, source, or constraints.

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

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

The description states a specific verb (List) and resource (connector status), and scopes it to four named channels and a support agent. It is clear what the tool does, though it does not explicitly differentiate itself from the nearby admin__list_channel_accounts sibling.

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, nor are any prerequisites or exclusions mentioned. The phrase 'for a support agent' hints at context but does not constitute usage guidance.

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

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

No annotations are provided, so the description carries the entire behavioral burden, yet it says nothing about ordering, pagination, default limit behavior, or what a "run" record contains. Only the implicit read-only nature of "List" conveys any behavioral signal.

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 wasted words, but the brevity reflects under-specification rather than disciplined conciseness. It is structurally clean yet too thin to be helpful.

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 0% parameter coverage, the description leaves key call details (result shape, pagination, limit semantics) unspecified. For a listing tool with two params, it does not supply enough context to invoke confidently.

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

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

Schema description coverage is 0% and the description only hints at agent_id via the phrase "for an agent". The limit parameter is entirely undocumented in both schema and description, so the agent has no idea of its default or maximum. It does not compensate for the coverage gap.

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

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

The description states a specific verb ("List") and resource ("bulk follow-up runs") scoped to "an agent", which implicitly distinguishes it from the singular get_followup_run and the action tool bulk_followup. It is clear but does not explicitly name or contrast with those 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?

There is no when-to-use guidance, no mention of when to prefer get_followup_run over this listing tool, and no prerequisites for the agent_id. The agent must infer all usage context.

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

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

No annotations are provided, so the description carries full behavioral disclosure. 'Read leads' implies read-only, and 'alias of get_scan' is useful context, but it omits pagination behavior, authorization requirements, rate limits, and whether any state is modified. For a 4-parameter tool with no annotations, 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?

A single front-loaded sentence that says what the tool is and what it does, with no redundant text. It is efficiently structured for its limited content.

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 context includes no annotations, no output schema, and 0% parameter description coverage. The description notes scan states and alias behavior but does not cover parameter usage, return shape, or safety profile, so it is inadequate for a 4-parameter tool with this much missing structured information.

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

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

Schema description coverage is 0% for four parameters, and the description does not mention agent_id, scan_id, limit, or offset. It provides no guidance on required IDs or pagination semantics, leaving parameter meaning entirely undocumented.

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

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

States a specific read action on leads from an active or completed scan, and explicitly identifies itself as an alias of get_scan. This distinguishes it from general scan-list siblings. A 4 rather than 5 because the term 'leads' is slightly narrower than the tool name's 'scan results,' but the core purpose 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?

Mentions that it reads leads from active or completed scans and that it is an alias of get_scan, which implies interchangeable use. However, it gives no explicit when-to-use vs. when-not-to-use guidance, no alternatives beyond the alias, and no prerequisites.

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

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

No annotations are provided, so the description carries the full burden. It discloses only that results span past and active scans; it says nothing about pagination, ordering, result volume, or whether it is a safe read-only 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?

A single efficient sentence with no filler, though it is arguably too short to carry the required behavioral load.

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 an undocumented required parameter, the description is too thin for an agent to invoke confidently — it should at least clarify the return shape and the agent scoping semantics.

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

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

The schema has 0% description coverage and the single required parameter agent_id is bare string type. The phrase 'for an agent' loosely implies agent_id scoping but adds no format, ID provenance, or semantics beyond what the schema already shows.

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 (List) and resource (leads discovery scans) with a scope qualifier (past and active, for an agent). It is distinguishable from siblings like get_scan (single record) and list_scan_results (results rather than scans), though it doesn't name them explicitly.

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 indication of when to use this versus list_scan_results, get_scan, list_scan_schedules, or continue_scan. The agent must infer the distinction purely 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 burden, and it discloses almost nothing: no statement that this is a read-only operation, no pagination/limit behavior, no return shape, no permission requirements. Only the implicit scope ('for an agent') is communicated.

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 short, front-loaded sentence with no filler. It is efficient, though the brevity reflects under-specification rather than tight editing.

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 0% parameter description coverage, the description leaves an agent without any information about what is returned, how results are ordered or paginated, or how this differs from the other list_* scan tools. It is too thin for the surrounding toolset's complexity.

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

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

Schema description coverage is 0% for the single required agent_id, so the description must compensate. The phrase 'for an agent' effectively conveys what agent_id scopes, but it neither names the parameter nor specifies its format (ID vs. name), leaving a real gap.

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

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

States a specific verb (List) and resource (auto-scan schedules) scoped to a single agent. It does not differentiate itself from close siblings such as admin__list_scans, admin__list_scan_results, or admin__create_scan_schedule, so an agent must infer the boundary from naming alone.

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 when-to-use guidance, prerequisites, or naming of alternatives among the many scan-related siblings (list_scans, create/update/delete_scan_schedule, trigger_scan_schedule). Usage must be inferred 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 burden. 'List' implies a read-only, non-destructive operation, which is the only behavioral signal given — no pagination, result shape, permissions, or empty-state 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?

One short, front-loaded sentence with no filler. It is efficient, though oppressively terse given the tool's undocumented parameter.

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 a 0%-covered parameter, the description should do more. It never explains what the catalog contains, whether labels are defaults or custom, or how the single required parameter is obtained.

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

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

Schema description coverage is 0% and the single required parameter agent_id is not mentioned anywhere in the description. The agent must infer from the schema that the label catalog is scoped per agent, and gets no help on expected ID format.

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 ('List') and a specific resource ('visitor session label catalog'), and scoping to 'an agent' via agent_id is implied. It is distinguishable from the mutating siblings (set_session_labels, update_session_label, bulk_set_session_labels), though it never names them.

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 prerequisites, and no alternatives named. An agent could reasonably infer this is the read step preceding label assignment, but the description does not say so.

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. It hints at a filtered read but says nothing about permissions, whether results are paginated, what filter_by accepts, or the consequence of omitting filters beyond the required-field note.

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 short sentence is compact, but here brevity comes at the cost of substance: it is under-specified rather than genuinely concise, packing almost no usable information for a 7-parameter 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?

A 7-parameter tool with zero schema coverage, no annotations, and no output schema gets a one-line description that omits field semantics, return behavior, and usage context. It is far from complete enough for correct invocation.

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

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

Schema description coverage is 0% across 7 parameters. The description mentions only filter_by (as required), leaving page, limit, agent_id, created_from, created_to, and contact_type completely unexplained in either the schema or 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?

It names the resource (visitor sessions) and signals filtering, but the verb 'drill-down' is vague and doesn't clearly state that this retrieves/lists sessions. An agent can guess it's a read operation but must infer the action from the name alone.

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

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

The only guidance is 'requires filter_by', which restates the schema's required field. There is no indication of when to use this versus siblings like admin__list_session_labels or admin__bulk_delete_sessions, nor any exclusion 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?

No annotations exist, so the description carries the full burden, and it discloses almost nothing: no read-only assurance, no auth requirements, no pagination or default-limit behavior. The only behavioral hint is the 'limit 5-10' constraint, which is useful but far from sufficient.

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 short sentence, front-loaded with the verb and resource, with no padding. It is terse to the point of under-specification, but nothing is wasted.

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 zero annotation coverage, no output schema, and 0% parameter description coverage, the definition should work much harder. An agent cannot tell how results are ranked, what 'busiest' means, or what order_by accepts.

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 0% for both parameters. The description adds a range for 'limit' (5–10), which the schema lacks, but says nothing about 'order_by' — what fields are valid or what the default sort is — leaving half the parameters undocumented in both places.

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 clear verb and resource ('List ... CRM agents') with a scope qualifier ('busiest') that separates it from the plain admin__list_agents sibling. However, 'busiest' is never defined (by message count? response time?), so the ranking basis stays ambiguous.

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

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

No indication of when to prefer this over admin__list_agents or admin__get_agent_analytics, both of which plausibly overlap. No prerequisites or exclusions are given.

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 behavioral burden but only states the operation. It does not say whether the count is cached, whether it respects channel filters, whether it requires admin auth, or how large result sets or rate limits behave.

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 short, front-loaded sentence with no filler, which is structurally good. However, its brevity reflects under-specification rather than efficient conciseness, so it lands at adequate rather than strong.

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 output schema, no annotations, and an undocumented channels parameter mean the description should do much more. As written, an agent knows it counts something called 'pending replies' but not what pending means, what channels does, or what the returned count represents.

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

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

Schema description coverage is 0% and there are 2 parameters. The description implies agent_id ('on an agent') but says nothing about 'channels' — the schema only declares it as a string, so the agent cannot know whether it is a comma-separated list, an ID, or a filter name. The description fails to compensate for the coverage gap.

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

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

States a specific verb (count) and resource (pending replies) scoped to an agent, which is unambiguous and not duplicated by any sibling. It lacks any differentiation language, but no sibling tool overlaps with this counting operation, so the gap is minor.

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 when-to-use guidance, no mention of prerequisites or alternatives, and no indication of what 'pending' means or when the count should be refreshed. The agent is left to infer usage entirely.

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, and it discloses almost nothing. The critical fact for a preview tool — that it renders without sending or persisting an email — is only implied by the word 'Preview' and never stated, nor is any information about permissions, cost, or side effects given.

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 single sentence is front-loaded and free of waste, and the core purpose is conveyed immediately. However, it is terse to the point of under-specification for a six-parameter tool, so brevity here costs more than it saves.

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 six undocumented parameters, no annotations, and no output schema, the description is far from complete. Nothing explains what the rendered HTML looks like, what the optional display parameters change, or what the caller receives back, leaving substantial gaps the agent cannot close.

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

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

Schema description coverage is 0% across six parameters, and the description supplies no parameter meaning at all. An agent has no idea whether 'format' is html/text, what cta_label vs cta_url do together, or how message/agent_id interact, so it cannot fill required fields confidently.

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 and resource combination ('Preview rendered follow-up email HTML'), which tells an agent this generates a visual/HTML rendering rather than sending anything. It is meaningfully distinct from send_followup and bulk_followup, though it does not explicitly contrast itself with the similarly named generate_agent_preview or compose_draft 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?

There is no when-to-use guidance, no mention of prerequisites (e.g., that a follow-up must exist or that agent_id must reference a configured agent), and no routing to alternatives such as compose_draft or generate_agent_preview. The agent must infer the entire usage context from the name alone.

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

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

No annotations are provided, so the description carries the full burden. It implies a mutation of derived data but does not say whether existing extracted results are overwritten or destroyed, whether the operation is synchronous or queued, what permissions are required, or what the caller receives back.

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 tight sentence with the action and its two modes front-loaded; no wasted words. It is efficient, though its brevity is partly a consequence of missing information rather than discipline.

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 fully undocumented parameters, the description leaves too much unspecified: effect on existing data, error modes, and expected outcome are all absent.

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?

Both parameters (agent_id, attachment_id) have 0% schema description coverage and the description does not mention them at all. With two undocumented required identifiers, the description fails to compensate for the schema gap.

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

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

The description states a specific verb (re-process) and resource (one attachment), and parenthetically clarifies the two modes (re-convert or re-extract schema). It is clearly distinguishable from read-oriented siblings like admin__get_attachment_content or admin__list_attachments, though it does not name those alternatives explicitly.

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 versus related tools such as admin__update_agent or admin__upload_attachments, nor any prerequisites (e.g., when an attachment needs re-processing because extraction failed or the agent schema changed). Usage context is left entirely to 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 behavioral burden. It does disclose the owner-only authorization requirement, which is a meaningful behavioral trait, but says nothing about whether removal is reversible, whether access is revoked immediately, or what side effects occur.

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 wasted words; the critical permission constraint is tucked in a parenthetical rather than buried, 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?

For a destructive mutation with no annotations, no output schema, and fully undocumented parameters, the description provides only an auth constraint. It leaves an agent without enough context to confidently invoke this irreversible-looking operation.

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

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

Schema description coverage is 0%, so the description must compensate for both parameters. It only implicitly maps 'agent' to agent_id and 'collaborator' to email, without naming either parameter, clarifying that the collaborator is identified by email address, or specifying any format constraints.

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

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

States a specific verb (Remove) and resource (collaborator from an agent), which cleanly separates it from sibling tools like invite_agent_collaborator, update_agent_collaborator, and list_agent_collaborators. It does not name those siblings explicitly, but the action is unambiguous.

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

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

The parenthetical '(owner only)' communicates a real prerequisite, which is useful. However, there is no guidance on when to use this versus update_agent_collaborator or transfer_agent_owner, no mention of confirmations, and no statement of what happens after removal.

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 implies a state-changing mutation on a paused conversation but does not state required permissions, side effects, whether resuming is reversible, or what happens if the conversation is not paused. The brief phrase 'paused visitor conversation' is the only behavioral clue.

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 repetition. It is efficient and immediately communicates the action, though its extreme brevity leaves important context unaddressed rather than being optimally sized for a mutation tool with two required 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?

Given the lack of annotations, output schema, and schema parameter descriptions, the description is too sparse. It identifies the operation but omits prerequisites, parameter meaning, permissions, and expected outcome, leaving an agent unable to invoke the tool reliably without guessing.

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

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

Schema description coverage is 0% and the description does not mention agent_id or visitor_id at all. With two required parameters completely undocumented in both the schema and the description, an agent gets no added meaning about what these identifiers refer to or how they are formatted.

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: 'Resume a paused visitor conversation.' This clearly differentiates the action from generic message sending or ending conversations, but it does not explicitly contrast with the sibling admin__end_conversation or explain the scope of 'paused visitor conversation' relative to other session states.

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 when-to-use guidance, no prerequisites, and no alternatives. It implies the tool is for conversations already in a paused state, but does not say when that state occurs or when an agent should choose this over other session-management tools like admin__end_conversation or admin__send_message.

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, yet it discloses almost nothing. It doesn't say whether resuming requires specific permissions, whether the run resumes from where it stopped, whether prior progress is preserved, or whether any side effects occur. 'Resume' implies continuation, but the mechanics are entirely undocumented.

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

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

A single front-loaded sentence with no filler or redundancy. It is appropriately terse for an action tool, though the terseness contributes to the information gaps 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 mutation-style action with no annotations, no output schema, and two fully undocumented required parameters, the description is far too thin. An agent lacks the state requirements, identity semantics, and effect description needed to invoke this 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?

Both parameters (run_id, agent_id) are required with 0% schema description coverage, so the description must compensate for undefined semantics and does not. It never clarifies what agent_id refers to in the context of a run, whether they must match, or how to obtain a run_id, leaving the identification contract to guesswork.

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 ('Resume') and resource ('follow-up run') with the qualifying state 'interrupted', which distinguishes it from siblings like get_followup_run or list_followup_runs. It falls short of a 5 because it doesn't explicitly name a counterpart tool such as resume_conversation or bulk_followup that an agent might confuse it with.

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 word 'interrupted' implies the pre-condition for use (a run that was paused or halted), but the description gives no explicit when/when-not guidance or alternative tool routing. An agent must infer when this applies versus starting a fresh follow-up run via send_followup or bulk_followup.

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 supplied, so the description carries the full behavioral burden. It adds one genuine trait ('the window widens within a run only'), but never says that this is a mutation/long-running job, whether a channel account must be assigned first, whether the call is async, or what it returns — significant gaps for a zero-annotation tool.

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

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

A single front-loaded sentence that leads with the action and channel list before the parameter detail. It is dense but every clause earns its place; only the parenthetical age-range detail could be tightened.

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 an untyped `params` object, the description should cover prerequisites and return values — it covers neither. Three of five channels have no parameter guidance at all, so an agent cannot confidently configure a whatsapp, telegram, or jiji scan from this definition.

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 0%, so the description must compensate; it does add the channel enum (whatsapp, instagram, x, telegram, jiji) and explains two nested discovery params (max_post_age_days 1-365, post_age_relax_steps 0-4 default 3) that are absent from the schema. But agent_id is never explained and the params payload for whatsapp/telegram/jiji is undocumented, leaving a substantial gap.

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

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

States a concrete verb+resource ('Start a leads discovery scan') and enumerates the five channels, which lets an agent separate it from siblings like list_scans, get_scan, continue_scan, or abort_scans. It does not explicitly name those siblings, so it falls one step 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?

Usage is implied by 'Start a ... scan', and the channel list plus the x/instagram parameter notes give context for configuration. However, there is no statement of when to prefer this over continue_scan, create_scan_schedule, or trigger_scan_schedule, and no prerequisites (e.g., an assigned channel account) are mentioned.

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

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

No annotations are provided, so the description carries the full disclosure burden, and it delivers very little: it never states whether the send is reversible, what channel constraints apply, or what account/channel assignment is required. The 'public KB files' hint and the public-only rejection note (in the schema, not the description) are the only behavioral signals.

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