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

With no annotations, the description carries the full behavioral burden. It discloses the auth requirement, which is useful, but says nothing about side effects, whether the new address becomes a default, duplicate handling, or validation behavior for a mutation 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 purpose sentence is front-loaded and the argument list is structured and scannable. Nothing is redundant, though the bare 'Args:' block is functional rather than polished.

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?

An output schema exists, so return values need not be explained, and all parameters plus the auth requirement are covered. However, for a mutation tool with no annotations, the description leaves behavioral gaps (side effects, default-address semantics) that would matter to an agent.

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%, so the description must compensate, and it largely does: it documents all 7 parameters with clarifications like 'State abbreviation (e.g. NY, CA)' and 'Label for the address (e.g. Home, Work)'. It does not mark which of the fields are optional, but the per-field guidance is solid.

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 ('Add a new delivery address'), making the operation immediately clear. It does not explicitly differentiate itself from the read-side sibling get_addresses, but the write intent is 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?

Provides a prerequisite ('Requires authentication') and the usage is implied by the name, but it never states when to use this versus alternatives like get_addresses, nor any conditions under which adding should not be done.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the authentication requirement, which is a plus, but says nothing about idempotency, what happens if the restaurant is already favorited, or error behavior for an invalid ID.

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 short sentences with the core action front-loaded and the auth prerequisite immediately after. The trailing 'Args:' block is slightly redundant with the schema but is compact enough not to hurt 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?

An output schema exists, so return values need not be explained, and the tool is a single-parameter mutation. Still missing is how to obtain a valid restaurant_id and what happens on duplicate favorites, which would matter 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?

Schema description coverage is 0%, so the description must carry the parameter burden. Instead it only restates the field name ('The restaurant ID to favorite'), adding no source, format, or example for obtaining restaurant_id, which matters given siblings like search_restaurants and get_restaurant.

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: 'Add a restaurant to favorites'. An agent can identify the action immediately, but the description never names the sibling remove_favorite or otherwise distinguishes itself from adjacent favorites 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?

'Requires authentication' is a useful prerequisite, implicitly telling the agent a session must exist before calling. However, there is no guidance on when to prefer this over related tools like get_favorites or remove_favorite, so usage context is only implied.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a mutation but says nothing about auth requirements, errors when the cart is invalid, or whether re-adding the same item merges quantities or creates a duplicate line.

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 purpose sentence is front-loaded, followed by a compact args list with zero filler. Slightly list-like, but every line 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?

An output schema exists, so return values needn't be explained, and all params are covered. However, for an unannotated mutation tool it leaves gaps around failure modes and prerequisites beyond the implicit 'existing cart' hint.

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, and it largely does: it documents all five params including defaults (quantity 1, special_instructions '') and the options shape {id, quantity}. The options object type is left loosely described but the added meaning over the bare schema is substantial.

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: 'Add an item to an existing cart.' The qualifier 'existing' implicitly separates it from create_cart, though no sibling is named 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?

'Existing cart' implies the cart must already exist (via create_cart/get_cart), which is useful implied guidance, but the description never names alternatives like update_cart_item or remove_from_cart, nor states when-not to use it.

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

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

No annotations are provided, so the description carries the full burden. It does not state whether the card can be applied more than once, what happens on an invalid PIN, whether funds are held or drawn immediately, or any permission/auth requirement. For a mutation tool with zero annotation coverage this is a substantial gap.

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-loaded with a one-line purpose, which is good, but the trailing Args block largely duplicates the schema field names and consumes space without adding 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 3-parameter mutation tool with no annotations, the definition omits failure modes, idempotency, and prerequisites. The output schema exists, so return values needn't be explained, but the behavioral context is far too thin.

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. Its 'Args' block only restates the parameter names tautologically ('cart_id: The cart ID', 'pin: Gift card PIN'), adding no format, length, or validation meaning 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?

States a specific verb+resource ('Apply a gift card to a cart'), which is unambiguous on its own. It does not, however, differentiate from the closely related sibling apply_promo_code or explain how gift-card application differs.

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 when-to-use guidance, no prerequisites (e.g. cart must exist / not already have a card applied), and no mention of the sibling apply_promo_code or get_gift_card_balance. The agent must infer all context.

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

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

No annotations are provided, so the description carries the full behavioral burden and largely fails it: it does not say whether applying a promo replaces a prior one, whether codes stack, whether an invalid code errors or silently no-ops, or whether the operation is idempotent. For a cart-mutating tool this is a meaningful gap.

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?

It is short and front-loads the verb+resource, which is good. However, the 'Args' block is pure repetition of schema titles and wastes the only space available for real guidance, making this under-specified rather than genuinely concise.

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?

