whitelabel-ordering

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

Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing polling semantics, the absence of background tracking, the absence of notifications, and the need to re-invoke on demand until a terminal state. These are exactly the behaviors an agent cannot infer from structured fields.

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 earning its place: purpose, what is reported, and the polling constraint, with the purpose front-loaded. 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?

Despite having no output schema, the description enumerates the possible reported outcomes (accepted, on its way, delivered, declined) and the polling lifecycle, which is everything an agent needs to interpret and re-call the 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 coverage is 100%, so orderId's origin ('returned by place_order') is already documented in the schema and the description mostly echoes it. It adds no guidance on clientId beyond what the schema already says, so 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?

States a specific verb (check) and resource (order status) and scopes it to 'an order the user has already placed', which separates it cleanly from place_order and prepare_order. It even enumerates the states it reports.

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?

Clearly establishes the usage context: call after place_order, when the user asks, and only until the order is finished. It stops short of naming sibling tools to avoid, but the polling condition and terminal-state cutoff give an agent enough to use it correctly.

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 and openWorldHint=false, so the safety profile is covered. The description adds useful scope detail (per-restaurant grouping, active-account flag) but says nothing about return shape or ordering, and there is no output schema to compensate.

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 the core purpose front-loaded; the second sentence earns its place by supplying the scenario that motivates the call.

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, parameterless read tool with good annotations, the description covers purpose, scope, and motivation. Only marginal gaps remain, such as not hinting at the returned shape, which is minor given the absence of an 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?

The tool takes zero parameters, so there is nothing to document; the description correctly adds no parameter guidance and the schema is fully specified (additionalProperties false).

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 ('Show which accounts are signed in'), plus scope ('per restaurant') and state ('which one is active'). It is clearly distinguishable from login/logout/switch_account siblings, though it never names them explicitly.

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 second sentence gives an implied usage context ('when the user keeps separate work and personal accounts'), but there are no explicit when-to-use rules or routing to alternatives such as switch_account or logout.

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 and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the return value is an HTML document that must be opened as an artifact rather than pasted as chat text. It says nothing about permissions or rate limits, but those are low-risk for a read-only listing.

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 sentences, zero filler, and the output-format instruction is front-loaded ahead of the parenthetical exclusion for ordering. 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?

There is no output schema, so the description carries the burden of explaining the return value, and it does so concretely (HTML artifact, not chat text). Combined with the optional-parameter guidance already in the schema, an agent has everything needed to call 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 description coverage is 100%, and the schema already explains that clientId/vendorId come from a list_vendors result and may be omitted in single-restaurant setups. The description adds no further parameter meaning, 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?

