ChowDeck MCP by Nova (CIVAI)

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

With no annotations, the description carries the full behavioral burden yet says nothing about what happens on duplicate items (merge vs new line), whether a cart/address must pre-exist, auth/login requirements, or failure behavior. The presence of a notification_message param hints at a follow-up-message workflow that is never explained.

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, front-loaded sentences with no filler; the required-inputs note and the item-type constraint are efficiently placed. Minor redundancy with the schema's own 'default menu' note keeps it from a 5.

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

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

For an 11-parameter mutation tool with no annotations and no output schema, the description is thin: it omits cart-state return behavior and the multi-step flow implied by the step-numbered fields and notification_message. The complete schema covers parameters, but behavioral context an agent needs is sparse.

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

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

Schema description coverage is 100%, so the schema already explains each field including id sources and the 'menu' enum. The description's notes on vendor id, item id, and item type largely restate schema content, so baseline 3 applies with little added 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 ('Add an item to cart'), making it clearly a cart-mutation tool distinguishable from siblings like view_cart, clear_vendor_cart, and remove_cart_item. It does not explicitly contrast with duplicate_cart_pack, but the core action 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?

Points to the required discovery path (search_product products[] or view_vendor_items) to obtain vendor and item ids, which implies you must search before adding. However it never states when to prefer this over siblings like duplicate_cart_pack, nor any exclusion such as checking view_cart first.

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 that this is a destructive, all-items operation and that the 'Active cart already exists' error is a valid precondition. It does not say whether the deletion is reversible or what confirms success, which would complete the picture 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?

Front-loads the action and scope, then layers the id requirement and the trigger condition; no filler sentences. The heavy em-dash compression makes some clauses do double duty (scope + side-effect label), which costs a bit of 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?

For a 2-parameter destructive tool with no annotations and no output schema, the definition covers what is destroyed, which id to supply and when to reach for it. Only the post-condition (what the state looks like after clearing, or how failure surfaces) is left unstated.

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 critical disambiguation — cart id from view_vendor_cart response data.id, not vendor id — is stated explicitly and compensates for the opaque internal parameter name in the schema. With schema coverage at 100% and both parameters already documented, this adds meaning rather than repeating 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 (delete/clear) and resource (entire cart for one vendor), with the scope narrowed to 'all items' so it reads differently from a single-item removal. It never names a sibling explicitly, so the contrast with remove_cart_item relies on inference rather than routing.

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

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

Gives concrete triggers: 'use when user wants to empty cart' and 'before re-adding after Active cart already exists'. That is real operative guidance beyond a generic description. It stops short of naming the alternative tool (remove_cart_item) for partial removals, which is the one exclusion an agent could plausibly need.

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 that this is a mutation ('Side-effect') and what changes (quantity increases by one duplicated pack), plus the POST endpoint, but it says nothing about reversibility, permission requirements, 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?

Three short sentences, front-loaded with the effect, then the endpoint, then the prerequisite and side-effect flag. No wasted words, though the telegraphic style leaves some ambiguity (e.g., 'one pack' relative to existing quantity).

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 with no output schema and no annotations, the description covers purpose, prerequisite, and mutation status, which is the essential minimum. It lacks any indication of what the call returns or what happens on invalid pack references, leaving real gaps an agent would want filled.

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

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

Schema coverage is 100%, so each of the three parameters is already documented, and the description only adds the gloss 'pack (configured line item)' to clarify what a pack reference represents. Baseline 3 is appropriate because the schema does the heavy lifting.

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

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

States a specific verb and resource ('increase quantity by duplicating one pack (configured line item)') and even gives the underlying endpoint, so the agent knows exactly what operation this is. It implicitly distinguishes from add_item_to_cart by emphasizing duplication of an existing configured line, but never names a 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?

'Run view_vendor_cart first' gives a concrete prerequisite and explains where the cart id and pack reference come from. There is no explicit when-not guidance or named alternative (e.g., add_item_to_cart for a new line), so it stops short of full routing guidance.

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 that no auth is required, which is useful, but says nothing about what the returned config contains, whether it is cached or rate-limited, or why a read-only fetch takes a notification_message parameter.

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 fragments, front-loaded with the most important fact (public, no auth). Nothing is wasted, though the terseness contributes to the gaps elsewhere.

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

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