An output schema exists so return shape need not be explained, but nothing covers the mutation's side effects, error behavior, or interaction with the cart state. Given no annotations and no parameter documentation, the definition is too thin for a write operation in a cart workflow.

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, yet it only restates the parameter names as glosses ('cart_id: The cart ID', 'promo_code: The promotion code to apply'). It adds no format, case-sensitivity, or constraint detail beyond the schema titles.

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 first sentence names a specific verb and resource ('Apply a promotion code to the cart'), so an agent knows exactly what the tool does. It stops short of distinguishing this from the sibling apply_gift_card, which applies a different credit type to the same cart.

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 indication of when to use this versus apply_gift_card, nor any prerequisite such as the cart existing or a promo code being valid. The only implied usage is the obvious 'you have a promo code' case.

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

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

No annotations are provided, so the description carries the full behavioral burden. It only says it returns suggestions; it discloses nothing about authentication, rate limits, or what a suggestion object contains, though it does usefully surface the location_mode default.

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 purpose is front-loaded in a single clear sentence, and the Args block is compact and justified given the complete absence of schema descriptions. No filler sentences.

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?

An output schema exists, so return values need not be described. Combined with the parameter documentation, the description is nearly complete for a simple read tool, with the only gap being the absence of behavioral/auth context.

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% and no enum is defined, yet the description documents all four parameters in an Args block, clarifying that 'query' is partial text, lat/long are location context, and location_mode takes DELIVERY or PICKUP. This meaningfully compensates for the empty 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 and resource ('Get autocomplete suggestions for a search query'), which is clearer than a generic search tool. However, it does not distinguish itself from the sibling 'search_restaurants', leaving the agent to infer the autocomplete-vs-full-search boundary on its own.

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 name and phrase 'autocomplete suggestions' imply it is used for typeahead/partial input, but there is no explicit statement of when to use this versus 'search_restaurants' or any prerequisite/context. Usage is implied rather than documented.

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

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

No annotations are provided, so the description carries the full behavioral burden. It notes the authentication requirement but says nothing about whether other sessions/tokens are invalidated, what happens on an incorrect current_password, or whether the change is reversible — all material for a credential mutation.

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 action in one line, then lists args compactly with no filler. The preamble 'Requires authentication' before the args block is slightly awkward placement but still 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?

An output schema exists so return values need no explanation, but for an unannotated, security-sensitive mutation the description omits session invalidation behavior and failure modes. An agent could invoke it correctly, but not with confidence about side effects.

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, and it does not. The 'Args' lines ('current_password: Current password') merely restate the property titles, adding no format, length, or validation semantics.

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 ('Change account password'), which is unambiguous on its own. However, it draws no distinction from the closely related sibling send_password_reset, so an agent cannot tell which flow this belongs to from the description alone.

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?

'Requires authentication' gives a prerequisite, which is more than most siblings offer. But there is no when-to-use guidance versus send_password_reset (forgot-password flow) or update_profile, leaving the choosing to inference.

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

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

No annotations provided; description fails to disclose side effects (e.g., auto-login, verification email), error states, or idempotency, which is critical for a mutation tool.

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?

Single sentence is concise but underspecified for the complexity of account creation; it should include more context without excessive verbosity.

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 no annotations and no description of return values or behavior, the description is incomplete for a tool that creates sensitive resources.

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%; description mentions no parameters and adds no meaning beyond the schema, which is insufficient for a 4-parameter tool with no enums.

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 verb 'Create' and the resource 'new Grubhub account', distinguishing it from sibling tools like 'login' and 'logout'.

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?

No guidance on when to use this tool vs alternatives, no prerequisites (e.g., user not logged in), and no conditions like email uniqueness.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it does not state whether calling this discards or replaces an existing cart, whether authentication is required, or that changes are persistent. For a state-mutating creation tool sitting next to get_cart and add_to_cart, that missing lifecycle context is a meaningful gap.

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 purpose sentence is front-loaded and the Args list is justified by the 0% schema coverage rather than redundant. Some entries (latitude/longitude) add little, but overall the size is proportionate to an 8-parameter tool.

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

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

An output schema exists, so return values need no explanation, and all parameters are documented. What is missing is the behavioral wrapper an agent needs before calling a cart-creating mutation with no annotations: required auth/session state and what happens to any pre-existing cart.

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 Args block is the only documentation of the 8 parameters, and it usefully explains quantity's default, is_delivery's true/false meaning, that latitude/longitude are for delivery, and the shape of options entries ({id, quantity}) beyond the schema's untyped object. It stops short of ID formats or option validity rules, but it compensates well for the empty 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: 'Create a new cart with the first item.' The phrase 'new cart' hints at the distinction from add_to_cart (which presumably targets an existing cart), but the description never names or contrasts that sibling, so the differentiation is left to inference.

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 only implied: the reader infers this is the entry point when no cart exists yet and add_to_cart / update_cart_item handle subsequent items. No explicit when-to-use or when-not-to-use statement, and no mention of prerequisites (login/session) despite a cluster of auth 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?

