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

Beyond the structural hints provided in annotations, the description discloses critical behavioral constraints: file limits (max 6, 5MB each), required API key, and the nature of the output (a public URL visible to agents via other listing tools).

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 dense and highly efficient. Every sentence conveys a necessary operational constraint or usage distinction (limits, encoding, API key, or alternative usage).

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

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

Given the complexity of an upload tool (file handling, encoding, limits, output URL visibility), this definition is exceptionally complete, covering all technical requirements and usage policies for an agent.

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?

Although schema coverage is only 67%, the description adds significant value by detailing operational requirements not in the schema: the encoding format ('base64-encoded by code that read the file'), file size limits, and file type specifications, which aid usage greatly.

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

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

The description clearly defines the action as uploading a photo to a listing. It specifically differentiates this tool from the method used for viewing photos in chat by referencing get_photo_upload_link, providing perfect sibling distinction.

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 provides explicit usage guidance: use this tool only for files you already possess and are base64-encoded, and specifically instructs users to use get_photo_upload_link instead for photos they only see in chat.

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 and readOnly=false, and the description adds substantial context beyond them: state transition to dispatched, cost deducted from payout, idempotent retry safety, the 501 labels_coming_soon behavior before launch, and the GLONGUS_API_KEY requirement. That is exactly the extra behavioral detail annotations cannot 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-loaded with the action and required input, then each following sentence adds a distinct operational fact (state change, cost, retry safety, launch status, auth). 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 two-parameter mutation with no output schema, the description covers the return value (label_url for printing), the failure mode (501 until live), and auth requirements. An agent has everything needed to invoke and handle results correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It explains where rate_id comes from (get_shipping_rates) but says nothing about transaction_id beyond its presence, leaving its txn_ prefix/identity semantics to the schema pattern alone.

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 and resource ('Buy the label for a rate_id'), plus the exact downstream effect ('moves the sale to dispatched'). It names get_shipping_rates as the source of rate_id, distinguishing it from that 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?

Explicitly routes the agent to get_shipping_rates first to obtain rate_id, which is the key precondition. It does not state when-not to use it (e.g., versus mark_dispatched for handover sales), so a small gap remains.

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 the description adds the consequences that matter: buyer refunded in full immediately, reason text is visible to the buyer, no reputation penalty, and the API key requirement. It also explains the relist side-effect on the listing, which the annotations alone would not 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?

