9bot

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

Even though annotations already mark destructive behavior and non-idempotency, the description adds real safety-critical detail: enabling rules can trigger real removal/approval actions, preview never applies changes, simulate only records audit events, events produced are not undone, and confirmation_id must be resent after preview. This is materially useful behavior disclosure beyond structured metadata.

Agents need to know what a tool does to the 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 long but justified by the tool's 18-operation surface. It is visibly structured with labels (Finalidade, Use quando, Operações, Parâmetros, Efeitos) and front-loads purpose before details. Every sentence adds value: none restates the title or repeats the annotation metadata.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 multi-operation tool with nested input schemas, output, and side effects, this description covers the important decision points: when to use the tool, which operations are safe/transit, preview/confirmation flow, whitelist policy, and state/log health after uncertain outcomes. The presence of an output schema reasonably covers return-value documentation.

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

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

Schema description coverage is 100%, so the schema already documents the parameters. The description adds meaning by clarifying that config is a patch that preserves omitted fields, active/enabled behave equivalently, cross-field parameter groups are representative (maxMessages/timeWindow, applyToAdmins, RSS fields), but it does not explain every nested field individually. That is acceptable because the schema handles the details.

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

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

The description opens with an explicit purpose: 'configurar regras automáticas de boas-vindas, antispam, links, RSS, aprovação, remoção e permanência'. It names the verb, the resource, and the specific rule families, and it distinguishes itself from sibling tools like participants_manage, schedules_manage, and workflows_design.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 'Use quando' clause gives a clear trigger condition (the bot must react continuously to group events) and explicitly names alternatives with the contexts where they should be chosen instead. The operational mapping (which operations query, which update, which validate, which only preview) further guides correct invocation.

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

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

Annotations provide readOnlyHint=false, destructiveHint=true, idempotentHint=false. The description goes well beyond these: it discloses which operations mutate state, that create is non-idempotent and may duplicate triggers, that test_api consumes quota via external calls, that delete doesn't erase already-delivered responses, preview never applies changes, and gives explicit error-handling guidance (401/403, 429, timeout) plus the confirmation flow. No contradiction with annotations.

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

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

Long but well-structured with labeled sections (Finalidade, Use quando, Escolha da operação, Parâmetros, Efeitos e falhas) that front-load purpose and usage. The length is justified by 28 conditional operations; each section earns its place, though the operation enumeration is dense and could arguably be trimmed.

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

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

Comprehensive for a highly complex tool: purpose, usage routing, operation selection, parameter semantics, effects/failure modes, preview behavior, and confirmation flow are all covered. An output schema exists, so return-value explanation is unnecessary. Nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100% (operation and input both have descriptions), so baseline is 3. The description adds genuine value: trigger is the exact typed text, response_content is the response or config, id comes from list/get, update takes only the patch while reorder takes the full revised order, and password fields are sensitive and only used by their own operation. These semantics go beyond the schema.

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

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

The description opens with a clear purpose statement: 'administrar comandos que respondem quando uma pessoa digita um trigger no grupo' – a specific verb (administrar) plus resource (comandos com triggers). It names the two closest siblings (automations_configure, workflows_design) and explains what distinguishes them, so an agent can select this tool without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 'Use quando' section states the condition (explicit command text) and gives explicit exclusions with named alternatives: automations_configure for automatic reactions, workflows_design for multi-step processes. The 'Escolha da operação' paragraph further routes between the 28 operations, leaving nothing to inference.

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

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

Annotations already provide destructiveHint/readOnlyHint context, but the description substantially exceeds them: pages_create is draft-by-default, update may silently republish an offline page, preview never applies changes, deletes are irreversible 'nesta API', accepting transfer changes ownership, and failed operations should be re-checked before retry. It also adds an anti-prompt-injection briefing (HTML/CSS is user content, not an instruction), which goes far beyond any structured annotation. Nothing contradicts the annotations.

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

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