No annotations are provided, so the description carries the full behavioral burden; it does disclose the authentication prerequisite, which is genuinely useful. However, for a zero-param read tool it adds nothing about scope, empty-result behavior, or whether the list is complete or paginated.

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 short sentences, purpose first, prerequisite second, with zero filler. Nothing could be removed without losing 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?

An output schema exists, so return-value details are not the description's responsibility, and a zero-param read tool needs little more than the purpose and auth note given. It could still mention relationship to add_address, but the definition is adequate for its complexity.

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 for the description to disambiguate; the baseline for a no-parameter tool applies. No misleading parameter hints are present.

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 (get) and resource (saved delivery addresses), which distinguishes it from the sibling add_address by operation type. It does not explicitly name the sibling or scope, but the purpose is 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?

There is no statement of when to use this versus alternatives such as get_profile or the address-adding sibling, and no exclusions. Usage is only inferable from the phrase 'saved delivery addresses'.

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

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

No annotations are provided, so the description carries the burden. 'Get the current state' implies a non-destructive read, which is the key safety fact for this tool, but auth requirements, error behavior (e.g., invalid cart_id), and freshness are not addressed.

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 and front-loaded with the core purpose, and there is no filler. The Args block is redundant but does not bloat the text significantly.

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?

An output schema exists so return values needn't be explained, and the tool is a simple single-param read. However, the absence of any usage or behavioral context leaves a gap for a tool embedded among many cart siblings.

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 only param info is the tautological 'cart_id: The cart ID', which adds no meaning beyond the parameter name. The description does not compensate for the schema's lack of documentation.

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

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

States a specific verb ('Get') and resource ('cart') and enumerates the returned content (items, totals, fees). It does not name or distinguish itself from nearby siblings like create_cart or get_order, but its purpose is 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?

There is no when-to-use guidance, no prerequisites, and no reference to alternatives such as create_cart or update_cart_item. The agent must infer context from the name alone.

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

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

With no annotations, the description carries the full burden. It usefully discloses the authentication requirement and the read-only nature implied by 'Get', but says nothing about pagination, ordering, or empty-list behavior, which is thin for an unannotated tool.

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 short sentences with no filler and the core purpose front-loaded. It is efficient, though the extreme brevity leaves the tool slightly under-explained.

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?

An output schema exists, so return values need not be described, and the parameterless read surface is simple. The auth note covers the main operational requirement; only minor gaps like empty-result handling remain.

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 per the rubric the baseline is 4. There is nothing for the description to clarify beyond what the empty schema already conveys.

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 (get favorite/saved restaurants), which clearly separates it from siblings like add_favorite and remove_favorite even without naming them. It stops short of explicit sibling differentiation, so it lands at a clear-but-undifferentiated 4.

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 only guidance given is a prerequisite ('Requires authentication'), not a when-to-use rule. Nothing tells the agent how this differs from get_profile, get_addresses, or other list-style reads when choosing among them.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It doesn't state whether the operation is read-only, whether card number/PIN are sensitive, what happens on invalid credentials, or anything about the return value. It only reiterates the parameter meanings.

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 short lines: a purpose sentence plus parameter restatements. No wasted prose, though the Args block duplicates the schema and adds little.

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-param card-balance lookup with an output schema and no annotations, the description is minimally adequate but lacks any behavioral context: safety profile, error behavior on bad PIN, or how it relates to apply_gift_card. It covers the what but not the how/when.

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%, but the description restates the same field labels already present in the schema (card_number, pin) with no added syntax, format, or validation details. An output schema exists, so return-value explanation is not required. Baseline 3 is appropriate given the schema already names the fields.

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 (Check) and resource (balance of a Grubhub gift card), making the purpose unambiguous. It is distinguishable from the sibling apply_gift_card, which applies rather than queries a card, though it doesn't name that sibling 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 description says nothing about when to use this tool versus alternatives like apply_gift_card. There is no when-to-use guidance or routing condition, only a bare statement of function.

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

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

With no annotations, the description carries the full burden, and it does add some context: the v4 endpoint returns the full menu, and latitude/longitude affect availability. It still says nothing about authentication requirements, failure modes for an invalid restaurant_id, rate limits, or caching behavior.

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 purpose in one sentence, then adds the sibling equivalence and a compact Args block restricted to the three parameters. No filler or restated 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?

