Orbilo

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

Annotations only indicate non-read-only, non-idempotent, non-destructive. The description adds meaningful behavior: checks run 'now and on a schedule', team alerts are triggered on readiness changes, and the action consumes a plan site slot. This goes beyond the structural 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?

Three sentences each earn their place: first states the action and its effects, second gives usage direction, third covers resource and prerequisite. Front-loaded with the core purpose; no filler or repetition of schema content.

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

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

For a single-parameter mutation tool with no output schema, the description covers the action, scheduling behavior, alerting, usage context, account requirement, and slot consumption. Nothing essential is missing for an agent to decide whether and how to call 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?

Schema coverage is 100% and the single url parameter is already well-described in the schema (domain or URL, monitoring per site, WebMCP pages on dashboard). The description adds no extra parameter-specific meaning, so the baseline score of 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?

Description opens with 'Start monitoring a site' – a specific verb and resource – and expands on what that entails: checks against UCP, WebMCP and Access now and on a schedule, plus alerts. It also contrasts with a 'one-off check', distinguishing it from the sibling check_site without needing to inspect schemas.

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

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

Explicitly states when to use: 'when someone wants ongoing monitoring rather than a one-off check, or asks to be told when their site breaks for agents.' It also gives a prerequisite ('Requires a connected Orbilo account') and an operational constraint ('Uses one of the plan's site slots'), giving clear go/no-go signals.

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 establish read-only, idempotent, non-destructive behavior, and the description adds valuable context: it runs live, can take up to a minute, returns scores/grades with check-level fixes, provides a shareable report link, and notes the signed-in daily limit difference. 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 front-loaded with purpose and usage, then return value, runtime expectation, and auth behavior. Every sentence adds useful information with 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?

Despite no output schema, the description explains what is returned: score and grade per spec, passed/warned/failed checks with fixes, and a shareable report link. Combined with the rich schema and annotations, an agent has everything needed to invoke the tool correctly and interpret the result.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces that all three specs are checked and that WebMCP is page-specific, but the detailed parameter meanings are already fully documented in the schema. No additional semantic burden is placed on the 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 states a specific verb and resource: checking whether a website is ready for AI agents against the UCP, WebMCP, and Access specs. It also gives concrete user-intent triggers such as "can agents use my site" and "why an agent cannot buy from or act on a page," which makes the tool's role clear and distinct from status or 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?

It explicitly says when to use the tool: when someone asks about agent readiness, spec support, or agent failures on a page. It does not name alternatives or state when not to use it, but the use cases are concrete and sufficient for an agent to select this tool over the siblings.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds meaningful context beyond annotations: reports expire after 30 days, the token is a 16-character code at the end of a URL, and no sign-in is required. This is useful behavioral information an agent otherwise would not know.

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 concise sentences with no filler. The core purpose is front-loaded, followed by usage context, expiration, and auth note. Every sentence adds 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 single-parameter read-only tool, the description covers purpose, token extraction, expiry, and authentication. It doesn't describe the report content or error behavior, but given the simplicity and strong annotations, nothing critical is missing for correct invocation.

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

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

The schema already describes the token parameter at 100% coverage, including accepting the full report URL. The description adds complementary meaning by explaining where the token comes from and how to recognize it, which helps the agent validate or extract the parameter in real user 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 states a specific action ('Fetch a check report') and a specific resource ('by its share token'), and clarifies the token's format and location. It clearly distinguishes this from siblings like check_site by framing it as retrieval of an already-run report rather than initiating a check.

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

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

Explicitly tells the agent when to use it: when someone pastes a report link or asks about a check that was already run. It also gives a direct alternative behavior ('instead of checking the site again'), which is strong usage guidance relative to 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?

Annotations already indicate read-only and idempotent behavior. The description adds transparency by noting it returns the 'latest stored check', implying no live check is performed. It does not mention potential errors or rate limits, but given the read-only nature and existing annotations, this is acceptable.

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

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

The description is concise yet informative, using three sentences to convey purpose, usage, and output. No redundant text; every sentence adds value and the structure flows logically.

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 an output schema, the description adequately describes what the tool returns: latest stored checks per spec and open issues with fixes. It also implies prioritization ('what to fix first'), giving users a complete picture of what to expect.

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 'site' is fully described in the schema with examples, and the description reinforces its usage by referencing list_monitored_sites. The meaning is crystal clear with no ambiguity.

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 function: retrieving the latest stored checks and open issues for a single monitored site. It also distinguishes from the sibling tool check_site by specifying that this is for already monitored sites, making the purpose unambiguous.

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?

Explicit usage guidance is provided: 'Use this when someone asks what is wrong with a site they monitor, what to fix first, or when it was last checked.' It also directs users to pass the domain or site id from list_monitored_sites, and explicitly says to use check_site for non-monitored sites, leaving no ambiguity about when 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?

Annotations already establish the tool as read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond annotations, including the requirement for a connected Orbilo account and the quota visibility ('how many sites the plan still allows'), which helps set expectations 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 compact and front-loaded: the first sentence states the primary action and output contents, and the second sentence gives user-intent triggers plus a prerequisite. No wasted words or redundant restatement of the title.

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, the description sufficiently covers what the call returns, when to call it, and what conditions are required. An agent has enough information to select and invoke this 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?

The input schema has zero parameters and the schema description coverage is 100%, so there is nothing for the description to add at the parameter level. Per the baseline for zero-parameter tools, a score of 4 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 uses a specific verb and resource: 'List the sites your Orbilo team monitors,' and enumerates exactly what is returned (latest grade per spec, open issues, remaining plan allotment). This makes it clearly distinct from siblings like check_site, get_site_status, and get_report.

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: 'Use this when someone asks what they are monitoring, how their sites are doing, or whether they can add another site.' It does not name exclusions or alternative tools, but the usage context is clear and actionable, plus it notes the connected-account prerequisite.

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