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, but it only restates the action and the target audience. It does not explain what accepting does, whether it is idempotent, what side effects occur, or what authentication requirements exist beyond the vague 'authenticated account' phrasing.

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 concise sentence with no filler or redundant wording. It is front-loaded with the primary action, though it could be slightly more informative without becoming verbose.

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

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

Despite the low complexity of one parameter and an output schema, the description omits key context such as how share_id relates to list_my_invites, what a successful acceptance returns, and what state changes occur. An agent can guess the basic call but lacks enough context to use it confidently.

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 one required parameter, share_id, with no description and 0% schema description coverage. The tool description does not mention share_id at all, so it adds no guidance about where the ID comes from, its format, or how to obtain it; only the parameter title 'Share Id' hints at its 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 states a clear action ('Accept') and a specific resource ('an invitation addressed to the authenticated account'), which conveys the tool's purpose. It distinguishes itself from siblings like invite_person and list_my_invites by direction and action, though it does not explicitly name those alternatives.

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

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

The phrase 'addressed to the authenticated account' implies the intended use case: accepting an invite received by the current user. However, there is no explicit guidance about when to use this tool versus list_my_invites, invite_person, or other related tools, and no exclusions are provided.

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 behavioral disclosure. It only says 'Save,' implying mutation, but does not disclose idempotency (despite the idempotency_key parameter), side effects, authorization needs, or what happens on duplicate captures. This is a significant gap for a mutating tool.

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

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

The description is extremely brief (one sentence), which is concise, but it is under-specified rather than appropriately sized. It omits essential operational details, so the brevity is a deficiency, not a virtue.

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 complexity (six parameters, one required), an output schema exists, but the description still leaves critical gaps: parameter semantics, usage context, and behavioral expectations. The description is far from complete for an agent to invoke it correctly without additional schema inspection.

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

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

Schema description coverage is 0%, and the description mentions none of the six parameters. It does not explain what list_id, url, title, variant, quantity, or idempotency_key mean or how they interact. The description fails to compensate for the total lack of schema-level descriptions.

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

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

The description states a clear action ('Save') and a specific resource ('the exact URL') with a notable qualifier ('including existing referral attribution'). This distinguishes the core purpose from unrelated siblings, though it does not explicitly mention the list context implied by the required list_id parameter, leaving some 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?

No guidance is provided on when to use this tool versus alternatives like reserve_item or create_list. There is no mention of prerequisites, when not to use it, or how it differs from other capture-like operations.

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 behavioral disclosure. It states the core action (creating a list) and implies an owner, but it omits side effects, permission requirements, idempotency behavior, and edge cases like duplicate titles. This goes only slightly beyond the tool's name and fails to describe the behavioral profile an agent needs for a mutation operation.

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

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

The description is a single, front-loaded sentence with no filler or redundancy. It efficiently communicates verb, resource, variants, and ownership. While arguably too terse for full clarity, it is appropriately concise for a simple create operation and every phrase 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?

Given the tool has 3 parameters, 2 enums, and an output schema, the description covers only the basic concept and leaves out when-to-use guidance, authentication expectations, and edge-case behavior. The presence of an output schema reduces the need to explain return values, but other important context (e.g., duplicate handling, ownership validation) is missing, so the description is not complete enough on its own.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning by mapping 'shopping/wish' to the mode enum and 'private/public' to the visibility enum, which the schema titles alone do not convey. However, it says nothing about the required title parameter or how defaults interact, leaving part of the parameter semantics to inference.

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 the specific verb 'Create' and identifies the resource as a 'shopping/wish list', while also explaining the two modes and visibility options. It clearly differentiates from read-oriented siblings like get_list and list_my_lists, though it does not explicitly name an alternative or contrast with a sibling, preventing a perfect score.

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 is provided on when to use create_list versus alternatives such as get_list, list_my_lists, or capture_url. There is no mention of prerequisites, ownership requirements, or any 'if you need X, use Y' instructions. The only implied usage is 'when you want to create a list', which is insufficient for distinguishing from other 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 behavioral burden. It communicates that the tool returns an agent credential that must be stored securely, which is useful, but it does not disclose whether the request secret is consumed, single-use, or what happens on 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?