An output schema exists, so return values need not be explained, and all three parameters are described. The main remaining gap is behavioral: auth/prerequisite context and the consequences of an unknown restaurant_id.

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, and it does: restaurant_id is identified as the Grubhub restaurant ID and latitude/longitude as optional coordinates for availability. It gives meaning beyond the bare schema types, though it doesn't specify format ranges or interaction between the coordinate pair.

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 ('Get the full menu for a restaurant') and enumerates the payload (categories, items, prices). It also explicitly compares itself to the sibling get_restaurant, telling the agent the two are equivalent at the v4 endpoint — useful differentiation even if it implies redundancy.

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?

No when-to-use, when-not-to-use, or preference rule is given. Saying 'this is the same as get_restaurant' tells the agent the tools are interchangeable, which removes any basis for choosing between them rather than clarifying selection.

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

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

With no annotations, the description carries the full behavioral burden and discloses almost nothing: it does not say whether this is read-only, whether authentication is needed (the sibling login/logout tools imply a session requirement), what happens with an invalid item_id, or how availability varies by location. Only the latitude/longitude 'for availability' note hints at behavior.

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 is front-loaded in one sentence, followed by a compact argument list with no filler or redundancy. Slightly expanded usage context would have been worth more than the terse '(default standard)' restatement of the schema default.

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?

An output schema exists, so return-value description is unnecessary. All five inputs are covered and the tool is a simple read, so the description is nearly sufficient; only error/permission behavior and the relationship to get_menu are absent.

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, and it does: all five parameters are explained, including the order_type enum values ('standard, catering') and its default, plus the optionality and purpose of latitude/longitude. This adds real meaning the schema lacks, though it gives no format constraints for the IDs.

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 ('Get details for a specific menu item') and enumerates the returned content (options, add-ons, pricing), which separates it from the sibling list tool get_menu. It never names those siblings explicitly, so differentiation is available but not made explicit.

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 when-to-use guidance: nothing says to call this after get_menu or search_restaurants, no prerequisite (e.g. needing a valid restaurant_id from a prior call), and no case where another tool is preferable. The Args block documents parameters, not usage context.

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

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

With no annotations, the description carries the full behavioral burden. 'Get details' implies a read, but nothing is said about authorization (whether the order must belong to the caller), rate limits, or what happens with an invalid/foreign order_id. The behavior is essentially undisclosed.

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 summary sentence is front-loaded and waste-free. The 'Args:' block is largely redundant with the schema, but it costs little and does not obscure the intent.

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?

An output schema exists, so return values need not be described. But for a tool with no annotations and no param documentation, the description should at minimum clarify how order_id is obtained and how it relates to the history/tracking siblings. That gap keeps it at minimum viable.

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, yet 'order_id: The order ID' merely restates the parameter name. It adds no format, provenance, or constraint information the schema does not already encode.

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 ('Get details for a specific order'), which is clearly distinct from mutation siblings like place_order and reorder. However, it gives no differentiation from the closely related read siblings get_order_history and track_order, leaving the agent to guess which read tool returns what.

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?

No guidance on when to use this versus get_order_history or track_order, and no prerequisites stated. The only contextual hint is the required order_id, which the agent must infer comes from a prior place_order or history lookup.

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

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

With no annotations, the description carries the full burden and does disclose two meaningful traits: authentication is required, and pagination is server-side via search_listing, reachable by iterating page_num up to pagination.total_pages. Return format itself is not described, but an output schema exists to cover 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?

Front-loads purpose, then auth, then pagination mechanics in a compact form. The Args block restates defaults already present in the schema, a minor redundancy, but overall well sized and organized.

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 read tool with an output schema, the description covers purpose, auth, and the pagination contract needed to retrieve all results. Little is missing; returned field contents are properly left to the 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?

Schema coverage is 0%, so the description must compensate, and it does: it clarifies page_size as orders-per-page and page_num as 1-based, plus the loop semantics for reaching full history. Only the defaults are repeated from the schema, so this adds real meaning.

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 ('Get past order history'), which is clearly distinguishable from siblings like get_order (single order) or track_order. It does not explicitly name those siblings, but the scope is 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?

Usage is implied by the resource name and the pagination instructions, and authentication requirement is stated. However, it gives no explicit when-to-use guidance or contrast with get_order / track_order for an agent choosing between them.

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

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

With no annotations, the description carries the behavior burden. It usefully discloses that authentication is required, which is real context not in the schema. However, it says nothing about read-only safety or what the operation returns, and an output schema exists so returns are covered elsewhere.

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 short sentences, front-loaded with the purpose followed by the auth requirement. No waste, though it is arguably under-specified rather than truly concise.

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 parameterless read tool with an output schema, the description covers purpose and the auth prerequisite. Nothing critical is missing, though scope details like ordering or default-method behavior are absent.

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 per the baseline there is nothing for the description to document beyond the schema. No additional parameter meaning is needed or missing.

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?

