hookpulse

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

No annotations are provided, so the description carries the full burden. It only states what the tool is, not what it returns, whether it requires authentication, or whether it is a read-only listing. The simplicity of an index suggests safety, but this is not explicitly disclosed.

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

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

A single, direct sentence with no filler. The key identifying phrase 'Full index of the HookPulse API' is front-loaded and contains the essential information without waste.

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 zero parameters and no output schema, the description is not deeply inadequate, but it leaves the agent wondering what 'index' means in practice: a JSON list of endpoint names, a documentation object, or a status summary. More detail on the shape or contents would make the tool fully self-explanatory.

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

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

The tool has zero parameters, so the baseline is 4. The description need not add parameter-level detail because there is nothing to configure. No gap exists here.

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

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

'Full index of the HookPulse API' clearly identifies the tool as providing a comprehensive index of the API, with a specific resource named. It does not explicitly distinguish itself from sibling tools like list_endpoints, so it misses the top score for 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?

The description gives no guidance on when to use api_index versus the many sibling tools. It does not mention that this is the tool to start with for an API overview, nor does it exclude 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?

No annotations are present, so the description carries the burden. It discloses that the value is 'IN FORCE, not the documentation's', explains the 'trial' field, and mentions session-dependent state. It does not explicitly state side-effect-free behavior or describe possible errors, but it does add meaningful behavioral nuance.

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, dense with useful context, and the actionable instruction is placed second. The wording is slightly cryptic ('x402 prices', 'usage paywall', 'monitor') but not padded or redundant.

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

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

For a parameterless tool with no output schema, it covers the core billing and trial semantics needed to interpret results. It does not describe the actual response payload, error behavior, or how this tool differs from sibling 'pricing', leaving some uncertainty.

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

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

The input schema has zero parameters, so there is nothing to explain. The description compensates by clarifying domain concepts and field semantics, such as the 'trial' field, which is appropriate for a parameterless tool.

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 never states an explicit verb such as 'returns' or 'gets'; it reads as a definition of the billing model and a usage hint. It is clear the tool is a read/check operation, but the mix of pricing information could confuse an agent choosing between 'billing' and 'pricing'.

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 an explicit condition: 'Check before creating the second monitor or lowering the interval'. This is concrete and actionable. It does not name alternatives or exclusions, but the trigger context is sufficient.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It states that no captcha, account, or payment is required, describes a 10-second queued rate limit per network, explains that earlier messages wait and then send without error, and says the message reaches the team by e-mail with `email` as the reply address.

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 repetitive: 'Free, no captcha and no payment' and the 10-second queuing rule appear twice in nearly identical wording. It is front-loaded with the core purpose, but the redundancy makes it longer and less efficient than it should be.

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

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

The tool has no annotations and no output schema, but the description covers the purpose, recipient, reply address, constraints, rate-limiting/queue behavior, and conditional proposal path. Minor omissions such as expected validation errors or response shape are not critical for a contact-form-like tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds some useful context around `tipo` and the proposal flow, but most parameter-level meaning is already provided by the schema descriptions. It does not substantially expand parameter semantics 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 precise action and target: 'Write to the people behind the product: a question, or a sponsorship/partnership/advertising proposal.' This makes the tool's purpose clear and distinguishes it from the unrelated sibling tools without relying on the generic name 'contact'.

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

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

The description explicitly states when to use the tool: for questions, sponsorship, partnership, or advertising proposals. It also explains the conditional proposal route via `tipo` and `GET /api/partners`. It does not mention exclusions or alternative tools, but no sibling tool is a direct alternative.

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

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

With no annotations, the description carries the full behavioral burden and does it well: duplicate device+measurement returns the existing stream, profiles only add compatible measurements, collections are capped at 200 per owner, and the signed collection id is scoped to its own stream. It also reveals that the environment's saved name and group are authoritative, which is a non-obvious precedence rule.

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 and front-loaded, with each of its seven sentences contributing a distinct fact: prerequisite, idempotency, authority, profile behavior, limit, and stream isolation. The prose is efficient, though the final 'signed collection id' phrase is cryptic and would benefit from a brief clarification.

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

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

Given no output schema and no annotations, the description is unusually complete: it explains prerequisites, mutation behavior, idempotency, limits, and parameter precedence. The main residual gaps are the unspecified create-success return format and the under-explained 'signed collection id' mechanism.

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 met. The description adds meaningful semantic details beyond the schema: environment's saved name and group are authoritative, and the same device+measurement combination is reused rather than duplicated, which clarifies how nome, medida, and ambiente_id interact.

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

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

The description opens with a specific action ('Adds compatible measurements') tied to a previously detected device, and immediately gives the required prerequisite: 'First create /api/ambientes and submit its environment report.' This distinguishes it from environment-creation tools, though 'compatible measurements' is not expanded and the 'collection' being created is only implied.

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

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

The description gives a clear workflow: the environment must already be detected, and the caller must reference its ambiente_id because the environment's saved name and group are authoritative. It does not explicitly name sibling alternatives such as list_collections or update_collection, but the conditions for using this tool are clear.

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

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

With no annotations, the description carries the full behavioral burden and handles it thoroughly: ownership checks, server-chosen IDs, hash-only auth, encrypted saved setup, non-expiring credentials, rotation side effects, paused-channel behavior, and the fact that DNS never authenticates. This is exemplary disclosure for a mutation tool.

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

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

The description is front-loaded with a clear purpose and every sentence carries relevant behavioral or security information. It is slightly verbose and dense, but for a security-sensitive create/rotate tool, the length is justified.

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 complete enough despite no annotations and no output schema: it explains prerequisites, response contents, credential lifecycle, rotation consequences, and persistence behavior. An agent has sufficient context to invoke the tool correctly and anticipate side effects.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful parameter-level context: resubmitting for the same collector rotates the credential and replaces monitoring with the submitted list. This clarifies how the monitoring and collector parameters affect state beyond their schema descriptions.

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

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

The description states a specific verb and resource: 'Create or rotate an authenticated collector channel for this device.' It also clarifies the dual purpose—creation and rotation—which distinguishes it from sibling tools like delete_device_input or get_device_input_setup.

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 clear context for when to use the tool, especially that a repeated call rotates the credential and edits the monitored scope. It does not explicitly name alternatives or say when not to use it, but the create/rotate/read/delete boundaries are inferable from sibling names and the described behavior.

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

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