Organized with clear headings (Finalidade, Use quando, Operações, Parâmetros, Efeitos) and front-loaded, so it is skimmable and every sentence carries operational weight. It is long, and the Parâmetros section overlaps somewhat with the schema's own guidance ('envie somente os campos solicitados...'), keeping it short of a perfect score.

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

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

For a 17-operation bundle spanning pages, subdomains, transfers, destructive deletes, confirmation flows, and sensitive codes, the description is remarkably complete: it covers purpose, alternatives, parameter semantics, side effects, failure recovery, and trust boundaries. An output schema exists, so return-value shape doesn't need explanation, and the remaining specifics are handled by the schema's conditional structure.

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

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

Schema description coverage is 100%, so the baseline is 3; the description earns more by explaining which identifiers to use (pageId/subdomain from query responses), the status=draft vs status=published semantics, preview=true being non-applying, and the confirmation_id resubmission flow — all meaning the bare schema cannot convey. It does not, however, fully map each of the 17 operations to its exact required inputs, leaving some of that to the conditional schema, so not a 5.

Input schemas describe structure but not intent. Descriptions should explain 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 ('administrar páginas públicas e subdomínios da comunidade') and then enumerates all 17 operations grouped by query vs. mutation vs. transfer, so an agent understands both the scope and the internal operation families. It also names workflows_design and workflows_connections_manage as the siblings it is not, which is exactly the differentiation needed in this large sibling list.

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

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

Provides an explicit when-to-use condition ('tarefa envolver conteúdo ou endereço público da comunidade') and explicitly routes staged publication automation to workflows_design and external connections to workflows_connections_manage. It also gives in-tool guidance on when to use preview versus the real mutation ('ela nunca aplica a mudança').

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

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

The description clearly distinguishes read-only operations from mutating ones: 'Consultas são somente leitura. Atualizações e exclusões não são idempotentes.' It also warns that apply settings can replace configurations and create synchronization, and that deletes remove links. This goes beyond the schema's basic field hints, though it could elaborate a bit more on side effects of template application.

Agents need to know what a tool does to the 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 concise and organized into labeled segments (Finalidade, Operações, Parâmetros, Efeitos). It front-loads the core purpose and operation list vivamente. A minor deduction because the parameter guidance is dense and could be split, but overall it is efficient and readable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 description is exceptionally complete: it explains the purpose, when to use it, the operations available, key parameter guidance, the read-only vs. mutating nature, the non-idempotency of deletes, and the preview behavior with confirmation. The presence of a structured output schema further fills in the return expectations, so nothing essential is missing.

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

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

The description adds high-value meaning beyond the schema. It tells the agent to use the groupJid returned by list, explains that moderationWhitelist includes administrators, clarifies that settings_update sends only the necessary patch, and explicitly states preview 'nunca aplica a mudança' (never applies the change). This meaningfully supplements the raw schema fields.

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

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

The description opens with 'Finalidade: localizar grupos e administrar dados próprios do grupo' (purpose: locate groups and manage group-specific data), which clearly states the tool's scope. It enumerates the exact operations: consulting groups, and configuring administrators, preferences, notes, or templates. This distinguishes it from other tools managing people/sanctions or automations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 explicitly names sibling tools and their domains: 'Para pessoas e sanções use automations_configure; para a conta use settings_manage.' It also says for people and sanctions use automations_configure, and for the 9bot account use settings_manage. This gives an agent clear routing criteria to choose this tool versus alternatives.

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

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

Annotations declare readOnlyHint=false, destructiveHint=true, idempotentHint=false, openWorldHint=true. The description adds substantial behavioral context beyond these: OAuth/credentials require account authorization, send_test and routes generate external messages and consume quota, delete/disconnect prevents future actions without deleting past messages, error handling for 401/403/429/timeout, and preview semantics (preview=true never applies changes, confirmation_id must be repeated). This is rich, non-obvious behavioral disclosure that goes well beyond the annotations.