'Get saved payment methods' states a specific verb and resource clearly. There is no competing sibling for payment methods, so sibling differentiation isn't needed, but the description adds nothing about scope (e.g. all methods vs. default).

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 when-to-use guidance and names no alternatives, though none of the siblings duplicate this function. An agent gets no context on ordering or prerequisites beyond the bare auth statement.

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

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

No annotations are provided, so the description carries the full disclosure burden. It usefully states the authentication requirement, and 'Get' implies a read-only, non-mutating call, but it says nothing about permissions scope, rate limits, or failure modes when unauthenticated.

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 short sentences, purpose first and constraint second, with no filler. 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?

An output schema exists, so the shape of the returned profile need not be explained. The auth prerequisite is covered; the only mild gap is the absence of any note on what happens if the session is invalid.

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 for the description to disambiguate and the baseline of 4 applies. No parameter-related value could be added here.

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: retrieving "the current user's profile information." The 'current user' scope implicitly separates it from update_profile and get_session_info, though no sibling is named 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?

Only guidance is the authentication prerequisite. It gives no when-to-use context and never contrasts itself with neighbors like get_session_info or update_profile, leaving the agent to infer boundaries from names alone.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read operation and notes that latitude/longitude affect delivery estimates, but it says nothing about authentication requirements, whether the restaurant must be discovered first, or behavior when lat/long are omitted. This is a significant gap for a no-annotation tool.

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 is front-loaded in the first sentence, followed by a scoped Args block. It is appropriately sized for a four-parameter tool with no wasted filler, though the Args formatting is slightly verbose.

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?

An output schema exists so return values need not be described, and the description still lists the main data returned. However, the absence of usage/routing guidance and of any auth or delivery-estimate caveats leaves the definition adequate but incomplete for a tool sitting among many restaurant and cart siblings.

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 and it largely does: it explains restaurant_id as the Grubhub ID, latitude/longitude as delivery-estimate inputs, and order_type values (standard, catering) with default. It stops short of marking latitude/longitude as optional or noting order_type is a constrained set, but it adds real meaning beyond the bare 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 and resource ('Get restaurant details') and enumerates the returned data (menu, hours, ratings, delivery info), so an agent knows exactly what this retrieves. It does not name siblings like search_restaurants or get_menu, so it fails to fully differentiate from adjacent 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?

There is no when-to-use or when-not-to-use guidance. Given siblings such as search_restaurants and get_menu, the description should explain when an agent reaches for get_restaurant rather than those, but it offers no routing or prerequisites (e.g., where restaurant_id comes from).

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

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

No annotations provided; the description only states what it gets. It does not disclose read-only nature, required auth status, or potential side effects, but the name and context suggest non-destructive behavior.

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?

One clear sentence, no extraneous words. Front-loaded with key action and target.

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?

Description is vague about what 'authentication state' and 'session info' include; could specify fields like logged-in status, user ID, or token validity for better completeness.

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?

No parameters, so schema coverage is 100%; description does not need to add param info. Baseline score of 4 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 the tool retrieves authentication state and session info, effectively distinguishing it from sibling tools that perform actions (e.g., login, logout) or manage other resources.

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 implies use for checking current authentication, but does not explicitly state when to use it versus alternatives or provide scenarios.

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

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

With no annotations, the description must disclose behavioral traits. It mentions returning session info but omits critical details such as side effects (e.g., invalidating previous sessions), rate limits, security implications, or what happens on failure. The lack of transparency is a significant gap.

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, clear sentence that is front-loaded with the core action. It could be more structured (e.g., bulleted output info) but is concise overall.

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 existence of an output schema (implied but not provided), the description still lacks completeness. It does not cover failure modes, error messages, session duration, or security context. For a critical authentication tool, this is insufficient.

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%, meaning the schema provides no descriptions beyond titles and types. The description adds minimal value by repeating 'email and password' but offers no additional constraints, formats, or semantics.

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 purpose: logging in to Grubhub with email and password, and specifies that it returns session info on success. It distinguishes itself from sibling tools like send_login_otp and verify_login_otp, which handle OTP-based authentication.

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

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

The description provides no guidance on when to use this tool vs alternatives (e.g., OTP-based login). It does not mention prerequisites, error handling, or scenarios where login might fail.

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

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

No annotations provided, so the description must disclose all behavioral traits. It only states the action ('Log out') without mentioning side effects (e.g., token invalidation, cart clearing) or prerequisites (e.g., being logged in). This is insufficient for a mutation tool.

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 with no wasted words. However, it omits potentially useful behavioral details, balancing conciseness against completeness.

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 tool, the description is minimally adequate. However, it does not explain the return value or confirm success, even though an output schema exists. It lacks context about when the session is considered active.

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?

No parameters exist; schema coverage is 100%. The description correctly implies no arguments are needed, adding no extra information but also not missing anything.

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 action ('Log out') and the resource ('current Grubhub session'), making it distinct from sibling tools like 'login' or 'create_account'.

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?