With no annotations, the description carries the full burden and does so extensively: it discloses 402 billing responses, the one-time visibility of token and templates, alert throttling rules, the free-minimum interval cost, and the distinct failure mode caught by max_duration_sec. This goes well beyond a generic 'creates a resource' statement.

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 content is dense and mostly valuable, but the cron-versus-interval guidance appears twice in nearly equivalent wording, and billing, response, and alerting details are packed together without clear structure. It is informative but less concise and scannable than it could be.

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 12-parameter creation tool with no annotations and no output schema, the description covers the critical behavior: mode selection, billing, alert throttling, and the must-keep response fields. It is not fully complete because the required guest_token parameter is never explained and the general success/error response shape is not described.

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 92%, so the baseline is 3, but the description adds substantial decision-level meaning: cron/tz/grace_sec versus interval_sec, the concrete 03:00 backup example, max_duration_sec's role in catching hangs, and alert_repeat_sec's interaction with the 24h default. It turns raw parameters into operational choices.

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?

Opens with a specific verb and resource: 'Creates a dead-man endpoint.' This clearly differentiates it from sibling operations like delete_endpoint, get_endpoint, and list_endpoints. The rest of the description clarifies that an endpoint is a monitor with either scheduled or silence-detection behavior.

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

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

The description gives explicit mode-selection guidance: use cron+tz+grace_sec for a real schedule, interval_sec for silence detection, and max_duration_sec for hanging runs. It also states the free-tier/billing condition and the 'pay and repeat' path. It does not explicitly compare this tool to sibling create_* tools, but the within-tool parameter guidance is strong.

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

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

With no annotations provided, the description takes on the full disclosure burden. It clearly states the 25-per-owner quota, that the UUID is a one-hour discovery capability and not a telemetry credential, and that the checks 'only display allowlisted system facts and install nothing.' It doesn't mention reversibility or permissions, but it is far more transparent than typical for this tool type.

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

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

The description is three sentences, front-loaded with the core action and scoping limits. The sentence about passos.posix/passos.powershell is cryptic and references a parameter that does not exist in the schema, which costs a point; otherwise 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 no output schema and no annotations, the description covers purpose, owner quota, UUID semantics, and non-invasive behavior. It doesn't describe a return value or the idempotency behavior that the schema already covers, but an agent has enough to decide whether and how to call it correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds useful meaning to request_id ('one-hour discovery capability; not a telemetry credential') and to the overall registration limit, but it doesn't elaborate on nome or grupo. The 'passos.posix or passos.powershell' reference points to a target terminal concept absent from the schema, which slightly muddies parameter understanding.

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 'Register a device UUID before discovery and collector selection,' which names a specific verb, resource, and workflow stage. It further differentiates itself from siblings like create_guest by stating 'maximum 25 per owner, creating a guest if needed,' making the tool's scope distinct.

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

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

It provides temporal context ('before discovery and collector selection') and a terminal hint ('Choose passos.posix or passos.powershell'), but it never explicitly names an alternative tool or says when not to use this one. The phrase 'creating a guest if needed' implies overlap with create_guest without giving a selection rule.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It adds meaningful context about the token being the recovery path to monitors, but it doesn't mention expiration, persistence, response behavior, or whether the token is returned directly.

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 two short sentences with no filler. The core action is front-loaded, and the critical usage warning immediately follows.

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

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

For a no-parameter creation tool with no output schema, the description is reasonably complete: it states what is created and warns about token retention. It could be improved by clarifying the response format, but the essential operational guidance is present.

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

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

The tool has zero parameters, so the description cannot add parameter-level detail. The 100% schema coverage plus no-parameter baseline makes this an appropriate score.

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: it creates a guest token with the 'hp_' prefix. This clearly distinguishes it from sibling tools like create_collection or create_endpoint, though it doesn't explicitly name alternatives.

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

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

It provides an important after-effect guideline: the token must be kept, as it is the only way back to monitors unless already tied to an email. However, it doesn't explicitly state when to choose this tool over alternatives or give selection conditions.

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

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

With no annotations, the description carries full disclosure burden and does it well: it explains that only ownership/authority/slot disappear, that retained readings persist until retention, that the device continues sending, and that the answer includes a `remover` crontab command. This goes far beyond a generic 'deletes a collection.'

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 first sentence is front-loaded, but the remaining sentences are long, metaphorical, and repetitive ('stands on its own there', 'which is why the answer carries remover'), making it harder to parse than necessary. Several clauses could be condensed without losing meaning.

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

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

Despite lacking annotations and an output schema, the description covers the key practical concerns: what is deleted, what survives, what still happens afterward, and the relevant remover output. The only notable gaps are the precise response shape and how `ativa:false` is invoked, but the one-parameter tool and rich side-effect narrative make it largely 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?

The schema already describes `id` completely (signed 22-character symbol or legacy UUID) with 100% coverage, so the bar is baseline 3. The description adds narrative about the symbol being signed and standing on its own, but does not clarify parameter syntax, defaults, or validation 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?

Opens with a concrete verb and object ('Removes one measurement') and clarifies the ownership/slot effects, so an agent can tell this is a destructive collection-level operation. However, it never explicitly names the resource as a 'collection' and doesn't reference sibling delete tools, leaving some differentiation to the name and 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?

It explicitly tells the agent when NOT to use this tool: 'Use ativa:false instead when you only want to stop looking.' It also implies the appropriate use case is permanent ownership removal rather than merely hiding data. But 'ativa:false' is not a named sibling tool, so the alternative is less actionable than it could be.

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

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

With no annotations, the description carries full behavioral disclosure. It reveals side effects (stops new authenticated input, removes channel from device list) and clarifies that stored measurements follow retention policy. It also states what it does not do (uninstall). It does not mention authorization requirements or error conditions, but the key behaviors are covered, so a 4 is appropriate.

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 two sentences with no redundancy. The primary action is front-loaded, followed by critical clarifications. Every sentence adds value, making it both concise and well-structured.

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

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

Given the simplicity (2 params, no output schema, no annotations), the description is remarkably complete. It explains the operation, scope, side effects, limitations, and directs to alternatives. An agent can confidently invoke this tool correctly without further context.

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

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

Schema coverage is 100%, so both parameters are already documented in the schema (id as UUID, collector as enum). The description does not add additional meaning beyond what the schema provides, such as format details, dependencies, or edge cases. Thus, per the baseline for high schema coverage, a 3 is justified.

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

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

The description states a specific action (revokes and removes) on a specific resource (collector channel from a device), and explicitly distinguishes from sibling tools like create_device_input and list_device_inputs. It also clarifies the scope ('only a channel of the same owner') and what it does not do, making its purpose unmistakable.

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 context: it works even for a deleted device, and it clearly directs the agent to an alternative command (`uninstall.remove`) when the goal is to uninstall or stop the collector. This is a strong when-to-use and when-not-to-use guide.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without mentioning irreversibility, permission requirements, side effects, or what happens to associated data. For a delete operation, this is a significant gap.

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

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

