FindMyPart

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

Annotations already declare readOnlyHint/destructiveHint=false, so the safety profile is covered; the description adds billing and auth context ('does not create a charge', 'email is optional') that annotations cannot express. It also enumerates the output facets, though it does not say whether repeated calls are stateful (idempotentHint=false).

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 tight sentences, front-loaded with the routing rule followed by return-value summary and the free/optional-email caveat. The enumerated return list is slightly list-heavy but each item is informative and none is redundant.

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 5-param, no-output-schema tool, the description compensates well by enumerating what the Passport returns and covering billing/safety, but it leaves the four optional parameters (domain, location, asset_info, email semantics) essentially unexplained. Adequate but with a clear parameter-side 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?

Schema description coverage is 0% across 5 params, so the description must carry parameter meaning, but it only clarifies that email is optional. It says nothing about the domain enum values, location, asset_info, or what part_description should contain beyond the tool's general trigger.

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?

Names a specific action (build the free Part Passport) and the exact trigger condition (concrete hard-to-identify or hard-to-source part problem), and positions itself as a free-tier entry point against the paid siblings. An agent can distinguish it from the offers/checkout/status tools immediately.

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

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

Explicitly states 'Preferred first tool' and orders itself before paid tiers ('before showing paid tiers'), which is exactly the routing guidance needed among the prepare_part_hunt_checkout / get_part_hunt_offers siblings. No exclusions are stated, but the sequencing rule is unambiguous.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior, and the description's verb 'Describe' aligns with those. It adds useful scope beyond the annotations by specifying that the tool covers endpoints, payment boundaries, and agent tools, which helps an agent know what to expect from the response.

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, tightly worded sentence with the action verb front-loaded and the subject matter listed as a concise set. Every phrase contributes useful information and there is 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 zero-parameter, read-only introspection tool, the description conveys purpose and scope sufficiently. The lack of an output schema is mitigated by the simple descriptive nature, though the description does not hint at the response format or detail level.

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?

This tool takes zero parameters, so per baseline it does not need parameter documentation. The description adds no parameter meaning, but none is required given the empty schema.

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

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

The description uses a clear verb ('Describe') and names a specific object: FindMyPart machine-facing endpoints, payment boundaries, and available agent tools. This is clearly a meta/capability tool and is distinguishable from the part-hunt sibling tools, though it does not explicitly contrast itself with them.

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: an agent would call this to discover FindMyPart's capabilities before choosing among operations. However, the description does not explicitly state when to use it versus alternatives, nor does it mention any exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds context beyond them by stating the call "creates no payment obligation" — a non-obvious reassurance for a tool that lists paid offers. It does not describe pagination or result shape, so it stops short of 5.

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

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

Three short sentences, front-loaded with what the tool returns, then usage routing, then the reassurance. Every sentence carries distinct information and none is padding.

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 zero-parameter read-only listing tool with no output schema, the description covers purpose, routing, and the key behavioral caveat. It does not sketch what an "offer" entry contains, which is a minor omission given there is no output schema to fall back on.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4; there is no argument syntax an agent needs from the description. The description appropriately spends its words on usage routing instead of nonexistent parameters.

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 ("List") and resource ("current paid FindMyPart hunt options and pricing"), making it immediately distinguishable from the free-triage sibling and the checkout/status siblings. An agent can tell what this returns without opening any schema.

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

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

Gives explicit positive triggers ("when the user asks about pricing or after free_part_triage") and an explicit negative trigger ("Do not use this as the first action when the user already supplied a concrete part problem"). This is exactly the when/when-not/alternative routing guidance the dimension asks for.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description still adds value by disclosing that the view is 'customer-safe' (i.e., filtered/sanitized) and by enumerating the state domains returned, which an agent cannot infer from structured fields. No contradiction with annotations.

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

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

A single front-loaded sentence that opens with the verb and ends with a scope qualifier. The domain list is slightly dense but each element is informative; 'Read-only' mildly duplicates the readOnlyHint annotation.

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 output schema exists, so the description correctly compensates by enumerating the returned state domains. Combined with annotations covering safety, an agent has enough to invoke it correctly; only error/edge behavior on the token is missing.

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

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

With one parameter and 0% schema description coverage, the description must carry the semantics. 'Using its tracking token' identifies the token as the hunt identifier, which is helpful, but it adds nothing about format, the 12-240 character constraints, or how an invalid/expired token behaves.

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 (Retrieve) and a precisely enumerated resource (customer-safe Part Passport, sourcing-lane, evidence, payment, fulfillment and solution state) scoped to a FindMyPart hunt. It is clearly distinguishable from get_part_hunt_offers and prepare_part_hunt_checkout by naming the aggregate state domains, though it never explicitly contrasts itself with those 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?

Usage is implied: call this with a hunting tracking token to read current state. There is no guidance on when to prefer it over get_part_hunt_offers, free_part_triage, or get_findmypart_capabilities, and no preconditions or exclusions 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?

Annotations already indicate this is not read-only (readOnlyHint=false). The description adds meaningful behavioral context: it creates a session, does not charge, and does not prove payment, plus implies a reservation side effect. This is beyond the structured fields and no contradiction exists.

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, front-loaded with the condition and action, and no wasted words. It efficiently conveys the core purpose and the non-charging nuance.

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 involves complex state changes and 11 parameters, but the description does not mention the output format (e.g., how the checkout URL is returned, whether an ID or expiry is provided). It also ignores parameter semantics. For a checkout preparation, this is incomplete for an agent to invoke correctly.

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

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

Schema coverage is 0% and the description provides no parameter-level explanation. It only indirectly mentions user_confirmed_payment via 'explicitly agrees to pay', but does not clarify offer_slug, email, part_description, or optional parameters. With 11 parameters, this is a significant gap that the description fails to address.

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 clear action: after human confirmation, reserve the hunt and prepare a secure checkout URL. It also clarifies it does not charge or prove payment. This distinguishes it from sibling tools (capabilities, offers, status) which are all read-only queries.

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 explicitly conditions usage on the human agreeing to pay, which is a useful trigger. It does not list exclusions or alternatives, but no sibling tool performs checkout, so the context is sufficient. It does not mention when not to use it, but the precondition is clear.

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