The description is two short sentences with no filler. The core action and timing are front-loaded, and the second sentence adds a meaningful security-handling instruction.

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 tool with an output schema, the description covers the essential workflow: when to call it and how to handle the result. It is slightly incomplete because it does not explicitly state where the request_secret comes from or whether the secret is reusable.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented request_secret parameter. It refers to 'a private pairing request secret' but does not specify its origin, format, or lifecycle, leaving the agent to infer that it likely comes from a prior pairing step.

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 ('Exchange') with a clear resource ('a private pairing request secret') and states the outcome ('Store the returned agent credential'). It is distinct from the sibling start_agent_pairing, which implies initiation rather than finalization.

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 'after the person approves' gives an explicit precondition for when this tool should be used. It does not name alternatives or exclusions, but the workflow timing is clear enough that an agent can infer when to call 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 must carry the behavioral burden. It mentions 'original saved merchant URL without rewriting it,' hinting at a read-only nature, but does not disclose any side effects, error conditions, or authentication requirements. It's too minimal for a tool with no 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?

The description is a single concise sentence, front-loaded with the core purpose. It avoids fluff, but is slightly under-specified; however, for conciseness it earns credit for being efficient.

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 has an output schema and a single parameter, the description should at least explain what a 'handoff' is and what the 'original saved merchant URL' represents. It lacks context about when to use this tool, how it relates to capture_url, and what the output looks like. The description is inadequate for an agent to call it correctly in a broader workflow.

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

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

The schema has 0% description coverage and the description doesn't explain what 'item_id' refers to. The agent is left to guess that it's an identifier for the handoff record, but no format, source, or relationship to the URL is provided. The description adds no value beyond the schema's bare property name.

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

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

The description states a specific verb ('Get') and resource ('original saved merchant URL'), and the phrase 'without rewriting it' implies a contrast with a rewriting variant, which helps distinguish it from tools like capture_url. However, it does not name the sibling tool explicitly, so it's clear but not fully differentiating.

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. The description doesn't mention any context or conditions under which this tool should be chosen over siblings like capture_url or get_list, leaving the agent to infer usage.

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 behavioral disclosure burden. 'Read' usefully signals a non-mutating operation, and 'when ... permits it' hints at authorization checks. But it does not describe what happens when access is denied or how grants are resolved.

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. It is concise and readable, though it does not make use of the available space to mention the list identifier.

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 one-parameter read tool with an output schema, the description is lean but incomplete. It lacks guidance on how get_list relates to get_public_list or list_my_lists, and with no annotations, the permission model remains too vague for an agent to confidently select this 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 0%, and the description never explains list_id or how the list is identified. The parameter name is self-explanatory, but the description adds no semantic value to compensate for the missing schema documentation.

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

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

The description states a clear action ('Read') and a clear resource ('a list'), and the permission condition adds useful scope. However, it does not explicitly differentiate get_list from siblings like get_public_list or list_my_lists, so it falls 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?

The description offers no guidance on when to use this tool versus alternatives. The phrase 'when the configured account or grant permits it' describes a precondition, not a use case, and sibling tools such as get_public_list and list_my_lists are never mentioned.

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

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

No annotations are provided, so the description carries the full burden. It indicates a read operation and mentions the 'authenticated account', implying authentication is required. However, it does not disclose error behavior, idempotency, or any side effects. For a simple read, this is adequate but not rich.

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

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

The description is a single, clear sentence that front-loads the action and object. No extraneous words or redundancy. Perfectly concise.

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

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

Given no parameters, an output schema that defines the return format, and a simple read operation, the description fully covers what the tool does. It specifies the exact data returned (alias and profile URL) and the scope (authenticated account). Nothing essential 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?

