Tá Rodando

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

Annotations cover the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), and the description adds real behavioral context beyond them: partial-update semantics, that section: null removes the service from a section, that supplying section on a private monitor publishes it to the status page, and that a new URL passes the same validation as criar_monitor requiring confirmar: true on url_failing.

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

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

Dense but front-loaded: the core mutation and partial-update rule come first, followed by edge cases and the sibling routing. Every sentence carries information, though the section/publishing rules are packed tightly enough to require careful reading.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 output schema, the description covers the partial-update contract, the section null/publish semantics, the validation dependency on criar_monitor, and the sibling scope. An agent has everything needed to invoke it correctly.

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

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

Schema coverage is high (83%) so the schema does much of the work, but the description adds meaning not stated in the schema: the null semantics for section and the publishing side effect on private monitors, plus the interaction of confirmar with url_failing. It does not add anything for intervalMin beyond what the schema already lists.

Input schemas describe structure but not intent. Descriptions should explain 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 (altera) and resource (monitor) and enumerates the mutable fields (nome, URL, intervalo, seção), so the agent immediately knows what the tool targets. It also explicitly distinguishes itself from the sibling estruturar_pagina, which owns whole-page edits.

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

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

Gives clear when-to-use context (only sent fields change) and names the alternative (estruturar_pagina) with the condition that selects it (multi-section, ordering, page removal). It also explains the specific edge case of section: null.

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 cover readOnly=false, idempotent=true, destructive=false, and openWorld=false. The description adds rich behavior: slug normalization rules, error codes (slug_taken, reserved_slug, no_page, page_exists, monitor_not_found), monitorIds visibility semantics, and the side effect that the old address stops working. This goes well beyond what annotations provide.

Agents need to know what a tool does to the 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 front-loaded with the main edit operation and then packs necessary detail about creation, errors, and side effects. It is dense but contains little obvious waste; a more scannable structure (e.g., bullets for error codes) could improve it slightly.

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

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

For a complex mutation tool with no output schema, the description covers creation prerequisites, validation rules, error responses, side effects, and return content. It is complete enough for an agent to call it correctly across both update and create paths.

Complex tools with many parameters or behaviors need more documentation. 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 conditional requiredness (name, slug, and monitorIds only required on creation) and slug normalization/character rules that are not fully captured in the schema. monitorIds semantics are partly in the schema, but the description reinforces how ids map to public monitors.

Input schemas describe structure but not intent. Descriptions should explain 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 ('Altera') and resource ('status page pública da conta'), lists the exact editable fields, and explicitly routes section/monitor-list editing to estruturar_pagina. An agent can distinguish this from siblings like estruturar_pagina and ver_conta without opening their 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?

Explicitly describes when it creates versus updates (statusPage null in ver_conta), the required fields on creation, and the alternative tool for sections and monitor list (estruturar_pagina). It also names error conditions and when they occur, leaving little 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?

Goes well beyond the annotations (which only mark it non-readonly, non-idempotent, non-destructive). It discloses the telegram asynchronous connection state (connected:false plus connectUrl/connectGroupUrl), the 24h link validity and the delete-and-recreate workaround, that the channel starts with no monitors, and the 20-channel cap – all material operational 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 purpose is front-loaded and every sentence carries operational weight (telegram flow, link expiry, monitor linkage, account cap). It is a single dense paragraph with some long clauses, but nothing is filler, so waste is minimal.

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

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

There is no output schema, so the description correctly compensates by describing the telegram return shape (connected:false, connectUrl, connectGroupUrl) and how connected:true appears in listar_canais. Combined with the limits and linkage notes, it is complete enough for an agent to call 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 coverage is 100%, so the baseline is 3, but the description adds real meaning: it maps each kind to its expected target (email address vs public webhook URL) and explains that telegram ignores target. That kind-to-target mapping is more than the schema states, though it does not add format/syntax detail for target 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?

States a specific verb and resource ('Cria um canal por onde o time recebe o alerta de monitor caiu/voltou'), making the outcome immediately clear. It also names lifecycle siblings (vincular_canal for linkage, listar_canais for status), so an agent can distinguish this create tool from the related ones.

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

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

