Vivere

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

Annotations only signal readOnlyHint=false, so the description carries the burden of explaining state changes. It does so by disclosing that 'success' resets the deadline and that the message is kept as the run log. It stops short of covering broader side effects like authentication or persistence details, but the key mutation behavior is 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?

Two concise sentences front-load the status semantics and the key side effect (deadline reset), with no filler, repetition, or unnecessary detail. 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?

For a simple check-in tool, the description covers purpose, statuses, the message parameter, and the deadline-reset behavior. The main gap is that it does not describe what the tool returns or what the agent should expect as a response, which is more notable because there is no output schema.

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

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

Schema coverage is already 100%, but the description adds value by defining what each status means (success resets deadline, start begins a run, fail reports failure) and clarifying that the message becomes the run log. It does not add anything about monitor_id, but the schema already documents that parameter clearly.

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 a specific verb ('Report on') and resource ('heartbeat monitor'), then enumerates the three statuses and their meanings. It is clearly distinct from sibling tools like get_monitor or pause_monitor, which perform different lifecycle actions.

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 lifecycle timing for each status: 'success' after a completed run, 'start' when a run begins, 'fail' when it failed. It also explains the deadline reset, which helps an agent choose the correct status. However, it does not explicitly name alternative tools or state when not to use this tool, so it falls just short of a 5.

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

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

Annotations already indicate this is a write operation (readOnlyHint=false, destructiveHint=false). The description adds useful behavioral context: it returns the monitor and, for heartbeats, the ping URL to call after each run. It also clarifies that page_id may be a shared page, which is beyond what annotations provide.

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

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

The description is two sentences, front-loads the core purpose, and packs the key distinctions (heartbeat vs HTTP, page placement, return value) without waste. 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?

For a creation tool with 10 parameters and no output schema, the description covers the essential context: what it creates, the two modes, the page target, and the return value. It doesn't explain all parameter interactions, but the schema covers parameter details, and the description provides enough for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents all 10 parameters. The description adds a little context by explaining the default behavior (first page) and the return value, but it doesn't add significant meaning beyond the schema's parameter descriptions. 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 clearly states the tool creates a monitor, distinguishes between heartbeat and HTTP check types, and specifies the target page. It uses a specific verb ('Create') with a clear resource ('monitor') and differentiates the two modes, which distinguishes it from siblings like get_monitor or list_monitors.

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 this tool (to create a monitor) and provides context about the two kinds of monitors and the page placement. It doesn't explicitly state when not to use it or name alternatives, but the sibling list and the clear creation purpose make the usage context 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the behavioral detail that the ping URL is included for heartbeat monitors and that the slug/page_id path works on shared pages. It doesn't disclose response shape or error behavior, but with annotations covering safety, a 3 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?

A single, well-structured sentence that front-loads the primary lookup mode (by id), then adds the alternative mode and the shared-page caveat. No wasted words; every clause earns its place.

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

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

For a read-only, idempotent tool with no output schema, the description covers the two lookup paths and the special ping URL behavior. It doesn't mention what happens if both id and slug/page_id are provided, or if no parameters are given, but the schema shows no required parameters. Given the tool's simplicity and annotation coverage, this is nearly 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?

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds the relationship between id and the slug/page_id pair, and clarifies that slug requires page_id, which is useful. However, it doesn't add details beyond what the schema descriptions imply, so the baseline 3 is correct.

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

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

The description clearly states the tool's purpose: retrieving a single monitor by id, or by page_id and slug. It also distinguishes the two lookup modes and notes that the slug/page_id path works on shared pages, which adds specificity beyond the title.

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

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

The description implies when to use this tool: when you need one monitor's details, especially its ping URL for heartbeat monitors, or when you have a page_id and slug. It doesn't explicitly contrast with list_monitors, but the 'one monitor' scope and the shared-page note provide clear context. No exclusions are stated, but the sibling list makes the alternative obvious.

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

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

Annotations already declare this as read-only, idempotent, and non-destructive. The description adds valuable behavioral context: monitors on shared pages have no id and must be addressed by page_id and slug, and the output includes status, page, and access fields. This goes beyond the annotations without contradicting them.

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 the primary action and scope front-loaded, followed by a critical caveat about shared pages. There is no redundancy or filler; every phrase 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?