There is no output schema, so the description should describe what the config response looks like, and it does not. For a tool whose only real value is the shape of the data it returns, that leaves the agent guessing.

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

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

Schema coverage is 100% and the single parameter is fully documented in the schema, so the baseline is 3. The description adds nothing about notification_message, which is an unexpected parameter on a config-fetch tool and would benefit from explanation.

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 identifies the resource (public customer app config) but the verb is only implied by the tool name, and it never says which settings are returned. It is distinguishable from transactional siblings like place_order or view_cart, but not from other read endpoints such as get_chowpass_status or get_payment_methods.

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?

"Good session probe" is a genuine usage hint that tells an agent to call this to check connectivity, but there is no explicit when-not guidance and no named alternative for actually retrieving customer configuration.

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, yet it discloses nothing: not whether it is a read or a mutation, whether it changes the active address, what side effects it has, or what it returns. The only hint, the word "pipeline," suggests multi-step behavior that is left entirely unexplained.

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 sentence is short but wasteful in the wrong direction: it is under-specified rather than concise. There is no front-loaded statement of what the tool does or returns, so the brevity buys the reader 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?

No annotations, no output schema, and an empty description leave the agent with nothing beyond the name. For a tool whose behavior is called a "pipeline" and whose sole parameter concerns failure messaging, the description is far too thin to support 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?

There is only one parameter and its schema coverage is 100%, with the description of notification_message fully spelled out in the schema, so the baseline of 3 applies. The description itself adds nothing about the parameter, and notably never explains why a get-addresses call requires a user-facing failure message.

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?

"Run the get_addresses pipeline" essentially restates the tool name with the word "pipeline" and adds no specificity. It does not say what kind of addresses are returned (customer saved addresses? delivery addresses?), nor how it differs from siblings like set_active_address_and_fetch_menu or search_menu_by_address.

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 mention of any alternative. Among a large sibling set of address- and cart-related tools, an agent has no basis to choose this one over set_active_address_and_fetch_menu or search_menu_by_address.

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 disclosure and delivers none: no indication of whether this reads or mutates state, whether it is safe to retry, what a 'pipeline' does, or what a caller receives. The presence of a notification_message parameter hints at a user-facing action with side effects, but the description never confirms or clarifies this.

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 short sentence with no filler, but its brevity is under-specification rather than efficiency — there is no front-loaded statement of what the tool actually does. Same failure mode as a bare name restated as prose.

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

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

With no annotations, no output schema, and an unexplained name, the definition leaves an agent unable to determine the tool's purpose, side effects, or return value. The notification_message parameter implies a follow-up reply flow that the description never explains, so the caller must infer the whole interaction model.

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

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

Schema description coverage is 100%, so the single optional parameter is already fully documented in the schema (short user-facing sentence used if the follow-up reply fails). Per the high-coverage baseline this lands at 3, though the description adds nothing to it.

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?

"Run the get_chowpass_status pipeline" restates the tool name with no added meaning; an agent learns nothing about what 'chowpass status' is (loyalty pass? routing pass? subscription?). Nothing distinguishes it from any of the 23 cart/order/vendor siblings.

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

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

There is no statement of when to call this, when not to, or which sibling handles related needs. Given the crowded e-commerce sibling set, this omission forces the agent to guess entirely.

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, yet it says nothing about whether this is a read-only lookup, whether 'pipeline' implies an async/job-style call, what data is returned, or any side effects or prerequisites. The word 'pipeline' actively raises ambiguity about execution semantics without resolving it.

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

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

It is one short sentence, so nothing is bloated, but the brevity comes from under-specification rather than efficiency. There is no front-loaded statement of what the tool returns or when to use it.

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

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

With no annotations, no output schema, and a description that conveys no behavior at all, an agent cannot tell what this tool returns or how to use the result. For a tool whose only purpose is to supply a country list to other flows, this is completely inadequate.

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

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