Gives strong context on when and how the tool is used: monitors are linked separately via vincular_canal, the 20-channel-per-account cap, and the telegram flow that requires the channel to be recreated after the 24h link expires. It stops short of an explicit 'use X instead of Y' routing statement, so it is clear context rather than full alternative 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?

Adds substantial behavior beyond the annotations: the check interval, the ~30s retry after a failure, marking the service down on the second consecutive failure, private-by-default creation, default notification channels, and named error outcomes (url_failing, plan_limit). This is exactly the operational context the readOnly/idempotent/destructive hints 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?

Front-loads the core purpose and the URL-validation/plan-limit constraints in one dense paragraph; every sentence carries operational information. It is on the heavy side, but no sentence is filler or a restatement of the name.

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

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

With no output schema, the description does the heavy lifting on failure modes (url_failing with reason, plan_limit with upgrade link) and preconditions, which is strong. The success response shape is left unspecified, a minor gap for a create tool.

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

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

Schema description coverage is 100%, so the schema carries the basics (baseline 3). The description still adds meaning not in the schema: the monitor is born private on default channels, `section` affects status page placement, and `confirmar` is tied to the url_failing path.

Input schemas describe structure but not intent. Descriptions should explain 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 ('Cria um monitor HTTP para uma URL pública') and scopes it to public https URLs, which cleanly separates it from atualizar_monitor and pausar_monitor. An agent knows exactly what object is being created 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?

Gives concrete conditions: a failing URL is rejected unless `confirmar: true`, non-existent Tá Rodando addresses and the status page itself are refused, and plan ceilings return plan_limit. It does not explicitly name an alternative sibling or a when-not-to-use case, so it stops short of full 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?

Goes well beyond annotations: describes that omitted sections are deleted, that monitors outside any section revert to private, that the operation is all-or-nothing with a named error (invalid_structure), and that it returns no_page when no status page exists. Annotations only say it is non-read-only, idempotent, and non-destructive – the description adds critical lifecycle and failure semantics.

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

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

Front-loads the core action, then details the full-replacement semantics and error cases. Some sentences are dense (the id/name/rename rules), but all earn their place; a small amount of repetition (structure source mentioned twice) keeps it just under 5.

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

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

Covers the input source, replacement semantics, deletion behavior, rename mechanism, monitor visibility side-effect, validation failure mode, and no-page case. Given no output schema and 100% schema coverage, 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%, so baseline is 3. The description adds value by explaining the semantics of the single 'sections' parameter: ordered list, each section keyed by id or name, rename via id+new name, and that empty list clears the page. It doesn't add format beyond the schema (e.g., maxItems limits) but the behavioral tie-in is useful.

Input schemas describe structure but not intent. Descriptions should explain 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 ('Põe monitores em seções da status page') and distinguishes it from siblings by describing it as the panel's 'Salvar estrutura' action. An agent can tell it apart from configurar_status_page and listar_monitores 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?

Explicitly says it receives the ENTIRE structure, tells where the current structure lives (listar_monitores with section/statusPage), and notes that anything not present is deleted. This is unambiguous when-to-use and how-to-get-inputs 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 already declare readOnlyHint, idempotentHint and destructiveHint=false, so the bar is lower, but the description still adds genuinely non-obvious behavior: webhook URLs come back masked to host only because they are credentials, and Telegram entries expose target=null plus a connected flag and connectUrl. It does not describe pagination or whether other secrets are masked.

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

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

Three tight sentences, front-loaded with the core 'what', followed by the two non-obvious fields (webhook masking, Telegram connected state). No filler and every sentence carries 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?

With no output schema, the description carries the return-shape burden and does well on the tricky fields (masked webhook URL, Telegram target/connected/connectUrl). It still omits the remaining shape an agent may need, such as whether a name/id/type field per channel is present and whether the monitor list is ids only.

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

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