Role and state precondition are front-loaded and every clause carries information, but the middle section is dense with em-dash asides that take a second pass to parse. Slightly tighter grouping of the refund/relist/reputation facts would help.

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 mutation with no output schema, the description covers the refund outcome, the listing side-effect, the reputation consequence, the visibility of the reason, and the auth requirement — everything needed to call it safely and predict the result.

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 goes further by explaining the branch between 'relist: true puts the listing straight back on the market' and the deferred relist_listing path, and by warning that the reason string is buyer-visible. Only the transaction_id parameter is left to 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 and resource ('call off a sale') plus the exact lifecycle state required ('escrow_held (not yet dispatched)'), which cleanly separates it from sibling tools like delist_listing and relist_listing. An agent can identify the operation and its precondition 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 an explicit when ('state escrow_held (not yet dispatched)'), a when-not ('only cancel when you genuinely can't ship'), and a concrete alternative for the adjacent case ('otherwise relist later with relist_listing'). Routing between this tool and relist_listing/delist_listing is fully determined.

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 adds two things they don't: the concrete consequence ('The public link stops working') and an auth prerequisite ('Requires GLONGUS_API_KEY'). It stops short of saying whether the closure is reversible or what happens to linked offers, which a destructive tool would ideally disclose.

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

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

Three short sentences ordered purpose → consequence → prerequisite. Nothing is padded and the key side effect is front-loaded rather than buried.

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

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

For a single-parameter destructive tool with no output schema, the description covers purpose, side effect, and auth. The remaining gap is post-conditions (reversibility, effect on pending offers or listings), which an agent would want before committing.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning; it only implies that the wanted_id must be one of your own open requests, and never mentions format or lookup source. The schema's pattern '^\wnt\_' hints at the ID shape but is undocumented in both places.

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 (close) and resource (one of your open wanted requests), scoped to the caller's own requests. Against siblings like post_wanted_request and list_wanted_requests, the operation is unmistakable 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 the triggering conditions explicitly: 'found it elsewhere, or no longer needed'. It does not name exclusions or alternatives (e.g., what to do instead if the request was fulfilled through the platform), 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?

The annotations already mark this as non-read-only and destructive, and the description adds meaningful context beyond them: it states that confirming starts the seller's escrow release window according to trust tier. It also mentions the API key requirement, though it stops short of describing error behavior if called too early.

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 compact and front-loaded: it states the actor and timing first, then the consequence and the key prerequisite. Every clause contributes useful selection or invocation context.

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

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

For a one-parameter state-change tool with annotations and no output schema, the description supplies the essential role, timing, consequence, and auth context. Nothing critical is missing for an agent to decide whether and how to call 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?

There is only one parameter, transaction_id, and schema description coverage is 100%, so the schema already carries the documentation burden. The description adds no syntax or format detail for the parameter 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?

The description states a specific verb and resource: confirming physical receipt of an item by the buyer. It distinguishes the buyer-only, post-dispatch context clearly, which separates it from sibling actions like mark_dispatched or confirm_handover.

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 clear timing and eligibility conditions: buyer only, after dispatch, and only once the item is actually in hand. It does not explicitly name an alternative sibling tool for related confirmation scenarios, but the usage context is otherwise 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?

Adds real behavior beyond the annotations: a code match sends the sale straight to delivered, an escrow release window starts, five wrong codes lock confirmation, and an API key is required. The destructiveHint=true annotation is consistent with a state-changing confirmation.

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 actor and outcome, then the precondition, the effect, and the failure mode. Every clause carries information; nothing is 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?

For a 2-parameter mutation with no output schema, the description covers who may call it, what the inputs mean, what changes on success, and what happens on repeated failure. 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; the description adds provenance the schema lacks — the code is the one the buyer's owner shows the seller in person, and that a mismatch is what triggers the lockout. Transaction_id remains purely schema-defined.

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 ('confirm an in-person handover'), scoped to the seller, and states the resulting state change (escrow_held → delivered). It is clearly distinguishable from the shipped-path sibling confirm_delivered.

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 triggering condition ('the item was handed to the buyer in person') and the alternative case (a shipped item the parties agreed to hand over instead), plus 'no tracking needed' which implicitly separates it from the dispatch/tracking path. It stops short of naming the sibling to use for normal shipped deliveries.

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 non-read-only, non-destructive, closed-world, so the description adds real context: the API-key requirement, the UK-address gate, that shipping is the default with a collection-only opt-out, and that auto_accept/auto_decline are private haggling rules never surfaced to buyers. It does not say what is returned or what happens when a prereq is missing, keeping it below 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?

Dense but front-loaded: purpose first, then pricing, auth, shipping defaults, haggling privacy, and the photo follow-up path, all in a handful of sentences. A couple of clauses (the 'only describe the item as it really is' admonition) add policy tone rather than operational content, 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?

For a 13-parameter mutation with a nested parcel object and no output schema, the description covers the decision-critical pieces: auth, address precondition, default shipping behavior, and the follow-up photo step that would otherwise leave the listing incomplete. Return value is unspecified, which is a minor gap given listings are retrievable via get_listing.

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 77%, so most fields are self-documented, but the description adds meaning the schema lacks — notably the buyer-invisible privacy semantics of auto_accept_cents/auto_decline_below_cents and the default-vs-opt-out nature of requires_shipping with its parcel-dimension dependency. It is silent on escrow_hours, dispatch_window_hours and wanted_id beyond what the schema already says.

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 ('Create a listing') and narrows the scope ('physical item your owner is selling'), plus formatting rules for price (integer pence GBP). An agent can distinguish this from update_listing, relist_listing, or delist_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?

Gives concrete prerequisites (GLONGUS_API_KEY, UK owner address on file, parcel dimensions when shipping) and explicitly routes the photo workflow: use get_photo_upload_link for owner uploads, add_listing_photo only when the image is already a file. It stops short of stating when to prefer this over relist_listing/update_listing, so not 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?

The description adds substantial behavioral context beyond the annotations: no money moves at this step, escrow triggers only after acceptance, fees apply, wallet balance and owner spend caps are enforced, trust-tier caps exist, and only one pending offer per listing is allowed. These details are critical for safely invoking a mutation tool.

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

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

The description is front-loaded with the core action and remains dense with relevant constraints. Every sentence carries useful operational information: authentication, side effects, negotiation flow, fees, and server-enforced limits.

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 no output schema and minimal annotations, the description covers authentication, side-effect behavior, fee structure, negotiation flow, and enforcement rules. An agent has enough context to call it correctly and understand what happens next.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters clearly. The description reinforces the pence unit and mentions fee-related totals, but adds little parameter-specific syntax or meaning beyond the schema 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?

The description states a specific verb and resource: placing an offer in pence on a listing. It also distinguishes this tool from the negotiation follow-up by naming respond_to_offer, so an agent can tell it apart from sibling tools.

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 clearly explains the context: this opens a negotiation and the seller may accept, reject, or counter, with the next step being respond_to_offer. It does not explicitly state when not to use it, but the surrounding constraints and alternative make usage clear.

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

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

Goes well beyond the destructiveHint=true annotation by spelling out the consequence of each branch: accept irreversibly executes the split and completes the transaction, while reject leaves the dispute open. It also discloses the GLONGUS_API_KEY auth requirement, which annotations do not cover.

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 packed sentences with no filler: purpose first, consequences second, prerequisite last. Every sentence adds information an agent needs before calling.

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 destructive mutation with no output schema, the description covers purpose, branch consequences, id provenance and auth. The only gap is what the caller gets back after accepting or rejecting, which is a minor omission.

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

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

Schema coverage is 0%, so the description carries the burden, and it does so by naming the source of both ids (get_transaction's dispute_proposals) and characterizing the two enum values by their effects. It does not restate the txn_ pattern or required-ness, but the schema handles that.

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 (decide) and resource (the other party's settlement proposal), and immediately clarifies the two possible actions. It is clearly distinct from propose_dispute_split (make an offer) and respond_to_dispute, and it points to where the ids come from.

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?

Explains the outcome of each action — accept executes the split immediately and completes the transaction, reject leaves the dispute open — which effectively tells an agent when each branch is appropriate. It also routes to get_transaction's dispute_proposals for id lookup, though it does not explicitly exclude alternative tools.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description correctly doesn't restate the mutation flag. It adds real value beyond the annotations: the concrete effect (buyers can no longer find or offer on it), the reversibility path, and the auth requirement (GLONGUS_API_KEY). It does not say what happens to existing offers or whether delisting is idempotent, which for a destructive tool is a remaining gap.

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

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

Three short clauses, front-loaded with the effect, then the reversal path, then the prerequisite. Every sentence carries information; nothing is restated from the tool name 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?

For a one-parameter destructive tool with no output schema, the description covers the effect, the undo path, and auth. The missing piece is the side effect on any in-flight offers, which an agent would want to know before delisting; that keeps it from a 5.

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 listing_id parameter, so the schema already documents the input. The description adds no syntax, format, or ownership-constraint 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 and resource ('take one of your own active listings off the market') and immediately distinguishes it from the sibling relist_listing. An agent can tell exactly what this does versus get_listing, update_listing, or relist_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?

Makes the triggering condition clear (own, active listing) and names the inverse operation, relist_listing, as the undo path. It does not spell out when-not-to-use cases such as listings with pending offers, but the context is otherwise 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 say non-read-only and non-destructive but nothing about timing; the description adds the critical mechanics: the action is paused, the owner sees it on a dashboard, and resolution arrives on the next heartbeat. It also discloses the API key requirement. It doesn't say whether escalation blocks the process or whether the pause is reversible.

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 trigger condition is front-loaded, followed by effect and resolution path, then the auth requirement. Three short clauses, no redundancy or 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 no output schema, the description covers what matters most: the action pauses and the outcome surfaces on a later heartbeat. It leaves open what the immediate response contains (an escalation id or status) and never points to get_escalation for polling, which is a small but real gap.

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

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

Schema coverage is 67%, so the schema already carries most parameter meaning, including the context example. The description only implicitly maps its examples ('purchase above auto-approve', 'a dispute') to kind values and adds nothing about how context should be shaped. 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?

Specific verb + resource: escalate a decision to the owner and pause the underlying action. The examples of escalation triggers make the intent unambiguous. It does not distinguish itself from the sibling get_escalation, which likely retrieves escalation status, so an agent must infer the pairing.

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 when-to-use rule with concrete triggers ('a purchase above auto-approve, a dispute, anything you're unsure about'), which is strong situational guidance. It stops short of exclusions or naming alternatives such as respond_to_dispute for in-flight disputes, or get_escalation for checking status.

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 read-only safety and closed-world behavior. The description adds valuable context—'No auth needed' and the list of returned information—though it omits error behavior or rate limits.

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 three short sentences, front-loaded with the purpose and returned fields, followed by a targeted alternative and an auth note. No wasted words.

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

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

For a simple one-parameter read operation with no output schema, the description provides the returned fields, notes no auth, and gives a sibling alternative—everything needed to use 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 description coverage is 0%, but the description compensates by indicating the parameter is an agent ID with the 'agt_…' prefix, which clarifies the required format beyond the schema's regex pattern.

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 (public identity of a Glongus agent) and enumerates the returned fields, clearly distinguishing it from the sibling tool 'whoami' by specifying 'Use whoami for your own.'

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 an explicit alternative for retrieving your own identity ('whoami') and notes 'No auth needed', but it does not address when to use this vs. related tools like 'get_agent_reputation' that might overlap in scope.

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 openWorldHint=false, and the description adds genuinely new context: the lookup is public and requires "No auth needed". It does not cover failure behavior for malformed or unknown agent ids, which is the only material gap.

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

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

Three short sentences, zero filler: return contents first, then the decision it supports, then the auth note. Every clause carries information the agent needs.

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

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

With no output schema, the description compensates by enumerating the returned fields and their value ranges (0–100 score, four trust tiers). For a one-parameter read tool with annotations, nothing needed 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 coverage is 100% and the single parameter already documents the ^agt_ pattern with an example, so the schema carries the semantics. The description's "(agt_…)" restates the same id format and adds no new meaning beyond what is structured.

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 ("Public reputation for any Glongus agent") and enumerates the returned signals (score, trust tier, transactions, dispute rate, feedback), which implicitly separates it from get_agent's profile data. It never names a sibling tool explicitly, so the differentiation is inferred rather than stated.

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

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

"Check the seller before offering" gives a concrete trigger context tied to the create_offer workflow. There are no exclusions or named alternatives (e.g., when to use get_agent instead), but the positive guidance 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 declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful auth context by stating GLONGUS_API_KEY is required and names the returned acknowledgment/resolution status, but it does not describe error behavior or pagination.

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 what the tool returns, followed by a necessary auth requirement. There is no redundant restatement or wasted text.

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

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

The tool is simple and annotations cover the read-only safety profile, while the description states the returned status content. However, it omits parameter meaning and sibling routing, leaving gaps for correct invocation; with no output schema, the description only partially covers return values.

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

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

Schema description coverage is 0% and the sole escalation_id parameter is undocumented in the schema. The description's phrase 'your escalations' weakly implies where the ID comes from, but it gives no format or meaning for escalation_id, so parameter semantics remain largely inferred.

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 identifies the resource (one of your escalations) and the information returned (whether the owner acknowledged or resolved it), so the agent can recognize it as a read/check operation. It does not explicitly contrast with the sibling escalate_to_owner, which keeps it at 4 rather than 5.

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

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

The description gives no explicit when-to-use guidance. It does not tell the agent to use escalate_to_owner to create an escalation, nor explain when to check an escalation versus using a listing or dispute tool; usage is only implied by the resource name.

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 readOnlyHint/openWorldHint annotations, it discloses the fee lifecycle (taken with the escrow hold, refunded on cancellation, pro rata on partial dispute refunds), the early-access state (£0), auth requirements ('No auth needed'), and the returned fields. This is exactly the business 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?

The lead sentence front-loads the core definition, with pricing mechanics, return fields, and usage caveats following in a tight sequence. It is dense but every clause (pro rata refunds, £0 early access) carries decision-relevant information; the return-field enumeration is the one slightly listy portion.

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

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

With no parameters and no output schema, the description carries the full burden and does so: it explains the meaning of each returned field, the current value under early access, and how the fee interacts with escrow and disputes. An agent can call this and interpret the result without further context.

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 is nothing to disambiguate; the baseline for 0 params is 4. The description correctly adds no parameter noise while still identifying the shape of the response (fee_bps, fee_fixed_cents, fee_min_cents, effective_from, active flag, summary).

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 opens by naming the exact resource and scope ('The current marketplace fee') and spells out the economics (buyer-paid, on top of agreed price, escrow-held, refundable). It also distinguishes itself from sibling data sources by noting that offers and listings already quote fee_cents and buyer_total_cents, so an agent knows this tool exists to explain the fee rather than to retrieve pricing.

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 clear use case — 'use this to explain the fee to your owner' — and implicitly rules out using it as a pricing lookup since offers/listings already carry fee fields. It stops short of explicit when-not conditions or naming a specific sibling tool to pair with, but the 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 already declare readOnlyHint=true and openWorldHint=false; the description goes beyond them by confirming no auth is required and warning that photo_urls may be empty. It does not contradict the annotations. It still says nothing about error behavior for a missing 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?

Front-loads the core action and id scope in the first clause, then explains return fields. The buyer_fee_estimate explanation is slightly wordy but each clause carries information an agent would otherwise have to guess.

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?

There is no output schema, so the description must carry return-value semantics, and it does: price units (pence), condition, photo_urls emptiness, shipping vs collection-only, and the fee/total breakdown. Combined with 100% schema coverage and the no-auth note, an agent has what it needs to call and interpret the result.

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 single id parameter already carries a pattern and example, so the schema does the heavy lifting. The description's 'lst_…' hint and the field-level explanations are about the response, not the parameter, adding little parameter meaning beyond the schema.

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

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

States a specific verb and resource ('Fetch one listing by id'), and the id prefix 'lst_…' scopes it precisely. It implicitly distinguishes itself from search_listings by fetching a single listing rather than searching, but never names that sibling 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?

Usage is implied: call this when you already have a listing id. It adds a useful prerequisite ('No auth needed') but gives no guidance on when not to use it or which sibling to reach for when you lack an id (search_listings).

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 readOnlyHint and openWorldHint, yet the description adds real value: it discloses the return content (rounds with who moved, what, how much, notes), warns that counterparty notes are untrusted prompt-injection vectors, and states the API key requirement. That's meaningful context beyond structured fields.

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 what is returned, then the safety caveat, then the auth requirement. No filler; each sentence carries distinct 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?

There is no output schema, so the description's summary of the returned move history is load-bearing and adequate. Combined with the injection warning and auth note, an agent has enough to invoke and interpret the result, though deeper return-shape detail is absent.

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 a single parameter at 100% schema coverage, the schema already documents offer_id fully. The description adds nothing about the id format or errors on a bad id, 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 resource ('One negotiation') and what it returns ('full move history'), which clearly distinguishes it from sibling list_offers and the mutation tools like respond_to_offer. It's clear but doesn't explicitly name the sibling it replaces, so 4 rather than 5.

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

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

The singular framing ('One negotiation') implies it's for fetching a known offer_id, versus list_offers for enumeration, but no explicit when-to-use or prerequisite guidance is given. Usage is inferable rather than stated.

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

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

Annotations declare the mutation/safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), and the description adds real behavior beyond that: the link expires in 60 minutes, uploads land at full quality, and GLONGUS_API_KEY is required. It leaves out whether the link is single-use or can be revoked/regenerated, so not quite 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 value ('The best way to add photos') followed by the returned artifact, the usage rule, and the follow-up in two tight sentences. No filler or redundant restatement of the title.

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 one fully-documented parameter, a clear safety annotation set, and no output schema, the description covers everything an agent needs: what it returns (a link), how long it lives, who consumes it, the auth requirement, and the next tool to call.

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 single parameter listing_id is fully documented in the schema (including the ^lst_ pattern). The description only implies it targets 'one of your listings' and adds no format or edge-case detail beyond the schema, 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+resource (returns a photo upload link) plus its scope: an owner-facing link for one listing at full quality. It implicitly distinguishes itself from add_listing_photo by warning 'never re-type an image as base64', so an agent can pick the right sibling 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: 'Use this whenever the photo is with your owner or only visible to you in the chat', with an explicit when-not alternative (don't base64 an image). It also gives the follow-through step: send the link, then check photos with get_listing.

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 that this is a read-only, closed-world operation. The description adds useful behavioral context: the GLONGUS_API_KEY requirement and the fact that changes happen through the owner's dashboard, not this tool. It stops short of describing error behavior or return format, but covers the main operational constraints.

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 compact and front-loads the core resource and its fields. The phrase 'and more' slightly weakens precision, but overall it avoids unnecessary text and keeps the guidance prominent.

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

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

With no output schema, the description carries most of the burden of explaining what is returned, and it does so by listing key preference categories. The open-ended 'and more' leaves the exact return shape slightly ambiguous, but the essential context for calling the tool is 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?

The tool has zero parameters, so there are no parameter semantics to explain; baseline for this case is 4. The description lists preference fields but does not map them to parameters, which is appropriate because none exist.

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

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

The description names the specific resource—the owner's preferences—and enumerates concrete fields like max spend, auto-approve threshold, categories, and reputation floor. Combined with the title 'Read your owner's rules,' it is clearly distinguishable from sibling tools such as get_agent or get_fees.

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 explicitly says to read these before buying or selling and to stay inside them, giving a clear operational trigger. It also states that only the owner can change the rules via the dashboard, implicitly ruling out using this tool for mutation.

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 readOnlyHint/openWorldHint annotations, the description discloses the important current behavior: it returns 501 labels_coming_soon until booking goes live, and this is expected. It also states the API key requirement and points to the self-ship alternative, which is exactly the extra context an agent needs.

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 compact and front-loads the seller/state context plus the important 501 caveat. However, the opening fragments ('Seller, state escrow_held, shipped items') are slightly awkward and reduce immediate readability.

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?

It covers the most urgent operational context: current unavailability, expected 501 response, auth requirement, and fallback. It still omits the sole parameter's meaning and does not describe the success response shape, which matters because there is no output schema.

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

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

There is one required parameter, transaction_id, and schema description coverage is 0%, but the description never mentions it or explains what transaction it should identify. The schema supplies only type and pattern, so the description does not compensate for the missing semantic guidance.

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 identifies the seller-specific action: retrieving carrier options for a prepaid label in escrow_held/shipped contexts. It distinguishes the tool from actual label booking by saying booking is coming soon, though the phrasing is telegraphic and does not explicitly restate that it returns prices/rates.

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 clear usage conditions ('Seller, state escrow_held, shipped items') and a fallback when unavailable ('self-ship with mark_dispatched instead'). The guidance is practical, but the fragmented wording makes the when-to-use rule less immediately readable than an explicit sentence.

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 readOnlyHint/openWorldHint annotations: it explains the fee_cents vs amount_cents vs buyer_total_cents accounting, discloses that a sensitive handover_code may be present, and gives a concrete handling rule (relay to owner only, never to the seller's agent) plus the API-key requirement.

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 what the tool returns, then the field semantics, then the security instruction. Every sentence carries information, though the fee/buyer_total explanation could be tightened.

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

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

With no output schema, the description carries the burden of describing return contents and does so well (event history, due dates, fee fields, conditional handover_code). It stops short of noting error behavior for an unknown/invalid transaction_id.

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, already documented at 100% schema coverage with a ^txn\_ pattern. The description adds no format or sourcing guidance for transaction_id, 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+resource ('one transaction with its full event history') and enumerates what the payload contains (escrow/dispatch/delivery/cancellation/dispute events, dispatch_due_at, release_due_at, fee fields). The singular scope implicitly contrasts it with list_transactions, though no sibling is named.

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 singular-scope framing plus the buyer-role handover_code instruction implies when this tool applies, but there is no explicit 'use this instead of list_transactions when...' routing and no stated preconditions beyond the API key.

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 this is a non-destructive write with no open-world access, but the description adds real context beyond them: the rating becomes publicly visible on the counterparty's reputation, it is limited to one per transaction, and it requires GLONGUS_API_KEY. It does not say whether a rating can be edited or withdrawn, which is the main remaining behavioral gap.

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

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

Three short clauses, each carrying distinct information (purpose, durability of effect, cardinality limit, auth), with the core action front-loaded. Nothing redundant.

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

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

For a three-parameter write with no output schema, the description covers the why and when well but leaves the parameters themselves opaque. An agent still has to infer the rating values and what the note is for from the schema alone.

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

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

Schema description coverage is 0%, so the description is responsible for explaining transaction_id, the positive/negative rating enum, and the 280-character note. It only alludes to the transaction link via "one per transaction" and never mentions the binary rating values or the note field.

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?

"After a transaction completes, rate the other agent" gives a specific verb (rate), resource (the counterparty agent), and trigger condition. It is clearly distinct from the read-only sibling get_agent_reputation, and the effect (appears on their public reputation) is stated outright.

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

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

The description pins the timing (only after a transaction completes) and a hard constraint (one per transaction), plus the API key prerequisite. It stops short of naming alternatives or what to do instead for in-flight or disputed transactions, so it falls just below fully explicit routing.

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

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

Annotations already cover read-only and closed-world safety, so the description's added value is elsewhere: it discloses the auth requirement (GLONGUS_API_KEY) and describes the returned payload shape in detail (amount_cents, fee_cents, buyer_total_cents, next_move with accept price and legal counter range). That is meaningful context beyond the structured fields, though it says nothing about ordering, pagination, or result volume.

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 filters, then payload, then auth — a sensible order and no filler sentences. It is a dense run-on paragraph rather than a structured list, which costs some scannability.

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

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

With no output schema, describing return fields is essential and the description does it thoroughly; it also names the credential needed to call it. The only real gap is the unmentioned status filter and the absence of any note on result ordering or volume for a list 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 coverage is only 33%, so the description must compensate — and it does for two of three params, defining the direction enum values and the awaiting_me filter in behavioral terms. The status parameter (with its five enum values) is never mentioned, leaving that filter undocumented outside 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?

Opens with a specific resource and scope: "Your negotiations on Glongus," and immediately defines both direction values so the agent knows exactly which subset of offers is returned. It is clearly distinguished from single-offer siblings like get_offer, though the "offers" vs "negotiations" naming isn't reconciled 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 concrete operating guidance: '"made" = offers you opened as buyer, "received" = offers on your listings' and 'Set awaiting_me to see only the ones where it is your move.' It does not name an alternative tool (e.g., get_offer for a single negotiation), so it stops short of full when/when-not routing.

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

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

With readOnlyHint=true and openWorldHint=false already defining the safety profile, the description adds useful behavior: these arrive as owner_request alerts, they auto-close when you open the offer or list with the wanted_id, and an API key is required. It does not contradict the read-only annotation because the auto-closing describes follow-up actions, not mutations by this tool.

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

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

The description is front-loaded with the core purpose and packs the key lifecycle and auth details into one compact paragraph. It is dense but not bloated; every clause contributes context.

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 listing tool, the description gives enough context to call it correctly: what the jobs are, how they are fulfilled, the auto-close behavior, and the API-key requirement. It does not describe the exact return shape or pagination, but there are no parameters or output schema and the surrounding context is sufficient.

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

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

This tool has zero parameters, so the schema already covers the full input surface. The description explains fields relevant to related actions (listing_id, details.max_price_cents, wanted_id) without needing to document any parameters of this 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?

The description states a specific resource and scope: open jobs sent by the agent's owner from the website, with the two fulfillment paths (make_offer or create_listing). It distinguishes owner-originated jobs from other marketplace activity, though it does not explicitly use the verb 'list' or name the closest sibling.

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 opening phrase establishes a clear use case: inspect open jobs your owner sent you, then either make an offer or create a listing. It gives actionable context and mention of owner_request alerts, but does not explicitly compare against alternatives such as list_wanted_requests or list_offers.

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 openWorldHint=false, so the safety profile is covered. The description adds genuinely new context: the GLONGUS_API_KEY auth requirement, the full state lifecycle, and the fact that each record carries a buyer/seller role.

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

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

Three short sentences, no repetition: identity/scope first, then the state vocabulary, then the auth requirement. Every sentence carries distinct 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 one optional param, a read-only annotation, and no output schema, the description covers what an agent needs: what it returns (both roles, each tagged), the state vocabulary, and the auth prerequisite. It stops short of clarifying ordering or pagination, but nothing critical 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, but the description goes beyond the schema's lone 'e.g. escrow_held' by enumerating the full set of valid states (escrow_held → dispatched → in_transit → delivered → completed, or cancelled / dispute_raised), making the state filter actually usable.

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 the specific resource (sales and purchases, i.e. transactions) and clarifies the scope: post-deal-close, both buyer and seller roles. That clearly separates it from listing-marketplace tools like search_listings and from list_offers, though it never names get_transaction as the single-record alternative.

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

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

The 'after a deal closes' framing implies when this applies and the state values hint at filtering, but there is no explicit 'use this when / not when' guidance and no pointer to siblings such as get_transaction for a single record or the state-specific action tools like mark_dispatched.

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 this as a read-only, non-open-world operation. The description adds useful behavioral context beyond the annotations: results are newest first, include a public URL and status values, and the call requires GLONGUS_API_KEY. It does not discuss pagination or empty-result behavior, but for a zero-parameter list tool the added context is solid.

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

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

The description is a single compact sentence with the key scope and return information front-loaded. Every clause contributes: what is listed, ordering, returned fields, status values, and the API-key requirement.

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

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

For a simple read-only list tool with no parameters and no output schema, the description supplies enough: scope, ordering, the fields returned, the possible statuses, and the authentication requirement. Nothing essential for correct invocation appears to be 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 is 4. There are no parameter semantics to clarify beyond the schema, and the description appropriately does not invent any.

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 and scope: the caller's wanted requests, returned newest first with public URL and status. It is clear what the tool does, though it does not distinguish itself from related siblings such as list_owner_requests or post_wanted_request.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives, nor any exclusions. The 'your wanted requests' scope implies a personal list, but an agent must infer that from the wording rather than being routed by the description.

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

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

With annotations already indicating this is a non-read-only, non-destructive, closed-world mutation, the description adds useful context: it is seller-only, records an escrow_held-related state, requires GLONGUS_API_KEY, and emphasizes only real tracking should be reported. It does not explain reversibility or error behavior, but it meaningfully supplements 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?

The description is compact and front-loads the key qualifiers: seller-only and escrow_held. Each sentence adds actionable information about shipped versus collection-only behavior, carrier format, and authentication without 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 three-parameter mutation tool with no output schema and low schema description coverage, the description supplies the critical operational context: seller role, escrow state, API key requirement, conditional tracking fields, and handover behavior. Minor gaps remain around transaction state preconditions and error handling, but the essentials are covered.

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 only 33%, so the description carries most of the burden for carrier and tracking_number. It explains their conditional requirement for shipped listings, gives lowercase carrier examples, and specifies that collection-only handover uses neither; transaction_id is left to the schema, which already describes it.

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: marking a sale dispatched by recording that the item has left the seller's hands. It also distinguishes shipped versus collection-only cases and seller-only access, so an agent can identify the tool's role 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?

It gives explicit usage conditions: seller-only, shipped listings require tracking_number and carrier, and collection-only listings should call it at handover with neither. It does not explicitly name all sibling alternatives such as confirm_handover, but the context is clear enough for correct invocation.

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 substantive context beyond the annotations: it is publicly visible via a shareable link, exposes the agent name but never the owner, requires GLONGUS_API_KEY, and emits a wanted_listed alert later. Annotations already flag this as a non-destructive write with no open-world access, so remaining gaps (duplicate handling, failure modes) are minor.

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 trigger is front-loaded in the first sentence and the rest follows a logical flow (what it creates → what you get back → follow-up → privacy → auth). Some of the quoted sales pitch ("list it on Glongus and my agent will buy it") is narrative padding that could be trimmed.

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

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

With no output schema, the description correctly explains the return value (a public glongus.com/wanted/… link) and the asynchronous wanted_listed alert. Auth and privacy are covered; only edge cases like duplicate requests or link expiry are absent.

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 field descriptions (title example, category, description details, budget shown as 'up to £…') already carry the semantics. The tool description adds nothing about parameter format or the public visibility of max_price_cents, 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 ('Post what your owner wants to buy') and implicitly contrasts it with search ('Searched and found nothing?'), which separates it from search_listings and create_listing. An agent can tell this is the demand-side counterpart to creating a listing without opening the schema.

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

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

Gives a concrete triggering condition ('Searched and found nothing?') and explains the downstream workflow (wanted_listed alert → make your offer). It does not name the alternative tool explicitly nor state when not to post (e.g. duplicates), so it falls just short of full routing guidance.

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

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

The description adds important behavioral constraints beyond annotations: the split must sum exactly to the transaction amount, only the counterparty can accept it, and an API key is required. It does not describe what happens after acceptance or rejection, but the key operational constraints are disclosed.

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

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

The description is three compact sentences with the core action and invariant front-loaded. Every sentence contributes a necessary constraint or prerequisite.

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

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

For a simple three-parameter mutation tool with annotations and no output schema, the description covers the critical split invariant, counterparty acceptance rule, and API-key requirement. It lacks lifecycle details such as proposal expiration or what acceptance triggers, but is largely complete 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 0%, so the description must carry parameter meaning. It explains the key invariant for buyer_refund_cents and seller_payout_cents and ties them to transaction amount_cents, though transaction_id is only implied by context and schema pattern.

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 and resource: proposing a split of the escrowed amount. It clearly distinguishes this as a settlement-proposal operation rather than accepting or deciding one, though it does not explicitly name sibling tools.

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 provides useful context that only the other party can accept the proposal, implying when this tool is appropriate. However, it does not explicitly say when to use this instead of raise_dispute, respond_to_dispute, or decide_dispute_proposal.

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 say destructiveHint=true; the description supplies the actual consequence — escrow freeze — plus reputation recording and the GLONGUS_API_KEY requirement, which is real context the annotations don't carry. It omits whether the dispute can be withdrawn or how the freeze is later lifted, so it stops one step short of full behavioral 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?

Four short clauses, each carrying new information (window, effect, category discipline, warning, auth), with the eligibility window front-loaded. The telegraphic fragments are dense but not padded; nothing is redundant.

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

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

For a destructive, no-output-schema mutation, the description covers eligibility, side effect, cost, and auth — enough to call it responsibly. The remaining gap is the downstream resolution path and the undocumented category/transaction_id parameters, which leaves an agent unsure what happens after the call.

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 only 33%: only reason is documented, with category and transaction_id carrying no description. The one line 'Pick the category that actually fits' adds real intent for the enum choice, but neither the enum semantics nor the txn_ pattern is explained, so the description only partially compensates for the coverage gap.

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

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

States the action and its effect concretely ('freezes the escrow') plus the eligibility window ('after dispatch and before escrow release'), which lets an agent place it relative to mark_dispatched and confirm_delivered. It does not explicitly distinguish itself from respond_to_dispute or propose_dispute_split, so sibling routing still requires inference from the name.

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 precondition (after dispatch, before escrow release) and an explicit when-not ('only dispute when your owner is genuinely harmed'), backed by a stated cost. It stops short of naming the alternative paths once a dispute exists (respond_to_dispute, propose_dispute_split), which would have made the guidance complete.

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 the safety profile (not readOnly, not destructive, not open-world); the description adds the meaningful behavioral constraint that only listings currently delisted or in a cancelled-sale state can be relisted, which is the main failure mode. It does not say whether relisting preserves the original listing_id/terms or what error surfaces if the state is wrong, so it is good but not complete.

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

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

A single sentence with the action and eligibility conditions front-loaded and supporting detail in a parenthetical. Nothing is redundant or 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?

For a one-parameter, non-destructive mutation with annotations covering safety, the description supplies the eligibility preconditions an agent needs before calling. It omits post-conditions (does the relist mint a new listing id, are fees re-charged?), but with no output schema and low complexity the definition is largely sufficient.

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 is a single required parameter with 100% schema description coverage and a pattern constraint, so the schema already does the work. The description adds only the ownership qualifier ("one of your own listings"), which is useful context but not syntax-level semantics; 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 and resource ("Put one of your own listings back on the market") and scopes it to the agent's own listings, which separates it from get_listing/search_listings. It also enumerates the precise source states (delisted, or sold with a cancelled sale), so an agent can tell exactly which listings qualify.

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

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

The description gives clear triggering context: use this when a listing is delisted or when a sale was cancelled by the seller or at the dispatch deadline. It stops short of explicitly naming the inverse tool (delist_listing) or stating what to do when the listing is in another state, so there is no explicit when-not/alternative routing.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the bar is lower; the description still adds ownership restriction ('your own listings') and the API-key prerequisite, which annotations do not carry. It stops short of saying whether the photo_url must currently exist in photo_urls or what happens on a mismatch.

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?

One sentence, front-loaded with the action and resource, with the two constraints (exact URL, own listing) and the auth note packed in without waste. Nothing to trim.

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 two-parameter destructive tool with no output schema, the description covers scope, identifier source, ownership and auth. Minor gaps remain around failure behavior (unknown URL, last remaining photo) that would matter for a delete operation.

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 50%: photo_url is documented in-schema and the description reinforces it as an exact URL match against photo_urls. listing_id has no schema description and the description only indirectly constrains it via 'your own listings', leaving the lst_ prefix and ownership requirement mostly to the schema pattern.

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 (Delete) and a narrowly scoped resource (one photo from one of your own listings), plus the identifier form (exact URL from photo_urls). This is clearly distinct from sibling add_listing_photo and from listing-level mutations such as delist_listing or update_listing.

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

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

Usage is only implied: 'from one of your own listings' signals the ownership precondition, and GLONGUS_API_KEY signals the auth requirement. No explicit when-not-to-use or named alternatives (e.g. add_listing_photo, update_listing) are given, so the agent must infer the routing itself.

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 a non-destructive write, so the description's job is to add context — and it does: one-shot semantics, a race condition (first response wins on delivery_failed), the pre-decision window, and an auth requirement (GLONGUS_API_KEY). It omits what happens to the response afterward (whether it binds the outcome) and any length/content expectations.

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

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

Two tight sentences, with the eligibility rule front-loaded ahead of the exception and the auth note. Dense but every clause carries a distinct rule; nothing 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?

For a two-parameter mutation with no output schema this covers eligibility, limits and credentials well, but leaves two gaps an agent needs: what to put in the response body and what the call changes about dispute state. Adequate, not complete.

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

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

Schema description coverage is 0% on two parameters, so the description carries the full burden and does not meet it. It never explains what the `response` string should contain, whether it is visible to the counterparty, or that `transaction_id` must be the disputed transaction.

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 (respond) and resource (dispute) plus the exact eligibility rule: the party who did not raise the dispute, one response only. That scope statement separates it from propose_dispute_split and decide_dispute_proposal without naming them, though an explicit sibling reference would push it to a 5.

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

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

Gives clear timing (before anything is decided), a frequency limit (once), and an exception path for Glongus-raised delivery_failed disputes where either side may respond. It stops short of saying what the alternative routes are when you cannot respond — e.g. proposing a split.

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 say destructive/non-read-only; the description goes well beyond by disclosing escrow funding, buyer fee charging and refund-on-cancel, the 20-move cap, the 72h per-move clock, application of owner spend caps, and the post-accept obligation to report and offer share_deal. It also states the GLONGUS_API_KEY requirement, which no structured field covers.

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 action semantics are front-loaded and every clause carries operational weight, but the single dense block mixes turn rules, fee mechanics, and post-deal etiquette, which makes it slightly harder to scan than a bulleted structure would be.

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, non-read-only mutation with no output schema, the description covers what's needed: preconditions (your turn), constraints (monotonic bids, move cap, deadline, spend caps), side effects (escrow, fees, refundability), and the required follow-up. Nothing essential to calling 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 75%, so the enum and message length are already documented; the description still adds real semantics the schema lacks — amount_cents is required for counter, bids must rise and asks fall, and a counter must land strictly between the two standing numbers. It stops short of clarifying the pence-vs-cents unit mismatch explicitly, which is the one residual ambiguity.

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 opens with a concrete verb framing ('Haggle. When it is your turn') and enumerates all four moves (accept/counter/reject/withdraw), making it unmistakably the negotiation-move tool rather than create_offer or get_offer. An agent can distinguish it from every sibling 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?

It states exactly when each action applies ('when it is your turn' for accept/counter; 'any time' for reject/withdraw) and names get_offer as the source of next_move for countering. The when-to-use-a-counter vs when-to-accept boundary is 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 cover the safety profile (readOnlyHint, openWorldHint), but the description adds real context: no auth is required, and when GLONGUS_API_KEY is configured your own listings are silently excluded from results — a non-obvious filtering behavior an agent would otherwise misread as missing data. It also discloses the return shape and currency semantics.

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?

Four short sentences, each carrying distinct information (scope, currency, return value, auth/filtering caveat), with the purpose front-loaded and no repetition of name or title.

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

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

With no output schema, the description steps in to say it returns listings plus a total count, and it covers auth and the self-exclusion caveat. Pagination behavior (offset/limit interaction) is left entirely to the schema, which is a minor remaining gap for an 8-parameter search 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 coverage is 100%, so 3 is the baseline; the description earns above that by pinning down the money unit with a worked example ('2500 = £25.00'), which removes ambiguity when the agent constructs min_price_cents/max_price_cents. It does not otherwise elaborate on query, category, or condition semantics beyond the schema.

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

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

States a specific verb and resource ('Search active listings on the Glongus agent marketplace') and scopes it ('physical goods, GBP'). This clearly separates it from singular readers like get_listing and from list_wanted_requests.

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 word 'active' implies a filter on listing state and the auth note explains a behavioral consequence, but the description never names an alternative (e.g. 'use get_listing to fetch one by ID' or 'use list_wanted_requests for demand-side search'). Usage is only implied.

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

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

The description adds useful behavioral context beyond the annotations: it says the tool returns the full preferences and requires GLONGUS_API_KEY. The annotations already declare it is not read-only, not destructive, and not open-world, so the remaining disclosure gap is minor.

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 three short sentences, front-loads the core action, and includes only relevant details: threshold meaning, return value, and authentication requirement.

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

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

For a one-parameter mutation with annotations and no output schema, the description covers the action, return value, and auth requirement. However, the pence-versus-cents inconsistency leaves a meaningful ambiguity about the input value that should be resolved in the description or schema.

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

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

Schema description coverage is 0%, so the description must carry the parameter meaning. It explains that the value is the wallet balance below which an alert fires, but it says '(pence)' while the parameter is named low_balance_threshold_cents, creating a unit ambiguity that could lead to incorrect invocation.

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: setting the wallet balance threshold below which the owner gets a low-balance alert. It also clarifies this is the only preference the caller may set themselves, distinguishing it from broader preference/profile tools in the sibling list.

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

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

Usage is implied: use this tool to set the low-balance alert threshold. The phrase 'the one preference you may set yourself' hints at scope relative to other preference tools, but it does not explicitly name alternatives or state when not to use this tool.

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 context beyond the annotations: content redaction rules, idempotent create-or-return behavior, the auth requirement (GLONGUS_API_KEY), and the return payload (url plus suggested share_text). The one gap is that unshare=true removes a live page while destructiveHint=false — the description discloses the action clearly enough that this reads as intentional scoping rather than a contradiction, but the reversibility (can it be re-shared afterwards?) is left implicit.

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 page contents, then the permission gate, then the unshare escape hatch, then the auth requirement — a sensible ordering with no filler. It is dense rather than short, but nearly every clause carries an actionable constraint.

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 only two parameters, no output schema, and flat inputs, the description covers everything an agent needs: what is created, who may trigger it, what is returned, how to undo it, and what credential is required. Nothing material is left to inference.

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 both parameters are documented there, so the schema does the heavy lifting. The description restates the meaning of unshare ('take the page down') and adds the create-or-return semantic that implies transaction_id identifies an existing deal, but provides no format or edge-case detail beyond that.

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 and resource: 'Creates (or returns) the public replay page for one of your deals', then enumerates the page contents (item, asking vs final price, every move) and what is excluded (owner and other agent). No sibling tool shares deals, and the 'or returns' phrasing signals idempotency, so an agent knows exactly what this produces.

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 precondition ('ONLY call this after your owner explicitly said yes to sharing this deal'), an explicit post-action ('hand them the url; never post it anywhere yourself'), and the inverse operation ('Pass unshare: true to take the page down'). When-to-use, when-not, and the alternative pathway are all stated.

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

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

Annotations declare non-read-only, non-destructive, closed-world, and the description adds substantive context beyond that: it returns a payment_url, crediting happens in seconds, and an API key is required. Minor gap: no mention of rate limits or failure modes, so not 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?

Compact and front-loaded: purpose first, then the return artifact, then the follow-up and the key safety rule. No sentence is padding.

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

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

With no output schema, the description still explains the return value (payment_url) and how to confirm success via whoami, plus the auth requirement. 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% and the single amount_cents parameter is fully documented, so baseline 3 applies. The description's '(pence, min 100)' merely echoes what the schema already states.

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 ('Start a deposit into your owner's wallet') with currency and minimum, and is clearly distinguishable from siblings like wallet_history and whoami. An agent knows exactly what this does.

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

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

Gives explicit operating instructions: send the returned payment_url to the owner, verify with whoami, and never pay yourself. These are the exact conditions for using and not misusing the tool.

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 state readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the API-key prerequisite and the either-party access rule, which is useful, but it does not disclose what tracking information is returned, rate limits, or error 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?

The description is short and front-loaded, with no wasted sentences. The fragment style ('Either party. Requires GLONGUS_API_KEY.') is efficient but slightly telegraphic.

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

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

This is a read-only tracking tool with no output schema and no parameter descriptions, so the description carries more explanatory burden. It omits what tracking data is returned (carrier, status, events), what errors may occur, and how to interpret transaction_id, leaving the agent under-informed beyond the annotations.

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 single required parameter transaction_id has 0% schema description coverage, and the description does not explain its format, the ^txn\_ pattern, or how an agent should obtain it. The phrase 'shipped transaction' provides only weak contextual linkage and does not compensate for the missing parameter semantics.

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

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

The description states a clear action and resource: carrier tracking for a shipped transaction. It is understandable without opening the schema, but it does not explicitly distinguish this from siblings like get_transaction, get_shipping_rates, or book_shipping_label.

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 useful context that either party may use it and that GLONGUS_API_KEY is required, along with the shipped-transaction scope. However, it does not state when to choose this tool over get_transaction or get_shipping_rates, nor does it list exclusions or failure conditions.

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 say it's a non-read-only, non-destructive, closed-world mutation. The description adds genuinely new behavior: computed fields (stats, tier, track record) are immutable, name is owner-set, links are publicly attributed to the owner, and GLONGUS_API_KEY is required. That public-visibility warning is the kind of consequence an agent could not infer from structured fields.

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 action, then constraints, then the auth requirement — no filler sentences. It is dense and slightly run-on, packing the links caveat and key requirement into single sentences, but every clause carries 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 8 optional params, full schema coverage and annotations, the description covers the essential gaps: patch semantics, immutable fields, owner consent for links, and auth. It does not say what the response returns or whether changes go live publicly immediately, which would round it out.

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 patch semantics that the schema does not convey: omitted fields are left alone rather than cleared. It also echoes the owner-consent constraint on links, which is meaningful 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?

Concrete verb+resource: 'Change how your public profile (glongus.com/agents/<your id>) introduces you', and it delineates editable vs non-editable fields (stats, tier, name). It doesn't name siblings like get_agent or whoami, but the public-profile scope is distinct enough without that.

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 partial-update instruction ('Send only the fields to change') and a conditional rule for links ('only set them if your owner asked'). No exclusions or named alternatives are given, so it falls short of a full when/when-not treatment.

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 real context beyond the readOnlyHint=false/destructiveHint=false annotations: sold listings are locked while a sale is live, updates are partial (only passed fields change), null clears auto-accept/decline rules, and GLONGUS_API_KEY is required. It does not disclose whether the lock is time-based, what error a locked listing returns, or whether escrow/price edits are restricted after offers exist.

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?

Four compact sentences, front-loaded with the partial-update rule and followed by constraints, the null convention, and sibling routing. No sentence 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?

For a 12-parameter mutation tool with a nested parcel object and no output schema, the description covers the highest-risk facts: partial semantics, the sold-listing lock, null clearing, and auth. It leaves the nested parcel object and per-field constraints entirely to the schema, which is reasonable, but a note on price/escrow editability after an offer exists would close the remaining behavioral gap.

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

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

Schema description coverage is only 8% across 12 parameters, so the description must compensate — and it only does for two of them, explaining the null-to-clear semantics for auto_accept_cents and auto_decline_below_cents plus the overall partial-update rule. Ten parameters (title, description, price_cents, condition enum, parcel nested object, dispatch_window_hours, requires_shipping, location, escrow_hours, listing_id) get no guidance from the description; the schema enums and constraints carry them alone.

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 ('Change fields on one of your own listings') and immediately scopes it to ownership. An agent can distinguish it from create_listing and get_listing 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 routes off-market/on-market transitions to delist_listing and relist_listing, which covers the main sibling ambiguity. It does not contrast with create_listing or say when a full re-create beats an edit, but the critical alternative is 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 non-readOnly, non-destructive, and closed-world. The description adds meaningful context beyond them: the owner sees the note, the note is required when declining, and GLONGUS_API_KEY is required. It doesn't state whether the action is reversible.

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

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

Two sentences, zero waste, front-loading the action and the two valid outcomes before the auth note. Every clause carries information an agent needs.

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 mutation with no output schema, the definition covers statuses, note semantics, audience for the note, and auth. It could mention what the call returns, but annotations and schema carry the rest.

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 only 33%, so the description must compensate, and it does: it explains what each status means and when a note is needed, plus that the owner will read it. It doesn't mention the request_id pattern or note length limit, but those are covered in 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: mark an owner request 'done' or 'declined'. The resource noun (owner request) distinguishes it from siblings like close_wanted_request and list_owner_requests, though it never names an 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 clear conditional guidance for each status, including concrete examples (listing made without a wanted_id → done; sold/rule-breaking/unsafe seller → declined). It lacks explicit when-not guidance or named alternatives such as escalate_to_owner.

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 safety (readOnlyHint=true, openWorldHint=false), and the description adds real context on top: the ledger is ordered newest first, and it enumerates which entry categories appear. That is exactly the kind of behavioral detail annotations cannot carry. It omits any note on pagination beyond the limit or on error behavior when the key is missing.

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?

One tight sentence: identity and contents first, ordering and auth requirement after. No filler, no restatement of the title.

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, single-optional-param tool, the description supplies the essential missing piece — what the returned entries actually are — which compensates for the absent output schema. A brief note on whether results are pageable (i.e., whether a full 200 is a truncation signal) would close the remaining gap.

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

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

Schema description coverage is 100% and the single optional `limit` parameter already documents its default (50) and bounds (1-200) in the schema. The description adds nothing about the parameter, 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 concrete resource ("Your owner's wallet ledger") plus the exact contents (deposits, escrow holds, refunds, payouts) and ordering, which lets an agent distinguish it from transaction-level siblings like list_transactions or get_fees. It stops short of naming those siblings explicitly, so differentiation is inferred rather than declared.

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?

"Requires GLONGUS_API_KEY" is a genuinely useful prerequisite the schema does not express. However, there is no statement of when to use this versus get_fees, list_transactions, or top_up_wallet — the agent must infer that this is the balance/ledger audit call.

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 openWorldHint=false, so the safety profile is covered. The description still adds real value beyond them: it discloses the exact response contents, notes that API keys are truncated to the last 4 characters, and specifies the balance unit (pence). It doesn't state what happens when unauthenticated or credentials are invalid, which is the natural remaining gap for a diagnostic 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?

Two sentences, front-loaded with what it returns, followed immediately by the usage trigger. No filler and every clause carries information the agent needs.

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?

There is no output schema, so the description carries the burden of explaining return values — and it does so field by field, including the pence unit and key masking. Combined with the annotation-covered safety profile, an agent has everything needed to call 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?

With zero parameters there is nothing to disambiguate, so the baseline of 4 applies. The description correctly implies the tool takes no inputs and derives everything from the server's session.

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 — 'Shows which account this server is acting as' — and enumerates the returned facts (sign-in method, agent/owner, trust tier, wallet balance). This is clearly differentiated from identity-adjacent siblings like get_agent and get_agent_reputation, which look up other agents rather than the caller's own authenticated identity.

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 triggers: 'Call it before your first offer, or whenever an authenticated tool fails, to confirm you are signed in as the owner you expect.' That covers both proactive and diagnostic usage. It stops short of a 5 because no when-not condition or explicit alternative (e.g., get_agent for other accounts) is named.

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