Server Quality Checklist

Tool Scores

• etsy_list_listingsC
  2.7/5.0
  Behavior2/5

  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 states that listings are filtered by state, which largely repeats the schema. It does not disclose pagination behavior, default state behavior, response shape, or any authorization requirements.

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

  Conciseness4/5

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

  The description is a short, front-loaded phrase with no filler or redundant detail. However, it is a fragment rather than a full sentence, and the extreme brevity starts to undermine completeness.

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

  Completeness2/5

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

  Given four parameters, no output schema, and no annotations, this description is under-specified. An agent cannot tell what happens when state is omitted, how pagination works, what fields are returned, or what errors may occur.

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

  Parameters2/5

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

  Schema description coverage is only 25%, and the description does not compensate. It hints at shop_id ('in a shop') and state ('filtered by state'), but says nothing about limit or offset semantics, defaults, or how the state filter behaves when omitted.

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

  Purpose4/5

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

  The description identifies the resource ('listings'), the scope ('in a shop'), and the key filter ('by state'). It is clear enough to distinguish from etsy_get_listing (single listing) and etsy_list_receipts (receipts), though it does not name those siblings explicitly.

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

  Usage Guidelines2/5

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

  There is no guidance on when to choose this tool versus etsy_get_listing, etsy_list_receipts, or etsy_list_operations. The context is implied only by the resource name, with no explicit when to use or when not to use.

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

• etsy_list_receiptsC
  2.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden, and it does add one useful behavioral detail: the 'transactions_r' scope requirement. However, it does not explicitly state that this is a read-only list operation, nor does it cover pagination, rate limits, or response shape. The auth requirement adds value but the behavioral context remains thin.

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

  Conciseness3/5

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

  The description is very short and has no filler, but it is terse to the point of being elliptical. Both sentences contribute information, yet the phrase 'Orders in a shop' is not a complete sentence and could be clearer. It is concise but sacrifices expressiveness.

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

  Completeness2/5

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

  For a tool with 5 parameters, no annotations, and no output schema, the description is far from complete. It explains neither the filter parameters nor the return behavior, and it gives no selection context relative to siblings. The 'transactions_r' requirement is helpful, but it is the only contextual signal beyond the schema.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description provides no explanation of shop_id, limit, offset, was_paid, or was_shipped. 'Orders in a shop' only hints at the shop_id parameter, while the boolean filters and pagination semantics are completely unexplained.

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

  Purpose4/5

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

  The description identifies the resource as orders/receipts within a shop, which aligns with the tool name 'list_receipts' and helps distinguish it from sibling tools that target listings or the current user. It lacks an explicit verb such as 'lists' or 'retrieves', but the resource and scope are clear enough.

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

  Usage Guidelines2/5

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

  The only usage-related information is the required 'transactions_r' scope, which is a precondition rather than guidance on when to use this tool. It does not mention alternatives like etsy_list_listings, etsy_list_operations, or when a different tool would be more appropriate.

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

• etsy_get_listingB
  3.2/5.0
  Behavior3/5

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

  The description discloses that the endpoint is public and does not require a seller token, which is valuable behavioral context. But with no annotations, it does not explicitly state whether the operation is read-only, mention rate limits, errors, or describe the response behavior beyond 'in full'.

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

  Conciseness4/5

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

  The description is extremely concise—two short phrases with no fluff—and front-loads the core purpose before the access note. It is a bit telegraphic, but every part earns its place.

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

  Completeness3/5

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

  For a simple fetch-by-ID tool, the description covers the core purpose and public access, and the schema documents the optional 'includes' parameter. However, it lacks explicit usage guidance, response expectations, and any note about how 'includes' affects the returned detail, leaving moderate gaps.

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

  Parameters2/5

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

  Schema coverage is 50%: 'includes' is described in the schema, but 'listing_id' has only a type. The description adds no parameter-level meaning and does not compensate for the undocumented required parameter.

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

  Purpose4/5

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

  The description 'One listing in full' clearly identifies the resource (a single listing) and the scope ('in full'), which distinguishes it from etsy_list_listings. It lacks an explicit verb like 'retrieve' or 'get', but the meaning is unambiguous from the name and phrasing.

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

  Usage Guidelines3/5

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

  The description implies usage for fetching one complete listing rather than a list, and the note 'Public — works without a seller token' gives useful context. However, it does not explicitly state when to use this tool versus alternatives like etsy_list_listings or etsy_call.

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