The tool takes zero parameters, so the 4 baseline applies; the description correctly introduces no parameter discussion and instead spends its space on output 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 and resource ('Lista os canais de alerta da conta'), enumerates the channel types covered (email, Slack, Discord, Google Chat, webhook, Telegram), and clarifies it also returns linked monitor ids, distinguishing it from listar_monitores and from the write siblings criar_canal/remover_canal.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 explains what is returned but never says when to call this tool versus alternatives such as ver_conta, listar_monitores, or testar_canal, and gives no prerequisites or exclusions. Usage is only faintly implied by the connected/connectUrl notes; routing guidance is absent.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description layers on genuinely non-obvious behavior: retention rules per window, that 30d/90d omit latency, that the 90d % matches the public status page, and the key anti-misinterpretation that an empty window on a paused monitor is not a downtime. This is exactly the context structured fields cannot supply.

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

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

Front-loads the return shape and then packs retention, paused semantics, and pagination into one dense but well-ordered paragraph with no filler. Slightly telegraphic and compressed, but every clause earns its place.

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

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

For a five-parameter, no-output-schema tool, the description fully covers what is returned (per-check fields and window aggregates), the retention constraints on those values, and the pagination loop. An agent has everything needed to call and interpret it correctly.

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

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

Schema coverage is 100%, so all five parameters are already documented in the schema. The description adds only a restatement of cursor-based pagination and the window concept, without new semantics for periodo, limite, or apenasFalhas, so baseline 3 is correct.

Input schemas describe structure but not intent. Descriptions should explain 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 ('checks anteriores de um monitor') plus the exact return shape (horário, ok/falha, latência, erro, resumo da janela), so an agent knows precisely what it gets. It is clearly historical data, implicitly distinct from status_monitor's current state, but it never names a sibling explicitly, which is what a 5 would require.

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

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

Gives clear context for use: it explains the retention window (8 days for individual checks, summary-only for 30d/90d), the paused-monitor case, and how to paginate with cursor. It does not name alternatives or explicitly state when not to use this tool, so it stops short of a 5.

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 declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description goes well beyond that by decoding the returned fields' semantics (e.g., 'failing' = last check failed but monitor not yet marked down, empty channels = notifies no one, null statusPage = private), which is genuinely useful behavioral context. It stops short of pagination or ordering 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 purpose is front-loaded in the first clause, which is good, but the rest is a single dense run-on sentence packed with nested parentheticals that would be easier to scan as separate sentences or a list.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 input parameters, no output schema, and annotations covering the safety profile, the description carries the return-value burden and handles it thoroughly by explaining each field and its edge cases. It is essentially complete for an agent to call and 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?

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to clarify beyond noting it operates on the whole account scope.

Input schemas describe structure but not intent. Descriptions should explain 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 ('Lista os monitores HTTP da conta'), making clear it lists the account's HTTP monitors. This implicitly separates it from siblings like listar_canais and listar_checks, though it does not 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?

There is no when-to-use guidance, no prerequisites, and no routing to alternatives such as status_monitor or listar_checks. The listing intent is inferable from the name and description alone, but no explicit usage conditions are given.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description adds much beyond them: the 90-day retention window, the sort order, the privacy constraint, the episode open/close semantics, and the meaning of an empty avisos list ('ninguém foi avisado'). This is exactly the extra behavioral context the 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?

Front-loads scope and ordering before the definition and the field inventory, so the most decision-relevant facts come first. The long field enumeration is dense and slightly run-on, but each clause (duration single-source, empty list meaning, null incidente_id) carries non-obvious 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?

There is no output schema, so the description absorbs that burden by enumerating every returned field with semantics (duracao_seg as the single source of duration, avisos channels with enviado/falhou/pendente, incidente_id null = unpublished). Nothing an agent needs to interpret the result is missing.

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

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

Schema description coverage is 100%, with abertas and monitor both documented inline, and the description does not restate or extend those parameter semantics. Baseline 3 applies when the schema carries the full parameter burden.

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

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

States a specific verb and resource (listing occurrences) plus precise scope: monitor occurrences in the last 90 days, most recent first. Defines the domain term 'ocorrência' (opens on the 2nd consecutive failure, closes on recovery or pause), which lets an agent distinguish it from both public incidents and from sibling ver_ocorrencia's single-item view.

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

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