Despite having no output schema, the description lists the returned fields (status, page, access) and covers the main edge case. Given the tool's simplicity (one optional parameter) and the annotations covering safety, the description provides everything an agent needs 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?

There is only one optional parameter, page_id, which the schema already describes with a hint ('from list_pages'). Schema coverage is 100%, so the description adds little beyond the schema. The mention of 'on one page' in the description aligns with the parameter, but no new meaning is added beyond the schema's own description.

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

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

The description clearly states the tool lists monitors across all visible pages or a specific page, and specifies the included fields (status, page, access). It also highlights a unique edge case (shared pages lack ids), which distinguishes it from related tools like get_monitor. The purpose is unambiguous and specific.

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 on when to use it: to list monitors across all pages or one page, with an optional page_id. It also provides guidance for the special case of shared pages, telling the agent to use page_id and slug instead of id. However, it does not explicitly name alternative tools like get_monitor for single-monitor retrieval, so usage exclusions are only implicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds behavioral detail beyond that, such as the ordering ('its own, then pages other accounts share with it') and the specific data returned (access level, monitor counts). This enriches the agent's understanding without contradicting the annotations.

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

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

The description is a single, dense sentence that front-loads the core action ('List the pages this account can see') before adding details. It contains no filler, though it could be slightly rephrased for readability. The content is efficient and 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 parameters, no output schema, and a complex return payload, the description sufficiently specifies what the agent can expect: own pages, shared pages, access level for each, and monitor counts (including down monitors). It even notes the ordering. This is complete enough for an agent to invoke the tool and interpret the result 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 tool has zero parameters, and schema coverage is 100% (no params). The description therefore does not need to explain parameter meanings, and the baseline of 4 applies. It appropriately focuses on what the tool returns rather than inputs.

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 'List' and the resource 'pages', and specifies the scope ('this account can see'). It also details the output content (own and shared pages, access levels, monitor counts), making its purpose unmistakable and distinct from sibling tools like list_monitors or get_monitor.

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 context for when to use the tool: to see all pages accessible to the account, including ownership and sharing details. While it doesn't explicitly exclude alternatives or name when not to use it, the absence of a similar listing tool among siblings makes the intended use obvious.

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

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

Annotations already cover idempotency and non-destructiveness. The description adds meaningful state-lifecycle detail beyond annotations: the pause persists until an explicit resume or a ping re-activates it. This helps the agent predict side effects without contradicting the idempotentHint.

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

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

The description is one efficient sentence that front-loads the action and resource, then adds the key lifecycle behavior. Every phrase earns its place with no redundancy or filler.

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

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

For a one-parameter, non-destructive, idempotent tool with no output schema, this description is complete. It covers what the tool does, the effect on alerting, and how the paused state ends, which is everything an agent needs to invoke it correctly.

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

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

Schema coverage is 100% and the single required parameter 'id' is described as 'Monitor id.' The description adds no additional parameter guidance, but the baseline 3 applies because the schema already documents the only parameter sufficiently.

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 and resource: 'Pause a monitor so it stops alerting.' It also clarifies the behavioral scope with 'until resumed or pinged again,' which implicitly distinguishes this from siblings like resume_monitor and create_monitor. An agent can identify what this tool does and what it does not do.

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 usage: use this when a monitor should stop alerting temporarily. The phrase 'until resumed or pinged again' gives lifecycle context, but it does not explicitly name alternatives or state when not to use this tool. Guidance is adequate but 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?

Annotations already communicate that this is a non-read-only, idempotent, non-destructive operation. The description adds a mild behavioral detail by scoping the action to paused monitors, but it says nothing about errors, side effects, or response behavior. No contradiction with annotations.

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

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

The description is a single front-loaded sentence with no filler. 'Resume a paused monitor' is compact while carrying the essential 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 one-parameter state-transition tool with complete schema coverage and unambiguous annotations, the description is sufficient to guide invocation. It could mention what happens if the monitor is not paused or what the response contains, but these are minor gaps for a state-changing op with no output schema.

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

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

Schema coverage is 100% and the id parameter is already documented as 'Monitor id'. The description does not need to add parameter detail and provides none, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Resume') and a specific resource ('monitor'), and the word 'paused' distinguishes it from its sibling pause_monitor. There is 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 phrase 'a paused monitor' implies the tool should be used when a monitor is in a paused state, but it never explicitly states this or mentions alternatives like pause_monitor or get_monitor. Guidance is present only by implication.

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