There are zero parameters, so the description needs no parameter-level detail. The schema is trivially complete. The description adds no parameter information but none is needed, so it meets the baseline for a zero-parameter tool.

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

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

The description clearly states the verb 'Read' and the specific resource: the authenticated account's alias and profile URL. It distinguishes from siblings like get_public_profile by explicitly scoping to the authenticated account. No 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 this is for the authenticated user's own profile, but it does not explicitly mention when to use this versus get_public_profile or other sibling tools. There is no explicit guidance on context or alternatives, leaving the agent to infer the intended use.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Read' implies a non-mutating operation, but the description does not state visibility rules, authentication needs, error behavior, or what qualifies as public; the output schema covers return shape but not these behaviors.

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: verb, resource, and lookup key are all present. The length is appropriate for a one-parameter read operation.

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 a closely named sibling get_list, the definition lacks enough behavioral and selection context for reliable invocation. The output schema covers return values, but missing visibility/auth details and alternative guidance leave a meaningful 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 schema has only one parameter with 0% description coverage, so the description's 'by slug' is the only clue that slug is the resource identifier rather than some unrelated filter. This adds essential meaning, though it does not define slug format or constraints.

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 ('Read') and resource ('public list') with the lookup key ('by slug'), so the core action is clear. The word 'public' partially differentiates it from the sibling get_list, but it never explicitly names or explains the relationship, 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?

No guidance is given for when to use this tool versus get_list, get_public_profile, or other siblings. The phrase 'public list' implies a use case, but there are no exclusions, prerequisites, or alternative routing cues, leaving the agent to infer selection logic.

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 behavioral burden. It does disclose that this is a read operation on public data, implying no side effects and likely no authentication. However, it does not mention potential errors, rate limits, or whether the alias is a username or ID. Minimal but not misleading.

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 that is efficient and front-loads the action. No wasted words.

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 tool with an output schema, the description covers the core action, but it lacks usage guidance and parameter semantics. It does not tell the agent when to choose this over siblings like get_public_list or how to format the alias. The presence of an output schema mitigates some return-format concerns, but the gaps in usage and parameter clarity keep it from being 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 coverage is 0%, so the description must explain the alias parameter. It only says 'by alias', which simply echoes the parameter name. It does not define what constitutes an alias (e.g., username, email, numeric ID) or provide format hints. This is insufficient given zero schema documentation.

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

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

States a specific verb 'Read' with a clear resource 'a person's public profile and public lists' and the key parameter 'alias'. This distinguishes it from get_public_list which likely returns a single list, while this covers profile and lists together.

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

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

No guidance on when to use this vs alternatives like get_public_list or get_my_profile. The description only states what it does, leaving the agent to infer usage. Lacks any exclusions or alternative routing.

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 says 'invite,' which implies sending an invitation, but does not clarify whether the invitee is immediately added to the list or must accept first (as suggested by accept_list_invite). It also does not mention permissions required, side effects, or reversibility. The absence of such details makes behavior ambiguous.

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 concise sentence with no waste, which is efficient. However, it is so short that it omits essential information. It is appropriately sized for its simplicity but under-specified, so it does not fully earn its place; it could be expanded without adding fluff.

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 complexity (3 params, no annotations, an output schema present), the description is incomplete. It does not explain the invitation flow, any requirements, or what the output represents. An agent would need to guess at behavior, making this insufficient for reliable invocation.

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

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

Schema description coverage is 0%, so the description must compensate by explaining parameters. However, it says nothing about list_id, recipient_alias, or can_reserve. The agent has no clue what 'recipient_alias' means (e.g., username vs email) or what 'can_reserve' does. This is a critical deficiency for a tool with three 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?