Gives clear context for when this is the right tool: it is the PRIVATE team-only view, explicitly 'not the public incident of the status page', and incidente_id=null signals not-yet-published (implying publicar_ocorrencia). It lacks an explicit routing statement toward ver_ocorrencia for a single occurrence's detail, so it is clear context without full exclusions.

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

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

Goes well beyond the annotations by disclosing concrete side effects: history is preserved, checking stops, no notifications are sent, a plan slot is freed, and the status page shows 'Pausado'. These are exactly the behavioral details an agent needs and are not derivable from destructiveHint=false alone.

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

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

Two tight sentences with the core effect front-loaded and the sibling reference last. Every clause carries distinct information with no padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 single-parameter state-change tool with no output schema, the description covers all relevant effects (history retention, notification suppression, plan-limit impact, status-page state) and the resume counterpart, leaving nothing an agent needs 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?

Only one parameter (id) and the schema already documents it at 100% coverage, including where to obtain the value (campo `id` de listar_monitores). The description adds no additional parameter meaning, 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 verb+resource ('Pausa um monitor') and immediately distinguishes it from the sibling retomar_monitor by naming the counterpart action (resume checking). An agent can tell this apart from retomar_monitor and remover_monitor 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?

Explicitly names the alternative retomar_monitor and its opposite effect, giving clear context for choosing between the two pause/resume tools. It stops short of stating prerequisites or when-not to use it (e.g. versus removing), so it is clear but not fully exhaustive.

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 only say this is a non-read-only, non-destructive, non-idempotent open-world write. The description adds the critical dry-run semantics, the subscriber notification side effect, retroactive creation for already-closed occurrences, and the one-incident-per-occurrence ceiling — real behavioral context the agent cannot get from 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 publishing action and the dry-run/production distinction are front-loaded, then constraints follow. Every sentence carries information: draft fields, gating flag, retroactive case, eligibility, and cardinality — 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?

With no output schema, the description usefully enumerates what the dry-run returns (título, serviço, início, severidade, status, mensagem) and covers the irreversible publish path, eligibility, and cardinality limit. An agent has what it needs to call this correctly on the first try.

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

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

Schema coverage is already 83%, so the baseline is 3. The description earns above baseline by explaining the collective role of titulo/mensagem/severidade/status as overrides to the draft, and by restating the confirmar dry-run switch in operational terms rather than just a field 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+resource: turns an occurrence (ocorrência) into a PUBLIC incident on the status page, and notes that subscribers are notified. This distinguishes it cleanly from siblings like ver_ocorrencia and listar_ocorrencias, which read occurrences rather than publish 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?

Gives explicit conditions: without `confirmar` it only returns a draft and publishes nothing; with confirmar:true it publishes. It also states exclusions ('só vale pra monitor que aparece na status page'; 'uma ocorrência gera no máximo um incidente'). It does not name a sibling alternative, but the when/when-not guidance is strong and actionable.

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 declare destructiveHint=true and idempotentHint=true, so the safety profile is known. The description still adds real value beyond them: it discloses cascade scope (all monitor links, including those created in the panel), the operational effect (alerts stop being delivered through it), and irreversibility.

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

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

Three terse sentences, front-loaded with the action and its blast radius, then consequence, then the irreversibility warning. No padding or redundancy.

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

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

For a one-parameter destructive tool with no output schema and annotations covering the safety profile, the description supplies the cascade and irreversibility context an agent needs. Missing only peripheral details such as permission requirements or what happens to already-triggered alerts.

Complex tools with many parameters or behaviors need more documentation. 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 and schema description coverage is 100%; the schema already explains that `id` is the channel id from listar_canais. The description contributes nothing about parameters, so 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 (apaga) and resource (canal de alerta) plus the deletion scope (all monitor links, including panel-made ones), which distinguishes it from sibling vincular_canal / remover_monitor. It never names a sibling alternative explicitly, so it stops short of full differentiation.

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

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

The description explains the consequences of deleting but gives no when-to-use framing, no prerequisites, and no pointer to an alternative such as unlinking monitors instead of destroying the channel. The agent must infer that this is the tool for retiring a channel entirely.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds real behavioral detail beyond them: the deletion cascades to the linked status page service and the check history, and it is irreversible. It does not cover permissions or confirmation requirements, so it stops short of a 5.

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

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

