I manage your Support Agent CRM, pipeline analytics, follow-ups, Leads Discovery, and workspace out…
Scored across 82 tools
Several admin tools overlap in purpose, especially send_message, send_followup, and bulk_followup, and list_scan_results is explicitly an alias of get_scan. The three identical converse tools across calendar/docs/sheets also create selection ambiguity, though namespace prefixes and descriptions help somewhat.
Tool names consistently use namespace-prefixed snake_case, with admin tools mostly following a verb_noun pattern and calendar/docs/sheets using stable namespace__action patterns. Minor deviations such as calendar__check_events_today and converse-only names keep it from a perfect score.
With 82 tools, this is far beyond a well-scoped set and includes redundant aliases, per-namespace duplicate converse tools, and many granular operations that could be consolidated. The extreme count makes the surface hard to navigate despite broad functionality.
The admin surface covers agents, knowledge-base attachments, lead scans and schedules, sessions and labels, follow-up runs, analytics, channel account assignment, connectors, and CRM alert settings. Some contact-lifecycle operations are missing, but most core workflows have workable coverage.
Stop stuck running scans (marks interrupted, releases schedule lock).
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | ||
| agent_id | Yes | ||
| scan_ids | Yes |
Assign or remove Instagram account on agent.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| instagram_account_id | No |
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.
Assign or remove Jiji account on agent.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| jiji_account_id | No |
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.
Assign or remove SMTP account on agent.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| smtp_account_id | No |
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.
Assign or remove Telegram account on agent.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| telegram_account_id | No |
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.
Assign or remove WhatsApp Web account on agent.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| whatsapp_account_id | No |
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.
Assign main X account on agent (inbound DMs and replies). One agent per handle.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| x_account_id | No |
Assign campaign X account: outbound only, borrows login from another agent's main account.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| move_main_to_agent_id | No | When this wave agent is still MAIN for the handle, move MAIN here first (hub/product agent), then set campaign borrow on the wave. | |
| x_campaign_account_id | No |
Delete multiple visitor sessions and their files.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| visitor_ids | Yes |
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.
Bulk follow-up to filtered visitors.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | ||
| agent_id | Yes | ||
| filter_by | No | ||
| visitor_ids | No |
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.
Merge labels onto multiple visitor sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| labels | No | ||
| agent_id | Yes | ||
| visitor_ids | Yes |
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.
Clear Leads Discovery scan cache for an agent (seen handles / WA progress).
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes |
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.
AI-compose shared bulk follow-up draft (agent voice only).
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes |
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.
AI-compose a draft reply for one visitor session (Zap; does not send).
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| visitor_id | Yes |
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.
Continue a scan paused for selection (WhatsApp/Telegram groups or IG/X targets).
| Name | Required | Description | Default |
|---|---|---|---|
| scan_id | Yes | ||
| agent_id | Yes | ||
| selected_resources | Yes | ||
| max_contacts_per_group | No |
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.
Create a new Support Agent for CRM/outreach.
| Name | Required | Description | Default |
|---|---|---|---|
| inapp | No | ||
| theme | No | ||
| title | Yes | ||
| context | No | ||
| is_public | No | ||
| allow_list | No | ||
| description | No | ||
| public_slug | No | ||
| file_support | No | ||
| instructions | No | ||
| contact_option | Yes | ||
| disable_ai_reply | No | ||
| x_ld_public_only | No | Cold LD import: public quote/reply only, no DMs. | |
| x_ld_quote_target | No | ||
| followup_x_message | No | ||
| public_category_id | No | ||
| public_description | No | ||
| x_ld_public_poster | No | ||
| x_ld_like_before_dm | No | ||
| x_ld_public_surface | No | ||
| x_ld_public_after_dm | No | ||
| bulk_followup_enabled | No | ||
| x_ld_like_daily_limit | No | ||
| x_ld_public_post_goal | No | ||
| followup_email_message | No | ||
| x_ld_public_daily_limit | No | ||
| followup_telegram_message | No | ||
| followup_whatsapp_message | No | ||
| x_ld_attention_use_custom | No | When true, use agent-specific X Leads Discovery public attention (Lane A/B). | |
| x_ld_public_per_run_limit | No | ||
| followup_instagram_message | No | ||
| x_ld_pool_public_quote_after_dm_fail | No |
Create an auto-scan schedule (Import Only or Message now outreach).
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | ||
| params | No | ||
| channel | Yes | ||
| enabled | No | ||
| agent_id | Yes | ||
| max_runs | No | ||
| frequency | No | ||
| auto_import | No | ||
| run_hour_utc | No | ||
| auto_outreach | No | ||
| source_scan_at | No | ||
| source_scan_id | No | ||
| max_leads_per_run | No | ||
| relax_target_filter_after_runs | No |
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 only implies a write. It does not state permissions needed, whether created schedules run immediately, how auto_import/auto_outreach interact, or any side effects. The mode hint 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?
A single front-loaded sentence with no filler, which is structurally clean. However, at this brevity for a 14-parameter tool, the terseness reflects under-specification rather than efficient communication.
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 high-complexity creation tool with 14 params, a nested object, no annotations, and no output schema, the description is far too thin. An agent has almost nothing to work with beyond the tool name to populate or interpret the arguments.
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?
Fourteen parameters exist with 0% schema description coverage, including a nested 'params' object, and the description explains none of them. Required fields (agent_id, channel), frequency, or the distinction between auto_import and auto_outreach go 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 and resource: 'Create an auto-scan schedule.' The parenthetical hints at scheduling modes ('Import Only or Message now outreach'), but it does not differentiate from siblings like update_scan_schedule or trigger_scan_schedule. Clear on what it does, weak on routing.
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 indication of when to create a schedule versus updating, triggering, or deleting one, despite four schedule-related siblings. No prerequisites or context are given. The agent must guess at the workflow position.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a Support Agent.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes |
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.
Delete one agent KB attachment.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| attachment_id | Yes |
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.
Delete one or more completed scan runs (does not delete schedules).
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| scan_ids | Yes |
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.
Delete an auto-scan schedule.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| schedule_id | Yes |
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.
Mark visitor conversation ended (stops IG/WA follow-ups).
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| visitor_id | Yes |
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.
Export filtered contacts as CSV (returns csv_content in result).
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| filter_by | No | ||
| created_to | No | ||
| contact_type | Yes | ||
| created_from | No |
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 one useful trait — the result contains csv_content — but says nothing about read-only safety, size limits on large exports, pagination, or permissions required to export an agent's contacts.
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 a tight parenthetical noting the return field. Nothing is wasted, though the brevity is also the source of its gaps.
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 tool with no annotations and no output schema, the description should document parameter behavior and return shape more fully. It covers the CSV output at a high level, which is helpful since no output schema exists, but the five undocumented parameters leave it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage across 5 parameters, the description must compensate and largely fails. 'Filtered' vaguely gestures at filter_by/created_from/created_to, but agent_id, the meaning of filter_by, and the date-range semantics of created_to are left entirely 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?
States a specific verb (Export) and resource (contacts) plus the output format (CSV), so the agent knows exactly what the tool produces. It distinguishes itself implicitly from admin__import_contacts by direction, but does not explicitly name siblings or scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no mention of prerequisites such as needing an existing agent, and no reference to alternatives like list_sessions or import_contacts. 'Filtered' hints at filtering but doesn't say when to apply filters or which to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
AI-generate agent title/instructions/context from business description.
| Name | Required | Description | Default |
|---|---|---|---|
| business_name | Yes | ||
| business_description | Yes |
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.
Return full agent metadata including chat/public/iframe links.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes |
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.
Pipeline overview on one agent_id (totals + top visitors).
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| top_visitors_limit | No |
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.
Read converted markdown or database schema summary for one attachment.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| attachment_id | Yes |
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.
Open a lead chat by visitor_id, email, phone, or contact handle.
| Name | Required | Description | Default |
|---|---|---|---|
| contact | No | Generic contact from analytics/list_sessions (email, phone, or @instagram). | |
| agent_id | Yes | ||
| visitor_id | No | ||
| whatsapp_no | No | ||
| visitor_email | No | ||
| instagram_username | No |
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.
Read CRM unreplied digest email settings.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes |
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.
Get sourced-leads analytics for an agent (window e.g. 7d, 30d).
| Name | Required | Description | Default |
|---|---|---|---|
| window | No | ||
| agent_id | Yes |
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.
Get one follow-up run with progress log.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | ||
| agent_id | Yes |
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.
Get one scan with paginated leads (status, progress, leads).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| scan_id | Yes | ||
| agent_id | Yes |
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.
Import contacts onto an agent.
| Name | Required | Description | Default |
|---|---|---|---|
| emails | No | ||
| channel | Yes | ||
| agent_id | Yes | ||
| contacts | No | ||
| whatsapp_numbers | No | ||
| telegram_usernames | No | ||
| instagram_usernames | No |
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.
Import discovered leads into the agent CRM (outreach: none|immediate|bulk_followup).
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | ||
| scan_id | Yes | ||
| agent_id | Yes | ||
| lead_ids | Yes | ||
| outreach | No |
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.
Invite a Nova user by email to collaborate on an agent (owner only).
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | ||
| Yes | |||
| agent_id | Yes |
List team members with access to a support agent (owner only).
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes |
List all Support Agents for the signed-in owner.
| Name | Required | Description | Default |
|---|---|---|---|
| order_by | No |
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.
List knowledge-base attachments on a Support Agent.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes |
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.
List available channel accounts for assignment (IG, X, Telegram, SMTP).
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes |
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.
List WhatsApp, Instagram, Email, X connector status for a support agent.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes |
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.
List bulk follow-up runs for an agent.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| agent_id | Yes |
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.
Alias of get_scan — read leads from an active or completed scan.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| scan_id | Yes | ||
| agent_id | Yes |
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.
List past and active leads discovery scans for an agent.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes |
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.
List auto-scan schedules for an agent.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes |
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.
List visitor session label catalog for an agent.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes |
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.
Filtered drill-down on visitor sessions (requires filter_by).
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| limit | No | ||
| agent_id | Yes | ||
| filter_by | Yes | ||
| created_to | No | ||
| contact_type | No | ||
| created_from | No |
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.
List busiest CRM agents (limit 5–10).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| order_by | No |
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.
Count pending replies on an agent.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| channels | No |
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.
Preview rendered follow-up email HTML.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | ||
| cta_url | No | ||
| message | Yes | ||
| agent_id | Yes | ||
| cta_label | No | ||
| image_url | No |
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.
Re-process one attachment (re-convert or re-extract schema).
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| attachment_id | Yes |
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.
Remove a collaborator from an agent (owner only).
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | |||
| agent_id | Yes |
Resume a paused visitor conversation.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| visitor_id | Yes |
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.
Resume an interrupted follow-up run.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | ||
| agent_id | Yes |
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.
Start a leads discovery scan (whatsapp, instagram, x, telegram, or jiji).
| Name | Required | Description | Default |
|---|---|---|---|
| params | No | ||
| channel | Yes | ||
| agent_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Start a scan' implies a mutation/long-running action, but the description never says whether the scan is asynchronous, how long it runs, whether it returns a scan id, what quota or rate limits apply, or what happens on repeated calls.
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 it is arguably too terse given the amount of undocumented behavior behind 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?
With no annotations, no output schema, a nested 'params' object, and 0% schema description coverage, the description is far too thin for a 3-parameter scan-starting tool. An agent would not know how to populate params or what the call 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. It does add real value by enumerating the accepted channel values (whatsapp, instagram, x, telegram, jiji), which the schema does not. But agent_id and the nested 'params' object are entirely 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?
States a specific verb ('Start') and resource ('leads discovery scan') and enumerates the supported channels. However, it does not distinguish itself from close siblings like admin__continue_scan or admin__trigger_scan_schedule, so the agent cannot tell which of these to pick from the description 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 guidance on when to use this versus admin__continue_scan, admin__trigger_scan_schedule, or admin__suggest_targets. Usage context is only implied by the tool name, and no prerequisites or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send follow-up via admin_followup channels.
| Name | Required | Description | Default |
|---|---|---|---|
| contact | No | Generic contact from analytics/list_sessions (email, phone, or @instagram). | |
| message | Yes | ||
| agent_id | Yes | ||
| visitor_id | No | ||
| whatsapp_no | No | ||
| visitor_email | No | ||
| instagram_username | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it discloses nothing: not whether the send requires an assigned channel account, what 'admin_followup channels' means, whether the message is dispatched immediately, or any rate/side-effect behavior. 'Send' weakly implies a mutation but that is the entire 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?
The single clause is short and front-loaded, but this is under-specification rather than conciseness. There is no waste because there is almost no content at all.
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 mutation tool with no annotations, no output schema, and 14% schema coverage needs substantial description to be callable correctly. The description supplies none of it, so an agent cannot determine required channel setup or which contact parameter to 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 only 14% across 7 parameters, and the description mentions none of them. The critical choice between contact, visitor_id, visitor_email, whatsapp_no, and instagram_username is undocumented, leaving six of seven parameters effectively unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description pairs the verb 'Send' with the resource 'follow-up', which is enough to identify the general action. However, 'via admin_followup channels' is an opaque internal reference and does not differentiate this tool from close siblings like admin__send_message or admin__bulk_followup.
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 admin__send_message (single outbound message) or admin__bulk_followup. No prerequisites, conditions, or exclusions are given, so the agent must guess from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send follow-up via WhatsApp, email, or Instagram.
| Name | Required | Description | Default |
|---|---|---|---|
| contact | No | Generic contact from analytics/list_sessions (email, phone, or @instagram). | |
| message | Yes | ||
| agent_id | Yes | ||
| visitor_id | No | ||
| whatsapp_no | No | ||
| visitor_email | No | ||
| instagram_username | No |
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 does not meet it. It does not say whether the message is sent immediately or queued, whether a channel account must already be assigned (see the many admin__assign_*_account siblings), what happens if multiple channel identifiers are supplied, or whether the contact must be an existing visitor. For an outbound messaging tool this is a significant omission.
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 action is front-loaded, so it is not bloated. But with 7 parameters and no annotations, this level of brevity edges into under-specification rather than efficient conciseness. There is room for one or two more sentences that would earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, 14% schema coverage, no annotations, and no output schema, the definition is far too thin for the tool's complexity. An agent must guess channel selection, required account setup, and the semantics of overlapping contact fields. The description needs to carry more of this load and does not.
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 14% (7 params, only "contact" documented), so the description must compensate and does not. It never explains the relationship between contact, whatsapp_no, visitor_email, instagram_username, and visitor_id, nor how the tool decides which channel to use, nor why agent_id is required. The channel list in the description does not map onto any 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?
It states a verb ("Send") and a resource (follow-up message) plus the three channels (WhatsApp, email, Instagram), so the basic action is understandable. However, the wording "follow-up" collides conceptually with the siblings admin__send_followup and admin__bulk_followup, and nothing in the description explains how send_message differs from them. An agent cannot confidently tell this tool apart from its nearest 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 when-not-to-use, and no reference to any alternative tool. With siblings like send_followup, bulk_followup, and compose_draft in the same namespace, the absence of routing guidance is a real gap. The only implicit context is the naming of the channels.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enable/disable pool fallback for x, instagram, or telegram channel.
| Name | Required | Description | Default |
|---|---|---|---|
| channel | Yes | ||
| enabled | Yes | ||
| agent_id | Yes |
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 tool. It does not say what 'pool fallback' means operationally, whether the change is immediate or reversible, what permissions are needed, or what happens to in-flight routing.
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 no filler. It is efficient, though it is efficient partly because it omits necessary 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?
A three-parameter mutation tool with no annotations, no output schema, and no parameter documentation in the schema needs the description to compensate, and it does not. An agent cannot safely call this without guessing at agent_id's role and fallback 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%. The description echoes the channel enum (already in the schema) and implies the boolean via 'enable/disable', but the required agent_id parameter is never mentioned, leaving a third of the inputs undocumented anywhere.
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 (enable/disable) and the resource (pool fallback) scoped to three channels, which separates it from the assign_* and list_* admin siblings. However, 'pool fallback' is unexplained jargon, so an agent knows the operation but not what it actually changes.
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 enable versus disable fallback, no prerequisites, and no reference to any alternative tool. The agent gets no routing guidance at all.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace labels on one visitor session.
| Name | Required | Description | Default |
|---|---|---|---|
| labels | No | ||
| agent_id | Yes | ||
| visitor_id | Yes |
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 discloses the important overwrite behavior via 'Replace,' but omits required permissions, whether the agent or visitor must already exist, what happens if labels are omitted, and any side effects. This is insufficient for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no wasted words. It states the action and scope immediately. It is appropriately concise for its surface-level purpose, even though it is incomplete 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 3-parameter mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is too thin. It gives the action and scope but omits parameter meaning, permissions, and replacement behavior details. An agent would need to inspect the schema and guess at usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It hints at the labels parameter and the visitor session via 'labels' and 'one visitor session,' but never explains agent_id, the shape of label objects, or how labels are formatted. The semantics are only partially and implicitly covered.
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: 'Replace labels' on 'one visitor session.' It distinguishes this tool from the bulk sibling via 'one visitor session,' but it does not explicitly differentiate itself from admin__update_session_label or name any alternative. The core purpose is clear without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus admin__update_session_label, admin__bulk_set_session_labels, or admin__list_session_labels. No prerequisites, exclusions, or alternative conditions are provided. 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.
AI-propose Instagram or X @targets for a discovery scan (depth/breadth optional).
| Name | Required | Description | Default |
|---|---|---|---|
| channel | Yes | ||
| agent_id | Yes | ||
| min_followers | No | ||
| discovery_depth | No | ||
| discovery_breadth | No | ||
| disable_hard_filter | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It does not disclose whether targets are persisted, permissions required, side effects, rate limits, or what the result contains. 'AI-propose' hints at generation but gives no operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the core action and scope. There is no filler or redundancy, and the optional note is parenthetically 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?
For a 6-parameter tool with no annotations, no output schema, and 0% schema coverage, this one-line description is drastically incomplete. An agent cannot reliably call the tool without additional documentation for required and optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for all six parameters. It maps channel to 'Instagram or X' and notes depth/breadth are optional, but leaves agent_id, min_followers, and disable_hard_filter entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('AI-propose') and resource ('Instagram or X @targets') scoped to a discovery scan. It is clear what the tool does, though it does not explicitly differentiate itself from siblings like run_scan or create_scan_schedule.
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 a discovery scan' implies context, but there is no explicit guidance on when to use this tool versus alternatives such as run_scan. No prerequisites, exclusions, or sibling routing are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transfer agent ownership to another subscribed Nova user.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| new_owner_email | Yes |
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 say whether the previous owner loses access, whether the transfer is reversible, what permissions the caller needs, or what happens if the email is not a subscribed Nova user. The word 'subscribed' is the sole behavioral hint.
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 appropriately sized, though the extreme brevity contributes to the gaps 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 destructive, permission-sensitive ownership transfer with no annotations, no output schema, and undocumented parameters, the description is too thin. An agent cannot confirm eligibility rules, side effects, or failure behavior before invoking 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 two required parameters. The description does not define agent_id format or clarify that new_owner_email must be an existing subscribed Nova account, so it adds no meaning beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('transfer') and resource ('agent ownership') with the target ('another subscribed Nova user'). It is clear what the tool does, though it does not name or contrast itself against sibling admin tools such as admin__update_agent or admin__delete_agent.
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 versus admin__update_agent (which may also alter ownership) or what prerequisites exist. The only usable signal is the implicit 'subscribed Nova user' eligibility, which is not framed as a usage condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run an auto-scan schedule immediately (Run now).
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| schedule_id | Yes |
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 mutation/trigger but says nothing about whether the run is synchronous or queued, whether it mutates the schedule's next-run time, required permissions, or whether the schedule is disabled/active state matters.
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. It is terse without padding, though the brevity contributes to the coverage 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?
With no annotations, no output schema, and 0% parameter coverage, the description is too thin for a trigger/mutation tool. An agent lacks enough to know side effects, return behavior, or parameter constraints.
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 neither parameter. Although agent_id and schedule_id are fairly self-explanatory names, the description adds no meaning, no format, and no indication of what identifies a valid schedule.
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: triggering an existing auto-scan schedule to run immediately. This distinguishes it from siblings like run_scan, continue_scan, and create_scan_schedule, though it never names 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?
The parenthetical '(Run now)' hints at a UI affordance but gives no guidance on when to prefer this over run_scan, continue_scan, or create_scan_schedule, nor any preconditions such as the schedule needing to exist or be enabled.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update Support Agent settings (partial patch — only send fields to change).
| Name | Required | Description | Default |
|---|---|---|---|
| inapp | No | ||
| theme | No | ||
| title | No | ||
| context | No | ||
| agent_id | Yes | ||
| is_public | No | ||
| allow_list | No | ||
| description | No | ||
| public_slug | No | ||
| file_support | No | ||
| instructions | No | ||
| contact_option | No | ||
| disable_ai_reply | No | ||
| x_ld_public_only | No | Cold LD import: public quote/reply only, no DMs. | |
| x_ld_quote_target | No | ||
| followup_x_message | No | ||
| public_category_id | No | ||
| public_description | No | ||
| x_ld_public_poster | No | ||
| x_ld_like_before_dm | No | ||
| x_ld_public_surface | No | ||
| x_ld_public_after_dm | No | ||
| bulk_followup_enabled | No | ||
| x_ld_like_daily_limit | No | ||
| x_ld_public_post_goal | No | ||
| followup_email_message | No | ||
| x_ld_public_daily_limit | No | ||
| followup_telegram_message | No | ||
| followup_whatsapp_message | No | ||
| x_ld_attention_use_custom | No | When true, use agent-specific X Leads Discovery public attention (Lane A/B). | |
| x_ld_public_per_run_limit | No | ||
| followup_instagram_message | No | ||
| x_ld_pool_public_quote_after_dm_fail | No |
Update collaborator role or permissions on an agent (owner only).
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | ||
| Yes | |||
| status | No | ||
| agent_id | Yes | ||
| permissions | No |
Update CRM unreplied digest email settings.
| Name | Required | Description | Default |
|---|---|---|---|
| enabled | No | ||
| agent_id | Yes | ||
| min_unreplied | No | ||
| recipient_emails | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description must disclose mutation semantics. It says nothing about permissions, whether the update is partial or full, reversibility, or side effects. It provides no behavioral context beyond the verb 'Update'.
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, front-loaded sentence with no wasted words, but it is too sparse for a mutation tool with four parameters. The sentence is structurally clean but does not earn its place by conveying actionable detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and fully undocumented parameters, the description is critically thin. It omits required-parameter context, setting semantics, and any operational guidance, leaving the agent unable 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 coverage is 0% for four parameters. The description does not explain any parameter's meaning, format, or constraints (e.g., what min_unreplied controls or how recipient_emails is used), so it fails to compensate for the empty schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb (Update) and resource (CRM unreplied digest email settings), distinguishing it from the read-only sibling get_crm_unreplied_alert_config. However, it does not explicitly name alternatives or scope beyond the title.
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 existence of get_crm_unreplied_alert_config as a read counterpart is not mentioned, leaving the agent to infer when to choose update versus retrieve.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update or pause/resume an auto-scan schedule.
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | ||
| params | No | ||
| channel | No | ||
| enabled | No | ||
| agent_id | Yes | ||
| max_runs | No | ||
| frequency | No | ||
| auto_import | No | ||
| schedule_id | Yes | ||
| run_hour_utc | No | ||
| auto_outreach | No | ||
| max_leads_per_run | No | ||
| relax_target_filter_after_runs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, and it says almost nothing. 'Update' implies mutation, but there is no mention of permissions, whether omitted fields are cleared, whether changes are reversible, or how pause/resume maps to state. The only behavioral hint is that pause/resume is handled here.
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 clean sentence with no wasted words and the core action front-loaded, so it reads efficiently. However, for a 13-parameter mutation tool it is far too terse to be considered well-structured coverage; brevity here borders on 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?
A 13-parameter mutation tool with a nested object parameter, no annotations, no output schema, and 0% parameter description coverage, yet the description is a single sentence. Nothing an agent needs to invoke it correctly across a dozen fields 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?
There are 13 parameters with 0% schema description coverage, so the description must compensate and it does not. The phrases 'update' and 'pause/resume' loosely gesture at the enabled toggle, but fields like params, channel, max_runs, frequency, auto_import, auto_outreach, max_leads_per_run, and relax_target_filter_after_runs are entirely undocumented anywhere.
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 (update) and resource (auto-scan schedule) and adds the pause/resume scope, so the agent knows it mutates an existing schedule rather than creating one. It does not explicitly differentiate itself from siblings like create_scan_schedule, delete_scan_schedule, list_scan_schedules, or trigger_scan_schedule, but the verb+resource pairing is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use guidance and names no alternatives. It implies the tool is for modifying or toggling a schedule, but an agent gets no help distinguishing it from trigger_scan_schedule or create_scan_schedule, and no prerequisites (e.g. needing an existing schedule_id) are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update catalog label (e.g. disable_auto_reply).
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| label_id | Yes | ||
| disable_auto_reply | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden for a mutation tool. It does not say whether the change is reversible, what permissions are needed, whether omitted labels are untouched, or what the response is; the only behavioral hint is the parenthetical example of one label 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?
A single front-loaded sentence with zero filler, so it is structurally clean and easy to scan. Its brevity is arguably under-specification rather than over-verbosity, but as a structural artifact it wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter mutation tool with no annotations, no output schema, and zero parameter documentation, this description is far too thin. It does not resolve the ambiguity around what a 'catalog label' is or how the toggle behaves relative to the sibling label tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so all three parameters (agent_id, label_id, disable_auto_reply) are undocumented. The description's example mentions disable_auto_reply but never explains that label_id identifies the label or how the boolean interacts with it, leaving the agent to guess at the relationship between the required id and the optional flag.
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 verb (update) and a resource (catalog label), which is better than a tautology, but 'catalog label' is ambiguous and the description never distinguishes this singular update from the sibling tools set_session_labels, bulk_set_session_labels, and list_session_labels. The 'e.g. disable_auto_reply' hint helps but doesn't pin down whether a label is a session attribute or a catalog entry.
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 versus set_session_labels (which also assigns labels) or bulk_set_session_labels. The agent is left to infer that this handles one label on an agent/session while the siblings handle sets, and 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.
Upload agent icon (JPEG/PNG/WebP, max 2MB, base64).
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| content_type | No | ||
| content_base64 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It adds concrete validation constraints (JPEG/PNG/WebP, max 2MB, base64), which is useful. However, for a write/upload operation it omits whether it overwrites an existing icon, permission requirements, and 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 short sentence with zero waste, front-loading the action and constraints. Appropriate size for a simple upload 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?
Given no annotations, no output schema, and 0% schema description coverage, the description is too thin. It lacks usage guidance, agent_id semantics, authorization needs, and any indication of the operation's effect on existing icon data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies content_base64 (base64 encoding), content_type (JPEG/PNG/WebP), and a size limit, but never mentions agent_id beyond the tool name. It partially compensates 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: 'Upload agent icon.' It clearly conveys what the tool does, but does not distinguish it from related siblings such as admin__update_agent or admin__upload_attachments.
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 instead of alternatives like admin__update_agent or admin__generate_agent_preview. The description only gives file constraints, leaving usage context to inference from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload files to agent KB (PDF/DOCX/TXT → prose; CSV/XLSX/SQLite → database).
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | ||
| agent_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it usefully discloses that file type determines downstream handling (PDF/DOCX/TXT → prose, CSV/XLSX/SQLite → database). However, it omits whether uploads add to or replace existing KB content, permission/auth requirements, and the 10-file cap present in the schema.
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 primary action leads and the type-routing detail follows compactly.
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 upload/mutation tool with no annotations, no output schema, and 0% schema coverage, the definition is too thin. It says what happens to file types but leaves the agent without auth expectations, replacement semantics, size/count limits, or any sense of the response.
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 two undocumented parameters, yet it never names or explains agent_id or the files array. The file-type note loosely relates to content_type but does not clarify the required base64 encoding of content_base64, filename handling, or the maxItems limit.
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 ('Upload files to agent KB') and even distinguishes the two processing paths by file type (prose vs database). An agent can tell it apart from sibling attachment tools like delete_attachment, get_attachment_content, list_attachments, and regenerate_attachment without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for populating an agent's KB but gives no when-to-use condition, no exclusions, and no reference to alternatives (e.g., when to regenerate or delete an existing attachment). The file-type routing is behavioral, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Google calendar action: add event
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Task-specific details from the objective. |
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 tool. It does not mention authentication requirements, whether invitations are sent, whether the event is created on a primary or specific calendar, or what happens on failure.
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 with no wasted clauses and is trivially front-loaded. The brevity is not the problem; the boilerplate framing contributes nothing beyond 'add event' and the under-specification is what costs it points.
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 that creates calendar events, the description omits essentials like time, title, attendees, and which calendar, and notes that no parameters are required (0 required). With no annotations and no output schema, the description leaves the agent without enough context 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?
Schema description coverage is 100% and there is a single parameter whose meaning ('Task-specific details from the objective') is already documented in the schema. The description adds no syntax, format, or content guidance beyond that, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'add event' gives a verb+resource for Google Calendar, so the agent can tell it apart from calendar__delete_event and calendar__update_event. However, it is wrapped in generic boilerplate ('Run Google calendar action') and gives no scope detail such as which calendar or what an event consists of.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool over calendar__update_event, calendar__delete_event, or the calendar__converse sibling. The only cue is the word 'add' in the name, which the description merely restates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Google calendar action: check events today
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Task-specific details from the objective. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it discloses nothing beyond the operation itself: no return shape, no calendar/account scoping, no auth or permission requirements, no note on whether events from multiple calendars are merged. For a zero-annotation tool 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 short sentence with the actionable scope front and center. The 'Run Google calendar action:' preamble is low-value boilerplate but costs little.
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-style listing with one optional param, no annotations and no output schema, the description is minimally viable but omits the return format and whether results are scoped to a single calendar, which an agent would need to interpret 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 100% and there is a single optional 'detail' parameter documented as task-specific details. The description adds no meaning about how 'detail' is interpreted or what values are expected, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource with an explicit time scope ('check events today'), which lets an agent separate it from calendar__check_events_week by scope alone. The 'Run Google calendar action:' prefix is filler but does not obscure the purpose.
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 versus calendar__check_events_week or the other calendar tools; the today-vs-week distinction is left entirely to inference from the name. No prerequisites or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Google calendar action: check events week
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Task-specific details from the objective. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Check' weakly implies a read operation, but the description says nothing about read-only nature, required auth/calendar scoping, timezone handling, or result size — significant gaps for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the operation, but the 'Run Google calendar action:' prefix is boilerplate that consumes space without adding information. Adequately sized, minimally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a calendar read tool with no annotations and no output schema, the description should at least indicate the return shape (list of events for the week) and the timezone/calendar scope. None of that is present, leaving an agent to guess how to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single 'detail' parameter is documented in the schema as task-specific details, so the baseline of 3 applies. The description adds no meaning beyond the schema — it does not explain what detail content the tool expects for a weekly event lookup.
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 recognizable verb+resource ('check events week') and the weekly scope distinguishes it from the sibling calendar__check_events_today in name, but 'check' is vague about what is actually returned and the 'Run Google calendar action:' wrapper is filler rather than clarification.
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 guidance, no mention of the obvious alternative (calendar__check_events_today), and no statement about prerequisites such as which calendar or account is queried. Only the tool name implies the weekly window.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reply conversationally when the request is ambiguous or needs clarification.
| Name | Required | Description | Default |
|---|---|---|---|
| reply_hint | No | Optional hint for the conversational reply. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It only says it replies conversationally and does not disclose whether it modifies state, what permissions are needed, whether the reply ends the turn, or any 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?
The description is a single front-loaded sentence with no wasted words. It communicates the trigger and action efficiently.
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 conversational fallback tool, the trigger is covered. However, with no annotations and no output schema, the description still leaves gaps around how the reply is delivered and how it relates to other calendar actions.
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?
There is one optional parameter with 100% schema description coverage. The description does not mention reply_hint or add meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Reply conversationally') and a trigger condition, but it does not identify the calendar domain or distinguish this tool from the identical docs__converse and sheets__converse siblings. Purpose is understandable but generic.
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 clearly says to use this tool when the request is ambiguous or needs clarification. It does not name alternatives or state when not to use it, so it is clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Google calendar action: convert timezone
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Task-specific details from the objective. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, yet it discloses nothing about behavior: no indication of whether the operation mutates anything, what auth is needed, or what the conversion depends on. It adds essentially 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?
The single-sentence fragment is short but does not earn its place: it is a near-verbatim restatement of the tool name rather than adding information, so brevity here reflects under-specification rather than 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 annotations, no output schema, and only a generic 'detail' parameter, the description leaves an agent unable to know what inputs the conversion needs or what it returns. For a timezone-conversion tool it should specify the source/target context but does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With one parameter and 100% schema coverage, the baseline is 3. The single 'detail' parameter's schema description ('Task-specific details from the objective') is itself generic, and the tool description adds nothing further about what detail should contain.
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 an action and resource ('Google calendar ... convert timezone'), so an agent can broadly tell what it does. But it is phrased as a generic wrapper ('Run Google calendar action') and mostly restates the tool name, without saying what is being converted (event times, current time, a timestamp) or from/to what.
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 siblings like calendar__add_event or calendar__check_events_today, nor any mention of prerequisites. Usage is only implied by the tool name itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Google calendar action: delete event
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Task-specific details from the objective. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does not state whether deletion is permanent or reversible, what permissions are required, or what happens to the event's attendees/notifications. 'Delete' signals a destructive mutation, but nothing beyond that 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?
A single short sentence, front-loaded with the action. It is efficient, though the 'Run Google calendar action:' prefix is boilerplate that earns little.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description should cover irreversibility, identification of the target event, and required permissions. None of that is present, and the lone 'detail' parameter gives an agent no reliable way to specify which event to delete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single 'detail' parameter is documented in the schema and the baseline is 3. The description adds no meaning about how the event to delete is identified, which is the key semantic gap, but per the high-coverage rule a 3 is the appropriate baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'delete event' gives a clear verb+resource and implicitly contrasts with siblings add_event and update_event. However, 'Run Google calendar action:' is filler that restates the tool's namespace, and there is no scope detail (which event, by what identifier), so it stays at minimum-viable rather than distinctive.
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 this should be used versus calendar__update_event or calendar__add_event, and no stated prerequisites (e.g., need an existing event id). Deletion is only vaguely implied by the word 'delete'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Google calendar action: update event
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Task-specific details from the objective. |
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 nothing: not which fields are mutable, whether the update is partial or wholesale, whether it needs event IDs or permissions, or whether changes are reversible. It signals only that a mutation occurs, which is the bare minimum.
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 with no bloat, so it is concise. However, the front-loaded portion ('Run Google calendar action') is filler that delays the only informative token, so it is not optimally structured despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and only a vague freeform 'detail' parameter, the description is too thin. An agent cannot determine the required inputs (which event, which fields), the side effects, or the expected result 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?
With a single parameter at 100% schema description coverage, the schema already documents 'detail' as 'Task-specific details from the objective.' Baseline 3 applies; the description adds no meaning about how to populate this freeform field, but the schema coverage means the parameter is not 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 contains a recognizable verb+resource ('update event') but wraps it in generic filler ('Run Google calendar action:'). It distinguishes the operation from siblings like calendar__add_event and calendar__delete_event only by the verb, with no indication of what an 'update' covers or how the target event is identified.
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 calendar__add_event, calendar__delete_event, or the read-only check_events tools. No prerequisites, no exclusions, no context — the agent must infer everything from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reply conversationally when the request is ambiguous or needs clarification.
| Name | Required | Description | Default |
|---|---|---|---|
| reply_hint | No | Optional hint for the conversational reply. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral load. It says it replies conversationally, which implies a non-mutating response, but does not disclose side effects, authorization needs, response format, or whether it can access document context, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. It is appropriately sized for a simple fallback 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 simple one-parameter tool with no annotations or output schema, the description states when to use it but omits what the reply looks like, how reply_hint influences it, and any behavioral expectations. It is minimally adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter reply_hint is already described in the schema. The description adds no meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Reply conversationally') and the triggering condition, so the agent understands it is a clarification/fallback tool rather than a doc CRUD tool. It does not name an alternative or further scope the resource, so it falls 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?
Explicitly gives the condition for use ('when the request is ambiguous or needs clarification'), which is clear usage context. No alternatives or when-not guidance are provided, so it is not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Google docs action: create doc
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Task-specific details from the objective. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden and discloses nothing: no information on required auth/permissions, whether the created doc is empty, whether it is shared, what it returns, or any side effects. 'Run ... action: create doc' restates the name without behavioral content.
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, so it is not verbose, but the 'Run Google docs action:' prefix is filler rather than front-loaded useful information. Brevity here comes from under-specification rather than efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations, no output schema, and a vague generic 'detail' parameter, the description should explain at minimum what gets created and what the caller receives back. It leaves the agent unable to predict the result or the required input content.
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?
Only one parameter exists and schema description coverage is 100%, so the schema already documents 'detail' as 'Task-specific details from the objective.' The description adds no additional meaning about what detail should contain for doc creation, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('create doc'), enough to separate it from delete_doc/get_doc/list_docs at a glance. However 'Run Google docs action:' is redundant wrapper text that adds nothing, and it never states what the doc initially contains or how it is named.
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 indication of when to use this tool versus docs__rewrite_doc, docs__get_doc, or the other siblings, nor any prerequisite or precondition. The agent is given no criteria for selecting it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Google docs action: delete doc
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Task-specific details from the objective. |
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 destructiveness, irreversibility, required permissions, or whether the deleted doc is recoverable. For a delete operation this is a critical omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short, but the boilerplate 'Run Google docs action:' prefix is filler that duplicates the namespace and dilutes the front-loaded intent. It is concise without being substantive.
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, annotation-free tool with no output schema needs to explain irreversibility and any confirmation requirements; none of that is present. An agent cannot safely decide to invoke this based on the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter ('detail') and schema description coverage is 100%, so per the calibration baseline the schema already documents it. The description adds no meaning about what detail should contain for a delete action, so it neither helps nor harms.
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 ('delete doc'), which is enough to distinguish it from siblings like docs__get_doc, docs__create_doc and docs__rewrite_doc. The generic 'Run Google docs action:' prefix adds no value but doesn't obscure the purpose.
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. The only hint of usage is the tool name itself; nothing tells the agent when deletion is appropriate versus rewriting or leaving a doc alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Google docs action: get doc
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Task-specific details from the objective. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, yet it says nothing about return format, whether it requires an ID, permission requirements, or error behavior. It only weakly implies a read operation via 'get'.
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 with no padding, but the generic 'Run Google docs action:' prefix is low-value filler rather than a meaningful front-loaded statement of the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a retrieval tool with no output schema and no annotations, the definition should explain what is returned and whether an identifier is needed. None of that is present, leaving significant gaps an agent cannot resolve from the other fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single 'detail' parameter is documented in the schema itself, giving the baseline of 3. The description adds no interpretation of what 'detail' should contain, but the schema-coverage rule caps the concern here.
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 phrase 'get doc' names a verb and resource, so the basic operation is inferable, but it is wrapped in generic boilerplate ('Run Google docs action:') that adds nothing and the definition reads as a near-restatement of the tool name. It gives no signal to distinguish it from siblings like docs__list_docs or docs__converse.
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 indication of when to use this tool rather than docs__list_docs for enumeration or docs__converse for content work. No prerequisites, exclusions, or alternative selection logic are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Google docs action: list docs
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Task-specific details from the objective. |
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 not state that this is a read-only operation, whether results are paginated, how many docs are returned, or what auth is required. 'List' weakly implies non-mutation but nothing 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?
A single short sentence with no wasted clauses, but it is boilerplate rather than deliberately concise — the brevity comes from under-specification, not from economical expression.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no annotations and no output schema, the description should at least describe the returned collection or pagination behavior. Neither is present, leaving real gaps an agent would need to resolve.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and there is only one parameter ('detail'), whose own schema description ('Task-specific details from the objective') is opaque. The tool description adds no meaning beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a verb (list) and resource (docs) inside a generic 'Run Google docs action:' wrapper, so the purpose is inferable. It does not distinguish itself from the sibling get_doc or explain what 'list' returns, so the differentiation is only implied.
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 choose this tool over docs__get_doc, docs__converse, or the research tools. The agent must guess from names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Google docs action: rewrite doc
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Task-specific details from the objective. |
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 delivers almost nothing. It does imply mutation/overwrite of an existing document (useful), but says nothing about whether the original content is lost, whether permissions are required, whether it is reversible, or how the new content is determined.
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, front-loaded sentence with no padding, which is fine structurally. However, it reads as generic auto-generated boilerplate ('Run <product> action: <verb> <resource>') that spends its one sentence restating the tool name rather than conveying information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotations and no output schema, the description omits everything an agent needs: how the rewrite is produced, what input content is expected, what happens to the existing document, and what a successful call returns. The gaps are significant relative to the tool'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 100% for the single 'detail' parameter, so the schema already documents it; per the baseline rule a 3 is appropriate. The description adds no additional meaning about what 'detail' should contain for a rewrite operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a verb ('rewrite') and a resource ('doc'), and the sibling list (create/delete/get/list_doc) makes the general category clear. But it does not say what a 'rewrite' actually does — full-content replacement, targeted edit, or LLM-driven rephrasing — so the agent cannot distinguish its precise effect from create_doc or a hypothetical update tool.
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 versus alternatives such as docs__create_doc or docs__get_doc, nor any prerequisite (e.g., must the doc already exist, must an ID be supplied). 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.
Conduct deep, iterative research on a topic by generating multiple search queries, processing the results, and recursively exploring new research directions.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | Depth of recursive exploration (0-2) | |
| topic | Yes | The main topic or question to research | |
| breadth | No | Number of search queries per research direction (1-5) | |
| objective | Yes | The specific goal or objective of the research | |
| connection_id | No | Optional connection ID for the user | |
| max_total_queries | No | Maximum number of search queries to process (2-5) | |
| max_duration_seconds | No | Maximum duration for the research process in seconds (60-300) |
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 the iterative/recursive nature, which signals long-running, potentially expensive execution and explains the duration and query caps in the schema, but it says nothing about permissions, the connection_id requirement, cost, or failure modes.
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 that front-loads the core purpose and then explains the mechanism. Nothing is padded or redundant.
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 complex (7 parameters, no output schema, no annotations) and the description leaves the return value entirely unspecified even though no output schema exists to cover it. The agent knows what the tool does procedurally but not what it yields or how results are shaped.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter (depth, breadth, max_total_queries, max_duration_seconds, connection_id) is documented with ranges and defaults in the schema. The description adds no parameter-level meaning beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb (conduct) and resource (deep, iterative research) and even explains the mechanism: generating multiple queries, processing results, and recursing. It is clearly a research-execution tool, but it never contrasts itself with the sibling research__generate-research-report, so an agent must infer the boundary.
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 the natural alternative, research__generate-research-report (report vs. raw research). The agent gets a description of the mechanism but no instruction on when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a comprehensive research report from existing research data.
| Name | Required | Description | Default |
|---|---|---|---|
| objective | Yes | The specific goal or objective of the report | |
| research_data | Yes | The research data and findings to include in the report |
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 not say whether the generated report is persisted or merely returned, what format/length to expect, or whether it requires prior research artifacts — for a generative 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 front-loaded sentence with no waste; 'comprehensive' is mildly decorative but the purpose is stated 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?
A simple two-parameter tool with fully documented params and no output schema, but the description never states what the tool returns or where the report goes, which is exactly the information missing when no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (objective, research_data) are already documented in the schema. The description adds no format, size, or structuring guidance beyond that baseline, so a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (generate) and resource (research report) plus the input source (existing research data), so the agent knows this synthesizes rather than performs research. It does not explicitly distinguish itself from the sibling research__conduct-deep-research, which an agent might reasonably 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?
There is no when-to-use guidance, no prerequisite statement (e.g. that research must already exist), and no mention of the alternative research__conduct-deep-research for gathering new data. The agent must infer the routing decision entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reply conversationally when the request is ambiguous or needs clarification.
| Name | Required | Description | Default |
|---|---|---|---|
| reply_hint | No | Optional hint for the conversational reply. |
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 of side effects, no indication of whether it is read-only or stateful, and no hint about what the reply contains. Only the ambiguous "reply conversationally" phrasing conveys 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?
A single sentence that front-loads the action and then the trigger condition. There is no filler, repetition, or redundancy; 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?
Complexity is low (one optional param, no nested objects, no output schema), so little is required, but for a conversational fallback the agent still lacks any indication of return format or whether conversation state is involved. Adequate but with an evident 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?
There is a single optional parameter (reply_hint) with 100% schema description coverage, so the schema already documents it. The description adds no syntax, format, or content guidance for the hint beyond what the schema states, which matches the baseline 3 for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ("Reply conversationally") plus the trigger condition for it. It is functionally distinguishable from the sibling CRUD tools (create/delete/get/update sheet) and the research tools, though it names no concrete resource or output artifact, keeping it 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?
It gives an explicit when-to-use rule: "when the request is ambiguous or needs clarification." That is a clear selection condition against the concrete sheet/research siblings. It does not name an alternative tool or state when NOT to use it, so it falls short of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Google sheets action: create sheet
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Task-specific details from the objective. |
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. 'Create sheet' implies a mutation, but there is no mention of permissions required, whether an existing sheet is overwritten, what the returned identifier is, or any side effects. The generic 'Run Google sheets action' phrasing adds no 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?
One short sentence with no wasted words, but the brevity comes from boilerplate rather than precision. The 'Run Google sheets action:' prefix is padding that could be replaced with substantive content at the same length.
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 a single opaque 'detail' parameter, the description is far too thin. An agent cannot tell what the tool actually creates or how to supply meaningful detail, leaving the definition inadequate 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 100% for the single 'detail' parameter, so the schema already documents it, establishing a baseline of 3. The description adds nothing about how 'detail' maps to sheet creation (naming, tab structure, etc.), but it is not required to when coverage is complete.
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 restates the tool name almost verbatim ('create_sheet' → 'create sheet'), wrapped in a generic 'Run Google sheets action' boilerplate. It does not describe what the created sheet contains, where it is created, or how it differs from siblings like sheets__generate_sheet or sheets__update_sheet. This is close to a tautology.
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 versus the numerous siblings (generate_sheet, update_sheet, delete_sheet, converse). No prerequisites, no exclusions, no alternative routing. The agent must infer usage entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Google sheets action: delete sheet
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Task-specific details from the objective. |
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 for a destructive operation. It does not state that deletion is irreversible, whether it requires permissions, or what happens to sheet data or references — it only repeats the word 'delete'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no waste, but the boilerplate 'Run Google sheets action:' prefix consumes most of it without conveying information. It is concise but front-loads filler rather than substance.
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 zero required parameters, the description is inadequate. It omits irreversibility, side effects, and expected outcomes that an agent would need before invoking a delete.
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?
There is a single parameter ('detail') with 100% schema description coverage, so the schema already documents it. The description adds no meaning beyond the schema, but per the high-coverage baseline a 3 is appropriate rather than penalizing further.
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 'Run Google sheets action: delete sheet' is essentially a restatement of the tool name sheets__delete_sheet, which is the definition of a tautology. It states a verb and resource but adds no distinguishing detail versus siblings like update_sheet or create_sheet.
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 update_sheet, get_sheet, or create_sheet. The only context is a boilerplate prefix ('Run Google sheets action'), which gives the agent nothing to route on.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Google sheets action: generate sheet
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Task-specific details from the objective. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it discloses nothing: not whether a sheet is created, overwritten, or derived; not auth requirements; not the effect on an existing spreadsheet. It is effectively opaque 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?
One short sentence, but its brevity comes from under-specification rather than efficiency. "Run Google sheets action:" is filler that consumes the whole description without conveying information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation-style generate action with no annotations, no output schema, and no explanation of what "generate" produces, the description is far too thin. An agent cannot confidently call it or predict 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?
Single parameter with 100% schema description coverage, so the schema already documents "detail" as task-specific objective details. Per the baseline for high coverage, a 3 is appropriate; the description adds no meaning beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Run Google sheets action: generate sheet" restates the tool name in wrapper phrasing without adding specificity. It does not distinguish generate_sheet from sibling create_sheet, converse, or update_sheet, all of which operate on the same resource.
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 create_sheet or the other sheets siblings. The agent is left to infer that "generate" differs from "create" purely from the name, which is not explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Google sheets action: get sheet
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Task-specific details from the objective. |
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, and it discloses nothing: no read-only vs. mutating status, no auth/permission requirements, no indication of what is returned or how a sheet is identified. The boilerplate phrase 'Run Google sheets action' adds zero behavioral content.
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 very short and front-loaded, but the 'Run Google sheets action:' prefix is pure template padding that earns no place, and the remainder is under-specified rather than concise. There is no useful structure or content to organize.
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 must explain operation semantics, but it supplies nothing — not what a 'get sheet' returns, not how the target sheet is determined, not any prerequisite. For even this simple one-parameter read tool, the definition is materially incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter ('detail') and schema description coverage is 100%, so the schema already documents it. The description adds no meaning beyond the schema, which is the expected baseline 3 when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description reads 'Run Google sheets action: get sheet,' which is effectively the tool name restated with template boilerplate around it. It gestures at a verb (get) and resource (sheet) but conveys no scope, return content, or distinction from siblings like sheets__list_sheets or sheets__generate_sheet.
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 is present at all, and no alternative tools are referenced. An agent cannot tell from this text whether it should call get_sheet, list_sheets, or generate_sheet for a given request.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Google sheets action: list sheets
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Task-specific details from the objective. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'List' weakly implies a read-only operation, but the description never states that, nor does it describe scope (all sheets? within a file?), pagination, or return shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with no redundancy, so it is not verbose, but the brevity comes at the cost of under-specification rather than economy of expression.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description must explain what a caller gets back; it says nothing about the return payload or how results are scoped. For a list tool in a family of similar sheet operations, this is an incomplete 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?
There is a single optional parameter 'detail', fully described in the schema as 'Task-specific details from the objective.' Schema coverage is 100%, so the baseline of 3 applies; the description adds no additional meaning about how detail influences the listing.
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 ('list') and resource ('sheets'), so the intent is inferable, but it is wrapped in a generic 'Run Google sheets action:' template that adds nothing. It does not distinguish this from the sibling get_sheet, which an agent could easily confuse for the same read operation.
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 get_sheet or generate_sheet. The agent is left to guess whether 'list' means enumerate sheet names, enumerate tabs within a spreadsheet, or something else.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Google sheets action: update sheet
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Task-specific details from the objective. |
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. The verb 'update' at least implies a mutation, but the description says nothing about required permissions, what fields can change, reversibility, or side effects on existing sheet content.
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 with no wasted words, but it is under-specified rather than concise — the brevity comes from omitting information rather than from efficient phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description should disclose at least what is being modified and any prerequisite context. Instead it offers only a generic action wrapper over a single vaguely named 'detail' parameter.
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?
There is a single parameter whose schema description coverage is 100% ('Task-specific details from the objective'), so the schema already documents it. The description adds no additional meaning about what 'detail' should contain, which matches the baseline 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description pairs the verb 'update' with the resource 'sheet', which is enough to separate it from create/delete/get/generate siblings by inference. However, the phrasing 'Run Google sheets action: update sheet' is a generic wrapper that restates the tool name rather than stating what is actually updated, so the purpose is only vaguely specified.
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 many siblings (create_sheet, delete_sheet, get_sheet, generate_sheet, converse). No preconditions, alternatives, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
research__conduct-deep-researchresearch__generate-research-reportadmin__abort_scansadmin__assign_x_campaign_accountadmin__create_agent12 fields changedInput schema / properties / x_ld_attention_use_customAdded value: +{
+ "description": "When true, use agent-specific X Leads Discovery public attention (Lane A/B).",
+ "type": "boolean"
+}Input schema / properties / x_ld_like_before_dmAdded value: +{
+ "type": "boolean"
+}Input schema / properties / x_ld_like_daily_limitAdded value: +{
+ "type": "integer"
+}Input schema / properties / x_ld_pool_public_quote_after_dm_failAdded value: +{
+ "type": "boolean"
+}Input schema / properties / x_ld_public_after_dmAdded value: +{
+ "type": "boolean"
+}Input schema / properties / x_ld_public_daily_limitAdded value: +{
+ "type": "integer"
+}Input schema / properties / x_ld_public_onlyAdded value: +{
+ "description": "Cold LD import: public quote/reply only, no DMs.",
+ "type": "boolean"
+}Input schema / properties / x_ld_public_per_run_limitAdded value: +{
+ "type": "integer"
+}Input schema / properties / x_ld_public_post_goalAdded value: +{
+ "enum": [
+ "attention",
+ "check_dm"
+ ],
+ "type": "string"
+}Input schema / properties / x_ld_public_posterAdded value: +{
+ "enum": [
+ "main",
+ "pool"
+ ],
+ "type": "string"
+}Input schema / properties / x_ld_public_surfaceAdded value: +{
+ "enum": [
+ "quote",
+ "reply"
+ ],
+ "type": "string"
+}Input schema / properties / x_ld_quote_targetAdded value: +{
+ "enum": [
+ "engagement",
+ "root"
+ ],
+ "type": "string"
+}admin__invite_agent_collaboratoradmin__list_agent_collaboratorsadmin__remove_agent_collaboratoradmin__update_agent12 fields changedInput schema / properties / x_ld_attention_use_customAdded value: +{
+ "description": "When true, use agent-specific X Leads Discovery public attention (Lane A/B).",
+ "type": "boolean"
+}Input schema / properties / x_ld_like_before_dmAdded value: +{
+ "type": "boolean"
+}Input schema / properties / x_ld_like_daily_limitAdded value: +{
+ "type": "integer"
+}Input schema / properties / x_ld_pool_public_quote_after_dm_failAdded value: +{
+ "type": "boolean"
+}Input schema / properties / x_ld_public_after_dmAdded value: +{
+ "type": "boolean"
+}Input schema / properties / x_ld_public_daily_limitAdded value: +{
+ "type": "integer"
+}Input schema / properties / x_ld_public_onlyAdded value: +{
+ "description": "Cold LD import: public quote/reply only, no DMs.",
+ "type": "boolean"
+}Input schema / properties / x_ld_public_per_run_limitAdded value: +{
+ "type": "integer"
+}Input schema / properties / x_ld_public_post_goalAdded value: +{
+ "enum": [
+ "attention",
+ "check_dm"
+ ],
+ "type": "string"
+}Input schema / properties / x_ld_public_posterAdded value: +{
+ "enum": [
+ "main",
+ "pool"
+ ],
+ "type": "string"
+}Input schema / properties / x_ld_public_surfaceAdded value: +{
+ "enum": [
+ "quote",
+ "reply"
+ ],
+ "type": "string"
+}Input schema / properties / x_ld_quote_targetAdded value: +{
+ "enum": [
+ "engagement",
+ "root"
+ ],
+ "type": "string"
+}admin__update_agent_collaboratorresearch__conduct-deep-researchresearch__generate-research-reportresearch__conduct-deep-researchresearch__generate-research-reportresearch__conduct-deep-researchresearch__generate-research-reportresearch__conduct-deep-researchresearch__generate-research-reportresearch__conduct-deep-researchresearch__generate-research-reportresearch__conduct-deep-researchresearch__generate-research-reportresearch__conduct-deep-researchresearch__generate-research-reportresearch__conduct-deep-researchresearch__generate-research-reportresearch__conduct-deep-researchresearch__generate-research-reportresearch__conduct-deep-researchresearch__generate-research-reportresearch__conduct-deep-researchresearch__generate-research-reportresearch__conduct-deep-researchresearch__generate-research-reportresearch__conduct-deep-researchresearch__generate-research-reportresearch__conduct-deep-researchresearch__generate-research-reportresearch__conduct-deep-researchresearch__generate-research-reportresearch__conduct-deep-researchresearch__generate-research-reportresearch__conduct-deep-researchresearch__generate-research-reportresearch__conduct-deep-researchresearch__generate-research-reportresearch__conduct-deep-researchresearch__generate-research-reportYour own CRM, fully customizable and agent-driven. Start with contacts, companies and a sales pipeli
Agent-native CRM. 25 tools — contacts, deals, sequences, enrichment waterfall, audit log.
AI CRO for Agencies and MSPs: full automatic CRM; multichannel tracking; draft follow-ups.
Telegram-native CRM for agents: contacts, deals, pipelines, campaigns, docs and reports.
Add one secure layer between your agents and this server.