Schema coverage is 100% and the single optional parameter (notification_message) is fully documented in the schema itself, including formatting constraints. The description adds no meaning beyond the schema, but baseline 3 applies since the schema does the work.

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 'Run the get_country_list pipeline' simply restates the tool name with the vague word 'pipeline'. It never states that it returns a list of countries, nor what kind of countries (supported/shipping/serviceable), and it does nothing to distinguish it from the many other 'get_*' and 'list_*' siblings.

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 guidance on when to call this tool, when not to, or which sibling to use instead (e.g. get_addresses, get_delivery_amount_for_order, which likely also need a country context). An agent has to guess based on 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?

No annotations are provided, so the description carries the full burden, and it discloses nothing: not whether the run is read-only or mutating, not what triggers it, not side effects, not whether it is expensive or rate-limited. "Pipeline" actively obscures the behavioral profile.

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 sentence is short but wastes its only slot on a tautology rather than front-loading purpose or scope. Brevity here comes from under-specification, not efficiency.

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

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

With no annotations, no output schema, and no explanation of what a "pipeline" run does or returns, the description leaves an agent unable to invoke this tool with any confidence.

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

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

Schema description coverage is 100% and there is a single optional parameter already fully documented in the schema, so the baseline of 3 applies. The description adds no meaning beyond the schema, but the schema itself is adequate.

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?

"Run the get_customer_survey pipeline" restates the tool name with the vague word "pipeline" and never says what the tool actually does — fetch results, submit a survey, or trigger a job. Nothing distinguishes it from siblings like fetch_customer_settings or get_order_details beyond the name itself.

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, prerequisites, or alternative is mentioned, despite 23 plausible siblings. An agent has no basis for choosing this tool over any other.

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 carry the full behavioral burden. It implies a read-only fetch but does not state permissions, return format, whether the amount is a quote or a stored fee, or what the notification_message parameter is used for.

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

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

The description is a single front-loaded sentence with no filler or redundancy. It is efficiently sized for a simple one-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?

With no annotations and no output schema, the description should clarify how the target order is identified, yet the only parameter is notification_message. It is not complete enough to explain how this tool resolves which order's delivery fee is returned.

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

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

The schema has 100% description coverage for its single parameter, so the baseline score is 3 even though the description adds no parameter-level meaning. The description does not mention notification_message at all, and the schema itself does the necessary work.

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 clear verb ("Fetch") and resource ("delivery fee details for an order"), making the basic purpose understandable. However, it does not distinguish this tool from a sibling like get_order_details, and the stated "for an order" scope is not reflected in the only exposed parameter.

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 guidance on when to use this tool versus alternatives such as get_order_details or view_cart, and no prerequisites or exclusions are stated. Usage is only implied by the phrase "delivery fee details for an order."

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 discloses almost nothing: it does not state that this is a read-only listing, that the address id must be an active address (only the schema says so), what 'featured' vs 'tagged' means, or how pagination behaves. For a 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?

A single eight-word fragment with zero padding and the geographic constraint front-loaded. It is efficient, though its terseness borders on under-specification rather than genuine conciseness.

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

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

With four parameters, no annotations, and no output schema, the description should explain what a caller gets back, what featured/tagged means, and how paging works. Instead it offers one clause, leaving an agent to infer nearly all calling behavior from the schema alone.

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

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

Schema description coverage is 100%, so every parameter is already documented, and the baseline is 3. The phrase 'near a delivery address' does add a small amount of meaning by explaining the role of the required address id, but the description says nothing about pagination or the notification_message fallback that the schema documents.

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

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

The description names the resource (featured and tagged vendors) and scopes it geographically to a delivery address, which distinguishes it from siblings like search_product or search_menu_by_address. However it is a noun phrase with no verb and never explicitly says what it does with those vendors (list them) or how it differs from a vendor search.

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 alternative-tool guidance appears in the description. The only usage hint in the whole definition ('Use when user asks for more vendors or next page') lives in the schema for step_40_page, not the description, and there is no mention of when to prefer this over search_menu_by_address or search_product.

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, yet it says nothing about side effects, permissions, or response shape. Calling it a "pipeline" conveys no behavioral information at all.

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 short sentence, but brevity here is under-specification rather than efficiency — it earns no information 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?