Agents need to know what a tool does to the 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 dense but well-organized into labeled sections (Finalidade, Use quando, Escolha da operação, Parâmetros, Efeitos e falhas). It front-loads the purpose and usage. It is long, but the tool is a multi-operation dispatcher with 26 operations, so the length is justified. A small deduction for density: the operation list is a bit compressed and could be slightly more scannable, but overall every sentence earns its place.

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

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

Given the tool's complexity (26 operations, nested input schemas, output schema present, annotations present), the description is remarkably complete. It covers purpose, operation selection, parameter semantics, side effects, error handling, preview/confirmation flow, and credential safety. The output schema exists, so return values don't need to be described. Nothing critical is missing for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents parameters. The description adds meaning by explaining the semantic role of key identifiers: 'groupJid é o grupo WhatsApp de origem ou destino; channelId é o canal Discord retornado por channels_list; routeId identifica a rota retornada por routes_list; alertId identifica a regra retornada por live_alerts_list.' It also clarifies that update receives patch, toggle receives enabled, and warns never to copy credentials into text/logs. This adds value beyond the raw schema.

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

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

The description opens with a clear purpose: 'consultar integrações nativas e operar encaminhamento Discord ou alertas de transmissões ao vivo.' It names the specific resources (Discord forwarding, live alerts, WhatsApp groups) and distinguishes itself from sibling tools by explicitly naming workflows_connections_manage, groups_manage, and messages_manage as alternatives. The operation list further clarifies the scope.

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

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

The description provides explicit when-to-use guidance: 'Use quando: precisar conectar Discord, encaminhar mensagens entre um grupo WhatsApp e um canal, ou avisar um grupo sobre uma live.' It also gives explicit exclusions: 'Para CRM/API arbitrária use workflows_connections_manage; para configurar o grupo use groups_manage; para envio comum use messages_manage.' This is exactly the kind of routing an agent needs.

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

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

The description reveals important behavioral nuances beyond the annotations: pending/running status does not prove external effect, cancel does not undo completed work, retry may repeat effects and is not idempotent, and access is restricted to the connection owner. It also clarifies that preview never applies changes and that confirmation requires repeating the operation with confirmation_id. This aligns with destructiveHint=true and goes far beyond the structured metadata.

Agents need to know what a tool does to the 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 compact but information-dense, organized into clear segments: purpose, usage, operations, parameters, effects, and preview/confirmation. Every sentence contributes actionable guidance with no filler or redundancy. The key differentiators and safety cautions are front-loaded.

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

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

Given the multi-operation conditional schema, the description covers all necessary context: operation selection, parameter requirements, ownership restrictions, destructive side effects, timeout handling, and the preview/confirmation workflow. With an output schema present, the description does not need to describe return values. It is complete enough for correct invocation across all four operations.

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

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

Schema description coverage is 100%, but the description adds crucial semantic guidance: use the jobId returned by list/get, send only the parameters for the chosen operation, and consult get before cancel/retry. It also explains the preview and confirmation_id flow, which the schema alone does not make clear. This materially improves the agent's ability to invoke each operation correctly.

Input schemas describe structure but not intent. Descriptions should explain 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 tool's purpose precisely: 'consultar e controlar tarefas assíncronas criadas pelo transporte MCP' (query and control async tasks). It further differentiates from siblings by directing runId-based executions to workflows_runs_manage and workflow starts to workflows_execute. This clearly identifies the resource and operations (list/get/cancel/retry) without ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 explicit when-to-use guidance: use it when you have a jobId from an MCP operation, and use workflows_runs_manage for runId-based operations. It also offers operational guidance, such as consulting get before cancel or retry, and repeats the same operation with confirmation_id after preview. This actively routes the agent to the correct alternative and prevents misuse.

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

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

The description goes well beyond the annotations, which already indicate non-readonly, non-idempotent, and destructive behavior. It explains that sends are external and repeating can duplicate, delete depends on the bot's current permission, 401/403 require reviewing access, 429 requires respecting Retry-After, timeout does not prove absence of effect, and preview never applies the change. It also details the confirmation_id flow. This is exactly the contextual behavioral information that structured annotations cannot convey.