The description clearly states the verb 'Invite' and the resource 'a named ShopsApp user to one list.' It distinguishes from accept_list_invite and list_my_invites by implying the act of sending an invitation. However, it could be more explicit about the meaning of 'named' (i.e., recipient_alias) and the fact that this is about sending, not accepting.

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 like accept_list_invite, nor any prerequisites (e.g., must the recipient be a ShopsApp user? Must I be the list owner? Does the invite require acceptance?). The description leaves the agent to infer usage context, which is a significant gap for a tool with no annotations.

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 does disclose that the operation is a read and scopes it to the authenticated account, but it does not mention whether only pending invitations are returned, whether any state changes occur, or what happens if no invitations exist. The output schema covers return shape, but behavioral details beyond that are sparse.

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 with no filler. The action, resource, and scope are all front-loaded, making the description easy to parse quickly.

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 an output schema, this description is complete. It identifies what is being listed and for whom, and the output schema handles return structure. Nothing else is needed 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?

There are zero parameters, so the baseline of 4 applies. Schema description coverage is vacuously 100%, and the description has no parameter meanings to add because none exist.

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 ('Read') and a precise resource ('invitations addressed to the authenticated account'). This clearly distinguishes it from sibling tools like invite_person (sending invitations) and accept_list_invite (acting on invitations), as well as from list_my_lists and list_shared_with_me.

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 'addressed to the authenticated account' implies the tool is for viewing the caller's own incoming invitations, but there is no explicit guidance about when to use it versus accepting invitations or listing shared items. No prerequisites or exclusions are stated; the usage context is present but only implied.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It communicates a read-only listing operation and ownership scope, but does not mention pagination, ordering, whether both list types are merged, or any other runtime behavior. The output schema exists, which helps, but the description itself adds little beyond the basic action.

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

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

The description is a single clear sentence with no wasted words. It front-loads the action and scope without redundancy.

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

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

For a simple zero-parameter read operation with an output schema, the description covers the essential context: whose lists and which lists. It could mention that it returns only non-shared, personally-owned lists more explicitly, but the current scope statement is largely sufficient given the tool's low complexity.

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

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

The tool has zero parameters and full schema coverage, so there are no parameter meanings to explain. The baseline for a zero-parameter tool is 4, and the description appropriately says nothing about 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?