With no annotations and no output schema, the description must explain side effects and return values, and it does neither. The unusual notification_message parameter (no required params) is left entirely unexplained.

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

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

Schema description coverage is 100%, so the single notification_message parameter is already documented in the schema; baseline 3 applies. The description adds no meaning about what the notification message is for in this pipeline.

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?

"Run the get_order_details pipeline" restates the tool name rather than describing the resource or what it returns. An agent learns nothing about what an "order detail" contains or how this differs from list_orders_success or view_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 statement of when to call this versus the many order/cart siblings. The only implicit cue is the name itself; no prerequisites, exclusions, or alternatives are named.

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

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, and it discloses nothing: not whether the call is read-only, not whether it requires login, not what happens on failure despite the presence of a notification_message fallback parameter. 'Run the pipeline' tells an agent nothing about side effects 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?

It is a single short sentence with no padding, but the brevity comes from under-specification rather than efficiency. The one sentence conveys zero actionable information beyond the tool name.

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

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

With no annotations, no output schema, and no explanation of return values or auth requirements, an agent cannot determine what this tool produces or whether it is safe to call. The definition is completely inadequate for a payment-related retrieval tool.

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

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

The single parameter, notification_message, is fully documented in the schema (100% coverage), so the schema already does the heavy lifting. The description adds no meaning beyond it, which meets the baseline-3 rule for high schema coverage but no more.

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 restates the tool name as 'Run the get_payment_methods pipeline,' which is a tautology rather than an explanation. It never says whose payment methods are returned, what fields come back, or how it differs from siblings like view_wallet_balance.

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 guidance on when to call this versus alternatives, and no mention of prerequisites such as an authenticated customer session. The word 'pipeline' hints at some internal workflow but gives the agent no selection criteria.

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 provided, the description carries the full behavioral burden, yet it discloses nothing about whether the operation reads or mutates data, what side effects occur, or what the response contains. Calling a "pipeline" gives an agent no basis to predict 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?

It is a single short sentence, but the brevity reflects under-specification rather than efficiency — there is no front-loaded statement of purpose or outcome.

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 tool with no annotations and no output schema, the description should explain the operation's effect and return shape. Instead it leaves the agent unable to determine what the pipeline does or when invoking it is appropriate.

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

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

Schema coverage is 100% and the single parameter notification_message is fully documented in the schema, so the baseline of 3 applies. The description adds no meaning beyond the schema, but the schema does the work 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?

The description restates the tool name as "Run the list_orders_success pipeline," which is tautological — it never says what the pipeline does or what it returns. An agent learns nothing beyond the name itself, and no sibling tool is distinguished.

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 guidance on when to use this tool versus the many order/cart siblings like get_order_details or view_cart. No preconditions, exclusions, or alternatives 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?

With no annotations, the description carries the full burden. It does disclose the key behavioral trait — that this is an asynchronous payment handoff returning pay_for_me_url rather than a synchronous completion — which is genuinely useful. However, it omits whether the order is created before or after payment, what happens to the cart, and whether the call fails if payment is abandoned, leaving the mutation semantics underspecified.

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 tight sentence with the payment mode and the returned URL front-loaded, and 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?

There is no output schema and no annotations, so the description is the only source of behavioral context. It covers the return value and payment handoff but leaves the order lifecycle (created now vs. on payment, cart cleanup, idempotency, failure modes) unexplained for what is a consequential write operation.

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

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

Schema description coverage is 100% and the single parameter is optional, so the schema already explains notification_message's purpose and plain-text constraint. The description adds nothing about it, but the baseline of 3 applies when the schema does the heavy lifting.

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

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

States a specific verb and resource (place order) and adds a distinguishing detail: this variant uses the 'Pay for me' flow and returns a pay_for_me_url. It does not name or contrast with any sibling, but no sibling appears to overlap on order placement, so 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?