Agents need to know what a tool does to the 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 well-structured with labeled sections (Finalidade, Use quando, Escolha da operação, Parâmetros, Efeitos e falhas) and front-loads the purpose. Every sentence delivers distinct operational, safety, or failure-handling information with no filler or repetition. The length is proportionate to the tool's complexity of 10 operations and nested conditional inputs.

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

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

Given the tool's high complexity, an output schema, and rich annotations, the description covers purpose, alternatives, operation selection, parameter provenance, failure handling, rate limits, timeouts, preview behavior, confirmation flow, and destructive effects. Nothing essential to correct invocation appears missing; return-value details are appropriately left to the output schema.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful guidance: messageId, groupJid, and participants must come from authorized queries; list uses period/search/limit-offset; poll_send expects question/options; reply needs the source message; broadcast_send should reuse the preview-reviewed selection; and confirmation_id must accompany confirmation. This aids correct parameter use, but it does not exhaustively describe every nested field (e.g., buttons, recurrencePattern), which is acceptable since the schema handles those.

Input schemas describe structure but not intent. Descriptions should explain 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 tool's purpose explicitly: consult accessible message history and perform immediate sends or deletions to authorized destinations. It enumerates the specific operations (list, get, broadcast_preview, send/reply/admins_send/buttons_send/poll_send, broadcast_send, delete) and differentiates from siblings such as schedules_manage, workflows_design, and integrations_manage. This is a specific verb+resource with clear sibling differentiation.

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

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

A dedicated 'Use quando' section says when to use this tool (search/read messages or deliver now) and explicitly routes other scenarios to siblings: future delivery to schedules_manage, multi-step processes to workflows_design, live alerts to integrations_manage. It also provides per-operation selection guidance, so the agent knows exactly when and how to choose the right operation. This is explicit and leaves no ambiguity.

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

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

The description goes well beyond the annotations by warning that some mutations can trigger external punishment and are not idempotent, that global entries are not removed by a group action, and that after a timeout the participant, report, and logs should be rechecked before retrying. It also clarifies preview semantics and the confirmation flow, giving the agent concrete safety context beyond destructiveHint and idempotentHint.

Agents need to know what a tool does to the 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 organized into labeled sections and front-loads purpose and routing before operation details. For a domain supporting 29 operations and nested conditional inputs, the length is justified and every sentence adds operational value.

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

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

Given the large operation surface, the description covers purpose, sibling routing, operation grouping, read-before-write ordering, parameter caveats, side effects, retry behavior, preview, and confirmation. The presence of an output schema means return-value detail is not required from the description, so nothing essential is missing.

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

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

Even though the input schema has descriptions for operation and input, the description adds non-obvious parameter guidance: use identifiers returned by queries, never convert LID to phone, moderation_whitelist_remove expects the line id, stillExempt=true means another exemption remains valid, and preview/confirmation require repeating the same operation with confirmation_id. This materially improves correct parameter usage.

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

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

The description opens with a clear purpose: consulting people and administering presence, roles, whitelist, warnings, reports, strikes, and punishments in authorized groups. It uses a concrete verb-resource pair and explicitly names sibling tools for adjacent domains, so an agent can distinguish this tool from groups_manage, automations_configure, and reports_manage.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 'Use quando' section states the trigger condition (target is a person or moderation record) and gives explicit alternatives for group preferences, automatic rules, and aggregate metrics. It also provides sequencing guidance: list/search/get must precede actions, which is exactly the kind of when-to-use instruction an agent needs.

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

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

The description discloses side effects in detail: queries/generations don't send messages, exports may update analytical state, admins_send is non-idempotent and can duplicate, timeout requires checking logs before retry, preview never applies changes, and confirmation_id must be reused. This adds significant context beyond the annotations (destructiveHint, idempotentHint) and covers the full behavioral profile.

Agents need to know what a tool does to the 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 structured with clear sections (Finalidade, Use quando, Operações, Parâmetros, Efeitos) and is front-loaded with purpose. It is long but each sentence carries useful information, making it appropriately sized for a tool with 22 operations and complex schema. Slightly verbose but efficient.

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

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