No explicit guidance on when to use this tool vs alternatives (e.g., ending a session vs. checking session info). The straightforward nature of logout partially mitigates this, but it remains a gap.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the authentication requirement, but for a money-moving mutation it says nothing about whether the order is immediately charged, what happens on payment failure, or whether repeat calls create duplicate orders.

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?

One sentence of purpose followed by a compact Args block; the primary intent is front-loaded and nothing is padded. The header sentence repeats slightly with the cart_id line but costs almost nothing.

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?

An output schema exists, so return values need no explanation, and all three parameters plus the auth prerequisite are covered. What is missing for a payment mutation with zero annotations is failure/duplicate-order behavior and any confirmation semantics.

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% and the schema titles are bare camelCase, so the description does the documentation work: payment_method_id falls back to a default when omitted (the schema only shows default: null, not the fallback behavior) and tip_amount is specified in dollars, a unit the schema omits entirely.

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 ('Place an order from a cart'), so an agent immediately knows this converts a cart into a submitted order, which distinguishes it from read-side siblings like get_order and track_order. It stops short of explicitly contrasting itself with reorder or create_cart.

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 'Requires authentication' line establishes a precondition, and the verb implies this is the terminal step after add_to_cart/update_cart_item. However there is no explicit when-to-use guidance and no mention of alternatives such as reorder for past orders, so usage must be inferred from the name.

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

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

No annotations are provided, so the description carries the full burden for a mutation tool. 'Add or update' hints at upsert semantics, but it says nothing about permissions, whether an existing tip is replaced or summed, or any confirmation/reversibility behavior. For a write operation with zero annotation coverage this is a significant gap.

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 opening sentence is tight and front-loaded, but the trailing Args block mostly repeats the schema's property titles, so part of the text does not earn its place. Size is acceptable but has 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?

An output schema exists so return values are covered, but for a post-delivery mutation with no annotations the description omits the behavioral detail an agent needs (permissions, replacement semantics, effect on an already-tipped order). Given the complexity this is under-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 description coverage is 0%, so the description must compensate for both parameters. It does document them, and 'in dollars' usefully clarifies the unit that the bare number type omits, but 'The order ID' merely restates the parameter name and adds no format or sourcing detail.

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 ('Add or update') and resource ('the tip') with a temporal qualifier ('after delivery') that implicitly separates it from the sibling set_tip. It is clear what the tool does, though it does not name set_tip directly to disambiguate the pre- vs post-delivery choice.

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?

'after delivery' is the only usage cue; it implies when to use this rather than set_tip but never states an explicit alternative or exclusion. An agent can infer the context but must reason about the sibling relationship itself.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses 'Requires authentication', but says nothing about idempotency, what happens if the restaurant is not currently a favorite, or error behavior.

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 operative sentence is front-loaded and short, with the auth prerequisite right behind it. The 'Args:' block is boilerplate that adds little, but overall the definition is tight.

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?

An output schema exists, so return values need not be described, and the single required parameter is named. However, with no annotations the description leaves the safety and failure profile of this mutation uncovered, so it is only minimally 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 description coverage is 0%, so the description should compensate; instead it merely restates the parameter name ('The restaurant ID to unfavorite') with no added format, sourcing, or constraint detail. It adds almost no meaning beyond the schema's own title.

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 ('Remove a restaurant from favorites'), which is unambiguous and distinct from sibling add_favorite. It is clear but does not explicitly name the sibling it complements, so it lands just short of 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 by the name and the inverse of add_favorite, and the auth prerequisite is stated, but there is no explicit when-to-use guidance or reference to alternatives like get_favorites or add_favorite. Adequate but with clear gaps.

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

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

With no annotations at all, the description carries the full behavioral burden. It implies a mutation but says nothing about required permissions, whether the line item must exist, whether removal is reversible, or what errors to expect.

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 and front-loaded with the purpose, which is good. However, the Args block duplicates the input schema verbatim without adding information, so part of the text does not earn 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 mutating tool with no annotations and 0% schema description coverage, the definition is too thin. An output schema exists so return values need not be explained, but nothing covers permissions, preconditions, or failure modes an agent would need.

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 and only supplies bare labels ('The cart ID', 'The line item ID to remove'). This is essentially name restatement with no format, origin, or sourcing detail for either required parameter.

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 gives a specific verb+resource ('Remove an item from the cart'), which clearly distinguishes it from siblings like add_to_cart and update_cart_item. It is clear but does not explicitly name those alternatives.

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?

No when-to-use guidance, no prerequisites, and no routing to alternatives such as update_cart_item (for quantity changes) versus remove_from_cart. The agent must infer the choice from the verb alone.

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

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

