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

Annotations already declare a non-read-only, non-destructive, non-open-world mutation. The description adds that the note is saved to "local history," which confirms local-only behavior, but it does not describe return values, permissions, or side effects beyond that.

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 clause adds useful context about what is saved and where.

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 mutation tool, the description covers purpose and note content adequately. It leaves gaps around booking_id semantics and expected behavior, but annotations and schema still provide the core safety and validation details.

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. It gives useful meaning for the "note" parameter via examples, but it does not explain "booking_id" at all, leaving one of two required parameters semantically undocumented.

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 ("Saves") and resource ("something the user said about a booking") plus the destination ("local history"). It is clear what the tool does, though it does not explicitly contrast itself with siblings like get_booking_history.

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 parenthetical examples ("how it went, who came, what to change next time") imply when to use it for capturing user feedback. However, it does not state when not to use it or name an alternative 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 flag destructive, non-idempotent and open-world, and the description adds genuinely new context: prerequisite token liveness, invalidation when the confirmation page changed since prepare, and the exact condition under which 'confirmed' is reported. This tells the agent how failures manifest and how to interpret success, which annotations alone cannot 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?

Four short sentences, front-loaded with what the tool does, then precondition, then failure modes, then success criterion. Every sentence carries distinct operational information; nothing is repeated from annotations or 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 destructive, non-idempotent confirmation tool with one opaque token and no output schema, the description covers prerequisite, invalidation condition, failure modes, and the meaning of a success result – enough for an agent to call it safely and interpret the outcome.

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% and the single parameter (confirmation_token) is never described in format or shape beyond the implied 'live token' from prepare. It adds origin context but not the length/reuse/expiry semantics an agent needs for the one required parameter, so it neither compensates fully nor leaves the gap unaddressed.

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 and effect ('Places the booking') and ties it explicitly to the artifact produced by the sibling prepare_booking, so the agent can distinguish this from the prepare step and from the read-only siblings without opening the 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?

Gives an explicit precondition ('Only call after the user has seen that summary and said yes') and names the alternative that produces the required input. Nothing about when-to-call 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description usefully signals that results come from Tabelog's own index rather than an external geocoder, but it says nothing about what comes back (candidate names, IDs, counts) or how to feed a result back into a search — relevant since there is no output 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?

Two tight sentences: what it returns first, when to use it second. Zero filler, no repetition of the title, and the important context 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 single-parameter read-only lookup with full schema coverage and no output schema, this covers purpose and trigger adequately. The only real gap is what a result looks like and how to use it to correct resolved_area, which a short clause could have closed.

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 itself supplies the format guidance with examples (銀座, 恵比寿駅) plus length bounds. The description only restates 'Japanese place name', adding no syntax or normalization hints, so the baseline 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 establishes that this returns Tabelog's own place-name suggestions covering stations, towns, and areas, which distinguishes it from restaurant-search siblings like search_restaurants. The verb is implicit ('suggestions for') rather than an explicit 'look up', but the resource and scope are 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?

'Use when a search's resolved_area looks wrong' gives a concrete triggering condition tied to another tool's output, which is exactly the kind of routing signal an agent needs. It stops short of naming alternatives or stating when not to use it, 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?

Beyond the read-only/open-world annotations, the description discloses several important behavioral traits: unset options come from saved preferences, walking time is estimated from map distance rather than transit, the call takes 30 seconds to 2 minutes, and the result includes walking minutes and open times. These are exactly the operational details an agent needs before invoking it.

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, front-loaded with the primary purpose, and every sentence adds useful information about scope, defaults, estimation caveats, or latency. There is no 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 13-parameter search tool with no output schema, the description is largely complete: it explains what is returned, how defaults are applied, and the main caveat about walking-time estimation. It stops short of mentioning some parameters such as budget and max_results, but those are partly covered by the 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?

With only 54% schema description coverage across 13 parameters, the description meaningfully supplements the schema by documenting defaults for unset options: dinner 17:00–20:00, business private room, and 15-minute walking limit. It also explains that walking time is an estimate. It does not cover every parameter, but it adds important 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 names a specific verb and resource: it finds restaurants within walking range of multiple locations that are bookable online. It is clearly a search tool and conveys the business-dinner context. It does not explicitly distinguish itself from the sibling search_restaurants or get_availability tools, so a 4 rather than 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?