For a complex multi-operation tool, the description covers purpose, usage, parameter guidance, and effects thoroughly. It omits per-operation details (left to the schema's enum) but provides sufficient high-level mapping and safety caveats. Given the output schema exists, return format is not needed. Overall, it is complete enough for an agent to invoke correctly.

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

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

The description explains key parameters: groupJid selects the group, period/filters/limit-offset define the scope, hot_topic_details uses identifiers from hot_topics, and settings updates should only include changed fields. This adds meaning beyond the schema, which has limited descriptions. However, not every parameter is explained, so it's not a perfect 5.

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

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

The description clearly states the tool's purpose: concentrating analytics, metrics, forecasts, reports, PDFs and summaries for groups. It explicitly differentiates from siblings by naming alternatives (messages_manage for single messages, workflows_design/schedules_manage for recurring delivery), so an agent can distinguish when to use this 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?

Provides explicit 'Use quando' guidance, lists when not to use (alternatives), and categorizes operations into analytics, content preparation, export, and settings. It also explains the confirmation flow and preview behavior, giving clear conditions for when to use specific operations.

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

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

Annotations already indicate destructiveHint=true, but the description goes further: clarifies delete is destructive, create doesn't prove delivery, pause/delete don't undo past deliveries, timeout handling to avoid duplication, preview never applies changes, and confirmation flow via confirmation_id. This adds substantial behavioral context beyond annotations.

Agents need to know what a tool does to the 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 organized into labeled sections (Finalidade, Use quando, Operações, Parâmetros, Efeitos) and front-loads purpose and usage. Every sentence adds value; no redundancy with schema or annotations. For a tool with 13 operations, this length is justified and focused.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 high complexity (13 operations, conditional schemas), the description covers purpose, usage, operation semantics, parameter constraints, effects, preview/confirmation, and idempotency guidance. The output schema exists, so return values needn't be described, and nothing critical for correct invocation is missing.

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

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

Schema already has descriptions for several parameters (groupJid, message, scheduledTime), and the description adds meaningful constraints: scheduledTime requires explicit timezone, recurrencePattern defines recurrence, activate=true is required for activation, and target groups must be authorized. These complement the schema and clarify usage semantics.

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

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

The description opens with 'Finalidade: programar e administrar entregas futuras de mensagens e enquetes', which is a specific verb+resource statement. It further distinguishes itself from messages_manage (immediate send) and workflows_design (multi-step), making sibling differentiation explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 'Use quando' section states exactly when to use this tool (delivery later or repeated) and explicitly contrasts with immediate sends and multi-step workflows. It also lists operation categories and when to use preview/confirmation, providing comprehensive routing guidance.

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

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

The annotations include destructiveHint=true, and the description expands on this by warning that removing an administrator is destructive and may revoke the user's own access depending on authorization rules. It also explains that changes affect future account operations, not just the current workflow, and that preview mode never applies changes. This adds behavioral context beyond the annotations, though it does not cover all nuances (e.g., rate limits) but the bar is lower given the annotations.

Agents need to know what a tool does to the 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 well-structured with clear sections (Finalidade, Use quando, Operações, Parâmetros, Efeitos) and front-loads the purpose and usage. It is concise given the tool's complexity, though it could be slightly shorter by merging some operational details. Overall, every section earns its place.

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

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

Given the tool's complexity (6 operations, nested input schemas, output schema present) and the rich descriptions in both schema and description, the description covers all critical aspects: how to select operations, use parameters, handle preview and confirmation, and manage destructive effects. With an output schema present and comprehensive guidance, nothing essential is missing for correct usage.

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

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

The schema provides descriptions for the operation and input parameters, with 100% coverage. The description adds meaning by explaining specific parameter semantics: prefix defines the command prefix, mode defines response behavior, timezone must be an IANA timezone and changes time interpretation, and admins_remove uses the identifier returned by admins_list. This complements the schema and helps agents use parameters correctly.

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

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

The description clearly states that the tool's purpose is to query and modify global preferences and account administrators for 9bot. It specifies the resource (account settings) and the verb (consult/alter), and distinguishes it from sibling tools by explicitly naming alternatives for group preferences, WhatsApp roles, and detectors. This exceeds a mere restatement of the name.

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

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

The description provides explicit usage guidance: when the configuration belongs to the account, use this tool; for group preferences, use groups_manage; for WhatsApp role/presence, use participants_manage; for detectors, use automations_configure. It also lists all operations and their purposes (consulting vs. altering). This is highly actionable and leaves no ambiguity.

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

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

Beyond the read/write and destructive hints, the description discloses non-obvious effects: revoke only prevents new use, run only enqueues and does not prove completion, import_openapi creates a local draft without calling the API, and preview=true never applies the change. It also specifies confirmation_id/requestId reuse semantics for retries. No contradiction with annotations 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?

Labeled paragraphs (Finalidade, Use quando, Operações, Parâmetros, Efeitos) make a long description scannable. Each sentence contributes a distinct fact, and the most important selection and safety information is front-loaded.

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

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

For a tool with 12 operations and a conditional nested schema, the description covers operation classification, side effects, idempotency, preview, confirmation, and security constraints. Because an output schema exists, return-value details do not need to be restated, and the remaining invocation details are left to the richly annotated schema.

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

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

The schema already covers the top-level operation/input pair, so the baseline is 3. The description adds useful rules: obtain connectionId and revisions via list, sharingOnly=true changes only shares and requires the current revision, and run's stable requestId makes repetition idempotent. It does not fully explain all profile-creation fields, and the blanket 'never send token/secret' warning sits awkwardly with the schema's secrets field, so it is not a 5.

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

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

The description states a concrete purpose: administrar conexões de APIs/CRMs e perfis de sincronização usados por Workflows. It then enumerates the operation groups (list/consult, import_openapi, write/revoke, crm_sync_profiles), making the tool's scope concrete. Named sibling tools (workflows_design, workflows_runs_manage) further separate it from adjacent domains.

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

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

Use quando gives explicit triggers: external account, protected credential, sharing, CRM sync. It also names alternatives: workflows_design for designing steps and workflows_runs_manage for execution cycles. This is direct when-to-use and when-not-to-use guidance.

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

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

Annotations declare readOnlyHint=false, destructiveHint=true, openWorldHint=true, idempotentHint=false. The description adds valuable behavioral context beyond those flags: creations remain inactive by default, layout changes don't affect execution, simulate/preview don't prove external delivery, dynamic_tools_invoke may have side effects, and preview never applies changes. It also explains the confirmation_id flow. The only minor gap is that it doesn't explicitly warn about the destructiveHint=true annotation, but the description's warnings about side effects and confirmation cover the spirit. No contradiction.

Agents need to know what a tool does to the 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 dense but well-structured with labeled sections (Finalidade, Use quando, Operações, Parâmetros, Efeitos). Every sentence carries operational value. It loses one point because it is long and packs many distinct behaviors into a single paragraph in the Efeitos section, which could be slightly more scannable. Overall, it earns its length given the tool's 23-operation complexity.

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

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

For a tool with 23 operations, 18 input schemas, and an output schema, the description is remarkably complete. It covers operation categories, parameter selection, side effects, confirmation flow, preview semantics, and sibling routing. The output schema exists, so return values need not be described. Nothing an agent needs to call this tool correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful parameter semantics beyond the schema: it explains intent as the objective, template/composition as the base, groupJid as the group delimiter, followProductLinks as product resolution control, and instructs to use returned ids/revisions and send only changed nodes. It also explains activate=true requires explicit authorization and preview=true never applies changes. This is above baseline because it gives selection and usage guidance for the most consequential parameters.

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

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

The description opens with a clear purpose: 'descobrir capacidades e criar, compor, editar, versionar, validar ou simular definições de Workflow' — a specific verb set and resource. It explicitly distinguishes design-time work from execution-time work and names sibling tools (workflows_connections_manage, workflows_execute, workflows_runs_manage) that handle other phases. This is a model of purpose 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?

The 'Use quando' section is explicit: use for design, not execution; for external accounts use workflows_connections_manage; for publishing/activating use workflows_execute; for monitoring use workflows_runs_manage. It also groups operations by intent (consult vs. alter vs. validate vs. simulate), giving an agent clear routing guidance. This exceeds the minimum viable bar.

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

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

Beyond the annotations, the description adds critical behavioral context: all operations except runtime_status alter state, run_now and external retry are not idempotent, disable/rollback/archive/cancel do not undo completed effects, delete is irreversible, and preview never applies a change. These details substantially expand on readOnly=false, destructiveHint=true, and idempotentHint=false.

Agents need to know what a tool does to the 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 long but tightly organized with labeled sections: Finalidade, Use quando, Operações, Parâmetros, and Efeitos. The purpose and usage guidance are front-loaded, and every added sentence conveys a necessary constraint or behavioral note for a complex multi-operation 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 the complexity of nine operations and a conditional input schema, the description is remarkably complete. It covers all operations, parameter constraints, state-change expectations, idempotency caveats, conflict handling, preview behavior, and confirmation flow. The existence of an output schema reduces the need to describe return values.

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

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

The schema already documents parameters, and the description still adds valuable constraints: expectedRevision must match the consulted revision, deploy only activates with activate=true, rollback may receive versionId, and delete_permanent requires an archived flow, exact confirmationName, and current revision. It does not explain every parameter such as reason or payload, but the schema coverage is high and the description covers the operation-specific rules that matter 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?

The description states a specific purpose: publishing versions and operating the executable lifecycle of an existing Workflow. It also names the two relevant siblings, workflows_design and workflows_runs_manage, which clearly differentiates this tool from create/edit and execution-tracking tools.

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

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

The description explicitly says to use this tool when the design has already been validated, and gives direct alternatives: use workflows_design to create/edit and workflows_runs_manage to follow an execution. This leaves no ambiguity about when this tool should be selected.

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

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

The description adds substantial behavioral detail beyond the annotations: it explains retry can create a new execution, cancel does not undo completed effects, statuses like pending/queued/running do not prove completion, and preview=true never applies the change. Although idempotentHint=false, the description carefully qualifies idempotency (same accepted request vs. retrying a new run), adding useful nuance rather than a flat contradiction.

Agents need to know what a tool does to the 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 organized into labeled sections (Finalidade, Use quando, Operações, Parâmetros, Efeitos) and is front-loaded with purpose and usage. Despite covering many operations, every sentence has a distinct role: routing, operation-mapping, parameter guidance, or effect/safety behavior. There is no filler.

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

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

For a multi-operation tool with 10 operations and an output schema, the description is heavily complete: it provides operation semantics, parameter use, preview/confirmation flow, failure/timeout guidance, and cancellation effects. The main residual gap is that generic list filtering fields such as limit/statuses/profileId from the schema are left to the agent to discover from the schema, but the high-value acceptance-specific semantics are already covered.

Complex tools with many parameters or behaviors need more documentation. 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%, but the description enriches parameter meaning beyond the schema: it tells the agent to reuse IDs and revisions from queries, says resume requires requestId, generation, and the checkpoint revision shown in preview, and clarifies that crm_sync_retry uses a stable requestId and current profile revision. This goes beyond what the raw input schema captures.

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

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

The description opens with an explicit purpose statement: 'consultar e controlar execuções de Workflow e ciclos de sincronização CRM já existentes.' This is a specific verb+resource+scope statement, and it is immediately distinguished from sibling tools like workflows_design (editing flows) and workflows_execute (starting/publishing flows).

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 a clear trigger condition ('Use quando: já houver runId ou syncRunId') and explicitly redirects to three alternatives: workflows_design, workflows_execute, and workflows_connections_manage. It also distinguishes the operations within the tool (consult vs. resume vs. retry vs. cancel), so an agent gets explicit routing guidance.

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