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

Discloses a real behavioral prerequisite (login required), which is useful especially with no annotations present. But it does not disclose side effects, failure modes (e.g., out-of-stock), or what happens after adding, leaving the agent to infer the full 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?

A single sentence front-loads the action and resource before the prerequisite. Every word earns its place, with no filler or repetition.

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

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

With no output schema and no annotations, the description should explain expected outcomes, failure behavior, and how to handle variations/quantity. It only covers the login prerequisite, leaving significant gaps for an agent invoking this mutation tool blind.

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 baseline is 3. The description adds no parameter-specific meaning beyond what the schema already provides, which is acceptable but not additive.

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'), a resource ('Etsy shopping cart'), and a prerequisite. The resource clearly distinguishes it from siblings like etsy_add_to_favorites and etsy_checkout, so an agent can tell it apart without opening the schema.

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

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

Gives a clear prerequisite ('Requires being logged in') and the resource makes intended use obvious. However, it does not explicitly name alternatives or state when not to use it, missing the top-tier guidance of naming sibling tools.

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 of behavioral disclosure. It reveals the side effect (adding to favorites) and the authentication requirement, but does not mention behavior on duplicate favorites, navigation steps, or error handling. Some behavioral context is provided, but not in depth.

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 short sentences with no redundant wording. The core action is stated first, and the prerequisite follows. Every word earns its place.

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

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

For a simple one-parameter mutation tool, the description covers the essential context: the action and the login prerequisite. There is no output schema, but for an add-to-favorites action, return values are less critical. It is slightly incomplete in not addressing duplicate favorites or failure cases, but sufficient for typical agent use.

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 parameter description already specifies 'Full URL of the Etsy listing to favorite.' The tool description adds no additional meaning or format details beyond the schema, so a baseline score 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 clearly uses a specific verb ('Add') and resource ('an item to favorites on Etsy'), which precisely distinguishes it from siblings like etsy_add_to_cart and etsy_get_favorites. The action is unambiguous and the scope is well-defined.

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 states a clear prerequisite: 'Requires being logged in.' This gives context for when the tool can be used, and implies that login should occur first. It does not explicitly name alternatives or when-not-to-use conditions, 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. It discloses the key prerequisites (logged in, payment configured) and implies a real-world purchase, which signals a consequential, non-read-only action. It does not disclose failure behavior, whether the purchase is reversible, or what confirmation the tool returns, which matters for a financially impactful 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?

Two sentences totaling roughly 15 words, with the primary action front-loaded in the first sentence. Every sentence earns its place — the first states what the tool does and the second states the critical precondition — with zero 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?

The schema covers all parameters and the description covers the preconditions, so an agent can feasibly invoke the tool correctly. But with no annotations and no output schema, the description leaves gaps around the confirmed-order outcome, error handling, and the irreversible nature of the purchase. Adequate, but thin for a high-stakes financial tool.

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

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

Schema description coverage is 100%, so the schema fully documents all four parameters including dry_run's safety default and the shipping_address fallback behavior. The description adds no parameter-specific meaning beyond the schema. The baseline 3 applies.

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

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

The description states a specific verb and resource: 'Proceed to checkout and purchase items in the cart.' This clearly differentiates the tool from siblings like etsy_view_cart and etsy_add_to_cart, which do not complete a purchase. However, it does not explicitly name an alternative tool, so differentiation is implicit rather than stated.

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 a clear precondition — 'Requires being logged in with payment method configured' — which tells the agent what state must hold before calling. But it offers no explicit when-to-use or when-not-to-use guidance relative to siblings, nor does it indicate that a cart must be populated first via etsy_add_to_cart. Usage context is implied by the checkout/purchase action but never spelled out.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It states the main action (closing the browser) and the resource cleanup, which conveys the session-ending nature. However, it does not mention whether this discards unsaved state, logs the user out, or is safe/idempotent. For a destructive lifecycle tool, a bit more detail would improve 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, front-loaded sentence with no fluff. Every word contributes meaning, and the structure is ideal for quick parsing by an agent.

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 this simple—no parameters, no output schema, and a straightforward lifecycle action—the description is complete enough. Nothing critical is missing for an agent to invoke it correctly.

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

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