The description frames this as the main search for business dinners and describes the intended context: locations, bookable slots over the next days, optional private room. It does not explicitly name alternatives or say when not to use it, so it lacks the explicit routing guidance 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 declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the return vocabulary (open / few_left / full), which is genuinely useful behavioral context, but says nothing about freshness, scraping cost, rate limits, or failure modes for a live third-party booking calendar.

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 compact clauses, each one mapping a calling pattern to a result shape, with the no-parameter case front-loaded. No filler or restated metadata.

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 lookup with no output schema and only three parameters, the description covers the result shape well enough to call the tool correctly and interpret the response. Minor omissions are the restaurant_url requirement (already in the schema) and any note on how stale the availability data may be.

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 only 33% (only restaurant_url is documented), so the description must carry weight — and it does, explaining the compositional semantics: date alone yields party-size availability, date+party yields bookable times. Format constraints (YYYY-MM-DD, party 1-50) are left entirely to 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 returns at three ascending levels of detail (calendar day status, party sizes for a date, bookable times for date+party), which is a precise resource statement rather than a restatement of the name. It does not explicitly differentiate itself from sibling find_available_restaurants, which is the main remaining gap.

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 'With date:' / 'With date and party:' construction effectively tells the agent which call shape to use for which question, which is real usage guidance baked into the parameter documentation. It stops short of stating when to prefer this over find_available_restaurants or prepare_booking.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description still adds real value by disclosing the sort order and the set of fields returned, but it says nothing about pagination/limit behavior or whether results are scoped to the authenticated user.

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 single fragment sentence is dense and front-loaded with the resource and ordering before the field list. Nothing is wasted, though the list-style phrasing sacrifices a little readability.

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, enumerating the returned fields is genuinely useful and largely covers the return value. However, the tool has three optional parameters whose semantics are absent from both description and schema, so the definition is not fully complete for an agent deciding 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 description coverage is 0% for all three parameters, so the description must carry the burden for limit, status, and purpose. Instead, 'status' appears only as a returned field, never as a filter, and neither limit nor purpose is mentioned, leaving the agent to infer filtering capability purely from raw enum definitions.

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 past bookings made through this server and adds the ordering (newest first), which lets an agent distinguish it from mutation siblings like prepare_booking or confirm_booking. It never names a sibling explicitly, and the verb is implied rather than stated, 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?

There is no statement of when to call this versus alternatives such as show_booking_window or get_availability, and no mention of the filtering options an agent could use. Usage can only be inferred from the phrase 'past bookings,' which is minimal guidance for a tool with three optional filters.

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 that this is a safe read-only, non-destructive, closed-world operation. The description adds valuable transparency about provenance: saved preferences come from what the user said, while learned preferences are inferred from confirmed bookings, which helps an agent interpret reliability of the data.

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 distinction between saved and learned preferences. The parenthetical field lists are efficient, though they make the sentence slightly harder to scan at a glance.

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 read-only tool with no output schema, the description gives a solid inventory of returned data and distinguishes saved from learned sources. The only meaningful gap is the unmentioned 'purpose' filter and the absence of usage guidance, but the core return content is adequately covered.

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 optional 'purpose' parameter is fully documented in the schema, including its business default. The description does not mention this parameter or add any semantics beyond the schema, so it meets but does not exceed the baseline for high schema coverage.

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 saved and learned booking preferences, and enumerates the kinds of data returned (seating, party size, budget, genres, areas, etc.). It does not explicitly contrast with the sibling set_preferences, but the read-oriented 'saved/learned preferences' framing makes the purpose distinguishable.

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 what the tool returns but gives no guidance on when to call it versus set_preferences or other booking tools. There are no conditions, prerequisites, or exclusions to help an agent choose this tool over its 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 readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful field-level context by listing the restaurant data returned, but it does not describe authentication needs, rate limits, failure modes, or response structure beyond the field names.

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 compact sentence with the scope front-loaded and a concise field list. It is appropriately sized, though "information table" is slightly telegraphic compared with using a clear retrieval verb.

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 read-only lookup with one fully documented parameter and safety annotations, the definition is largely complete. Because there is no output schema, enumerating the returned fields adds helpful context; only error behavior or URL validation details are missing, which are minor for this 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 description coverage is 100%, and the sole parameter is fully documented as a tabelog.com restaurant page URL returned by search_restaurants. The description does not add syntax, validation, or format detail beyond what the schema already provides, 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 clearly states that this tool returns Tabelog information for one restaurant and enumerates the fields available, such as genre, address, hours, budget, and payment. It distinguishes a single-restaurant lookup from list/search tools by scoping to "one restaurant," though it does not explicitly name search_restaurants as the alternative.

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 explicit when-to-use guidance, prerequisites, or alternatives. The only routing cue is the phrase "for one restaurant," while the schema separately notes that restaurant_url comes from search_restaurants.

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?

