Perimeter Watch

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

With no annotations, the description itself must convey behavior. 'Liveness check' implies a non-mutating probe, but it does not state what the response contains, how failures are reported, or whether any side effects occur. This is acceptable but 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?

The description is a single, front-loaded sentence with no filler. Every word contributes to the tool's purpose.

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 health check, the description is nearly sufficient to invoke the tool. It is missing only the shape of the response or a definition of what 'liveness' means in practice, but this is a minor gap given the tool's simplicity.

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 no parameters, so there is nothing for the description to add beyond the schema. The baseline of 4 applies because parameter semantics are not a 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 tool as a liveness check for the Perimeter Watch API, naming both the operation and the target resource. It is implicitly distinct from the sibling snapshot/stats/status tools, though it does not explicitly contrast with 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 phrase 'liveness check' implies when to use the tool: to verify that the API is reachable and alive. However, it provides no explicit guidance about when not to use it or how to choose among the sibling tools.

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 scan duration (20-60s), a rate limit (3/IP/24h), and an important authorization requirement with a prohibition on scanning third-party domains. This is substantial behavioral context beyond what the schema provides.

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

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

The description is well-structured with a short purpose line followed by an Args section. Each sentence provides necessary information: purpose, domain format, authority requirement, expected duration, and rate limit. It is slightly dense but every part 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?

The description covers purpose, required inputs, authority constraints, timing, and rate limits. The main gap is that there is no output schema and no description of what the scan result looks like, so an agent must infer the return format. Still, the tool is simple and all invocation-critical information 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?

Schema description coverage is 0%, so the description must fully explain the parameters. It does: 'domain' is illustrated with an example.com format, and 'authority' is explained as a required attestation of ownership or management, including the prohibition against unauthorized scanning. This fully compensates for the schema's lack of 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 opens with a specific verb and resource: 'Run a free one-time external-perimeter scan on a domain.' This clearly states what the tool does. It does not explicitly differentiate from sibling tools like pw_health or pw_watch_status, though 'one-time' hints at a distinction from ongoing monitoring tools.

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

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

The description provides clear operational constraints: the domain must be specified, authority must be true, and third-party scanning is prohibited. However, it does not state when to choose this tool over siblings such as pw_health, pw_stats, or pw_watch_status. Usage context is implied but not explicitly contrasted with 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 exist, so the description carries the full burden of behavioral disclosure. 'Funnel counters' implies a read-only operation, but the description does not state whether results are current totals, period-specific, whether they are reset, or whether the operation is expensive or 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 highly concise and free of filler. It communicates the tool's core purpose in a single short phrase, which is appropriate for a no-parameter stats counter, though it could be more structured with a complete sentence.

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 parameters and a simple counter purpose, the description is minimally viable. However, with no output schema and no annotations, it leaves ambiguity about the return format, time range, and whether these counters are cumulative or resettable. An agent could invoke it safely, but the interpretation of results would be uncertain.

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 an empty input schema, so there is nothing to document. The baseline for a no-parameter tool is 4, and the description adds no conflicting or redundant parameter information.

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 resource, 'Funnel counters', and enumerates the exact metrics: page views, snapshots run, paid registrations. It is not a tautology and is clear enough that an agent can tell this is a stats/read tool, although it does not explicitly differentiate itself from siblings like pw_health or pw_watch_status.

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

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

There is no guidance on when to use this tool versus the sibling tools, no prerequisite context, and no mention of whether this is the right tool for current counts, historical counts, or health monitoring. The usage context is left entirely to inference.

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

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

No annotations are present, so the description carries the full burden. It states the action but does not disclose return format, side effects, permissions, or error behavior. The verb 'check' weakly implies a non-mutating read operation, but that is not explicitly stated.

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

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

The description is a single, front-loaded sentence with no wasted words. It states the action and the object concisely, which is ideal for a simple status-check tool.

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

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

With no output schema, no annotations, and a minimal description, the agent lacks enough context to fully understand behavior or interpret the result. Given the existence of sibling tools, there is also no information to help choose this tool over alternatives, making the definition incomplete for reliable invocation.

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

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

Schema description coverage is 0%, yet the description adds no meaning beyond the parameter name 'domain'. It does not specify expected format, validation rules, or examples. The simplicity of the single parameter mitigates the gap somewhat, but the description still fails to compensate for the lack of schema documentation.

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

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

The description clearly states a specific verb 'check' and a precise resource: whether a domain is on a paid weekly watch plan. This concept is distinct from the sibling tools pw_health, pw_snapshot, and pw_stats, making the tool's purpose immediately identifiable.

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 its siblings. There are no conditions, prerequisites, or alternative suggestions, so the agent must infer usage solely from the tool name and the generic task.

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