XP Tickets

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

Annotations only declare destructiveHint=true; the description adds far more, disclosing that acceptance is irreversible, that it starts a seller-transfer deadline set by XP per sale, that missing it can cancel the sale and forfeit payout, that only confirm=True returns success=true, and that auth plus write:listings scope is required. This is rich context the annotations cannot convey.

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

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

Front-loaded with the core action and the deadline constraint in caps, but slightly over-long and mildly repetitive -- the deadline is restated ('per sale, not a fixed window -- do not quote a countdown') and the casual-buyer exclusion overlaps with the usage guidance. Still, every clause largely 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?

With an output schema present, return values needn't be explained, yet the description still notes the accept result carries the real deadline or says when XP hasn't set it. Combined with the destructive/irreversible profile, auth scope, and alternatives, an agent has everything needed to call 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 coverage is 100%, so the baseline is 3. The description meaningfully augments the confirm parameter by explaining the preview-vs-commit workflow ('confirm=False first to preview which offer will be accepted; confirm=True only after explicit approval'), which adds workflow meaning beyond the schema's terse wording.

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+resource ('accepting sells to a buyer') and immediately clarifies the offer originates from a buyer on XP, not XP itself. It distinguishes itself from buy-side siblings (buy_tickets, buy_listing_now) and from reject_offer by framing the seller-side accept action explicitly.

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

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

Explicit when-to-use ('an authenticated seller wants to accept a specific bid on their listing'), when-not ('do not use for casual ticket buyers'), and names the alternatives (search_events, get_ticket_listings). It also prescribes the mandatory two-phase preview-then-confirm workflow with the exact confirm flag semantics.

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 mark this as read-only and non-destructive, but the description adds critical behavioral context: using it as a preflight swallows the 401 that would otherwise trigger OAuth. It also discloses the return shape at a high level (authenticated boolean, tier roles, wallet flag, never raw tokens), which is valuable for a zero-parameter auth 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 warning about not using this as a preflight is front-loaded and the remaining sentences each add necessary routing, behavioral, or return-value context. Nothing reads as filler, and the quoted examples make the usage condition concrete.

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 auth-status tool with rich annotations and an output schema, the description supplies exactly the missing operational context: when it is valid, when it is harmful, and what class of data it returns. An agent has enough information to invoke it correctly or avoid it appropriately.

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 there are no parameter semantics to explain; the baseline for a zero-parameter tool is 4. The description correctly does not waste space documenting nonexistent inputs.

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 makes the tool's purpose unmistakable: checking whether the user is signed in to the XP marketplace and returning auth state. It also distinguishes this diagnostic/status tool from protected sibling tools, so an agent can tell it apart without inferring from the name alone.

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

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

It gives explicit when-to-use conditions, quoted user intents, and a clear after-AUTH_REQUIRED re-check case. It also gives an equally explicit DO NOT preflight rule and explains the alternative: call the requested protected tool directly and let the client trigger OAuth on 401.

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?

Far exceeds the annotations: it discloses the two-phase confirm=false preview vs confirm=true purchase, that a confirm completes the sale immediately, debits the caller's XP USDC balance, and commits the seller, plus that auth is required. This meaningfully enriches the destructiveHint=true annotation with concrete consequences.

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

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

Front-loads the source ('connected resale + primary order book'), then usage, constraints, the two-phase mechanic, and payment/auth. Dense but every sentence earns its place with no filler.

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

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

Covers origin, eligibility (ask required), the preview/purchase flow, payment source, auth requirement, and sibling alternatives. With an output schema present, no return-value detail is needed; nothing an agent requires to call it safely 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?