The description never says when to call this: no prerequisites (non-empty cart, active address, selected payment method) and no statement of what state the user must be in. The only implicit guidance is that payment is completed out-of-band in a browser, which the agent must infer the workflow 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 are provided, so the description carries the full behavioral burden. It discloses that this is a side-effect operation and specifies POST with quantity 0, plus the prerequisite lookup, but it does not cover permissions, reversibility, or how the cart state changes beyond the removal itself.

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 three tight sentences, front-loaded with the action and followed by the endpoint, prerequisite, and side-effect note. There is no redundant filler.

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

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

For an 8-parameter mutation with no annotations or output schema, the description gives enough to invoke it correctly, including the prerequisite lookup and ID source. However, it omits what the response looks like and any post-removal effects or reversibility details that would make it fully self-contained.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description reinforces that the menu line ids come from view_vendor_cart and apply to type menu, but adds little beyond what the schema descriptions already say.

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 one line item (pack) from a vendor cart.' The phrase 'one line item (pack)' distinguishes this from clear_vendor_cart, which presumably removes the whole cart, and from add_item_to_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?

It gives an explicit prerequisite: 'Run view_vendor_cart first' and says to pass menu line ids from data.cart_items[] with type menu. It does not explicitly name when to use clear_vendor_cart or add_item_to_cart instead, but the one-line-item scope makes the intended use clear.

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

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

With no annotations, the description carries the burden and does disclose the key side effect (an SMS is sent to a real user) and the OTP/non-OTP boundary. It does not mention failure modes such as invalid or already-registered numbers, rate limiting, or whether the code expires — gaps for a tool that triggers external messaging.

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

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

Three short sentences, each doing distinct work (purpose, exclusion, next step), with the action and sequencing front-loaded. No filler.

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

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

For a 3-parameter, no-output-schema tool, the definition covers purpose, exclusions, and the follow-up call, which is enough to invoke it correctly. It stops short of saying what a successful response provides (e.g., a reference or expiry) that the agent would need before calling verify_login_otp.

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

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

Schema description coverage is 100%, so all three parameters are already well documented (phone format, country code, notification message). The description's instruction to ask the user for the phone first adds workflow framing but no parameter-level meaning beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource ('Send ChowDeck login SMS') and ties it to the endpoint semantics ('validate phone → auth/login'). It also explicitly carves out scope ('Does not accept OTP'), which separates it from verify_login_otp among the siblings.

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

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

Gives an explicit ordered workflow: ask the user for their phone first, then the SMS code, then call verify_login_otp. The alternative tool is named along with the condition that selects 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, and it discloses nothing: not whether the call is read-only, whether it depends on a session/active address, what happens on failure, or what the response contains. The only hint about behavior is the notification_message parameter, which is documented in the schema rather than the description.

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 one short sentence, but brevity here is under-specification rather than conciseness — the sentence conveys no information an agent could not get from the tool name alone.

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

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

With no annotations and no output schema, the description is the only source of behavioral context, and it supplies none. Critically, there is no address parameter at all, and the description never explains where the address comes from (an active-address context, presumably), leaving the agent unable to invoke the tool correctly.

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

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

Schema description coverage is 100% for the single parameter, so the schema already explains notification_message fully. The description adds no meaning beyond that, which is the baseline case when the schema does the work.

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?

"Run the search_menu_by_address pipeline" is essentially a restatement of the tool name with the word "pipeline" appended. It never says what searching a menu by address actually does (look up vendors delivering to an address? return menu items?) or how it differs from siblings like search_product or set_active_address_and_fetch_menu.

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, when-not-to-use, or alternative-tool guidance whatsoever. With 23 siblings including several address- and menu-related tools, the agent is left to guess entirely 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 exist, so the description must carry behavioral disclosure itself. It does disclose the response shape (data[] entries, id = vendor id, products[].id = menu item id) and the empty-products fallback, which is genuinely useful. It omits pagination, result limits, and applicability constraints, which are meaningful gaps 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?