No annotations are provided, so the description carries the full behavioral burden. It never says whether the new cart replaces or coexists with an existing cart, whether authentication/customer context is required, or whether the prior order's items and prices are revalidated. For a mutating tool this is a real gap.

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 one-sentence summary is front-loaded and free of padding. The trailing Args block restates the parameter in a slightly redundant way but is short and harmless.

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?

An output schema exists, so return values need not be described, and the tool has only one parameter, keeping complexity low. The missing piece is side-effect behavior on any existing cart, which no structured field covers.

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 schema's only property is the bare title 'Order Id', so the description's 'The order ID to reorder' does add the meaning that it references a prior order. However, it conveys nothing about format, source of the ID, or what happens if the order is unknown, so it is minimal compensation.

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+resource ('Create a new cart from a previous order') and names its distinguishing input, so an agent can tell it apart from create_cart or add_to_cart. It stops short of explicitly contrasting with those siblings, but the 'from a previous order' scoping is enough to disambiguate.

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 'for easy reordering' implies the intent, but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g., create_cart vs. reorder). Usage is inferable from the resource, not 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It never states auth requirements, pagination termination behavior, result limits, or whether an empty query returns all restaurants. It only documents the input parameters, leaving behavior opaque.

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 is front-loaded in one line, followed by an efficient parameter list. No filler or repetition, though the args block could note which params are required.

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?

An output schema exists so return values need not be explained, and all params are documented. But with no annotations and no usage guidance, the definition omits the behavioral and routing context an agent needs to pick this over autocomplete_search.

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, and it does document all seven parameters with real semantics—latitude/longitude tied to the delivery address, query examples (cuisine, name, dish), page_size default, 1-based page_num, and location_mode enum values. It stops short of enumerating valid sort_type values or query syntax.

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: 'Search for restaurants near a location.' This distinguishes it from most siblings (get_restaurant, get_menu, add_to_cart), though it doesn't differentiate from the similarly-named autocomplete_search sibling, which an agent might confuse with it.

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?

No when-to-use guidance, no exclusions, and no reference to alternatives such as autocomplete_search or get_restaurant. The usage context is only implied by the tool name.

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

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

No annotations are provided, and the description fails to disclose important behavioral details such as side effects, rate limits, OTP validity, or whether it invalidates previous codes. The description only states the action without transparency.

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 of 10 words, efficiently communicating the core action without extraneous information. It is front-loaded and concise.

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 tool with one parameter and an output schema, the description covers the basic action but lacks details about context such as typical usage flow, expected response, or preconditions. It is adequate but not thorough.

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%, and the description adds no additional meaning to the 'email' parameter beyond what the schema already provides. For a single, obvious parameter, this is minimally acceptable but does not compensate for the lack of 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 states the tool sends a one-time passcode to an email for login, distinguishing it from sibling tools like verify_login_otp and send_password_reset. The verb 'send' and resource 'one-time passcode' specify the action and object.

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 context ('for login') but does not explicitly state when to use this tool versus alternatives like verify_login_otp or login. No exclusions or prerequisites are mentioned.

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

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

No annotations provided, and the description only says 'send'. It lacks critical behavioral details: whether the email is validated, if the OTP is rate-limited, expiration, or error handling (e.g., silent failure for non-existent email).

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 with no redundant words. However, it could be slightly more structured with bullet points for clarity, but overall it is appropriately concise.

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 security-sensitive nature (password reset), the description lacks critical context: OTP expiration, visibility of success/failure to avoid user enumeration, rate limiting, or links to authentication docs. Output schema exists but description does not reference 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?

The sole parameter 'email' has 0% schema description coverage. The description adds no additional meaning (e.g., format, registered email requirement) beyond the parameter name.

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 it sends a password reset OTP to an email, differentiating from send_login_otp which is for login. However, it does not explicitly distinguish itself from sibling tools like change_password or verify_login_otp.

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?

No guidance on when to use this tool versus alternatives such as change_password or verify_login_otp. It does not mention prerequisites (e.g., user must exist) or context of use.

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

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

No annotations exist, so the description carries the full behavioral burden. It does not say whether this requires an authenticated session, whether it overwrites or adds to an existing tip, whether zero is allowed, or what happens on an already-placed order.

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 purpose sentence is front-loaded and the Args block is compact with no redundant prose. Nothing extraneous, though the argument list largely restates 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?

An output schema exists, so return values need not be explained. But for a mutation tool with no annotations, the description omits auth/permission expectations, replacement semantics, and routing versus post_delivery_tip, leaving real gaps.

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 documents both parameters, and 'Tip amount in dollars' usefully resolves the unit ambiguity of a bare number. But 'The cart ID' adds nothing beyond the schema title 'Cart Id'.

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: 'Set the tip amount on the cart.' An agent can tell what changes. However, it does not differentiate itself from the similarly-named sibling post_delivery_tip, which is the most likely confusion point.

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?