The description names a specific verb ('List') and a precise resource ('the authenticated owner's shopping and wish lists'), making the tool's purpose immediately clear. This clearly distinguishes it from siblings like list_my_invites, list_shared_with_me, and get_list.

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 conveys that this is for the authenticated owner's own lists, which implies the right context for use. However, it does not explicitly mention when not to use it or point to alternatives such as list_shared_with_me or get_list.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It communicates a read operation and an authentication requirement, but it does not disclose pagination, ordering, or any response limitations. This is adequate for a simple list read but adds little beyond the operation name.

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 that front-loads the verb and resource and contains no filler. It is appropriately sized for a zero-parameter read 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?

For a zero-parameter read with an output schema, the description covers the essential resource and scope. It does not explicitly contrast with list_my_lists, which would help disambiguation, but the 'shared with' phrasing largely carries that meaning.

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 zero parameters and schema description coverage is 100%, so the description has no parameter burden. The zero-parameter baseline applies; no additional parameter explanation is needed.

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 ('Read') and a precise resource ('lists shared with the authenticated account'). This clearly distinguishes it from siblings like list_my_lists (owned lists) and get_public_list (public lists).

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 the intended context: use when you need to see lists others have shared with the authenticated account. It does not explicitly name alternatives or state when not to use it, so the guidance is left to inference rather than explicit routing.

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 says 'release' but does not state whether the action is destructive or irreversible, what happens to the underlying item, or whether any permissions are required. The lack of behavioral detail leaves significant room for misinterpretation.

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 that front-loads the action ('Release') and the target ('abandoned gift reservation'). There is no wasted wording, and it is appropriately sized for a 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?

Given the low complexity (one parameter, no annotations, output schema present), the description still leaves critical gaps: no usage context, no behavioral details, and no parameter explanation. The presence of an output schema reduces the need to describe return values, but the tool remains incomplete for safe and 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 coverage is 0% and the description does not mention the reservation_id parameter at all. It does not add any meaning beyond the parameter's name and type, failing to compensate for the missing schema documentation.

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

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

The description uses a specific verb ('Release') and resource ('abandoned gift reservation'), making the tool's core action clear. It distinguishes from siblings like reserve_item (which creates reservations) and list tools, though the qualifier 'abandoned' could be more fully explained.

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

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

The description provides no guidance on when to use this tool vs alternatives, such as reserve_item, or any prerequisites or conditions (e.g., what counts as 'abandoned'). The inverse relationship to reserve_item is implied but never 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 behavioral burden. It does disclose that the tool does not purchase, which is a key safety behavior. However, it omits other important behaviors such as side effects (inventory hold), reversibility, timeout, or idempotency implications. It provides only minimal transparency.

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

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

The description is a single sentence that efficiently conveys the core action and its key exception (not purchasing). It is front-loaded with the verb and resource, and every word contributes to understanding. No fluff or redundancy.

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

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

Despite having an output schema, the description is incomplete for a state-changing operation. It does not explain what happens on success or failure, how idempotency_key affects behavior, or what the response contains. Given the lack of annotations, an agent would be under-informed about the consequences of calling this 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 0%, and the description does not explain either parameter. It mentions 'gift unit' but never ties it to item_id, and idempotency_key is entirely unexplained. The description adds zero value beyond the raw schema types, so the agent cannot infer parameter purpose or constraints.

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: 'Reserve one gift unit' and clarifies the critical nuance that it does not purchase it. This distinguishes it from a purchase action and gives a specific resource. While it doesn't explicitly reference sibling tools like release_reservation, the core purpose is unambiguous and actionable.

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

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

The description provides no guidance on when to use this tool versus alternatives such as release_reservation or other list/gift tools. It mentions 'after the buyer chooses' which implies a sequence, but there is no explicit when/when-not or mention of alternatives. An agent is left to infer context from the sibling list.

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. It discloses that signup is email-verified, that only the person can finish, and that no credential is returned. This is meaningful behavioral context that goes beyond the schema and helps set expectations.

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 with zero fluff. The main action is front-loaded, and the follow-up sentence adds critical constraints. Every word contributes value.

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

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

For a single-parameter tool with an output schema present, the description covers the essential purpose, precondition, and a key aspect of the return (no credential). It could mention error conditions or duplicate email handling, but those are likely handled by the output schema. Overall, it is adequately complete 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?

Schema description coverage is 0%, so the description must compensate. It indirectly explains the email parameter by mentioning 'email-verified signup' and 'sending an email', implying the email is the verification target. However, it does not explicitly describe the parameter's format or constraints, leaving partial gap.

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 a specific action ('Start email-verified signup') and the resource involved (email). It distinguishes itself from siblings like start_agent_pairing by focusing on account signup, and it conveys a clear purpose that is not a tautology.

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 specifies the precondition 'after the person approves sending an email', giving clear context for when to invoke it. It does not explicitly name alternatives, but the sibling set contains no direct signup alternative, so the context is sufficient for a reasonable agent.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that the tool initiates an owner-approval flow and returns an approval_url and request_secret, including a clear security directive. It doesn't cover state changes or failure cases, but the essential behavior is 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?

Two short sentences with the main action front-loaded. Every word earns its place, and the security note is essential guidance tightly packed.

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 tells the agent what to do and how to handle secrets, but omits requested_access semantics and any follow-up pairing step. An output schema exists to cover return structure, but the missing parameter explanation and lack of flow context leave gaps.

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

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

Schema description coverage is 0%, so the description needed to explain agent_name and requested_access. It does not define either, only referencing 'this agent' generically. The output fields approval_url and request_secret are described, but the input parameters are left undocumented.

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 ('Request owner approval for this agent') with a specific verb and target. It doesn't reference sibling tools like exchange_agent_pairing to differentiate, so it misses the top score, but the purpose is unambiguous.

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

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

No guidance is provided about when to use this tool versus alternatives such as exchange_agent_pairing, invite_person, or start_account_signup. No prerequisites, exclusions, or follow-up steps are mentioned, leaving the agent to infer the appropriate context.

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