Three short sentences, front-loaded with the action and scope, followed by response-field decoding and the conditional next step. Every sentence carries distinct information with no filler.

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

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

With no output schema, the description proactively explains the return structure and the empty-result case, which is exactly what's needed to consume results correctly. What remains missing (pagination, limits) is minor for a simple search endpoint.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the schema, including examples for the query term and the address-id sourcing rule. The description only echoes 'by name near a delivery address' and adds no new parameter-level semantics, so the baseline 3 applies.

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

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

States a specific verb and resource ('Search vendors/products by name near a delivery address'), with scope qualifiers (by name, near an address) that an agent can act on. It does not explicitly differentiate itself from the close sibling search_menu_by_address, so it stops short of a 5.

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

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

Provides one useful routing rule — 'If products[] empty, call view_vendor_items next' — which tells the agent the follow-up path. However, it offers no guidance on when to choose this over search_menu_by_address or get_featured_vendors, leaving the main sibling ambiguity for the agent to resolve.

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 falls short: it never says whether setting the active address overwrites a previous one, whether the operation is idempotent, or what happens if the menu fetch half fails — despite the schema's notification_message field hinting at a failure-handling flow. The mutation half is named but its effects are 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?

A single front-loaded sentence with no filler, clearly ordered (set address, then fetch menu). It is efficient, though its brevity borders on under-specification for a two-step mutation.

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 composite tool with a write step, four parameters (two of them duplicated API fields), no annotations, and no output schema, one sentence is not enough. An agent is left unsure about address-id sourcing, failure behavior, and what the menu response contains.

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

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

Schema description coverage is 100%, so all four parameters, including the duplicated address_id fields and the notification_message fallback text, are already documented in the schema. The description adds nothing beyond that, which is the expected baseline when the schema does the heavy lifting.

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

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

The description names a specific compound action: setting the active delivery address and fetching the chowsmart menu for that address. It is clear what the tool does, but it does not distinguish the menu-fetch half from the sibling search_menu_by_address, which could plausibly cover similar ground.

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 by the name and the 'for that address' phrasing — an agent can infer this is a set-then-fetch composite step, but there is no explicit statement of when to prefer it over search_menu_by_address or why the address must come from get_addresses (that hint lives only in the schema). No exclusions or prerequisites are 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 and does disclose meaningful behavior: the internal validate-phone → validate-OTP → refresh-token pipeline, which signals a token/session side effect. It also rules out an SMS send, preventing wrong expectations. It omits failure modes, permissions, and rate-limit behavior, keeping it from a 5.

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

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

One front-loaded sentence with the primary action first, followed by a compact parenthetical flow and a single scoping exclusion. Every clause earns its place, and no sentence is wasted.

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 multi-step auth tool with full schema coverage and no output schema, the description adequately conveys what happens during the call and that no new SMS is sent. It does not state what is returned (e.g., token/session) or failure behavior, which leaves a small gap for an agent handling the response.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters including the phone/OTP pairing and country code. The description adds only the high-level validation sequence and no syntax or format details, so the baseline 3 applies.

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

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

States a specific verb and outcome ('Complete ChowDeck login with SMS code') and enumerates the internal sequence (validate phone → validate OTP → refresh token). The clause 'Does not send a new SMS' also distinguishes it from the sibling request_login_otp, so an agent can route between them without reading either schema.

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

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

The sequence implies this is the second step after requesting an OTP, and 'Does not send a new SMS' tells the agent when not to use it (use request_login_otp instead). It stops short of explicitly naming that sibling or stating prerequisites like OTP expiry, but the context is clear.

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

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

No annotations exist, so the description carries the full disclosure burden and largely drops it. 'View' implies a read, but it says nothing about empty-cart behavior, what fields come back, whether it triggers a notification, or that the notification_message parameter only matters on follow-up failure.

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 short, front-loaded sentence with zero filler — appropriate for a simple read tool. The flip side of that brevity is under-specification rather than 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?

For a parameterless read tool with no output schema and no annotations, the description is minimally adequate but thin. An agent still lacks return-shape expectations and cart-state edge cases (empty cart, guest vs logged-in) that would make calling it confident.

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

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