• etsy_callB
  3.3/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full behavioral disclosure burden. It does offer a useful insight: Etsy scope refusals can masquerade as permission errors. But it fails to disclose that the tool can invoke mutating operations, requires authentication/scopes, or returns operation-dependent response shapes. These are material gaps for a generic dispatcher.

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

  Conciseness5/5

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

  Two short sentences deliver the core purpose first, then add a targeted troubleshooting hint. There is no filler, restatement, or redundant detail. The structure is front-loaded and every word earns its place.

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

  Completeness2/5

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

  For a generic dispatch tool with no output schema and no annotations, this definition is incomplete. It omits how to obtain valid operation ids, how body and params should be shaped, what response variability to expect, and whether operations can have side effects. The 403 scope hint helps but leaves too many invocation details unexplained.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate for the schema's silence. It only clarifies operation_id ('by id'). The body and params objects receive no explanation of how they correspond to Etsy API path, query, or body arguments. This is insufficient for an agent to confidently construct a request.

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

  Purpose5/5

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

  The description states a specific verb ('Call'), a clear resource ('any Etsy operation'), and the key selection criterion ('by id'). This immediately distinguishes it from the sibling tools, which are named for specific operations (e.g., etsy_get_listing, etsy_list_receipts), making it clear this is the generic dispatcher.

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

  Usage Guidelines3/5

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

  The description implies use when an operation id is available and provides a conditional fallback to etsy_check_scopes on 403. However, it does not explicitly state when to prefer dedicated sibling tools over this generic call, nor does it mention discovering valid operation ids via etsy_list_operations. Normal selection guidance is only implied, not explicit.

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

• etsy_get_meA
  3.5/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full disclosure burden. It communicates that the tool returns the authenticated user and includes two key fields, implying a read-only lookup, but it does not mention failure behavior, scope requirements, or response shape beyond those fields.

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

  Conciseness5/5

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

  One concise sentence front-loads the resource and the important returned fields with no filler or redundancy. Every word adds information.

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

  Completeness4/5

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

  For a zero-parameter getter with no output schema, the description covers the essential resource and return fields adequately. It is slightly thin on auth/scope expectations, but the low complexity makes this a reasonably complete description.

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

  Parameters4/5

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

  The input schema has zero parameters and 100% coverage, so there is no parameter detail for the description to add. The baseline of 4 applies because no parameter documentation is needed.

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

  Purpose4/5

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

  The description names the resource, 'authenticated Etsy user', and the specific fields returned, 'user_id' and 'shop_id', which makes it distinct from sibling tools like etsy_get_listing and etsy_list_receipts. It loses a point only because it is phrased as a noun phrase rather than an explicit verb like 'retrieves' or 'gets'.

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

  Usage Guidelines2/5

  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 etsy_call or etsy_list_operations, and no mention of required authentication scopes or prerequisites. An agent must infer from the name and resource alone that this is the tool for fetching the current user.

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

• etsy_check_scopesA
  4.2/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the behavioral burden. It discloses that held=true asks Etsy what the token actually carries and requires a seller token, and it frames the tool as diagnostic. It doesn't spell out rate limits or response shape, but for a check-style tool this is solid context.

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

  Conciseness5/5

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

  Four short sentences, front-loaded with purpose, then when to use it, then how to use the parameters. Every sentence contributes to the diagnostic story with no filler.

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

  Completeness4/5

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

  This is a simple tool with two optional parameters and no output schema. The description covers purpose, use cases, and both parameters well. It doesn't explicitly describe the response format, but the output is reasonably inferable from 'which scopes' and 'what each one unlocks.'

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

  Parameters3/5

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

  The schema already provides 100% parameter coverage, so the baseline is 3. The description's 'pass an operation id' and 'pass held=true' instructions reinforce the schema rather than adding new syntax or constraints. The 403-fix framing adds workflow context but no new parameter-level meaning.

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

  Purpose5/5

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

  The description opens by defining exactly what the tool delivers: which OAuth scopes the Etsy API needs and what each scope unlocks. This distinguishes it from sibling tools like etsy_call or etsy_list_operations, which are about executing or listing operations rather than explaining scope requirements.

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

  Usage Guidelines4/5

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

  It gives explicit timing and diagnostic context: useful before authorizing an app and as the fastest way to understand a 403. It does not name sibling alternatives or state when not to use it, so it falls just short of the top anchor.

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

• etsy_list_operationsA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full disclosure burden. It communicates that this is a read-oriented browse operation, that it covers the entire seller-facing Etsy API, and that each entry exposes the OAuth scope needed — actionable context for handling 403s. Exact output shape and pagination are not stated, but the core behavior is clear.

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

  Conciseness5/5

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

  Three sentences with no filler: purpose is front-loaded, the seller-facing scoping sentence gives useful context, and the final sentence points to the consuming tool. Every sentence earns its place.

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

  Completeness4/5

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

  For a single-optional-parameter catalog tool with no output schema, this is nearly complete: it explains what the tool returns conceptually, why OAuth scopes matter, and how to use the result with etsy_call. The only gap is finer output-shape or pagination detail, which is not essential for selecting and invoking it correctly.

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

  Parameters4/5

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

  The schema already documents the single optional search parameter, so the baseline is 3. The description adds value by naming the fields it filters (id, path, tag, summary) and providing concrete examples ('listing', 'receipt', 'shipping'), going beyond what the schema alone provides.

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

  Purpose5/5

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

  Opens with a concrete action and countable resource: 'Browse all 105 operations in the Etsy Open API v3.' It clearly positions the tool as the operation catalog and ties it to the next step, 'find an operation id for etsy_call,' which distinguishes it from siblings like etsy_list_listings, etsy_get_listing, or etsy_call itself.

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

  Usage Guidelines4/5

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

  Explicitly says when to use it: 'Use this to find an operation id for etsy_call.' It also gives helpful search direction by id, path, tag, or summary. It does not enumerate when-not-to-use conditions or name alternative siblings for comparison, so it stops just 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.