States a specific verb (show) and resource (the restaurant's menu) and further specifies the rendered form: a horizontally-scrollable category strip with photos, names and prices. It also distinguishes itself from prepare_order, so an agent can tell it apart from siblings without opening 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?

Gives an explicit when-not condition: ordering does not require this tool because prepare_order resolves item names on its own. It names the alternative sibling directly and the circumstance that selects it, leaving nothing 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 only say readOnlyHint=true and openWorldHint=true; the description adds substantial context beyond them — the return is a self-contained HTML document, restaurants open today are colour-coded and closed ones greyed at the bottom, and the mandated rendering behaviour. This is exactly the kind of disclosure annotations cannot carry.

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?

Purpose and the no-argument default are front-loaded, followed by return shape and presentation guidance. Every sentence is functional; nothing is 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?

There is no output schema, so the description correctly compensates by describing the returned HTML document's content and ordering, plus how to render it. For a one-parameter discovery tool this is fully specified.

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's schema description already carries the caution. The description reinforces semantics by framing the argument-less call as the default case, which tells the agent the parameter is truly optional in practice — a modest but real addition over 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?

States a specific verb+resource ('Find restaurants (vendors)') and positions itself explicitly as 'the discovery entry point' that produces the clientId/vendorId consumed by list_menu and prepare_order. This distinguishes it from all siblings without opening their 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 says to call with no arguments as the normal case, and gives an exclusion rule for the one parameter ('Pass this ONLY when the user named a city themselves; never guess one from context'). It also tells the agent how to present output (open as HTML artifact, don't paste markup).

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 only cover the safety profile (readOnly=false, idempotent=false, destructive=false); the description supplies the operational behavior annotations cannot express: the call returns a URL the user must open out-of-band, the user must copy a 'code' from the address bar, and a second tool call completes the flow. The only arguable tension is that openWorldHint=false while the flow involves Google/Apple sign-in, but that interaction happens outside the tool, which itself only mints a URL.

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, each doing distinct work: purpose, exclusion, return-and-continuation mechanics, and per-restaurant scope. The key fact (returns a URL, follow up with submit_login_code) is front-loaded in the third sentence with 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?

There is no output schema, and the description compensates by describing exactly what the call returns (a URL) and what the agent must do with it. Combined with the per-restaurant scope and the named follow-up tool, an agent has everything needed to run the full login flow 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 clientId parameter is already fully documented in the schema (including the omit-when-single-restaurant case). The description reinforces why a restaurant must be identified ('each restaurant has its own login'), which is mildly useful context but mostly restates the schema rationale, 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?

States a specific verb and resource ('Start signing the user in to a restaurant') plus the goal ('so they can place orders'). It explicitly carves out the sibling boundary — browsing the menu never needs this — so an agent can rule it out without inspecting other 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?

Gives explicit when-to-use (ordering, saving an address), explicit when-not (browsing the menu), and names the follow-up tool (submit_login_code) that must be called afterward. It also states the per-restaurant constraint that governs when the tool applies at all.

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 destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the default is a broad, account-wide sign-out, so an agent knows the blast radius of omitting parameters. It omits consequences such as session/token revocation or the need to re-authenticate, keeping it from a 5.

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 sentence that front-loads the default behavior and then the two narrowing options. Every clause carries information; there is 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?

With no output schema, zero required parameters, and annotations covering safety, the description supplies everything needed to invoke the tool correctly across all three modes. It could be slightly more complete by noting what a signed-out session implies (e.g., re-login required), but nothing essential for correct invocation 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 description coverage is 100%, so both parameters are already documented in the schema, including the omit-to-widen behavior. The description restates the same omission semantics without adding format, validation, or edge-case detail, 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?

States a specific verb and resource ('Sign the user out') and immediately enumerates the three scope levels: all restaurants by default, one restaurant via clientId, one account via label. This clearly separates it from siblings like login and switch_account, which perform different session operations.

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 selection rules for each mode of use (omit both = everywhere; clientId = one restaurant; label = one account), which is effectively when-to-use guidance at the parameter level. It stops short of naming an alternative tool or a when-not-to-use condition, so it does not reach 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 cover the safety profile (destructiveHint=true, idempotentHint=false, openWorldHint=true), and the description adds the concrete consequence — a real order is sent to the vendor — which gives the agent operational context beyond the structured hints. It does not describe failure behavior, but the key irreversibility is conveyed.

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 the action and its prerequisite, with zero redundant padding. Every sentence carries a distinct fact (what it does, what it needs, what side effect it triggers).

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 rich annotations and no output schema, the description covers the prerequisite, the token dependency, and the real-world side effect. Only minor gaps remain, such as error/failure behavior, but nothing essential to invoking 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?

Schema description coverage is 100% and the single parameter's meaning is already documented in the schema as 'the confirmationToken returned by prepare_order.' The description restates exactly this, so it adds no meaning beyond the schema; 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?

States a specific verb (place) and resource (order) and explicitly distinguishes itself from the staging sibling prepare_order. An agent can tell it apart from prepare_order and check_order without opening any 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 states the prerequisite: the order must first be staged by prepare_order and the call requires the confirmationToken it returned. It does not state when not to use it, but the staged-then-confirm flow is unambiguous.

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 declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the safety profile is partly covered. The description adds genuinely new behavior: the two-step token handoff to place_order, the ASAP default, the one-delivery-per-call rule, and that the restaurant may refuse an unopened time. It does not explain token expiry or what the summary contains, so it falls short of 5.

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?

Roughly four sentences, each carrying a distinct rule, with the non-placement caveat and the confirmation-token handoff front-loaded. 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 prepare-then-confirm flow with no output schema, the description supplies the missing return semantics (summary + token) and the follow-up tool, while the schema fully covers every parameter. An agent has everything needed to call it and act on 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 schema already documents all 8 parameters in detail (date default, size rejection, repeat-to-double extras). The description adds only light framing (each call covers one delivery), which is the expected baseline when the schema does the heavy lifting.

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 precise verb+resource: resolve a natural-language food order to concrete menu items and return a summary plus confirmation token. It explicitly distinguishes itself from the sibling place_order, which is the key disambiguation an agent needs here.

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 when/when-not: 'Does NOT place the order. Call place_order with the returned token to actually place it.' It also states the default (ASAP delivery), how to override it (pass 'date'), and the one-call-per-delivery constraint.

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 cover the safety profile (readOnlyHint=false, idempotentHint=false, openWorldHint=true), and the description adds the meaningful outcome that the user can then 'place orders from that restaurant'. It does not disclose failure modes such as an invalid or expired code, but it adds real domain context beyond 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?

Two tight sentences, front-loaded with the action and the key input source. 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?

With no output schema and full annotation coverage, the description supplies the essential missing context: the code's origin and the post-success state. A note on handling ambiguous clientId or failed/expired codes would make it fully 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 coverage is 100%, so code, label, and clientId are already fully documented. The description only contextualizes the 'code' origin (browser address bar), which is marginally richer than the schema's 'redirect URL' wording; it says nothing about label or clientId. 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?

States a specific verb and resource ('Complete a sign-in') and explicitly ties it to the prior 'login' step, which distinguishes it from the sibling login tool. An agent can identify this as the second half of a two-step flow 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?

The description clearly states when to use it: after 'login', with the code the user copied from the address bar. It names the prerequisite tool but does not state exclusions (e.g. expired code, already-signed-in) or how it relates to switch_account/logout.

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 idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the meaningful behavioral precondition that the target account must already be authenticated via login, which is not derivable from the annotations or 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 compact sentences with the purpose and example front-loaded and the precondition last. No redundant restatement of the title or annotations, and every clause carries information.

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-parameter, annotation-covered tool with no output schema, the description covers what it does, when to use it, and the authentication requirement. It omits whether an in-flight or prepared order is affected by switching accounts, a minor but plausible agent question.

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 'label' and 'clientId' are already documented in the schema, including the single-restaurant omission rule. The description adds no format or constraint detail beyond that, 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?

States a specific verb and resource ('Choose which signed-in account to order with') with a concrete scope ('at a restaurant'). The final sentence explicitly separates it from the login flow, so an agent can distinguish it from siblings like login, logout, and list_accounts 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?

Gives a clear use case ('to switch between work and personal') and an explicit precondition ('must already be signed in via login'). It stops short of naming an alternative for the not-signed-in case (i.e., use login first), which leaves a small inference for the agent.

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