Discloses behavior well beyond the annotations: a Chrome window opens, sign-in may be required, the token is single-use with a 5-minute TTL, and each of the four return statuses is spelled out. This is consistent with readOnlyHint=false and destructiveHint=false (it mutates a form but books nothing).

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?

Front-loads the core constraint in the first clause, then enumerates return statuses compactly. Dense but every clause carries information an agent needs.

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?

No output schema exists, so the description carries the return-value burden and does so fully: status names, token lifetime and single-use semantics, and the user-handoff condition. Nothing needed to call it correctly 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?

With only 57% schema coverage, the description compensates by explaining the plan parameter's role in the choose_plan loop and by naming the cases (card, code, unknown field) that fall to needs_user. It adds little on date/time/party, but those are self-evident and pattern-constrained.

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 and resource ('Fills Tabelog's booking form') with the crucial scope boundary 'up to, never through, the final button' and repeats 'Books nothing'. Combined with the title 'step 1 of 2', an agent can cleanly separate it from confirm_booking.

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?

Implicitly routes the agent: 'call again with plan' for choose_plan, 'the user finishes' for needs_user, and 'Books nothing' signals that confirm_booking is the next step. It never names the sibling confirm_booking explicitly, so one inference is left.

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, openWorldHint=true, and destructiveHint=false, so safety is covered. The description adds real behavioral context the annotations do not: page size of 20, that 'total' is Tabelog's own count (not a computed value), and that per-result booking times are only populated when date, time, and party are supplied.

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, front-loaded with purpose, then the conditional result behavior, then pagination. No filler and nothing repeated from the schema or 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?

With 11 optional parameters, no output schema, and low schema description coverage, the description does a fair job explaining result shape and pagination but leaves several filters (sort, budget_for, budget_max_yen, private_room, online_booking_only) without prose support. An agent can call it, but may pick filters incorrectly.

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 low at 27% across 11 parameters, so the description carries extra burden. It explains the conditional interaction between date/time/party and the returned booking times, but says nothing about area/keyword language expectations, sort options, budget fields, or private_room, leaving most parameters defined only by bare schema types.

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 and resource ('Search restaurants') and scopes it to Tabelog's filter set, which separates it from generic listing tools. It does not explicitly distinguish itself from the closer siblings find_available_restaurants and get_availability, so an agent must infer the boundary.

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 by the phrase 'Search restaurants with Tabelog's filters' and by the conditional note about date/time/party, which hints at when the richer result appears. However, there is no explicit when-to-use or when-not-to-use guidance versus find_available_restaurants, get_availability, or find_area.

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 that this is a non-destructive write operation. The description adds useful behavioral context by explaining that the saved value becomes a default for later searches and bookings, but it omits critical mutation semantics such as whether omitted fields are cleared or whether existing preferences are merged or replaced.

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 states the action and effect without filler. The enumerated fields are dense but appropriate for orienting the agent quickly.

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 an 11-parameter write tool with no output schema and low schema coverage, the description covers purpose and persistence but leaves important gaps: whether this replaces or merges existing preferences, what happens to omitted fields, and how the time-window parameters are formatted beyond the schema patterns.

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 low at 27%, so the description must compensate. It does map several parameter groups to natural-language concepts (seating windows, party size, private room, walking limit, budget, note), but it does not explain formats, units, or the lunch/dinner time distinction beyond what the parameter names already imply.

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 (saves) and resource (lasting preference) and enumerates the kinds of preferences stored. It clearly distinguishes saving from reading preferences, though it does not explicitly name get_preferences as the read counterpart.

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 clear usage context: save when the user states a lasting preference that should become the default for later searches and bookings. It does not state when not to use it or mention alternatives, which keeps it 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?

The annotations already declare this as read-only, non-destructive, and not open-world. The description adds useful behavioral context beyond annotations: it surfaces a Chrome window and hands control back to the user for manual completion, which tells the agent this is an interactive UI action rather than a data-returning operation.

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 sentence that front-loads the action and follows with the reason. Every clause earns its place by combining purpose and usage context without repetition.

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 zero-parameter schema, rich annotations, and no output schema, the description provides enough information to select and invoke the tool correctly. A minor gap is that it does not state what happens if no current booking exists, but the core behavior and manual-completion scenario are clear.

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 no parameter semantics burden. The baseline for a zero-parameter tool is 4, and the description does not need to compensate for schema gaps.

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: it brings the Chrome window with the current booking on-screen. It also explains the intended outcome, letting the user finish a needs_user booking manually. It does not explicitly contrast itself with sibling tools such as prepare_booking or confirm_booking, so it falls short of full 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 phrase 'so the user can finish a needs_user booking by hand' gives clear usage context: this tool is for bookings in a needs_user state that require manual completion. It does not list exclusions or name alternative tools, but the triggering condition 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?

Beyond the annotations (which only say non-readonly, non-destructive, open-world), the description discloses that this blocks/waits on a human, that credentials never reach the tool, and that the session persists in the local browser profile. That is exactly the behavioral context annotations cannot convey. It stops short of saying what happens if the user never completes login before the timeout.

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 short sentences, front-loaded with the optionality warning so an agent stops reading early if it doesn't need the tool. Every sentence adds a distinct fact: optionality, alternative, mechanism, credential safety, session persistence.

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?

A one-parameter, no-output-schema tool is well covered: the agent knows it launches a browser, waits for a human, and leaves a persistent session. Only the timeout semantics and post-timeout state are unaddressed, which is minor for this 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 single parameter timeout_minutes has zero schema description coverage, and the description never names or explains it — no statement of what happens when the wait expires or whether the session is kept. The name and default/range in the schema make it inferable, so this is a gap rather than a failure.

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 concrete action (sign in) against a concrete resource (Tabelog) and describes the mechanism: opens the Chrome window on the login page and waits for the user. It also distinguishes itself from prepare_booking, which handles sign-in implicitly, so an agent can tell the two apart without opening a 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?

Explicitly marks itself as optional and says prepare_booking already signs in by itself when needed — a direct when-not-to-use rule plus a named alternative. That is the highest-value guidance an agent can get for a redundant-looking auth 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 cover readOnly/openWorld/non-destructive, but the description adds genuinely new behavioral facts beyond them: the expiry is read from Tabelog's session cookie captured at sign-in (implying staleness), and the call can spawn a background Chrome process as a side effect. That side effect is exactly the kind of trait annotations do not 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?

A single dense sentence that front-loads the returned information and closes with the side-effect caveat. Every clause carries information, though the phrasing 'Where data is stored' is slightly oblique compared with a plain 'Returns the data directory'.

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 carries the burden of describing return values and does so by naming all three fields; combined with the zero-parameter schema and read-only annotations, an agent has enough to call it correctly. It stops short of stating the response shape or what the storage path actually looks like.

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?

Zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate and it correctly avoids inventing 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 enumerates the three concrete facts the call reports (storage location, sign-in state for this browser profile, sign-in expiry), which is specific enough to distinguish it from siblings like tabelog_login or get_preferences. The verb is implicit (a noun phrase rather than 'Returns...'), which keeps it just 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?

Usage is implied rather than stated: an agent can infer this is a diagnostic/pre-flight call, but the description never says when to call it or that tabelog_login is the follow-up when the profile is not signed in. No exclusions or alternatives are named.

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