A single sentence that front-loads the action, then the cascade, then the irreversibility warning. Every clause earns its place with zero 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 one-parameter destructive tool with no output schema, the description covers what is destroyed and that the action cannot be undone, which is the critical information. It lacks only permission/authorization context to be fully complete.

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

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

There is one parameter with 100% schema coverage, and the schema already explains that `id` comes from listar_monitores. The description adds nothing about the parameter, 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+resource ("Apaga um monitor") and goes further by naming the cascading side effects (status page service and check history). An agent can distinguish this permanent-delete tool from siblings like pausar_monitor or remover_canal 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 word "Irreversível" implies this is the permanent-removal path as opposed to pausar_monitor, but the description never names the alternative or states when to prefer one over the other. Usage is inferable rather than explicit.

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 only declare idempotent/non-destructive hints; the description goes further by disclosing the latency consequence ('próximo ciclo do worker, até 30 min') and the plan-limit failure mode (returns plan_limit and the monitor stays paused). This is exactly the kind of operational context annotations cannot carry.

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

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

Three short sentences, zero filler: action first, then timing, then failure behavior. Each sentence delivers distinct information an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 single-parameter state-change tool with no output schema, the description covers the trigger, the async timing, and the error/limit outcome — nothing material is missing 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?

Only one parameter (id) and schema description coverage is 100%, with the schema already explaining that id comes from listar_monitores. The description adds no further parameter meaning, 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+resource ('Retoma um monitor pausado') and explicitly names the inverse operation pausar_monitor, letting an agent distinguish it from siblings such as pausar_monitor, criar_monitor or status_monitor 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 precondition is clear — the monitor must have been paused via pausar_monitor — and the counterpart tool is named, which gives strong routing guidance. There is no explicit 'when not to use' statement (e.g. what to do if the monitor is already active), so it falls just short of a 5.

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 declare read-only, idempotent, non-destructive, so safety is covered. The description adds real behavioral depth: the meaning of monitor.state='failing', the ~30s re-check window, and the escalation to major_outage with team notification on the second consecutive 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?

Front-loaded with the return-field inventory, then drills into the state machine. Dense but every clause carries semantics; only minor redundancy in restating the failure-escalation rule twice.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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, the description correctly carries the return-value burden: it explains lastFailure.message, ocorrenciaAberta, and the monitor.state semantics. An agent can interpret the response without a schema, though it does not cover fields it lists only by name (status, configuração).

Complex tools with many parameters or behaviors need more documentation. 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 explains that id is the 'id de listar_monitores'. The description adds nothing beyond the schema for the parameter, which is the expected baseline 3.

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

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

The description opens with 'Detalhe de um monitor' and enumerates exactly what is returned (status, configuração, último check, ocorrência). It is clearly a single-monitor detail read, distinguishable from listar_monitores, though it never names that sibling 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?

Usage is implied — fetch detail for one monitor by id — and it cross-references listar_ocorrencias for the occurrence object. There is no explicit when-to-use/when-not guidance or routing away from listar_monitores.

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 cover only the safety profile (readOnlyHint=false, idempotentHint=false, openWorldHint=true), while the description adds substantive behavior: a per-channel rate limit with a 60 s wait, and a precise error taxonomy (send_failed, not_connected with the missing connectUrl, provider_error) explaining what each failure means and who caused it. This is exactly the kind of context annotations cannot carry.

Agents need to know what a tool does to the 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 short, front-loaded paragraph: purpose first, then rate limit, then error semantics. Every sentence carries information, though the error clause is dense enough that a slightly more scannable structure would help.

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

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

There is no output schema, so the description carries the return-side burden and does so: success is implied by sending the test, and every failure mode is enumerated with its cause. For a single-parameter tool this is complete enough to invoke and interpret 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?