The tool has zero parameters, so the schema coverage is trivially 100% and there is nothing to document. Baseline for no parameters is 4; the description need not add parameter details.

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 ('Close') and names the exact resource ('browser instance'), clearly distinguishing this tool from the Etsy-focused sibling tools. The addition of 'clean up resources' reinforces its lifecycle-management role. There is no ambiguity about what the tool does.

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 intended usage is implied by the name and description: call it to end a browser session after other Etsy operations. However, there is no explicit guidance on when to use it versus alternatives or any mention of prerequisites (e.g., 'after all tasks are complete'). The context makes the purpose obvious, but the description does not spell it out.

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

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It correctly conveys a read-only operation via 'View' and notes the authentication requirement. It does not mention error behavior, defaults, or what happens with invalid usernames, but the essential safety profile is clear enough.

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 concise and front-loaded with the core purpose. The second sentence adds the important login prerequisite. Minor redundancy like 'on Etsy' is not harmful, but it does not carry much new information.

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

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

For a simple read-only tool with no required parameters and no output schema, the description is adequately complete: it states the resource, the action, and the key prerequisite. It does not enumerate optional filtering behavior, but that is already covered by the input schema.

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

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

The input schema has 100% description coverage for its two parameters, so the baseline is 3. The description does not add meaningful semantic detail beyond what the schema already states, though the login requirement indirectly relates to the optional username defaulting to the logged-in user.

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 ('View') and the resource ('a user's favorited items and collections on Etsy'), which distinguishes it from siblings like etsy_add_to_favorites and etsy_get_item_details. The scope is specific and immediately understandable.

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 clear context for when to use the tool: to view a user's favorites and collections. It also discloses the login requirement as a prerequisite. However, it does not explicitly mention alternatives or 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?

With no annotations, the description carries the burden of explaining behavior. It clearly signals a read-only operation ('Get') and describes what data will be returned. It does not mention potential side effects, authentication, or rate limits, but these are less critical for a GET-style tool and the return content is well disclosed.

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

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

The description is a single, compact sentence that front-loads the core purpose and immediately lists what the caller will receive. There is no wasted wording.

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?

The description covers the output content but leaves a notable gap: both parameters are marked optional in the schema, and the description does not state that at least one identifier (listing_id or listing_url) must be supplied. Without an output schema, this missing requirement could lead to an agent calling the tool with no arguments. Otherwise, for a simple retrieval tool, the description is reasonably 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 100%, so parameter semantics are already fully documented by the schema. The description adds no additional meaning beyond referencing a 'specific Etsy listing' and does not clarify the relationship between the two identifier parameters or that at least one is expected.

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 detailed information for a specific Etsy listing and enumerates the key content areas (seller info, reviews, shipping, variations). It is easy to distinguish from siblings like etsy_search_products, which searches rather than retrieves details for a known listing.

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 clear context: use this when you need detailed information about a specific, already-identified listing. It does not explicitly exclude alternatives or name sibling tools, but the purpose is specific enough that an agent can infer when it applies versus searching or viewing cart.

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 burden of disclosing behavior. It indicates the tool is a get operation and lists some included data, but it does not mention whether authentication is required, whether the operation is fully read-only, how 'all listings' is returned or paginated, or any potential side effects.

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 focused sentence with no filler. Key information about the resource and the included data is front-loaded, though it could be slightly clearer about parameter requirements.

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?

The description is adequate for a simple get operation but incomplete in important ways: the schema marks both params optional while logically at least one shop identifier is needed, and the description does not address authentication or return structure. Since there is no output schema and no annotations, this leaves the agent with notable ambiguity.

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 input schema already has 100% coverage with descriptions for shop_url and shop_name, including the 'alternative to shop_name' note, so the schema handles parameter semantics. The tool description adds no extra parameter-level meaning beyond naming the shop resource.

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-resource structure: 'Get information about an Etsy shop' and specifies the content areas: ratings, policies, and all listings. It is clearly distinct from item-level or search tools, though it does not explicitly name a sibling alternative.

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

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

The intended use is implied: call this when you need shop-level information such as ratings, policies, or listings. However, the description gives no explicit guidance on when to choose this over etsy_get_item_details or etsy_search_products, and it does not mention 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?

No annotations are provided, so the description carries the full burden. It conveys that login is an authentication prerequisite, but does not disclose session behavior, failure modes, repeated-call effects, or related side effects. This is adequate but leaves notable behavioral gaps.

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 deliver the core purpose and the key usage precondition with no filler. Both sentences earn their place, and the most important information is front-loaded.

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

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

For a low-complexity login tool with two fully documented parameters, the description is largely complete: it states what the tool does and when it should be invoked. It could add more about login success or session state, but the lack of an output schema does not critically hinder 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 100%, with both email and password already described as 'Etsy account email' and 'Etsy account password.' The description only adds the generic term 'credentials,' so it provides no meaningful parameter 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?

The description uses a specific verb and resource: 'Log in to Etsy with credentials.' It clearly identifies the tool's function and naturally distinguishes it from all sibling tools, which are post-authentication Etsy actions rather than authentication 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?

The second sentence explicitly states when this tool is needed: 'before operations that require authentication.' It does not name alternatives or exclusions, but there is no alternative login tool among the siblings, so the guidance is sufficient.

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 full responsibility for behavioral disclosure. It does disclose the login requirement, which is useful auth context, but it does not mention side effects, irreversibility, or expected outcomes after sending. For a mutation tool, this is a moderate 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?

Two short sentences, no filler, action first, and the auth caveat second. Every word earns its place, and the structure is easy to scan.

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?

The schema fully covers parameter semantics and the description states the login requirement, covering basic invocation needs. However, with no output schema and no annotation, the agent gets no information about what a successful send looks like or what errors to expect, which is a noticeable gap for a write tool.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters, including that listing_url is an alternative to shop_name. The tool description adds no parameter-level detail, 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 uses a specific verb ('Send'), a clear resource ('a message to a seller on Etsy'), and is distinct from every sibling tool, none of which handle messaging. It immediately tells an agent what the tool does and leaves no ambiguity about its domain.

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 'Requires being logged in' gives a concrete prerequisite and implies the agent should call etsy_login first if no session exists. It does not explicitly compare to alternatives or state when not to use the tool, but no sibling offers a competing messaging action.

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 of behavioral disclosure, and it is thin: it implies a read-only search but never states that results are paginated, what a response looks like, or any defaults. More seriously, it claims filtering by 'location' while no location parameter exists in the schema — a misleading capability that could cause an agent to expect or pass unsupported arguments.

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

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

Two sentences, zero waste, with the core action front-loaded in the first sentence and the capability scope compressed into a compact second sentence. 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?

For a tool with six parameters, no annotations, and no output schema, the definition leans on the schema for sort and pagination semantics — which works because schema coverage is 100%. Clear gaps remain: no description of the return shape, the misleading location reference, and no explicit acknowledgment of pagination behavior via the page parameter. Adequate but with evident 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 coverage is 100%, so the baseline 3 applies. The description adds marginal value by grouping filters into conceptual categories (category, price range) that map to schema parameters, but it also introduces a phantom 'location' filter with no corresponding property, which could mislead an agent into passing an invalid argument. Net effect is baseline.

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 for products on Etsy' — with a scope no sibling shares. The closest sibling, etsy_get_item_details, targets a known item rather than discovery, so an agent can route to this tool confidently without ambiguity.

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

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

The description implies use for product discovery and lists filtering capabilities, giving the agent a sense of when it is useful. However, it never explicitly says when to prefer it over alternatives like etsy_get_item_details (known-item lookup) or states exclusions. Usage context is inferable from sibling names but not articulated.

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 behavioral disclosure burden. It discloses an authentication requirement and implies a read-oriented operation through 'View,' but it does not explicitly state side effects, default behavior, or what is returned.

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, no filler, and the primary purpose is presented first. The authentication note is a necessary addition that 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?

The tool is simple and parameters are well-described, but there is no output schema and the description does not clarify default behavior when no filters are supplied or what the response looks like. It is adequate for selection but slightly incomplete for full invocation 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%, so both order_id and status_filter are already documented. The description adds no parameter-level detail, which is acceptable because the schema fully covers parameter 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?

The description uses a specific verb phrase, 'View and track orders,' and clearly names the resource (Etsy orders). It is easy to distinguish from all sibling tools, which target different resources like cart, favorites, or checkout.

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 clear context by stating this is for viewing/tracking orders and explicitly notes that login is required. It does not list exclusions or alternative tools, but the resource focus makes when to use it reasonably 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 are provided, so the description carries the full burden of behavioral disclosure. It only implies a read-only operation ('View') and gives no details about side effects, authentication requirements, session state, or whether the operation can fail. This is a meaningful gap for a tool interacting with cart state.

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, focused sentence with no filler. It states the purpose directly and is easy to scan.

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?

This is a simple no-parameter read operation, so the description is mostly adequate for invocation. However, with no output schema and no annotations, the agent is not told what response shape to expect or whether authentication is required. For a tool this simple, this is a minor but real gap.

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 has zero parameters and the schema is fully covered. With no parameters, there is nothing for the description to add; the baseline 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 action ('View') and the resource ('current contents of the Etsy shopping cart'). It is immediately distinguishable from sibling tools like etsy_add_to_cart or etsy_checkout.

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 usage context is implied: an agent would call this to inspect the cart, likely before checkout or before adding items. However, there is no explicit guidance about when to use this versus alternatives, no exclusions, and no mention of prerequisites like login.

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