Schema coverage is 100%, so the schema already documents confirm, rail, and identifier. The description still adds value by clarifying that an ask must exist to use this flow, that confirm acts 'at the ask as it stands at confirm time', and that the rail is USDC-only for fan listings.

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 (buy a fan listing at the seller's published asking price) and explicitly scopes it against siblings: negotiating (make_offer_on_listing) and the x402 rail used by buy_tickets. An agent can distinguish this from offer-based acquisition 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 an explicit when-to-use ('buyer wants a listing outright at the ask, rather than negotiating'), a when-not/alternative ('for one without an ask, use make_offer_on_listing'), and names the sibling buy_tickets for the other payment rail. Routing 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 only declare write/destructive/openWorld flags; the description adds substantial context beyond them — required scopes (write:tickets, plus read:account for the balance preflight), the two-phase preview/confirm contract, what the preview returns (payment_link, checkout_session_id), what confirm returns (stripe_payment_intent), and the explicit need for user approval. It is consistent with destructiveHint=true by gating execution behind explicit approval.

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

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

Front-loaded with the trigger and default rail, then progressively discloses the alternative rails, so the most important content comes first. It is dense and heavily parenthetical for a single paragraph, but the length is defensible given four payment rails and a multi-step confirm flow.

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 destructive, nine-parameter purchase tool with four payment modes, the description covers permissions, the preview/confirm state machine, per-rail return values, and client capability constraints. An output schema exists, so return-value detail is a bonus rather than a gap, and nothing needed to invoke it correctly 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?

Schema coverage is 100%, so the baseline is 3 and the schema already explains each parameter well. The description still adds meaning the schema lacks: rail-selection heuristics, the mpp credential fallback via params._meta when a client cannot send _meta, and the ordering relationship between the preview's checkout_session_id and the confirm call.

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 — buying tickets to an event on the XP marketplace connected order book — and frames it as a purchase flow, which is far more than a restatement of the name. However, it never distinguishes itself from the closely named sibling buy_listing_now, leaving the agent to infer that this tool operates on ticket groups (uvid) rather than listings.

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 when to use it ('when the user wants tickets to an event'), which rail to pick by default and when to switch ('use stripe_link unless the user asks for another'), and gives a per-rail condition for the non-default options including a caution that x402 should only be used by callers that can sign Solana payloads. The preview-then-confirm sequencing is spelled out as a procedure.

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 destructiveHint=true and readOnlyHint=false, but the description adds substantial context beyond them: open offers are rejected and buyers notified, the action cannot be undone, relisting requires create_listing, and it works only on the caller's own authenticated listing. This is rich behavioral disclosure well past the annotation floor.

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

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

Front-loaded with the primary use case and trigger phrases, then layers constraints and side effects in descending priority. Despite its length, nearly every clause (offer rejection, irreversibility, accepted-offer exclusion, auth scope) carries operational weight.

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 an output schema present, return values needn't be described, and the description fully covers prerequisites, side effects, irreversibility, and the preview pattern. For a destructive two-param tool this is 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 already 100%, so the schema documents both parameters; the description still reinforces the confirm=false/true preview-vs-commit semantics and advises saying so before committing, adding decision-context beyond the schema text.

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

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

Specific verb+resource: closes a seller's own listing so buyers cannot make an offer. It names the exact trigger phrases and clearly distinguishes this from sibling actions like cancel_my_offer by scoping to the caller's listing. An agent can identify the operation 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 explicit when-to-use (seller removing own listing), colloquial triggers, and a clear when-not: it cannot be used once an offer is accepted, since that is an agreed sale handled by support. The two-phase confirm flow is also spelled out as a usage pattern.

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 destructiveHint=true and readOnlyHint=false, and the description reinforces this by calling it a mutating 'write on the XP live offer book.' It adds substantial context the annotations cannot convey: the two-phase confirm workflow, that only confirm=True returns success=true, the auth and write:bids scope requirement, and the indirection where offer_uuid may be a swap id resolved server-side. Rich, non-redundant behavioral detail.

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?

Dense but front-loaded: purpose first, then the confirm workflow, then auth/scope, then exclusions. Nearly every sentence carries actionable information, though the run is long and could be trimmed slightly (e.g. the parenthetical examples and the swap-id resolution note are somewhat packed together).

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 three-parameter mutating tool with an output schema present (so return values needn't be described), the definition covers purpose, workflow, auth/scope, parameter provenance, and alternative tools. Nothing an agent needs to invoke it safely 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?

Schema coverage is 100%, so the baseline is 3; the description pushes above it by explaining the provenance and accepted forms of offer_uuid (bid_uuid from make_offer_on_listing, or the buyer swap id, resolved via privy-bids/mine) and the preview-vs-commit semantics of confirm. This adds meaning beyond the field descriptions, though it does not document identifier syntax further.

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 — rescinding a buyer's outstanding offer on the XP live offer book — and frames it as a two-phase write. It implicitly separates this from siblings like cancel_my_listing and rescind_standing_bid by naming the bid/offer resource and the make_offer_on_listing origin. An agent can identify the operation 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?

Explicit when-to-use with concrete user utterances ('pull my bid'), a required two-step workflow (confirm=False to preview, confirm=True only after approval), and explicit exclusions: 'Do not use for browse / discovery' and 'For standard buy-now ticket purchases... use search_events and get_ticket_listings.' Alternatives are named, so nothing is left to inference.

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?

Goes far beyond annotations: explains header-based auth (open-world, no bearer/OAuth), the failure taxonomy (never raises, never 401, three structured errors), pagination truncation at 50+ rows, and the semantic difference between `listing` snapshot vs. `actions` history. Notes the retired payout rail. Annotations only cover readOnly/openWorld/destructive, so this substantially enriches the picture.

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

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

Front-loaded purpose sentence is excellent, but the embedded JSON result schema is large and largely duplicates the actual output schema referenced in context signals. Header notation, ARGS, POLL LOOP, BUCKETS and EVENT VOCABULARY sections add operating value but make the description long 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?

Despite the output schema existing, the description adds the bucket semantics, event vocabulary, and cursor bookkeeping needed to drive a correct poll loop – none of which live in schema/annotations. An agent has everything required to invoke and interpret the tool correctly.

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

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

Schema coverage is 100%, so baseline 3 applies. The description adds meaning the schema lacks: what the cursor *is* (value from previous `cursor` field), the per-correlation-id storage discipline, and that negative values return invalid_since rather than being silently clamped.

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 (poll) and resource (status and action feed for the listing tied to this call's correlation id). The identity mechanism (correlation id via header, not an argument) immediately distinguishes it from all sibling read tools like get_event_details or search_market.

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 documents the poll loop, when to omit `since` (first call), how to page via `cursor`, and clarifies non-error cases (unrecognized correlation id is not an error). No sibling tool overlaps this function, so no alternative needs naming.

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?

Adds substantial behavior beyond the annotations: the two-phase confirm=false preview vs confirm=true create, the fact that a new listing is REVIEWED before going live, the listing_state values (live/in_review/not_accepted) with the critical warning that only 'live' means buyers see it, that tickets transfer only after an offer is accepted, and that auth is required. This is exactly the kind of context annotations cannot convey.

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

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

Front-loads the usage trigger, then layers the flow, state semantics, and the important 'live' caveat. Dense but every sentence carries actionable information with no filler.

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

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

For a mutation tool with an output schema already present, the description covers the safety profile (auth required), the two-phase confirmation, the review lifecycle, and the result's listing_state semantics. An agent has everything needed to call it and interpret the response 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 100%, so the schema already documents all 12 parameters (baseline 3). The description adds real value by explaining the confirm preview/create interplay and the seat-detail read-back purpose, clarifying how section/row/seat inputs are meant to be surfaced to the 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?

States a specific verb and resource (creates a ticket listing on the XP marketplace) and anchors it with user-utterance examples ('sell my two seats', 'list section 104 row C'). It clearly distinguishes itself from the offer-handling siblings by naming accept_offer and reject_offer as the downstream step.

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 clear trigger conditions ('use when the user wants to sell tickets they hold') plus concrete example phrasings, and explains the seller's position in the flow. It does not explicitly exclude near-neighbor siblings like list_my_listings or cancel_my_listing, but the sell-side context 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 only declare readOnlyHint=false, destructiveHint=true, openWorldHint=false; the description goes well beyond by disclosing the two-phase confirm preview flow, that fills take whole lots with no stranded remainder, that whole-dollar pricing is enforced, that auth is required, and that the offer rests on a live offer book that self-fills. This is exactly the extra behavioral context the annotations cannot convey.

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?

Purpose and the sibling contrast are front-loaded, and most sentences carry decision-relevant content. It is long and leans on parenthetical asides and meta-instructions ('that is the term to use when speaking to the user'), which slightly dilute density, but nothing is truly wasted.

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

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

With an output schema present, full schema description coverage, and annotations covering the safety profile, the description supplies everything else an agent needs: auth requirement, two-phase calling convention, pricing granularity, fill behavior, and alternative-tool routing.

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 is 3, but the description adds real meaning: the two-phase confirm=false/true lifecycle, the whole-dollar constraint rationale ('XP refuses cents so every fill passes per-ticket validation'), and the whole-lot fill semantics that qualify quantity. Some of this overlaps the schema ('Cents are not accepted'), keeping it below a 5.

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 ('Creates a STANDING OFFER'), defines the term explicitly, and distinguishes it from the closely related make_offer_on_listing and buy_listing_now by explaining the fill/wait mechanic. An agent can identify this tool without inspecting 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?

It gives concrete when-to-use triggers with example utterances ('offer 80 a seat for any of these nights'), names the alternatives (make_offer_on_listing, list_open_listings, get_market_read), and explicitly clarifies that both paths are valid to forestall misuse. Exclusions and pre-checks are all present.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the data source (XP marketplace catalog), the returned fields, and a caching instruction to avoid re-calling for the same event_id.

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 trigger and payoff, then the exclusion. Every clause carries either usage routing, return contents, or a caching constraint — 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?

An output schema exists, so the description needn't document return structure, and it nonetheless summarizes the card's contents. For a single-parameter read tool, routing, behavior, and caching guidance are all present.

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 lone `event_id` parameter is already fully documented in the schema, including its provenance from search_events. The description adds no syntax or format detail beyond what the schema provides, so the baseline of 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 — returning the 'full event card' with named contents (venue, performers, fee-inclusive price preview, images) — and explicitly contrasts itself with `get_ticket_listings`. An agent can distinguish it from the many sibling search/get tools without opening a 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?

It gives a concrete trigger ('event ID is in hand and the user wants the full event card before browsing tickets') and an explicit exclusion ('Do not use to list ticket inventory; `get_ticket_listings` is the right tool'). Both when-to-use and when-not-to-use are named with the alternative.

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 establish read-only/non-destructive safety, but the description adds meaningful behavior: fee-inclusive cheapest price per building area, price-ordered results, inclusion of fan listings open to offers, and a constraint against averages/medians/max asks. This goes beyond the annotations, though it omits pagination or result-size 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?

Front-loads the trigger and the key output trait (cheapest fee-inclusive price, price-ordered) before the presentation guidance. Sentences are purposeful and none is filler.

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

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

With an output schema present, return-shape details need not be in the description, and this read-only tool is adequately covered. Only minor gaps remain around pagination/cardinality of returned areas and listings.

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 event_id, quantity, and sections are already documented. The description only loosely alludes to these ("each area of the building", "fan listings") without adding syntax or format detail, so baseline 3 applies.

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

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

States a specific verb and resource (reads the market / trading price for an event) and clearly distinguishes its output from mere row browsing. It does not explicitly name the sibling it contrasts with (e.g., get_ticket_listings), so an agent can infer but not confirm the alternative without reading schemas.

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 trigger ("Use when the user wants to understand what an event is trading at, not just browse rows") that implicitly routes away from listing-browse tools. It lacks an explicit when-not or a named alternative tool, so the routing cue is good but not fully prescriptive.

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 only cover the safety profile (readOnly, non-destructive), but the description adds substantial behavior: bids are classified open/completed via the admin outcome engine, rejected/lapsed/refunded bids are hidden, pagination defaults and limits, and OAuth is required. That filtering and visibility detail is exactly what annotations cannot convey.

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

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

Front-loaded with the when-to-use trigger, followed by visibility rules and pagination facts. Dense but each clause carries operational information; only the pagination restatement is mildly redundant with the schema.

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 an output schema present, return values need not be re-explained, yet the description still clarifies that pagination.total counts only visible bids and how to phrase has_more results. Nothing needed to call this tool correctly 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?

Schema description coverage is 100%, so limit and offset are already documented in the schema; the description largely restates the 1-200 range, 25 default, and offset paging. It adds no new syntax or edge-case semantics beyond what the schema provides.

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 (see) and resource (bids placed by the authenticated user) with concrete example utterances ('show my bids', 'did any of my bids settle?'). It is clearly distinguishable from siblings like get_my_orders and list_my_standing_bids.

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

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

Provides clear triggering context via example phrasings and scopes it to the authenticated user's own bids. It does not explicitly contrast against near-neighbors such as get_my_orders or list_my_standing_bids, so an agent must infer the boundary.

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 declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is already covered. The description adds valuable context beyond annotations: it clarifies that nothing said in the current conversation is stored and that a new budget only persists as a resting commitment (referencing create_standing_bid). It also explains the intended use of notes ('shape what you say, never read them back verbatim'). This is rich for a read tool, though it could mention response format or caching.

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 front-loaded with the primary purpose and timing. It is a bit long (four sentences) and includes some verbose phrasing like 'e.g. re-asking a budget right before you help them make an offer on the XP marketplace,' but every sentence still earns its place by conveying a distinct usage rule or behavioral caveat.

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 read-only retrieval tool with one required parameter, full schema coverage, annotations covering safety, and an output schema (so return values need not be described), the description is complete. It covers timing, purpose, behavioral caveats, and cross-references the sibling tool create_standing_bid. Nothing critical is missing for 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% – the schema already fully documents event_ids ('Event IDs the user has settled on. Usually one.'). The description does not add any parameter syntax, format, or edge-case details beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

Clearly states what is retrieved (budget per ticket, quantity, date flexibility, notes) and its temporal position ('once the user has settled on an event, before quoting prices'). The phrase 'what they already told XP' is slightly colloquial but still defines the resource as stored user-provided context. It doesn't explicitly distinguish itself from get_user_account, but the scope is specific enough to be useful.

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 says when to use it ('once the user has settled on an event, before quoting prices') and why ('stops you asking twice'). It also gives a constraint ('use saved notes to shape what you say, never read them back verbatim'). However, it does not name alternative sibling tools for retrieving user data (e.g., get_user_account) or say when NOT to use it, so it falls short of a 5.

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 read-only, non-destructive, non-open-world, but the description adds substantial behavioral context the annotations cannot supply: the requires-auth and read:bids scope, the special sold/awaiting-transfer result shape with transfer instructions and remaining obligation, and the USDC 6-decimal raw-unit encoding for amount_raw plus human-readable amount_display.

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 primary purpose arrives second; the description opens with a narrow edge case (sold listing awaiting ticket transfer) that is not the main use case. The body is information-dense and useful but meanders between units, scopes, and routing before the core function is established.

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?

An output schema exists, so return values need not be restated, and the description still adds the one thing the schema can't convey (USDC raw-unit encoding and the sold-listing transfer case). Auth, scope, seller-side positioning, and alternatives are all covered for a one-parameter read 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% for the single identifier parameter, and it even points to list_open_listings/list_my_listings as its source. The description adds nothing extra about the parameter but does clarify the semantic result fields (actions mapping to accept_offer/reject_offer), slightly exceeding the baseline given full schema coverage.

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 — polling an authenticated seller's own listing to see open bids, state, and seats — and explicitly names it as 'the seller view of the live offer book.' An agent can distinguish it from sibling read tools like get_open_listing, check_listing, and search_market.

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

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

Gives an explicit when-to-use ('authenticated seller wants to poll their listing before deciding to accept or reject an offer'), a concrete example query, and explicit when-not ('Do not use for casual ticket buyers'), plus named alternatives (search_events, get_ticket_listings, accept_offer/reject_offer). Routing 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 cover the safety profile (readOnlyHint=true, destructiveHint=false), and the description adds real context on top: auth requirement, newest-first ordering, dollar-denominated money, and the fields surfaced. It does not discuss pagination behavior, though ordering 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?

Front-loaded with purpose and trigger phrases before the routing exclusions. The example queries add genuine matching value rather than filler, though the definition is on the longer side.

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 read-only list tool with a rich output schema and full annotation coverage, this covers everything an agent needs: what it returns, ordering, auth, and which siblings to prefer. Nothing material 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?

Schema description coverage is 100% (the single 'limit' param documents range 1-50 and default 20), so the schema carries the full burden. The description adds nothing about the limit parameter, which is the correct baseline of 3.

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 (Show) and resource (the authenticated user's own orders on the XP marketplace) plus the scope 'where each one stands'. It is clearly distinguishable from siblings like get_my_tickets and list_my_listings.

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 trigger phrases ('where is my order', 'did my tickets go through', 'what did I buy for Saturday', 'when do my tickets arrive') and three explicit when-not routes naming the correct alternatives (get_my_tickets, list_my_listings, get_my_bids).

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/destructiveHint/openWorldHint. The description adds meaningful context beyond them: it requires auth and the read:account scope, and it enumerates what the response contains (counts, spend, kickback in cents, per-referral rows). Slight redundancy on 'read-only' but the auth/scope disclosure is real value.

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

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

Front-loaded with the triggering condition, then returns, then behavioral constraints. Three tight clauses with no filler.

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

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

Purpose, trigger conditions, auth/scope requirements, and return shape are all covered, and an output schema plus rich annotations handle the rest. Nothing an agent needs to call it correctly 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?

All four date-window parameters are documented in the schema at 100% coverage, so the baseline of 3 applies. The description adds no extra meaning about the order_* vs referral_* semantic distinction beyond what the schema offers.

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 ('their XP marketplace referral kickback totals and rows') with concrete example queries, making it easy to distinguish from siblings like get_my_orders or get_my_wallet. The scope (XP marketplace referrals) is precise.

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 'Use when an authenticated user wants...' clause plus two example queries gives clear context for when to invoke it. It does not name explicit alternatives or exclusions, so a 4 rather than 5.

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 and destructiveHint=false, so the safety profile is covered. The description adds useful context beyond them: 'Requires auth' and the important scoping caveat that only delivered tickets surface while pending swaps live in list_my_listings. It does not describe rate limits or pagination behavior, so it falls short of a 5.

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

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

Front-loaded with the core purpose before the routing and exclusion details, and every sentence carries a distinct fact (scope, triggers, alternative, auth, exclusion). It is somewhat dense for a two-parameter list tool but not padded.

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?

An output schema exists, so return values need not be explained. Auth requirement, scope boundaries, the sibling alternative, and the exclusion are all present — nothing an agent needs to invoke this correctly 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?

Schema coverage is 100% and both parameters (limit, offset) are fully documented in the schema with defaults and ranges. The description adds no syntax or semantic detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource+scope: 'Show the authenticated user the tickets currently delivered to their XP marketplace account.' It explicitly distinguishes itself from list_my_listings (pending swaps/seller-side) and get_my_orders (past orders), so an agent can route correctly without opening a 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 concrete trigger phrases ('my tickets', 'pull up my seats for tonight'), names the sibling alternative for the adjacent case, and includes an explicit exclusion: 'Do not use to list past orders or browse the marketplace.' Both when-to-use and when-not-to-use are covered.

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/destructiveHint, but the description adds meaningful context: requires auth and read:account scope, and explicitly does not expose the raw bearer token. It also names the wallet_connected flag, which is behavioral detail beyond the 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?

Front-loads the 'Use when...' trigger, then the return contract, then auth/privacy notes. Dense but each clause earns its place; only mildly long.

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?

An output schema exists so return values need not be re-explained, yet the description still summarizes the key shape and covers auth scope and token-safety. Nothing needed to invoke it correctly 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 0 parameters, so the baseline is 4. There is nothing for the description to clarify, and it appropriately says nothing about inputs.

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 precise verb+resource (retrieve the authenticated user's Privy embedded-wallet address and USDC balance) and names the exact return fields. It is clearly distinguishable from siblings like get_user_account or get_my_context.

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

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

Gives concrete triggering user utterances ('what's my wallet for tickets to tonight?') and context ('Used to fund offers on the live offer book'). It does not explicitly name an alternative tool or say when NOT to use it, so it stops short of a 5.

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 cover the safety profile (readOnly, non-destructive, closed-world), and the description adds real context beyond them: it requires auth, requires read:bids scope, and notes the data is a live row from the connected resale + primary offer book. It does not discuss staleness or rate limits, but with an output schema present the return format is covered elsewhere.

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

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

Front-loads provenance and purpose, then usage and alternatives. Mostly every sentence earns its place; the 'casual ticket buyers' sentence is slightly verbose but serves a genuine routing purpose.

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?

An output schema exists, so return values need not be explained, and annotations carry the safety profile. Combined with auth/scope requirements, trigger conditions, and sibling routing, an agent has everything needed 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 description coverage is 100% and the single parameter is documented in the schema as a public listing identifier from list_open_listings. The description says 'identifier is in hand' but adds no format or validation detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource: retrieve the full record for one open listing, and clarifies the scope is a single row from the live offer book. It explicitly contrasts with list_open_listings (list) and get_ticket_listings (standard inventory), so an agent can separate it from siblings without opening a 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 the trigger condition ('a listing identifier is in hand', before making an offer), an explicit exclusion ('do not use for casual ticket buyers; seller-side and power-user surface'), and names the alternatives ('search_events', 'get_ticket_listings') for standard purchases. When/when-not/alternatives are all present.

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 cover the safety profile (readOnly, non-destructive, closed-world), so the bar is lower. The description adds genuine context beyond annotations: it requires auth, only the caller's own orders are visible (a real access constraint), and it enumerates what the response contains including currency units.

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

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

Front-loads purpose, then usage triggers, then return contents, then constraints and the alternative. Every sentence is functional with no filler, despite being fairly information-dense.

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?

An output schema exists so return-value documentation isn't required, yet the description still summarizes the returned fields usefully. Auth, visibility scope, and currency are all covered, leaving nothing an agent needs 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?

Schema description coverage is 100%, so the schema already documents the single required order_uuid. The description restates its provenance from buy_tickets and get_my_orders, which the schema description also provides, so it adds little beyond the 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 (Get), resource (status of an order), and scope (the authenticated user's own orders on the XP marketplace), keyed by order_uuid. It also distinguishes itself from the sibling get_my_orders, which handles the multi-order list case.

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 when-to-use triggers ('right after a purchase', user asking about a specific order) plus concrete example phrasings. It also names the alternative to reach for when no order_uuid is available ('use get_my_orders for the recent 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?

Annotations already declare read-only, non-destructive, open-world behavior, but the description adds meaningful context beyond them: the return shape (one point per day, oldest first, fee-inclusive dollars), the recording policy (only tracked events), and the important caveat that an empty history is a real, common answer rather than a flat line.

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 front-loaded with usage cues before explaining return semantics and caveats. Every sentence contributes either routing guidance, output meaning, or an important limitation, with no filler.

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

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

Given an existing output schema, the description need not detail return values, yet it still clarifies the output semantics and the empty-history edge case. Together with the rich annotations and full schema coverage, an agent has everything needed to call this tool correctly.

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

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

Schema description coverage is 100%, so both parameters (`event_id`, `days`) are already documented in the schema, including the default and range for `days`. The description adds no parameter-level syntax or format beyond what the schema provides, so the 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 states a specific verb and resource ('Returns the daily closing get-in price') and clearly scopes what the tool does over time. It explicitly distinguishes itself from the sibling `get_recent_sales` by contrasting asking-side history with actual sale prices.

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

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

It gives explicit trigger conditions: rising/falling prices, buy-now-vs-wait decisions, and recent event behavior. It also names the main alternative (`get_recent_sales`) and warns against conflating the two, which is exactly the routing guidance an agent needs.

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 this a safe, read-only, open-world read. Beyond that, the description discloses genuinely useful behavior: what an empty result means ("no verified transfers in the window") and an interpretive caution ("One sale is one sale -- do not generalise from a single clear"). It doesn't cover rate limits or fetch-window size, keeping it at a strong 4.

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

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

Front-loaded with the triggering condition, then the return shape, then edge-case semantics, then decision context. Each sentence mostly earns its place, though the closing "One sale is one sale" line is more flavor than specification and adds slight length.

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 an output schema present, return fields need not be re-explained, and annotations carry the safety profile, so the description's remaining job is purpose, usage, and edge-case semantics -- all of which it covers, including the important empty-result interpretation. Nothing an agent needs to call this correctly 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?

Schema description coverage is 100% and there is exactly one parameter (event_id), whose meaning and source are already fully documented in the schema. The description adds no parameter-level detail, which is the expected baseline 3 when the schema does the heavy lifting.

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

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

The description names a precise verb+resource: recent completed deals (actual sold prices) from the XP marketplace, with per-ticket price and recency. It implicitly distinguishes itself from listing-oriented siblings (check_listing, get_ticket_listings) by framing the result as what "actually sold for" and adds scope via "verified transfers in the window." An agent can tell this apart from get_price_history without opening either schema.

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

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

Multiple concrete when-to-use triggers are given: "Use when the user asks what tickets actually sold for," "before claiming nothing has traded," and "before deciding whether to make an offer or wait for a price drop." This is rich contextual guidance, but it never names a specific alternative tool (e.g. get_price_history) or states a when-not condition, so it falls short of the 5 bar.

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 cover readOnly/openWorld/non-destructive, and the description adds substantial context beyond them: the return type is an image, charts are not universal, the missing-chart fallback is spelled out, and no sign-in is required. It stops short of describing image format or any size/pagination characteristics, but the operational behavior is well covered.

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

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

Front-loaded with trigger phrases, then the layout-vs-photo clarification, then failure handling and auth. Every sentence carries information, though the anti-photo warning is emphasized twice ('must never be described as one'), which is slightly 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?

Simple one-parameter read tool with an output schema, and the description still covers the return artifact, the not-every-venue failure mode, the fallback tool, and the auth requirement. Nothing an agent needs to select or invoke it correctly 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?

Only one parameter, and schema description coverage is 100%, so the schema fully documents event_id and its provenance (search_market, search_events, get_event_details). The description adds no additional parameter meaning, which is the expected baseline here.

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

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

States a specific verb and resource ('Returns the venue seating chart as an image') and explicitly defines scope as the venue LAYOUT. It distinguishes this from the view-from-seat photo it must not be confused with, and from get_ticket_listings which supplies section/row text.

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?

Opens with concrete user utterances that trigger it ('where is 104', 'show me the map', 'is that behind the stage') and points to get_ticket_listings as the alternative when a chart is missing. Both the when-to-use and the when-not condition are explicit.

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 and destructiveHint=false, so the safety profile is covered. The description adds genuine value beyond that: it returns offers at any status including filled and rescinded, includes the fills taken, and requires auth. It doesn't add anything about pagination or result size, but the status-spanning behavior is a real disclosure.

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 trigger and example queries, then the differentiating capability and the auth requirement. No filler.

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

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

With an output schema covering return values, a one-param schema at full coverage, and read-only annotations, the description supplies everything else an agent needs: when to call it, what statuses it spans, and that auth is required.

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% for the single standing_bid_id parameter, and the schema itself documents where the id comes from (list_my_standing_bids or create_standing_bid). The description adds no syntax or format detail beyond that, so the baseline of 3 applies.

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

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

States a specific verb and resource ('get one specific standing offer') and explicitly scopes it relative to the sibling list tool, noting it covers filled and rescinded offers that list_my_standing_bids omits. An agent can pick this over the sibling without opening either schema.

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

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

Opens with an explicit trigger ('Use when the user asks about one specific standing offer') and gives concrete example questions ('did that offer get my tickets'), then names the alternative and the condition that selects this tool over 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true. The description adds genuine context beyond that: it pulls the LIVE offer book of resale plus primary inventory (freshness characteristic), prices are fee-inclusive, and prices are integer cents. Missing only things like result volatility or rate-limit behavior.

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

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

Three compact sentences, each earning its place: trigger, the pre-condition exclusion, and the price-unit note. The scoping constraint is front-loaded before the caveat.

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 an output schema present, return values need no explanation, and the description covers liveness, fee-inclusive pricing and required precedence. Minor gap: no guidance on how the overlapping tags/section_tags and sections/section_ids alias parameters differ, though the schema documents each individually.

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% across all 15 parameters, so the schema carries the burden and baseline 3 applies. The description only restates the price-unit convention already documented on min_price_cents/max_price_cents and does not clarify the ambiguous tag/section alias pairs.

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+resource (list ticket options for an XP event) plus the distinctive traits of the result: fee-inclusive prices and live resale+primary inventory. This distinguishes it clearly from siblings like check_listing, get_recent_sales, and get_seat_map.

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 names the trigger condition ('after search_events', user asking for cheap seats or parking) and gives an explicit exclusion: 'Do not use before an event has been resolved — call search_events or get_event_details first.' Both the when and the alternative are named.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so 'Read-only' partly repeats structured data. However, the description adds the auth requirement, which annotations do not convey, and clarifies the aggregate nature of the payload (account card combining profile, wallet, orders, referral stats).

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

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

Front-loaded with the resource and its payload, then usage examples, then the exclusion. The six quoted example phrasings are somewhat repetitive, but each maps to a distinct sub-query and remains short overall.

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 an output schema present, the description need not explain return structure, and it still notes the payload mirrors the account page. It covers scope, auth, and the sibling boundary — nothing an agent needs to call it 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?

The tool takes zero parameters, so the baseline of 4 applies — there is nothing for the description to disambiguate at the parameter level.

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

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

Specific verb (pull) plus resource (authenticated user's XP account card), and it enumerates the concrete contents — profile, wallet, email, name, order history, referral stats. It differentiates from the nearby get_my_orders and get_my_referral_kickbacks siblings by naming one alternative explicitly.

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

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

Gives both when-to-use (user asks 'my account', 'my orders', 'my referral link') and an explicit when-not-to-use with the alternative named: tickets delivered to the account should use get_my_tickets instead. An agent can route without inference.

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 cover the safety profile (readOnly, openWorld, non-destructive), and the description adds real value beyond them: it discloses that pricing is live from a connected order book and that the return includes an upcoming-events feed designed to tee up get_ticket_listings. It stops short of describing pagination, freshness windows, or coverage limits on the calendar.

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

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

Front-loaded with the core purpose before the usage examples, and every sentence earns its place by adding routing or payload information. Slightly long because of the repeated example phrasings, but not wasteful.

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 a full output schema present, the description needn't explain return values, yet it still summarizes the composite payload and the downstream call it enables. For a single-parameter read tool with rich annotations, nothing an agent needs to invoke it correctly 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?

Only one parameter and schema coverage is 100%, so the schema already documents venue_id and its origin in search_venues. The description adds no format, range, or sourcing detail beyond what the schema provides; baseline 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?

States a specific verb+resource (pull full venue info) and enumerates the composite payload: XP venue data, upcoming-events calendar, and live resale/primary pricing. It explicitly contrasts itself with get_ticket_listings, so an agent can distinguish it from siblings without opening schemas.

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 when-to-use (after search_venues, or when the user asks about upcoming shows) with concrete example phrasings, plus an explicit when-not-to-use routing to get_ticket_listings for seat-level data. Nothing is left to inference.

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?

Beyond the annotations (readOnly/destructive=false/closed-world), it discloses meaningful behavior: muting is per-user and never touches the listing itself, it hides the listing only on xp.tickets, and sibling read tools do NOT filter muted listings. It also notes auth is required.

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

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

Front-loads the trigger condition, then behavior, then the operational warning. Dense but every sentence carries new information; only minor trimming is possible.

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?

An output schema exists so return values need not be detailed, and the description still summarizes them. For a zero-arg, annotated, output-schema-backed tool, nothing an agent needs to invoke it correctly 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?

Zero parameters, so there is nothing for the description to clarify and the baseline is 4. The description correctly adds no filler about inputs.

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 ('Returns the listing identifiers this user has muted') and names the sibling tools it relates to (list_open_listings, get_market_read), so an agent can distinguish it from the many list_* siblings without opening a 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?

Explicit when-to-use: when the user asks what they have hidden/muted, and crucially before muting (to avoid duplicate-mute claims). It also warns to read this list before showing listings for offers, naming the exact alternative tools that fail to filter muted items.

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 and destructiveHint=false, and the description adds genuinely new behavioral context: the read:account scope requirement, default/limit pagination bounds, and the edge case that some accounts follow thousands of performers so pagination.has_more should be surfaced to users.

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

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

Front-loads the trigger condition, then auth/scope, then sibling pairing, then pagination behavior. Every sentence carries a distinct operational instruction with no filler.

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

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

Output schema is present so return values need no explanation, yet the description still references pagination.has_more to tell the agent how to interpret and phrase results. Nothing needed to call or report this tool correctly 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?

Schema coverage is 100%, so both limit and offset are already documented in the schema. The description restates the same 25/200/offset facts without adding syntax or constraint detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb and resource ('list the performers they've favorited') plus the marketplace scope, which cleanly separates it from siblings like list_my_listings, list_my_standing_bids, and search_performers.

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?

Opens with 'Use when an authenticated user wants...' and supplies concrete trigger utterances, the auth/read:account prerequisite, and an explicit pairing with search_events for the follow-on ticket lookup. An agent knows exactly when to pick this over search_performers.

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 cover the safety profile (readOnlyHint=true, destructiveHint=false), so the description adds the genuinely useful operational facts: auth plus read:bids scope, and that a page is per-category rather than the whole book. It stops short of describing pagination totals format or what determines ordering, but the additions are real and non-obvious.

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?

Content is dense and mostly earns its place, but the opening sentence leads with paging mechanics while the actual purpose ('list my listings bucketed by lifecycle') is buried mid-paragraph. Front-loading the what-it-does before the paging caveat would make selection faster.

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 an output schema present and annotations covering safety, the description only needs to add auth scope, paging semantics, and routing — and it does all three. Nothing an agent needs to invoke this correctly 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?

Schema coverage is 100%, so baseline is 3, but the description adds usage meaning: 'page on with offset or narrow with state_category' tells the agent how the two optional params interact with the paged-per-category model, which the schema alone does not convey.

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+resource ('list my listings') and the non-obvious scope: results bucketed by lifecycle category, seller-side, on the XP connected order book. An agent can distinguish this from get_my_tickets, get_my_listing_status and list_open_listings without opening a 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?

Explicitly names the caller condition ('authenticated seller wants to see their listings'), gives example utterances, states exclusions ('do not use for casual ticket buyers'), and routes elsewhere ('for standard ticket purchases, use search_events and get_ticket_listings'). Also tells the agent what to do when has_more is set.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds value beyond that: it discloses the auth requirement, that the result set is filtered to live offers, and where the excluded states (filled, rescinded) have gone — genuinely useful behavioral context for interpreting the output.

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 usage trigger, followed by the concept definition and the live-only scoping rule. No filler and no restatement of the tool name; each sentence carries a distinct fact.

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?

An output schema exists, so return-value explanation is unnecessary and the description rightly omits it. Combined with the auth note, the live-only scoping, and the sibling routing for excluded offers, an agent has everything needed to call this correctly on the first attempt.

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 zero parameters, the baseline is 4. There is nothing further to document, and the description correctly does not invent parameter guidance; it instead spends its words on scope and routing, which is the right allocation for a no-arg 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 states a specific resource (standing offers on the XP marketplace) and explains the concept in plain terms: 'A standing offer buys at the user's price whenever a matching fan listing appears.' It explicitly scopes the listing to live offers only and names the sibling that retrieves historical ones, so an agent can distinguish it from get_standing_bid and get_my_tickets without opening a 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?

It gives explicit triggers ('when the user asks what offers they have resting... or before they make an offer so you do not stack a duplicate') and names the alternatives for the non-live cases: filled offers are reachable via get_my_tickets and rescinded ones via get_standing_bid. When-to-use, when-not-to-use, and alternatives are all present.

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, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds non-schema context: it requires auth and a read:bids scope, which an agent needs before calling. It does not discuss pagination behavior, though the output schema covers return shape.

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

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

Front-loads the source and the core use case before the examples and exclusions. The example phrasing and the 'do not use' clause both carry routing value, though the sentence count is on the higher side for a list tool.

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

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

With annotations covering the safety profile, a 100%-covered schema, and an output schema for returns, the description fills the remaining gaps: auth/scope prerequisites and the buyer-vs-seller decision boundary. An agent has everything needed to select and invoke it.

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

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

Schema description coverage is 100%, so every filter, sort field, and the USDC raw-unit convention are already documented in the schema. The description only summarizes 'filterable by event, performer, and amount,' adding little beyond what the schema provides; baseline 3 applies.

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

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

States a specific verb and resource — browsing the live offer book of listings open on XP — and situates it in the resale + primary order book. This clearly separates it from the singular sibling get_open_listing and from the buyer-side search_events/get_ticket_listings.

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 gives trigger examples ('what's open near me this weekend'), names when NOT to use it (casual ticket buyers; this is the seller-side/power-user surface), and routes to two concrete alternatives with the condition that selects them.

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?

Goes well beyond the annotations: discloses the preview-then-confirm two-phase flow, that only confirm=True returns success=true, the required auth and write:bids scope, and that real money is at risk. The destructiveHint=true annotation is reinforced rather than merely repeated, giving the agent genuinely new behavioral context.

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?

Purpose is front-loaded, followed by sequencing, constraints, and alternatives in a tight logical order. Despite its length, every sentence carries operational weight (preview contract, auth scope, sibling routing).

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 an output schema, full schema descriptions, and annotations all present, the description still adds the safety-critical pieces an agent needs: the mandatory preview step, scope requirements, and the money-at-risk warning. Nothing material 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?

Schema coverage is 100%, so the baseline is 3, and the schema already documents each parameter thoroughly. The description adds cross-parameter semantics not in the schema: confirm=False previews a fee-inclusive total with no bid placed, and only confirm=True yields a successful submission.

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 ('make an offer on an open XP listing') and immediately distinguishes itself from buy-now and browse tooling. An agent can tell it apart from siblings like buy_listing_now, accept_offer, and create_standing_bid without opening a 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?

Explicit when-to-use ('when the user wants to make an offer on an open XP listing'), explicit when-not ('Do not use for browse / discovery'), and names concrete alternatives ('use search_events and get_ticket_listings' for buy-now). It also prescribes the required two-phase sequencing, leaving nothing to inference.

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?

Goes well beyond the annotations by disclosing idempotency ('sets the state you pass rather than toggling, so repeating a call is safe'), scope of effect (only this user's view, nothing changes for seller/other buyers), and the auth requirement. This is exactly the extra context annotations don't carry.

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

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

Front-loads the when-to-use triggers before the behavioral caveats, which is the right order. It is dense but each clause carries information; the enumeration of example phrases is a touch long for the marginal benefit.

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?

An output schema exists, so return values need not be described, and the description fully covers scope, safety, idempotency, and auth. Nothing an agent needs to call it correctly 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?

Schema coverage is 100% so the schema already documents both params; the description still adds value by explaining the state-set semantics of 'muted' and the unmute direction. Slightly above the baseline given the semantic clarification.

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+resource (mute/unmute a listing) and clearly bounds the effect to the user's own view of the live offer book. An agent can distinguish it from siblings like make_offer_on_listing or cancel_my_listing 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?

Provides explicit trigger phrases ('hide this one', 'stop showing me that', 'unmute that listing') and a scenario ('after deciding not to make an offer'). It also disambiguates the mute vs unmute direction, leaving little to inference.

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 flag destructiveHint=true and readOnlyHint=false, and the description builds on that with the crucial detail that only confirm=True submissions return success=true, plus the required auth and write:listings scope. This is exactly the behavioral context an agent needs before mutating 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?

Information is front-loaded and mostly tight, but the 'Do not use without the two-phase preview-then-confirm flow' sentence restates the earlier confirm=False/confirm=True instruction, adding mild 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?

With an output schema present, return values need not be explained. Auth scope, destructive nature, two-phase flow, alternatives, and audience restrictions are all covered, leaving nothing an agent needs 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?

Schema coverage is 100%, so parameters are already documented, giving a baseline of 3. The description adds real nuance by tying confirm to the two-phase preview/confirm semantics and clarifying that confirm=False is a non-mutating preview, which slightly exceeds the schema text.

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 (reject) and resource (a specific bid/offer on the seller's listing) on the XP live offer book, and clearly distinguishes itself from accept_offer and buyer-side tools. An agent can tell what this does 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?

Explicitly states when to use (authenticated seller rejecting a bid), when not to use (casual ticket buyers; the standard purchase path), and names alternatives (search_events, get_ticket_listings). The two-phase preview-then-confirm flow is spelled out as a hard requirement.

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 declare destructive=true/readOnly=false, and the description goes well beyond them: it states that existing fills are completed purchases and are not undone, discloses the two-phase confirm=false preview vs confirm=true commit behavior, and notes auth is required.

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

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

Front-loaded with the usage trigger, then effect, then irreversibility, then the phase model and auth requirement. Every sentence carries distinct operational information with no 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?

Coverage is complete for a two-param mutation: trigger, effect, reversibility limits, confirmation protocol, and auth need are all stated, and an output schema exists so return values need not be described.

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 parameters are already documented in the schema, including the confirm preview/commit semantics. The description largely restates the two-phase behavior rather than adding new parameter meaning, so baseline 3 applies.

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

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

Names a specific verb+resource ('rescind' a 'standing offer') and immediately bounds the effect ('closes it to new fills'). It also points to the alternative path when the user instead wants to bid on something open, which separates it from the make_offer/cancel_my_offer family.

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?

Explicit trigger conditions are given via user phrasings ('cancel that standing offer', 'stop waiting on those') plus the routing rule to an open-listing offer when that is the real intent. This is unambiguous when-to-use guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuine behavioral context beyond that: results merge resale and primary inventory into a single connected order-book feed, which tells the agent what the returned listings represent. It still omits ranking/pagination behavior and how the default limit of 100 is applied, keeping it short of a 5.

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

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

Three sentences, front-loaded with the usage trigger, then the differentiator, then the exclusion. Every clause carries routing information; none restates the title or annotations.

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?

An output schema exists, so return-value description is unnecessary. For a 7-parameter, one-required search tool, the description covers the selection conditions, the result-set composition, and the boundary cases that route an agent elsewhere. Nothing an agent needs to call it correctly 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?

Schema coverage is 100% and the schema itself is unusually informative (CBSA synonyms, date resolution against _meta.context.today, limit bounds), so the baseline would be 3. The description adds marginal value on top by enumerating what belongs in `query` (performer, team, venue, city, keyword) versus what belongs in structured filters, and by clarifying that multi-word natural-language phrases like 'shows near me this weekend' are valid input.

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 (find/search) and resource (live events) plus the domain (concerts, sports, theater) and the facets it accepts (performer, team, venue, city, keyword). The 'by X, Y, Z' enumeration and concrete example queries let an agent distinguish it from search_market, search_performers, or search_venues 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?

Explicitly frames the trigger as an agent-facing condition ('Use when the user wants to find live events...'), gives two realistic utterance examples, and names the exclusions and the fallback ('Do not use for scores, news, standings, or non-ticketed listings; use a web tool for those'). Both when-to-use and when-not-to-use are covered with the alternative named.

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

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

Annotations already cover the read-only, non-destructive, open-world profile, and the description goes further by explaining the dual-sided order book semantics, fee-inclusive pricing, and ask-side availability. It doesn't mention rate limits or result cap behavior, but the added output-context is valuable beyond the 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?

Front-loaded with the usage condition, then the return content, then the routing guidance and exclusion. Every sentence earns its place, though the third clause is fairly dense and slightly redundant with the opening 'might make an offer' phrasing.

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?

An output schema exists so return-value documentation isn't required, and the description still summarizes the payload well. Annotations cover safety, so nothing critical is missing for 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%, so each parameter (cbsa, genre, limit, query, min/max_date) is already documented in the schema. The description adds no per-parameter meaning beyond what the schema provides, so the baseline 3 applies.

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

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

The description states a specific action (searches XP events) and precisely what it returns (both sides of the connected order book, fee-inclusive get-in price, whether fans are selling with cheapest ask). It is immediately distinguishable from the sibling search_events tool.

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?

Explicit trigger ('when the user is shopping and might make an offer rather than pay asking price'), a named preferred alternative ('Prefer this over search_events whenever price matters'), concrete examples, and an explicit exclusion ('Do not use for scores, news, or standings').

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 (readOnlyHint, openWorldHint, non-destructive) cover the safety profile, so the bar is lower. The description adds value: it says it returns performer cards, not events, and that results come from the XP catalog, plus the pairing workflow with search_events. It doesn't mention result ordering, empty-result behavior, or pagination, but the output schema exists to cover return shape.

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

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

Front-loaded with the core purpose, then triggers, then return semantics, then sibling routing and exclusion. Every sentence earns its place, 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?

Covers purpose, triggers, return type, and sibling routing well. The output schema handles return structure. Slight gap: no mention of what happens with filters like sport/genre or no results, but nothing essential for correct invocation 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?

Schema description coverage is 100% with all six params documented, so baseline is 3. The description adds no parameter-level detail (e.g. what a good query string looks like, or how min_similarity interacts with results), so it neither compensates nor detracts from the schema.

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

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

States a specific verb+resource+scope: find a performer (artist/team/comedian) on the XP marketplace by name, and explicitly contrasts with search_events ('not events'). An agent can distinguish it from siblings 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?

Provides explicit trigger cases (user names a performer like 'Taylor Swift' or 'Lakers season opener'), names the alternative search_events with its qualifying condition, and states an exclusion ('Do not use for general events near me queries'). This is a complete when-to-use, when-not, and alternative mapping.

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 readOnly/openWorld/non-destructive, so the safety profile is covered. The description adds genuine behavioral context by clarifying the result domain ('venue records, not tickets') and the price-question exclusion. It does not discuss limit/pagination behavior, but that is minor given the limit parameter and output schema.

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 tightly written sentences, front-loaded with the usage trigger, then scope, then the exclusion. No filler; every clause carries routing or scope 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?

With an output schema, rich annotations, and 100% schema coverage, the description only needs to supply routing and scope — which it does fully. An agent has everything required to select and invoke this correctly.

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

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

Schema description coverage is 100%, so all five parameters are already documented, including the city/metro synonym notes. The description loosely echoes the searchable facets (name, city, area) but adds no syntax, format, or disambiguation beyond the schema. Baseline 3 applies.

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

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

States a specific verb+resource ('search venues') and immediately bounds the resource: venue records from the XP marketplace catalog, not tickets. This clearly separates it from siblings like search_events and get_venue_details.

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?

Explicit trigger conditions with concrete example phrasings ('venues near me', 'arenas in Brooklyn') plus a named exclusion and the alternative to use instead (get_ticket_listings). Both when-to-use and when-not-to-use are stated.

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