Only one parameter, and schema description coverage is 100% — the schema already explains 'id do canal (campo `id` de listar_canais)'. The description's 'por canal' phrasing reinforces the per-channel scoping but adds no syntax or format detail 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 states a specific verb and resource: sending the panel's test message through the channel. This is clearly distinct from sibling operations like criar_canal, vincular_canal, or remover_canal, so an agent can pick it out without opening a 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 rate limit ('1 teste por minuto por canal') and the error taxonomy give strong operational context, but the description never states when to reach for this tool versus alternatives (e.g., after criar_canal/vincular_canal) or when not to use it. Usage is implied rather than stated.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description goes further, disclosing edge-case behavior: returning `null` when the account has no page, the meaning of `identityChosen: false`, and the shape of the `onboarding` entries — genuine behavioral context 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?

Every clause describes a returned field, so little is wasted, and the size is defensible given there is no output schema. However, it is delivered as a single dense run-on sentence with nested parentheses and semicolons, which hurts parseability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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, the description must carry the return-value burden, and it does so thoroughly, covering plan, limits, intervals, status page and onboarding. Annotations handle the safety profile, so the definition is close to complete for a no-parameter read tool.

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

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

The tool takes zero parameters, so per the baseline rule a 4 applies. There is nothing for the description to disambiguate on the input side.

Input schemas describe structure but not intent. Descriptions should explain 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 ('Mostra') and resource (the account), and enumerates the concrete data returned — plan, monitor ceiling, check intervals, status page, onboarding. It is distinguishable from the monitor/channel/occurrence siblings, but it never explicitly names what it is NOT, so it falls short of true 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?

No explicit when-to-use or when-not-to-use guidance is given; usage is only implied by the fact that this is the sole account-level tool. An agent can infer it should call this to inspect account state, but nothing in the text frames that context or points to an alternative.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds real behavioral context beyond that: the timeline content, the guarantee that texts match the panel, and notably the retention limit ('falhas individuais só existem enquanto o check cru está guardado (8 dias)'), which warns the agent that failure detail can be absent for older occurrences.

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

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

Two sentences, well front-loaded: first the payload scope and timeline components, then the retention caveat. 'Com os mesmos textos do painel' is slightly decorative but conveys UI-parity, so little 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 no output schema, the description must convey what comes back, and it does enumerate the timeline segments and state parity with the panel. Combined with a single required id and read-only annotations, an agent has enough to call it correctly; only the return format/ordering details are left unspecified.

Complex tools with many parameters or behaviors need more documentation. 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 id parameter is already documented in the schema as coming from listar_ocorrencias. The description adds no extra semantics about the id (format, retrieval path) beyond what the schema 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?

States clearly that it returns the detail of a single occurrence and that the payload equals the fields of listar_ocorrencias plus a timeline (falhas, início, avisos por canal, volta, encerramento, publicação). That implicit contrast with listar_ocorrencias lets an agent separate the two, though it is phrased as a noun ('Detalhe de...') rather than an explicit 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?

Usage is implied: it is the per-occurrence view, taking an id produced by listar_ocorrencias. There is no explicit when-to-use vs when-not statement and no named alternative beyond the implicit link to the listing tool. The 8-day retention note is a useful practical constraint but is not framed as 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?

Annotations already declare idempotentHint=true and destructiveHint=false, so the idempotency claim ('repetir não duplica') reinforces rather than adds. The genuinely new behavioral context is the "all" caveat ('monitor criado depois não entra sozinho') and the return value, which go 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?

Three tight sentences that front-load the purpose, then cover parameter semantics, mutation behavior, and return value. No filler, though the idempotency sentence partially restates the annotation hint.

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

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

Covers purpose, both parameters, the 'all' edge case, additive behavior, and the return value even though no output schema exists. An agent has enough to call 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%, so the baseline is 3, but the description adds real value: it explains the "all" sentinel's time-bounded semantics and the trailing-monitor caveat, which the schema's bare 'Lista de ids de monitor ou "all"' does not convey.

Input schemas describe structure but not intent. Descriptions should explain 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 ('Liga o canal a monitores') and immediately clarifies the effect: alerts flow through this channel when a linked monitor goes down or recovers. This is clearly distinguishable from siblings like criar_canal, remover_canal, and testar_canal.

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

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

Explains how to supply monitorIds (ids from listar_monitores, or "all" for today's monitors) and notes the additive semantics ('Soma aos vínculos que já existem'). It does not explicitly state when not to use this tool or name an unlink alternative, but the usage context is clear.

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