Riverview Office Cleaning

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

Goes well beyond the annotations (readOnly=false, openWorld=true) by disclosing the side effects: the office is emailed and a confirmation goes to the supplied email. It also decodes the three possible outcomes — 'booked', 'requested', 'unavailable' — which is behavioral information the agent needs and no annotation could supply.

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

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

Four compact sentences, front-loaded with the action before the preconditions and status semantics. No filler, and the status decode is placed last where it supports the call decision.

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, yet the description supplies the return semantics the agent actually needs (three status values) plus the notification side effects and the confirmation prerequisite. For a 9-parameter mutation tool, nothing essential is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds only mild extra meaning, clarifying that slot_start must be an exact value from list_walkthrough_slots and reinforcing that email receives the confirmation. Both are close to what the schema already states, so the lift is modest.

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

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

States a specific verb+resource ('Books a free on-site walkthrough') and immediately scopes the input source ('at a time from list_walkthrough_slots'). This distinguishes it clearly from siblings like list_walkthrough_slots and check_service_area.

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 ties the call to a slot produced by list_walkthrough_slots and instructs the agent to confirm time and details with the user before calling, which is genuine when-to-use guidance. It stops short of naming explicit exclusions or alternatives beyond that dependency, so it is clear context rather than full 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?

Annotations already declare readOnly, idempotent, and non-destructive behavior, so safety is covered. The description adds genuine domain context beyond the annotations: it discloses the business rule that online booking is gated on service-area membership. It does not describe the return shape, but adds real behavioral value.

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

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

Two tight sentences with zero filler, and the core purpose is front-loaded ahead of the booking constraint. 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 single-parameter, read-only lookup with no output schema, the definition is largely complete: it conveys purpose and the downstream booking constraint. It is slightly short on what the check returns (presumably a boolean) and how ambiguous city names are handled, but 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 coverage is 100% and the 'city' parameter is already documented with a concrete example ('Solon' or 'Solon, OH'). The description adds nothing about parameter format or matching semantics, so the baseline of 3 for a fully-covered schema 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 states a specific check ('Whether Riverview regularly serves a city') tied to a named resource, and the name/schema make the verb+resource unambiguous. It does not explicitly differentiate itself from siblings like book_walkthrough, though it hints at the relationship, so it stays below 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?

Usage is implied rather than stated: the note that 'Walkthroughs can only be booked online for cities in the service area' suggests calling this before book_walkthrough, but there is no explicit 'use this when...' guidance or named alternative. The link to the sibling is inferable but not spelled out.

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 readOnlyHint, idempotentHint, and destructiveHint=false. The description adds genuine business context beyond that: pricing is not quoted directly, a free on-site walkthrough is required, and the published per-square-foot range is a guide rather than a quote. This is useful behavioral framing that the annotations do not supply.

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

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

Two tight sentences with no filler. The content scope is front-loaded and the pricing caveat follows immediately, earning its place by preventing the agent from presenting a range as a firm quote.

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-param read tool with full annotation coverage and no output schema, the description is nearly complete, as it enumerates the information categories returned. It does not detail response format, but that 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 zero parameters, so the schema imposes no semantic burden and the baseline is 4. Nothing in the description needs to compensate for a 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 names a specific resource and enumerates its contents (services, contact details, hours, service area, pricing model), so an agent knows exactly what this returns. It is clear but does not explicitly contrast itself with siblings like search_faq or check_service_area, which also surface overlapping business facts.

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 explicit when-to-use guidance or named alternative. The remark that quotes require a walkthrough implies book_walkthrough is the path for pricing, but the routing is left to inference rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the 45-minute slot duration, the America/New_York timezone, and the bookable window constraint. It stops short of describing pagination or the shape of the returned slots.

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 tight sentence covering what the tool returns and the two most decision-relevant constraints (timezone, bookable window). Zero filler and front-loaded with the resource.

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-optional-parameter read-only availability tool with no output schema, the description supplies the key domain context an agent needs: timezone, slot length, and bookable horizon. Only minor gaps remain, such as whether results are grouped by day or how many slots are returned.

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 both parameters (days, start_date) are fully documented in the schema itself. The description adds no parameter-level detail such as how 'days' interacts with the 21-day maximum, so the 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 names the specific resource (open start times for a free 45-minute on-site walkthrough) and adds distinguishing scope details like timezone and booking window. It clearly reads as a listing/availability tool distinct from the sibling book_walkthrough, though it never explicitly contrasts itself with that 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?

Usage is implied: an agent can infer this is the tool to consult before booking, and the bookable window (24 hours out to 21 days) frames when results are valid. However, there is no explicit when-to-use statement or reference to book_walkthrough as the follow-up action, so the guidance remains inferential.

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 two genuinely useful behavioral facts: results are fuzzy 'closest matches' rather than exact hits, and an empty argument returns the full FAQ set. It says nothing about result limits or ranking, so the value added is modest.

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

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

Two tight sentences with no filler; the subject scope is front-loaded in the parenthetical list and the invocation behavior follows immediately. Every clause carries information the agent can act on.

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 one optional parameter, no output schema, and rich annotations, the description covers what the tool answers and how to call it. It stops short of describing the shape of the returned matches (e.g., ranked list, count), but for a simple lookup tool that gap is 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?

Schema coverage is 100% and the schema already gives an example value for 'question', so the baseline is 3. The description goes slightly beyond the schema by disclosing the semantics of omitting the parameter (returns every FAQ), which the schema alone does not state, even though the parameter is optional.

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 resource and action (search FAQ / common questions) and enumerates the covered topics (cost, insurance, contracts, start times), so the agent knows exactly what domain of questions it answers. It does not, however, differentiate itself from the similarly informational sibling get_business_info, leaving some routing ambiguity.

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 explains how to invoke the tool (pass a question for closest matches, or nothing for every FAQ), which is invocation guidance rather than when-to-use guidance. It never names an alternative sibling or states a condition under which a different tool (e.g., get_business_info) would be preferable, so the when/when-not is only implied.

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