Schema description coverage is 100%, so the single optional notification_message parameter is already fully documented in the schema. The description adds nothing about it, which is the expected baseline when the schema does the heavy lifting.

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

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

States a specific verb (View) and resource (current cart contents), so the agent knows exactly what the tool returns at a high level. It does not, however, explicitly distinguish itself from the near-identical sibling view_vendor_cart, leaving the 'current' vs 'vendor' scope to be inferred.

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 call this versus view_vendor_cart, view_vendor_items, or any of the other cart-adjacent siblings. There are no prerequisites, exclusions, or context cues, so the agent must guess 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 must carry the burden of behavioral disclosure. It only implies a read-only operation via the verb 'View' but does not state whether it requires authentication, what data is returned (e.g., items, totals), or any rate limits or side effects. This is minimal for a tool with zero annotation coverage.

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

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

The description is a single, front-loaded sentence with no wasted words. The parenthetical adds useful context without 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 the tool's simplicity, the description covers the core purpose, and the schema fully describes parameters. However, the absence of usage guidelines and behavioral details leaves gaps that could lead to incorrect tool selection or invocation, especially with a sibling 'view_cart' available.

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

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

Schema description coverage is 100%, so the schema fully documents both parameters. The description adds no additional meaning about the parameters beyond what is in the schema, so the baseline of 3 is appropriate.

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

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

The description states a specific verb ('View') and resource ('cart for one vendor'), and the parenthetical 'vendor-specific checkout view' clarifies the scope. It distinguishes from general cart tools by specifying 'one vendor', though it doesn't explicitly name the alternative 'view_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?

Usage is implied: this tool is for viewing a cart scoped to a single vendor, as opposed to a general cart. However, there is no explicit guidance on when to use this over 'view_cart' or other cart-related siblings, nor any prerequisites or exclusions.

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 usefully discloses the ordering dependency and parameter source, but it does not explicitly confirm read-only behavior, side effects, permissions, or what the loaded menu contains.

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 two sentences and front-loads the core action. The second sentence is dense but earns its place by explaining the required vendor id source and call ordering.

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

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

For a simple two-parameter tool with full schema coverage, the description covers purpose and invocation sequencing. However, because there is no output schema, it should say more about what "vendor items" are returned, and it omits any mention of notification_message.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description reinforces where step_58_url_path_2 comes from and its sequencing role, but it adds little about notification_message beyond what the schema says.

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: "Load a vendor menu." It also identifies the tool's workflow role relative to search_product and add_item_to_cart, though it does not explicitly differentiate itself from sibling menu-fetching tools such as search_menu_by_address.

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

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

It gives a clear conditional: call before add_item_to_cart when search products[] is empty, and source the vendor id from search_product data[].id. It does not explicitly say when to use the other menu-related siblings instead.

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. 'Retrieve' implies a safe read, but it never states that explicitly, nor does it mention auth requirements, whether balance is currency-denominated, or what happens on failure. For a 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?

A single front-loaded sentence with no filler or redundancy. It is lean to the point of under-specification, but nothing in it is wasted.

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

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

A one-parameter read tool is a simple case, and with no output schema the description could reasonably stop early. Still, it doesn't say what a balance looks like (amount plus currency) or whether a missing wallet yields zero or an error, leaving the agent guessing at the result shape.

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

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

Schema description coverage is 100% for the single parameter, so the schema already explains notification_message fully; the baseline of 3 applies. The description adds nothing about the parameter, and notably does not clarify why a wallet-balance read takes a follow-up-failure message at all, which is the one genuinely confusing element 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?

Specific verb 'Retrieve' plus a specific resource, 'the user's wallet balance'. It is clearly distinct from the sibling set, which is dominated by cart, order, and login tools, so confusion is unlikely. It stops short of a 5 because it says nothing about scope (per-user vs per-account, which currency) that would fully pin down the resource.

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, no prerequisites, and no alternatives. It doesn't even say whether the wallet must be set up or a login must precede the call, which matters in a sibling set that includes request_login_otp and verify_login_otp.

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