No when-to-use guidance, no conditions, and no mention of the alternative (post_delivery_tip for after an order, update_cart_item for other cart fields). The agent must infer that this applies to a pre-checkout cart only.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that results are real-time and scoped to active orders, which is genuine context, but it says nothing about auth requirements, rate limits, or error behavior when an order is untrackable. An output schema exists, which relieves some of the return-value burden.

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 purpose sentence is front-loaded and free of filler. The 'Args:' block partially restates what the schema already declares, which is mildly redundant, but overall the description is compact.

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?

An output schema covers return values, so the description needn't explain them. For a simple one-parameter read tool this is close to sufficient, but with zero annotations it leaves open the read-only assumption, the meaning of 'active,' and failure modes.

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 should compensate. It documents the single parameter as 'The order ID to track,' confirming intent, but adds no format or constraint detail (string type, ID shape) beyond the schema's own 'Order Id' title. Minimal but non-zero value added.

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: 'Get real-time tracking info for an active order.' The 'real-time tracking' framing distinguishes it from sibling get_order (order details) and get_order_history (past orders), though it doesn't name those siblings explicitly. Clear enough for an agent to select it among the order-related 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?

'For an active order' implies a usage condition (live/in-flight orders vs. historical), which is useful scoping. However, it never names get_order or get_order_history as the alternatives, nor does it say what happens if the order is not active. Usage is implied 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?

With no annotations, the description carries the full burden. It adds one useful behavioral trait (quantity=0 removes the item), but says nothing about auth requirements, what happens with an invalid line_item_id, or quantity bounds. For a mutation tool with zero annotation coverage this is a significant gap.

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-loaded with the action, then a short Args list with no wasted text. Efficient, though the Args entries for cart_id/line_item_id add little beyond restating the names.

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?

An output schema exists so return values needn't be explained. As a 3-param mutation with no annotations, it is minimally adequate but leaves permissions, failure modes, and quantity constraints unaddressed.

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%, so the description must compensate, and it does document all three parameters. However, cart_id and line_item_id are restated near-tautologically, and only quantity ("0 to remove") adds real meaning. It covers the params but thinly.

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 ("Update the quantity of an item in the cart"), which an agent can distinguish from siblings like add_to_cart and remove_from_cart. It does not explicitly name those siblings, but the operation is 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?

Usage is implied rather than spelled out. The parenthetical "(0 to remove)" is the one piece of routing guidance, hinting this overlaps with remove_from_cart, but there is no explicit when-to-use/when-not statement or named alternative.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the authentication requirement, which is useful, but says nothing about the critical ambiguity that all three parameters default to null — whether null means 'leave unchanged' or 'clear the field', nor whether the update is partial or full. That gap matters for a mutation tool.

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 opening sentence is front-loaded and the description is short. However, the three-line Args block is pure repetition of the input schema and consumes space without adding information, weakening the structure.

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?

An output schema exists so return values need not be described. But for a three-parameter mutation with no annotations, the description omits partial-update behavior, null-field semantics, permission scope beyond 'authentication', and effects on unmentioned fields — too much is left unspecified.

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% and all three parameters are nullable with null defaults. The Args block merely restates each parameter name as 'New <field>', adding no meaning beyond the schema titles, and fails to resolve the null semantics that the schema leaves ambiguous.

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 ('Update user profile information'), which is clear on its own. However, it does not distinguish itself from the sibling get_profile or explain how it relates to read vs write profile operations, so an agent must infer the split.

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 only usage signal is 'Requires authentication,' which is a prerequisite rather than guidance. There is no statement of when to call this instead of get_profile, whether partial updates are allowed, or what triggers the need to change profile fields.

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

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

No annotations are provided, so the description must fully disclose behavioral traits. It mentions 'complete login' but does not specify side effects (e.g., session creation), error conditions, or security implications. This is insufficient for a login action.

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 of 8 words, front-loaded with the key action. Every word is meaningful, with no redundancy or extraneous 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?

Given the simple nature (2 required params, output schema exists), the description is minimally adequate but lacks crucial details about return values, error handling, and post-login state. It covers the basic purpose but not enough for a secure authentication step.

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%, and the description adds no details about the parameters beyond their names. While 'email' and 'code' are intuitive, the description should elaborate on format, length, or constraints to compensate for the missing schema descriptions.

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

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

The description clearly states the tool's purpose: verify an OTP and complete login. It distinguishes from sibling tools like send_login_otp (which sends the code) and login (which may use password), making the specific action 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?

The context is clear: this tool should be used after receiving an OTP, likely from send_login_otp. However, it does not explicitly mention when not to use it or provide alternatives, though the flow is implied by sibling tool names.

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