The description is a single, concise sentence with no wasted words. It is front-loaded with the core action, but it is too brief to convey necessary details, making it efficient yet under-specified.

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

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

For a destructive operation with no output schema and no annotations, the description is severely incomplete. It lacks critical context such as reversibility, authorization requirements, or the meaning of guest_token. The agent cannot reliably understand the tool's full behavior or prerequisites from this description.

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

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

Schema description coverage is 50% (id is described, guest_token is not). The tool description adds no parameter-level information, so it does not compensate for the missing guest_token explanation. It merely echoes what the schema already provides for id and leaves guest_token entirely unexplained.

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

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

The description clearly states the action ('Removes') and the resource ('the owner's endpoint'), making its purpose unambiguous. It does not explicitly differentiate from sibling tools, but the verb 'removes' distinguishes it from create/get/list operations, which is sufficient for basic distinction.

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

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

No guidance is provided on when to use this tool versus alternatives like get_endpoint or list_endpoints. There are no contextual cues, prerequisites, or exclusions mentioned, leaving the agent to infer usage solely from the tool's name.

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

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

With no annotations, the description carries the full burden, and it does so exceptionally well. It discloses what is deleted, what persists, the ordering of channel revocation, the 503 failure mode, repeatability, and that the response carries a remover command per measurement.

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 opening sentence is front-loaded and effective, but the body is dense and includes a cryptic reference to GET /api/coletas/serie and a convoluted 'That is why the answer carries remover' explanation. Most clauses carry behavioral value, but the structure is not as crisp as it could be.

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

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

For a destructive tool with no output schema, the description addresses key concerns: side effects, retention, retryability, error status 503, ordering, and even a hint of the response shape. It does not cover success status codes or not-found behavior, but the core contract is well specified.

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

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

The input schema already documents the id parameter as a UUID v4 with a one-hour capability note, so schema coverage is 100%. The description does not add extra parameter-level details, which matches the baseline for fully covered schemas.

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

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

The first sentence names the exact action and resource: 'Removes a device and every measurement on it, in one call.' This clearly distinguishes it from sibling delete_* tools that target narrower resources, and the later description reinforces what is owned and removed.

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 when to use it: when you want to remove a device and all its measurements in one operation rather than one call per measurement. It does not explicitly name alternative sibling tools or exclusion conditions, but the intended 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.

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses authentication semantics, intentionally identical 404 responses, the 401-only case, 503 behavior, 60-second response reuse, rate limits, Retry-After handling, and the requirement to keep the last successful reading.

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 dense and purposeful; nearly every sentence carries operational guidance. It is front-loaded with the core purpose and then elaborates on behavior. Some rhetorical phrasing could be trimmed, but the length is justified given the absence of annotations.

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

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

For a two-parameter read endpoint with no output schema and no annotations, the description is remarkably complete: it covers the intended caller, authorization model, error semantics, caching, polling cadence, retry behavior, and overload safety. Nothing critical seems missing for an agent to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful extra semantics: changing n does not bypass reuse or capacity limits, and id ownership is tied to the 404 behavior. This goes beyond the schema's basic parameter descriptions.

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

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

The description clearly identifies the resource as the latest readings of one device and positions it as a read operation ('readings', 'screen that draws it'), distinguishing it from write/collection-management siblings. It lacks an explicit verb like 'fetch' or 'retrieve', and it does not name sibling alternatives, so it stops short of a 5.

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

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

Provides strong usage context: this is for the screen that draws a device, is authorized by the caller's session rather than a crontab symbol, and includes explicit polling guidance (no faster than once per minute, 5-second checks after registration, no overlapping requests, backoff on 429/503). It does not explicitly compare against sibling tools or state when not to use it, so it misses the top score.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses several important behaviors: the unified shape across protocols, the handling of non-JSON values as strings, the truncation of very large batches to 5,000 series, and the `newer`/`older` navigation fields. This is substantial behavioral context beyond what a schema would provide. It doesn't mention auth requirements or rate limits, but the described behaviors are rich and useful.

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, front-loading the core purpose and then explaining the unified shape, edge cases, and navigation. Every sentence earns its place, though the length is substantial. It is not overly verbose given the complexity of the tool's behavior, and the structure is logical.

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 (multiple protocols, unified shape, edge cases, truncation, navigation), the description is quite complete. It explains the return shape, edge cases, and navigation fields. It doesn't have an output schema, so the description must explain return values, and it does so thoroughly. Minor gaps include not explaining the `resources` array structure in detail, but the overall context is strong.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds context about the batch id being from the history list and the collector enum values, but it doesn't add significant new meaning beyond the schema. The baseline of 3 is appropriate because the schema does the heavy lifting, and the description's added context is marginal.

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: it decodes one received batch into a unified shape of series or NCPA checks. It names the specific resource (a received batch) and the verb (get/decode), and distinguishes it from sibling tools like list_device_input_history and get_device_input_setup. The description is detailed and specific, leaving no ambiguity about what the tool does.

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

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

The description explains the context of use: it operates on a batch from the history list, and mentions the `newer`/`older` neighboring batch ids for moving through history. It doesn't explicitly state when to use this tool versus alternatives, but the context is clear enough that an agent can infer it is the tool for retrieving a specific decoded batch. It lacks explicit exclusions or alternative routing, but the context is strong.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the response carries the credential and is only accessible by the device owner, is one channel per request, is never cached, and documents the two error cases and their meaning.

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 every sentence earns its place: definition, return format, security and caching behavior, then error handling. The key facts are front-loaded in the opening sentence, and the prose does not waste words on restating the tool name.

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

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

Given the tool has no output schema and no annotations, the description is unusually complete: it explains what is returned, the credential sensitivity, caching behavior, error codes, and recovery action. Nothing essential 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 description coverage is 100%, so the baseline is 3. The description does not add much parameter-specific detail beyond the schema, aside from framing id and collector as a single collector channel; that is a minor extension, not a necessary compensation.

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 returns the saved setup for one collector channel, specifically the last generated setup whose credential is accepted. It also distinguishes itself from list routes by stating they never include the credential, so an agent can tell it apart from list_device_inputs and similar siblings.

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

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

The description explicitly states when to use it: to copy or reinstall files without rotating the credential. It also warns that list routes never include it and gives a concrete fallback action—generate a new setup via POST /api/ambientes/:id/inputs—when 404 or 409 errors occur.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it handles this well. It explains that the monitor token is read-only, that `duration` is computed at read time over an event window, and that `p50_ms` is a low median representing a real observed duration. This goes well beyond a generic status description.

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 longer than a one-liner but every sentence contributes: scope, token semantics, schedule field, and unique duration fields. It front-loads the core purpose and keeps the most distinctive detail for the end. Some phrasing is dense, but it remains efficient for the behavioral nuance it conveys.

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 and no annotations, so the description must supply key return and behavior information. It covers `next_expected_at`, `duration`, and the read-time computation, which are the most important non-obvious fields. It does not fully describe the complete response structure or explicitly clarify the `guest_token` parameter, leaving some gaps for a status tool of this complexity.

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

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

The schema already documents `id` and `token`, but `guest_token` has no description. The text adds useful meaning around token roles ('monitor token only reads') and advises using the endpoint token, but it never explicitly connects 'monitor token' to the `guest_token` parameter. With 67% schema coverage, the description compensates only partially for the undocumented parameter.

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

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

The description opens with 'Status of one endpoint,' clearly identifying the verb-like purpose and resource. It also distinguishes itself from sibling list tools by noting that 'only this endpoint carries duration' and 'the list does not pay for it,' so an agent can confidently pick this over list_endpoints.

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 concrete usage context: use the endpoint token if you have it, and use the monitor token when you need read-only dashboard access without exposing owner credentials. It also implies that for duration fields you must call this endpoint rather than the list, but it does not explicitly name sibling alternatives or state when *not* to use this tool.

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 explicitly says 'Read,' making the non-mutating nature clear and indicating that the result contains environment and compatible measurements. With no annotations, though, it stops short of explaining expiry, error behavior, or how the returned data is shaped; the one-hour write-capability note appears only in the parameter schema.

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

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

A single front-loaded sentence conveys the action and object with no filler. It could be slightly more informative, but that is a completeness issue rather than a conciseness issue.

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 tool with no output schema, the description names the resource and the high-level response content, which is passable. It does not define 'detected' or 'compatible measurements' or explain where the id comes from, so an agent is left with some uncertainty.

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

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

The single parameter is fully documented in the schema (100% coverage), so the baseline of 3 applies. The tool description adds no extra meaning about the id or how to obtain it, but the schema already provides the UUID and one-hour write-capability context.

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 identifies a concrete read operation on environment data and says compatible measurements are included, so it is not a tautology and is distinguishable from create/report tools. However, it does not draw an explicit contrast with list_environments or report_environment, and 'detected' is left somewhat vague.

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

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

There is no guidance about when to call this tool versus siblings such as list_environments or report_environment. The only usage signal is the verb 'Read,' which is implied rather than stated as a decision rule.

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

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

With no annotations provided, the description carries the full burden. 'Liveness' implies a read-only health probe with no side effects, but it does not explicitly state that it is non-destructive, whether it requires authentication, or what kind of response the agent should expect.

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

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

The description is extremely concise with no wasted words. For a zero-parameter liveness check, a single-word description can be acceptable, though a bit more elaboration would improve clarity.

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

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

Given the simplicity of the tool, 'Liveness' is minimally adequate. However, with no output schema and no annotations, a short phrase like 'Returns service liveness status' would make the tool behavior more complete without adding much length.

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

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

The tool has zero parameters and the schema description coverage is 100%, so there are no parameter semantics that need explanation. The baseline of 4 for a zero-parameter tool is appropriate.

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

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

The description 'Liveness' is essentially a synonym of the tool name 'health', so it restates rather than explains. It communicates the general idea of a health check but does not specify a verb and resource or what exactly is being checked.

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

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

There is no guidance on when to use this tool versus alternatives. The sibling list includes 'channel_health', which is likely related, but the description does not clarify whether this tool is the global API liveness check and whether channel_health is channel-specific.

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

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

With no annotations provided, the description carries full burden. It discloses that nothing is written without apply, that passwords are redacted, that the proposal includes what was ignored and why, and that apply is all-or-nothing. It also mentions the monitor name travels in emails/dashboard/badge, which is transparent about side effects.

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

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

The description is longer than necessary and repeats the same point twice: 'Without apply=1 nothing is written' appears verbatim twice, and the explanation of the proposal is redundantly restated. While the information is valuable, the redundancy detracts from conciseness.

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

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

Given no output schema and no annotations, the description covers all essential aspects: dry-run vs apply behavior, ignored lines, redaction, name derivation, and all-or-nothing semantics. It explains the proposal contents sufficiently, making it complete 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 schema covers 67% (apply and crontab have descriptions; guest_token does not). The description adds meaningful context for apply (dry-run vs apply) and crontab (format as text/plain), but does not elaborate on guest_token. It adds value beyond the schema for two of three 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 clearly states the tool reads a crontab and proposes one monitor per scheduled line, with an optional apply mode. It distinguishes itself from siblings by describing the specific behavior and the dry-run proposal, which no other sibling tool does.

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

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

It explicitly explains when to use apply=1 versus without, states the all-or-nothing semantics, and details which crontab lines are ignored (comments, variables, @reboot) and how @daily shortcuts are handled. This gives clear usage guidance and alternatives.

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

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

With no annotations, the description carries the full burden and does so unusually well: it discloses idempotent minting, the side effect of creating a monitor on first check-in, the 402 failure beyond the free tier, and key persistence across sign-in. This gives an agent a clear behavioral model.

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 front-loads the key result and is reasonably scannable, but it repeats the 'free tier' and 'whole fleet' concepts almost verbatim. It earns its place overall but could be tightened without losing meaning.

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

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

For a simple one-optional-parameter tool, the description covers usage context, side effects, and failure modes well. However, there is no output schema, no mention of the return format, and the guest_token parameter is unexplained, leaving a noticeable gap for an agent deciding how to invoke it.

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

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

The input schema has one optional parameter, guest_token, with 0% schema description coverage, and the description never mentions this parameter at all. An agent cannot infer what guest_token is for, when to include it, or what value to pass.

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 returns (and mints on first call) the key for /in/<key>/<slug>, which is a specific verb and resource. It is distinguishable from a ping tool, but it does not explicitly contrast itself with ingest_key_rotate or other key-related siblings.

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

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

It conveys when to use the tool by describing fleet instrumentation with no per-job setup and one key per owner, and it warns about the free-tier limit. However, it never explicitly names alternatives or says when not to use this tool versus a sibling like ingest_key_rotate.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It transparently states the key side effect: rotating revokes the ability to create new monitors while leaving existing monitors unaffected. It lacks explicit auth/permission details but covers the primary destructive/behavioral aspect well.

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

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

The description is short and front-loaded with the main action, but it repeats the same idea twice: 'Existing ones keep working' and 'Monitors already created keep working'. This redundancy means not every sentence earns its place, though the overall length is acceptable.

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

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

For a simple tool with one parameter, no output schema, and no annotations, the description explains the behavioral outcome but leaves the guest_token parameter completely unexplained. It also does not mention prerequisites, return values, or repeated-call behavior, so an agent may not be fully equipped to invoke it correctly.

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

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

The schema has 0% description coverage for the single parameter guest_token, and the tool description does not mention this parameter at all. The agent receives no additional meaning beyond the parameter name and type, so the description fails to compensate for the schema gap.

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

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

The description clearly identifies the action ('Rotates the ingest key') and specifies the scope and consequences: the previous key stops creating monitors while existing monitors keep working. This distinguishes it from related tools like ingest_key or status_feed_rotate by describing the unique effect of rotation.

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

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

The description implies when to use the tool—when you need to rotate the ingest key and revoke creation capability without disrupting existing monitors. However, it does not explicitly state alternatives or when not to use it, leaving the choice mostly to inference.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so richly. It explains when command fields are null, how commands depend on the detected environment, which runtimes are honored, that `comandos.agora` is a multiline block to run whole, and that unsupported formats are never guessed. This goes well beyond what a bare schema or annotation would 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 dense but each sentence earns its place: purpose, view selection, environment constraints, script behavior, execution advice, and cron conditions are all covered without filler. The main purpose is front-loaded before the clarifying details.

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

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

For a zero-parameter tool with no output schema and no annotations, the description is unusually thorough: it covers both views, null conditions, command generation, execution guidance, and format behavior. The main remaining gap is that it never explicitly defines the top-level response shape or precisely reconciles "measurements" with "collections," but that is a minor ambiguity for a list 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 parametershare, so the schema coverage is complete by default. Per calibration, a zero-parameter tool starts at baseline 4 because there is no parameter meaning for the description to clarify.

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 specific verb and object, "Lists your measurements," and immediately states that entries carry commands adapted to saved device environments. It explains the two views, `coletas` and `equipamentos`, which gives useful detail about what the listing contains. It does not explicitly compare itself to sibling list tools, so it misses the highest level of 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 gives explicit in-tool guidance: use the `equipamentos` view unless a single measurement is genuinely desiredhola. It also sets behavioral expectations such as commands only being generated from detected environments and cron lines only being offered when crontab exists. However, it never names sibling tools or tells an agent when to choose `list_collections` over another listing endpoint.

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

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses sort order, server-side filtering/pagination, eviction limits, behavior when channels are removed, q's time-budget and continuation semantics, and the meaning of stored/rejected/discarded outcomes.

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 each sentence carries useful information: order, pagination, result meanings, retention, q behavior, and a pointer to the single-batch endpoint. It is front-loaded with the core purpose, though slightly long.

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

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

For a list tool with 8 parameters and no output schema, the description explains the essential behavior, result states, retention, and search semantics, making the response shape predictable. It stops short of specifying a return envelope or auth requirements, but these are partially covered by the schema and the list context.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds real meaning beyond the schema by explaining q's search scope (metric names, NCPA host/service), the time-budget behavior, and search.complete continuation. Other parameters remain adequately self-documented by the schema.

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

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

The description states exactly what the tool does: lists batches a collector sent, newest first, with server-side filtering and pagination. It distinctly separates this from opening a single batch by pointing to the dedicated GET endpoint for a batch, so an agent can tell this list operation apart from get_device_input_batch.

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 rich context about filtering by date, outcome, and q, as well as pagination and retention behavior. It implicitly points to an alternative for opening one batch, but it never explicitly says when to prefer this tool over siblings or when not to use it.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention whether the operation is read-only, any authentication requirements, rate limits, side effects, or what 'live numbers' implies about freshness. The only behavioral hint is 'live', which is vague and insufficient.

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

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

The description is a single concise sentence that front-loads the action and resource. Every word contributes; there is no filler 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 simple, single-parameter list operation, it states what is listed and the data fields returned. However, without an output schema or annotations, it could more explicitly note that this is a read-only operation, describe the output format, and clarify the meaning of 'live numbers'. The current text is adequate but leaves some gaps.

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

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

Schema description coverage is 100%, and the sole parameter 'id' is well documented with an enum and explanatory text. The tool description adds little beyond referring to 'this device', which maps to the id, but the schema already covers that. Baseline 3 applies when the schema does the heavy lifting.

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

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

The description clearly states a specific verb ('List') and resource ('collector channels') with the fields included ('state' and 'live numbers'). It is distinguishable from siblings like create_device_input or set_device_input_active, but it does not explicitly contrast with list_input_fleet or list_device_input_history, so it lacks explicit 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?

There is no guidance on when to use this tool versus alternatives. It only describes what it does, leaving the agent to infer that it should be used when needing collector channel states and live numbers. No exclusions or sibling routing are provided.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Lists', which names the operation but does not describe return shape, pagination, error behavior, permissions, or whether the operation is read-only beyond the verb itself.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes to the core meaning, making it immediate and easy to parse.

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

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

For a tool with no annotations and no output schema, the description is incomplete. An agent still lacks information about the expected return value, how guest_token affects results, potential errors, and any session-versus-guest scope ambiguity.

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

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

Schema description coverage is 0%, so the description must compensate for explaining guest_token. The phrase 'guest's/session's' loosely hints at ownership but does not explicitly define what guest_token is, how it is used, or what values are acceptable.

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

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

The description clearly states the action ('Lists') and the resource ('guest's/session's endpoints'), making the basic purpose understandable. However, it does not explicitly differentiate from the sibling get_endpoint, relying on the plural form to imply a list operation.

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

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

No guidance is given about when to use this tool versus alternatives like get_endpoint, create_endpoint, or delete_endpoint. There is no mention of typical call scenarios, exclusions, or prerequisites beyond the required guest_token.

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

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

With no annotations, the description carries the burden, and it discloses two meaningful behaviors: results are scoped to the current account/guest, and an absent session yields an empty result rather than an error. It does not discuss return format or ordering, but for a simple 0-parameter list operation this is reasonable transparency.

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

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

A single sentence with no filler. The ownership scope is front-loaded and the session edge case follows immediately; every clause adds information.

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

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

For a parameterless list tool with no output schema, the description tells the agent what it will return (saved environments), who they belong to, and what happens without a session. It could mention that the result is an array or list, but the tool name and wording make that a minor gap.

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

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

There are no parameters, so the description has no parameter semantics to explain. The baseline for a 0-parameter tool applies and no additional annotation is needed.

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 identifies the resource ('environments') and its ownership scope ('current account or guest'), which distinguishes it from get/update/delete_environment siblings. It lacks an explicit verb like 'returns' or 'lists', but the tool name and noun phrase make the purpose clear.

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

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

The session condition ('empty without a session') gives useful context about when results will be present, and the ownership wording implies this is the tool for viewing current account/guest environments. It does not explicitly mention alternatives or state when not to use it, so the guidance is adequate but not 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?

With no annotations, the description must disclose behavioral traits. It only states 'Latest ingest pings' without indicating whether the operation is read-only, has side effects, requires authentication, or has rate limits. The description provides almost no behavioral context.

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

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

The description is extremely short and concise, but it lacks structure and front-loading of key information. It is not well-organized for an agent to quickly grasp the tool's function or usage. It is concise but under-specified.

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 incomplete for a tool with three parameters and no output schema. It does not explain what events are, how to interpret the output, or the significance of the required 'id'. The description fails to provide sufficient context 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?

The description adds no parameter information beyond what the schema already provides. Schema coverage is 67%, but the description does not compensate for the undocumented guest_token parameter, nor does it clarify the meaning of id or token in context. It adds minimal value.

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

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

The description 'Latest ingest pings' is vague and does not clearly state the tool's purpose as listing events or retrieving data. It lacks a specific verb and resource, and does not distinguish it from sibling tools like list_endpoints or list_templates. The purpose is implied but not 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 description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, contexts, or exclusions, leaving the agent without direction on tool selection.

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

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

With no annotations, the description carries the behavioral disclosure burden and does well: it reveals the single aggregated query to the time-series store, the all-channels scope, and its relationship to socket events. It does not explicitly state read-only status or return shape, but the listing semantics and 'live numbers' make the behavior reasonably transparent.

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

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

Three sentences, front-loaded with the most important information about scope and response content, with later sentences adding efficiency and socket-context details. It contains no filler, though the third sentence is slightly dense with socket event names.

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 parameterless, read-style fleet list with no output schema, the description is largely complete: it states the resource scope, the data categories (state, live numbers), and the aggregation behavior. Exact response shape is not specified, but there are no input parameters to misuse and the data categories are stated clearly.

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 and the empty schema covers 100% of the contract, so parameter-level documentation is not needed. The baseline of 4 applies because there are no parameters to explain.

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

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

The description states a specific verb ('list'), a clear resource ('collector channels of the caller'), and scopes it to the whole fleet with state and live numbers. It also distinguishes itself from per-device access by emphasizing 'one call for the whole fleet' and 'never one per device.'

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

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

It explicitly frames the tool as the REST/synchronous alternative to the dashboard's socket subscription and explains data equivalence, giving a clear alternative. It implies when not to use it (per-device queries) via 'never one per device,' though it does not name a sibling tool such as list_device_inputs.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does explain that miss_json and recovery_json are the same bodies posted to alert_url and that Slack/Discord receive only their relevant field, but it never describes what calling list_templates actually does, returns, or whether it has side effects.

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

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

The description is short and does not waste words, but the opening phrase is grammatically awkward and the structure is unfocused. Valuable context about alert bodies and integration behavior is buried without a clear statement of the tool's core function.

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

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

For a simple list tool with no parameters and no output schema, the description should at minimum say what is being listed and what the response contains. Instead it discusses alert payload semantics and omits the only information an agent needs to correctly understand the tool.

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

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

The tool has zero parameters, so the schema imposes no burden. The baseline of 4 applies: the description cannot add parameter semantics because there are no parameters to document, and no ambiguity is introduced.

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

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

The description uses 'Ingest snippets and the JSON HookPulse POSTs on a miss' without ever naming a list, a template, or a return value. It suggests the tool exists to prevent guessing the alert format, but does not clearly state that it lists templates. The relationship between the name and the description is left to inference.

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

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

No guidance is given on when to call this tool versus alternatives such as list_endpoints, list_events, or create_endpoint. The sentence 'It exists so nobody guesses the alert format' hints at a purpose but not at conditions or exclusions for use.

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

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

With no annotations, the description shoulders the behavioral burden. It explicitly discloses the auth model ('No credential on purpose'), the authentication mechanism (the ID is the secret), and the lack of quota/cost. It does not, however, describe side effects or error behavior, so it is not fully transparent.

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

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

Three short sentences each add information: the operation, the auth model, and the cost/quota rule. There is no padding, and the core endpoint pattern 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 one-parameter endpoint with no output schema, the description plus schema covers the invocation source, auth, and rate-limit implications. It would be more complete if it stated what happens on success or failure, but that is a minor gap for such a simple 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 schema already documents id and its source ('Monitor.ingest_url') at 100% coverage, so the baseline is 3. The description's only parameter-related addition is that the ID is already the secret, which reinforces its role rather than adding new syntax or format detail.

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

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

The description names a specific operation: 'Simulates the cron: GET on /in/:id', so an agent can see this is a no-auth ping to a monitor ingest endpoint. It is clearer than a generic verb description, but it never contrasts itself against siblings such as ping_slug or other ingest 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 caller is a cron, and the ID is already the secret' gives an explicit context in which this tool is meant to be used. The statement about no cost and no quota tells the agent this call is safe and unthrottled, but it does not name an alternative to use when this tool should not be used.

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

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly: it discloses idempotence, slug normalization constraints, 402 failure behavior, side-effect guarantees ('nothing is written — not even the event'), and HTTP method flexibility. This is exactly the kind of context that an agent needs beyond the schema.

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

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

The description is front-loaded with the core purpose and packs in dense, actionable constraints without filler. There is some repetition around 'nothing is written' and the same-monitor identity rule, but the repeated phrasings add useful nuance about free-tier limits and retry behavior.

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

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

Given no annotations and no output schema, the description compensates well by covering idempotence, failure modes, validation rules, and HTTP methods. The main omission is the success response shape, but the description is still sufficient for an agent to invoke the tool correctly with the two required parameters.

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

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

Schema coverage is 100%, so the baseline is 3, and the description adds substantial extra meaning for slug: normalized to lowercase, allowed character set, 40-char limit, and the fact that it becomes the monitor name and identity. It does not add further semantics for ingestKey, so it stops short of 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 opens with a specific verb and resource ('Ping that creates its own monitor on the first hit') and immediately establishes the key identity rule: 'Same slug = same monitor'. This clearly differentiates the tool from a plain ingestion tool like ping_ingest, even though it doesn't name the 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?

The description gives strong context about when creation is allowed ('only inside the free tier (or the trial)') and what happens past that point (402 with accepts[]), but it never explicitly says when to choose this tool over ping_ingest or another alternative. The usage guidance is implied by the monitor-creation behavior rather than stated as a recommendation.

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

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

No annotations are supplied, so the description carries the full burden, and it does little: 'no charge' is ambiguous (does it mean the endpoint is free to call, or that listed prices are zero?). It never states whether the call is read-only, whether auth is required, or whether results are cached/static.

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

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

A single short clause with no filler, and the key content (what it returns) is front-loaded. It is arguably too terse to stand alone, but nothing is wasted.

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

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

With no output schema, the description is the only source of return-shape information, and it only gestures at the payload ('prices and free allowances') without indicating structure or freshness. For a trivial zero-parameter informational tool this is adequate but thin.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. No parameter meaning is missing.

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

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

The description names the resource ('public prices and free allowances') so an agent can tell it returns pricing information, but it gives no verb and no differentiation from the sibling 'billing' tool, which an agent could easily confuse it with.

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

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

There is no statement of when to call this versus the sibling 'billing' or 'api_index' tools, and no prerequisites are given. Usage must be inferred purely from the resource name.

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

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

With no annotations, the description carries the full burden and delivers: preview writes nothing, only allowlisted facts are saved, raw commands are never stored, first report wins within an hour, identical retries do not rewrite, and the operation never creates a measurement, sends a reading, installs software, or creates a schedule. This is precisely the behavioral context an agent needs.

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?

Roughly 120 words, with the purpose front-loaded, followed by workflow, then side effects and output behavior. Every sentence adds non-redundant behavioral information; there is no filler or restatement of the schema.

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

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

For a 5-parameter tool with a nested object and no output schema, the description covers the multi-phase workflow, idempotency, safety boundaries, and the preview return shape. It leaves minor gaps: the default save receipt when Accept is not text/plain and the behavior on duplicate submission are not described, but the schema fully documents all parameters.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds procedural context for conferir (initially true, omit to save) and maps saidas to pasted step output, but it does not add essential parameter meaning beyond the schema; relatorio remains documented only in the schema.

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

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

The description states a clear verb and resource: preview or save the allowlisted discovery report for one device. It is distinct from generic environment CRUD siblings through the 'allowlisted discovery report' scope, though it never explicitly names an alternative sibling.

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

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

It gives an explicit workflow: send terminal and saidas with conferir:true first to preview, then omit conferir to save when complete. It also states exclusions and retry behavior (first report wins, identical retries do not rewrite) and side-effect boundaries, so an agent knows exactly when and how to use it.

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

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

No annotations exist, so the description carries the full disclosure burden – and it does so thoroughly. It reveals that paused batches are accepted and discarded, nothing is stored or measured, no retry loop occurs, resuming stores the next batch, only same-owner channels are affected, and the operation works even when the device was already deleted. This is exemplary behavioral disclosure for an unannotated mutation tool.

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

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

Three sentences with zero waste: the core purpose is front-loaded in the first sentence, the second delivers dense behavioral detail that earns its length given the absence of annotations, and the third covers an important edge case (deleted devices and ownership). Every sentence contributes unique value.

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

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

For a state-transition tool with no annotations and no output schema, the description covers an impressive range: pause semantics, resume semantics, batch handling, retry behavior, ownership constraint, and the deleted-device edge case. What remains unstated is the response/return format, permission requirements, and behavior on already-paused or non-existent channels – minor but real gaps.

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

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

Schema coverage is 100%, so the schema already documents all three parameters, including the active field's 'false pauses, true resumes.' The description adds marginal meaning by tying 'pauses/resumes' to the active parameter and 'one collector channel' to the collector field, but it does not meaningfully go beyond the schema. Baseline 3 is appropriate.

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

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

Opens with 'Pauses or resumes one collector channel' – a specific verb (pause/resume) and resource (collector channel) that immediately differentiates it from siblings like create_device_input, delete_device_input, and list_device_inputs. The follow-up details about what pausing does further pin down the exact operation.

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

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

The description gives clear context for when this tool is appropriate: pausing is non-destructive (keeps credential and configuration, discards batches without retry loops), which signals it is for temporary suspension rather than removal. It does not explicitly name alternatives or state when-not-to-use, so it falls short of a 5, but the behavioral context is strong enough to guide selection.

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

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

With no annotations present, the description takes on the behavioral disclosure burden. It discloses the key behavior: 0 is not a failure, 1-255 records a failure, and values outside 0-255 are rejected as 400. The phrase 'leave the failure for the cron' adds useful context about downstream handling, though some ambiguity remains.

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 and front-loads the essential 0-vs-1-255 semantics in the first sentence. The curl command is a worthwhile concrete integration example. There is some redundancy in restating the 0-ping behavior, but nothing is excessive.

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

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

For a simple two-parameter ingestion-style tool, the description gives enough context to call it correctly: the curl pattern, the meaning of the exit code, and the error condition for out-of-range values. There is no output schema and the endpoint is effectively a fire-and-forget signal, so not describing a return value is acceptable. It could be more explicit about authorization or response behavior, but those gaps are minor.

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

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

The input schema already documents both parameters and their ranges with 100% coverage, so the baseline is 3. The description adds real value by explaining that exit_code 0 behaves like a ping rather than a recorded failure, and by showing the shell `$?` as the source of the value.

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

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

The description clearly explains the tool's behavior: exit code 0 is treated as a ping, while 1-255 records a failure. It uses the shell-exit context and curl recipe to make the resource clear, though it never states the imperative 'signals the exit code' directly. It differentiates from related signal/ping tools through the 0-as-ping distinction, making the purpose recognizable.

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

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

It gives concrete usage guidance: run the curl command at the end of a script to integrate the monitor check. It explains how 0 and nonzero exit codes are handled, which helps an agent decide whether this tool is appropriate. It does not explicitly name sibling alternatives or say when not to use them, 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly explains that no e-mail is sent, the 5-minute cron conversion, the one-per-24h cap, that failure is not proof of life, and that it works by GET or POST. This is exemplary transparency.

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

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

The key fact—'Says the run FAILED'—is front-loaded, but the description repeats the e-mail/cron/alert-cap behavior almost verbatim in two consecutive passages. This redundancy makes it longer than necessary and violates the 'every sentence earns its place' principle.

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 one simple parameter, no output schema, and no annotations, the description covers all essential behavior: what the call records, how and when the alert is generated, the rate cap, the liveness semantics, and the HTTP methods. Nothing critical 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% and the single `id` parameter is already documented as the Monitor ID from `Monitor.ingest_url`. The description does not add parameter-specific semantics, but the schema already covers it, matching the baseline.

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

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

The description opens with a specific verb and resource: 'Says the run FAILED' via a monitor id. It clearly conveys the tool's function and is easy to distinguish from sibling tools like signal_start and signal_exit_code, though it never explicitly names them.

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

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

The description provides clear behavioral context: calling this tool records an alert_pending state, the cron converts it to an alert with reason 'fail' within 5 minutes, and it is subject to a one-per-24h cap. It does not explicitly state when not to use it or mention alternatives, so it falls 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?

With no annotations, the description carries the full burden and does so thoroughly: it discloses that start does not clear the miss counter, does not move last_event_at, that the next success closes the run and records last_duration_ms, and how max_duration_sec triggers an alert. This is substantial behavioral context beyond the bare schema.

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

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

The description is front-loaded with the core purpose and contains dense, useful information. However, it is redundant: the point that start does not clear the dead-man clock / miss counter and that a hanging run still becomes a miss is made twice, as is the fact that the next success records duration. Shorter would be clearer.

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 subtle monitor semantics and no output schema, the description covers the critical operational details: dead-man clock behavior, overlap-safe rid handling, duration recording, and max_duration_sec alerting. It is nearly complete, though it does not describe the response format or explicitly explain the relationship to sibling signal tools.

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

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

The schema already documents the only parameter `id` fully as "Monitor ID, from Monitor.ingest_url," so schema coverage is 100%. The description adds useful context about the `?rid=` query parameter for overlapping runs, but does not add new meaning about the `id` parameter itself. Baseline 3 is appropriate.

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

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

The description opens with a specific action, "Says the run STARTED," and clarifies the tool's role by explaining what it does and does not do (does not clear the dead-man clock, does not move last_event_at). It is clear enough to stand apart from signal_exit_code and signal_fail, though it never names or explicitly contrasts those siblings.

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

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

The description implies the tool should be called when a run starts and provides conditional guidance for using `?rid=` when runs can overlap. However, it does not explicitly state when to prefer this tool over signal_exit_code or signal_fail, nor does it provide exclusions or alternative routing.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It does disclose the key destructive side effect (previous URL stops working), but omits other important behavioral details such as whether rotation is permanent, whether repeated rotations are allowed, or how the new token is returned.

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

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

The description is a single focused sentence that front-loads the action and consequence. No filler or redundant wording.

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

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

For a tool with no output schema and no annotations, the description should clarify what the agent receives after rotation and whether the optional guest_token is needed. It does not mention the new token or URL, making the tool's behavior incomplete from an agent's perspective.

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

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

Schema description coverage is 0% and the description does not mention the guest_token parameter at all. The description fails to explain what guest_token is, whether it is required, or how it affects the rotation, leaving the agent without necessary parameter semantics.

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

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

The description states a specific verb ('Rotates') and resource ('status feed token'), and adds a clear consequence ('the previous URL stops working'). This distinguishes it from siblings like status_feed_url, which presumably fetches the URL rather than rotating it.

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

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

There is no guidance on when to use this tool versus alternatives such as status_feed_url or create_guest. The description implies rotation is needed but does not describe conditions, prerequisites, or when not to use it.

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

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

With no annotations, the description carries the full burden and does well: it discloses the read-only nature of the token, the scope of the data, and the security requirement to treat the link as a secret. It goes beyond a generic 'get URL' statement by explaining what the token cannot do.

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 two sentences with no filler. It front-loads the core purpose and then adds relevant security and non-mutation context, every sentence earning its place.

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

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

For a simple one-parameter tool with no output schema, the description covers the essential facts: what the URL contains, the scope of the data, the read-only nature, and the need to keep it secret. It could more explicitly connect guest_token to the feed token, but overall it is complete enough for correct selection and invocation.

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

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

Schema coverage is 0%, so the description must compensate. It refers to a 'feed token' that is read-only and secret, which maps naturally to the guest_token parameter, but it never explicitly says guest_token is that feed token or explains how it is used. Some meaning is added, but the mapping is left implicit.

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 identifies the artifact as a public URL containing JSON and RSS status for all the owner's endpoints, which is specific and useful. It lacks an explicit action verb like 'returns' or 'retrieves', but the tool name and noun phrase make the purpose clear.

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

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

The description implies this is a read-only status-feed tool and warns it must not be used for creating, changing, or deleting anything. However, it does not explicitly say when to prefer this over the sibling status_feed_rotate or list_endpoints tools, so alternative selection is left to inference.

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

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses id immutability tied to the crontab symbol, partial-update semantics, persistence of history and commands when deactivating, the query-cost implication, the critical caveat that the device keeps sending, and that the response is the authoritative current collection.

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 its purpose, and each later sentence adds a distinct behavioral or response fact rather than restating the schema. It is longer and more vivid than strictly necessary, especially the crontab rationale, but the length is justified because there are no annotations and the tool has nontrivial side effects.

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

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

Given no annotations and no output schema, the description covers the essential execution model: what changes, what persists, what deactivation means and does not mean, and that the returned collection should be used as the source of truth. Parameter format constraints are already in the schema, so no significant gap remains.

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

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

The input schema already documents all four parameters with 100% coverage, so the baseline is 3. The description adds meaningful semantics beyond the schema: partial-update behavior for omitted fields, why the id is immutable, and what ativa:false and ativa:true actually do to fleet reading, query cost, and device behavior.

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 concrete operations ('Renames one measurement, or stops and resumes reading it') tied to the collection resource. It distinguishes this from create/delete/list siblings by naming the exact mutation surface and adding the invariant that the id never changes.

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

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

The description gives clear context for when to use the tool: partial updates, renaming, and toggling active state. It also warns that ativa:false does not silence the machine and that the cron line must be removed instead, which is an explicit exclusion. It does not name sibling tools as alternatives, but the context is clear and the guidance is not misleading.

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

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

With no annotations present, the description carries the full behavioral burden and does so thoroughly. It discloses cascading renames to measurements, effects on collector channels and dashboard tabs, partial-update semantics, and the fact that the detected environment is never rewritten—preventing a serious misassumption about immutable evidence.

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 longer than average but every sentence adds meaningful behavioral context, and the core action is front-loaded in the first sentence. The prose is dense but not padded, and the caveat about the detected environment is placed at the end where it reads naturally.

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

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

Given no annotations and no output schema, the description is unusually complete for a mutation tool. It covers the resource being changed, side effects, group/dashboard implications, partial-update semantics, and the one field that must never be rewritten. An agent has enough context to invoke the tool correctly and avoid common mistakes.

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 value beyond the schema by explaining the real-world effect of the name/group parameters, including how the group determines the dashboard tab and that the environment field is intentionally preserved. This exceeds the minimum baseline without being redundant.

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 specific verb and resource: it renames a device along with its measurements. It makes the scope and main behavior unmistakable and distinguishes this from generic CRUD updates by explaining that renaming cascades to measurements, collector channels, and dashboard grouping.

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 clear partial-update guidance: 'Send only what changes; what you omit stays.' It also explains the consequences of renaming. However, it does not explicitly state when to use this tool versus siblings like update_collection or create_environment, nor does it specify exclusions or prerequisites.

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