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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the mutation/safety profile is partly covered. The description usefully adds the confirm gate and preview fallback plus side effects (reserves/re-opens the listing), but does not state whether 'complete' and 'cancel' also honor the confirm preview behavior, leaving the confirmation contract only half disclosed.

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

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

Two dense sentences with the gating rule front-loaded and no filler; every clause adds operational meaning.

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, the description covers the destructive actions and the preview path adequately. The remaining gap is whether confirm:true is also required for 'complete' and 'cancel', which an agent would need to call 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%, so the description must carry parameter meaning. It explains the 'action' enum values well and clarifies 'confirm' semantics, but says nothing about 'dealId' and leaves the confirm requirement ambiguous for two of the three actions, so it 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?

The description names a specific operation and enumerates the three action values with their distinct effects ('approve' reserves the listing, 'complete' marks sold, 'cancel' re-opens the listing). This lets an agent distinguish it from nearby siblings like propose_deal and negotiate_offer. It stops short of explicitly naming a sibling it replaces or excludes.

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 per-action context for when each mode applies and adds a meaningful precondition (approve requires confirm:true). There is no explicit 'when-not' guidance or named alternative tool, so it lands at clear-context-but-no-exclusions.

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=false, destructiveHint=false, openWorldHint=false), and the description adds real value on top: it discloses that the effect is local-only persistence ('Stored locally; nothing is posted') and that it returns a ≤280-char drafted X post. It does not say what happens on repeat calls (duplicate/overwrite), which keeps it off 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?

Two dense sentences with no filler: the field inventory comes first and the return/side-effect statement follows. Efficient and front-loaded, though the field list is a long run-on that slightly obscures the two most decision-relevant clauses.

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 states the return (a drafted ≤280-char X post) and the persistence behavior, which covers the critical unknowns for a mutation tool. For an 18-param tool with nested objects and 0% schema description coverage, though, too many optional parameters are left entirely unexplained.

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 carries the burden and does add genuine semantics — notably 'private floor (lowest you'll accept) and ceiling' and 'photos (≤4 URLs/paths)', which clarify otherwise opaque fields. But of 18 params it only touches a subset (title/item, condition, ask, floor, ceiling, photos, pickup/delivery, payment, rules), leaving quantity, currency, location, highlights, category, style, tags and rule sub-fields undocumented anywhere.

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 (Create) + resource (sale listing) with the key content enumerated, and it implicitly separates itself from post_listing by stating 'nothing is posted' and calling the result a draft. An agent can tell this apart from post_listing/update_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?

Usage is implied rather than stated: 'Returns a drafted X post... Stored locally; nothing is posted' tells the agent this is a draft-only step, which is a useful when-not signal for publishing. However, no sibling is named (e.g. post_listing for publishing, update_listing for edits), so the routing decision is left to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that the output is aggregate totals rather than raw deal rows, which is genuine context beyond the annotations, but it says nothing about whether results are workspace-scoped, dated, or paginated.

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 dense, front-loaded sentence that lists the returned metrics with zero padding. It works as a summary, though the missing verb and the unreconciled word 'All' cost a point against the status filter.

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 usefully names the aggregates returned, which is the most important thing an agent needs. However, for a single-enum-parameter tool it omits the status filter semantics entirely, leaving a real gap in how to call it correctly.

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

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

Schema description coverage is 0% and the sole parameter is a meaningful status enum (pending_approval, agreed, completed, cancelled, all). The description never mentions filtering by status and its phrase 'All deals' actively implies no filtering is possible, so it does not compensate for the schema gap.

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

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

The description names a specific resource (deals) and enumerates the aggregates returned (completed revenue, pending/agreed value, average discount from ask), which is far more informative than a tautology. It implicitly distinguishes itself from write-oriented siblings such as propose_deal and approve_deal by being a reporting view, though it never says so 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?

There is no when-to-use guidance, no mention of alternatives, and no indication of when an agent should call deal_ledger rather than list_listings or query a specific deal. The only usage signal is inferable from the noun 'ledger'.

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 declaring readOnlyHint=false, destructiveHint=false, and openWorldHint=false, the bar is lower, yet the description still adds real value: it discloses that the output is a DRAFT requiring human approval rather than a sent message, that negotiation state is persisted across rounds, and that buyer text is untrusted data (a prompt-injection warning). It stops short of stating permissions, rate limits, or what happens to an unapproved draft.

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: the first front-loads the trigger ('Paste a buyer's message') with a compact pipeline, the second front-loads the critical return/behavior facts. Dense but no filler; the long enumerations of intents cost some readability without wasting much space.

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 multi-step tool with no output schema and zero schema-level parameter documentation, the behavior side is well covered but the invocation side is not: an agent cannot learn from the description what listingId vs. buyer mean, what tone changes, or where the floor/ceiling/rules configuration is sourced. Adequate, but with a clear gap on inputs.

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

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

Schema description coverage is 0% across 4 parameters, so the description must compensate and largely does not. It alludes to the message body and references 'your floor/ceiling and rules' — which are not parameters at all — while the roles of listingId, buyer, and the friendly/brief tone enum are never explained.

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

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

The description names a specific verb and resource ('drafts a reply') and enumerates the full internal pipeline: intent detection, offer extraction, scam flagging, negotiation engine, thread tracking. An agent can distinguish this from negotiate_offer (which computes rather than drafts) and send_dm (which sends rather than returns a draft) 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?

'Paste a buyer's message' plus 'The thread is tracked for negotiation rounds' implies when the tool applies, and 'Returns a DRAFT needing your approval' implies the follow-on action. However, it never states when NOT to use it or names an alternative sibling (e.g., negotiate_offer, send_dm) for cases where drafting is the wrong step.

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, so the non-mutating safety profile is covered. The description reinforces this with 'Draft only' and adds that the output includes safety tips, which is mild extra context, but it says nothing about idempotency, permissions, or what the drafted output looks like.

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

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

Two short, front-loaded sentences with no filler and the core action stated first. It is efficient, though arguably too terse given the tool's parameter surface.

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 7 parameters, 0% schema coverage, and no output schema, the description should carry substantially more. It omits required listingId, the buyer field, and any return-format notes, so an agent lacks what it needs to invoke the tool confidently.

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

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

Schema description coverage is 0%, so the description carries the full parameter burden, yet it names only place, time, price, and mode-like concepts. It omits listingId (a required parameter), buyer, and fee entirely, leaving required inputs undocumented in both schema and prose.

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

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

The description names a specific verb (Draft) and resource (a pickup or delivery confirmation message) and enumerates the content it covers (place, time, price, payment). It does not explicitly distinguish itself from the close sibling draft_buyer_reply, though 'Draft only' signals it is a draft-generation tool.

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

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

The clause 'Draft only' implies the tool stops at drafting and that a separate action (e.g., send_dm) is needed to dispatch, which is useful implied guidance. However, it never states when to choose this over siblings like draft_buyer_reply or propose_deal, leaving the routing decision to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds nothing further: it doesn't say whether results are paginated, what the default ('all'?) filter is, or how many listings are returned. For a simple read tool this is a minor gap, but zero added behavioral context keeps it low.

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 short sentence with the action and the filter front-loaded and zero filler. It is arguably too terse to be maximally informative, but nothing in it is 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?

The tool is low-complexity, has no output schema to compensate for, and its annotations carry the safety profile, so the short description is roughly adequate. It still omits the default-status behavior and any sense of result scope, which an agent would need to call it confidently.

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

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

Schema description coverage is 0%, but the single parameter is a fully self-documenting enum (draft, posted, reserved, sold, withdrawn, all). The description's 'by status' confirms the parameter's role without adding syntax or default-value semantics, which is the minimum viable for one enum param.

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 verb+resource ('List your listings') and adds the scoping dimension ('by status'), which distinguishes it from the mutating siblings create_listing/update_listing/post_listing. It stops short of naming a sibling or clarifying how it differs from deal_ledger-style retrieval tools, so it lands at clear-but-undifferentiated.

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

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

There is no when-to-use guidance, no mention of alternatives such as the listing-mutation siblings, and no indication of what the default behavior is when 'status' is omitted. The phrase 'by status' hints at filtering but never states the context or exclusions.

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 the description confirms 'without recording anything', which is consistent. It also adds non-annotation domain behavior: the engine never goes below the floor and the floor is never surfaced in drafted text, valuable constraint context.

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

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

Two tight sentences, the what-if scope is front-loaded, and every clause adds information without repetition.

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

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

No output schema exists, yet the description never says what the simulation returns (e.g., a counter amount or accept/reject), and two of four parameters are undocumented. The floor constraint helps but the picture is incomplete for a 4-param tool.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, but it only echoes 'offer' and 'round' by name without format, range, or intent. 'listingId' and 'lastCounter' are left entirely unexplained.

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 action: run the negotiation engine for an offer/round as a what-if, with no recording. That cleanly separates it from mutating siblings like propose_deal or approve_deal, 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?

The 'What-if' framing implies this is a simulation to try before committing, which is useful context, but there is no explicit statement of when to use it versus propose_deal or deal_ledger, and no exclusions or prerequisites.

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

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

Goes well past the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) by disclosing that it uses the END USER's own OAuth token with scope tweet.write, that confirm:true is required to actually publish, and that photos are not uploaded. These are real operational constraints an agent could not infer from the 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 the action and the credential requirement, with the preview behavior and photo limitation following in priority order. 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 no-output-schema mutation tool, the description covers auth, the confirm gate, and a known limitation. It omits failure modes (X API rate limits, the 280-character platform limit versus the 1000-character schema cap) and whether a published post can be undone, which matters given openWorldHint=true.

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 confirm well (preview vs. live post), but leaves 'text' (maxLength 1000) and 'listingId' unexplained — notably whether 'text' overrides the listing's stored text or whether it is required at all.

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 the listing's text to X') plus the credential context, which cleanly separates it from siblings like send_dm, create_listing, and draft_buyer_reply. The title and first sentence together make the operation unambiguous.

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

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

Describes the two-phase flow explicitly: calling without confirm:true returns an exact preview, and confirm:true performs the post. That tells the agent when to use the tool in each mode, though it never names an alternative tool or states when not to use this one.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false, but the description adds the key behavioral fact annotations cannot convey: the write creates a non-binding PENDING state and acceptance requires a separate confirm:true call. It does not state reversibility, auth requirements, or whether re-proposing overwrites an existing pending deal.

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 zero filler, front-loading the state semantics (PENDING APPROVAL) before the approval dependency. Every clause earns its place.

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

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

The lifecycle and approval gating are well covered, but with six undocumented parameters, no output schema, and no detail on what an approval-gated proposal returns or how pending proposals are surfaced, the definition is only minimally adequate for the operation it describes.

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

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

Schema description coverage is 0% across six parameters, so the description carries the full burden and mostly fails it: it gestures at 'price' and 'buyer' but never explains listingId, quantity, notes, or handoff. Four of six fields remain undocumented anywhere, so it only marginally 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?

Specific verb and resource: records an agreed price with a buyer into the deal ledger, and explicitly labels the resulting state as PENDING APPROVAL. It also names the sibling tool (approve_deal) that transitions the state, so an agent can distinguish propose from approve 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?

States the workflow condition clearly: nothing is accepted until approve_deal is called with confirm:true, which tells the agent this is the pre-approval step. It does not, however, contrast with negotiate_offer or draft_handoff, leaving some ambiguity about when a proposal is preferable to continued negotiation.

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 genuinely useful behavior beyond the annotations: the call consumes the user's own token with dm.write scope, and omitting confirm:true yields a preview rather than a real send — the single most important safety fact here. It still says nothing about rate limits, failure modes, or whether a sent DM can be undone.

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 with zero filler, front-loaded on what the tool does, then prerequisites, then the confirm behavior. Nothing repeats the title or restates the obvious.

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, it covers purpose, prerequisites, auth scope, and the dry-run default, plus a hint at the return value ('a preview only'). Only error/idempotency behavior is left uncovered.

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 carries the burden. It explains participantId ('buyer's numeric X user id') and, valuably, the confirm semantics (preview vs. actual send), but leaves text — including its 10,000-character bound — entirely to the schema. Two of three parameters get meaning, one does not.

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 ('Send an approved reply as an X direct message') with a stated prerequisite (approved reply, user's own token). It implicitly distinguishes itself from draft_buyer_reply by insisting the reply is already approved, but never names that sibling explicitly, so differentiation requires inference.

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 context for use: the reply must already be approved, the participant must be identified by numeric X user id, and confirm:true is the switch between preview and real send. It does not state exclusions (e.g., when to prefer drafting first), so it stops short of full when/when-not guidance.

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

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

Annotations declare a non-read-only, non-destructive, closed-world mutation, and the description adds one genuinely useful trait beyond them: the post text is re-drafted as a side effect. However, it says nothing about partial-update semantics (what happens to fields left out), reversibility, or any side effects of status transitions like withdrawn/sold.

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

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

Two short, front-loaded sentences with no filler; the mutation scope comes first and the side effect second. It is efficient, though the extreme brevity is closer to under-specification than to tight editing.

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 7-parameter mutation tool with a nested rules object, no output schema and no schema descriptions, the definition is too thin: it leaves the ceiling parameter unexplained, the rules sub-fields undefined, and partial-update behavior unstated. An agent could invoke it but could easily get semantics wrong.

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

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

Schema description coverage is 0% across 7 parameters, including a nested rules object with 8 sub-properties, so the description carries the full burden. It only echoes a few English names (price, floor, rules, status, photos), omits 'ceiling' entirely, and explains none of the nested rule fields or their constraints.

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

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

States a specific verb (Change) plus the concrete resources it touches (price, floor, rules, status, photos) and adds the notable side effect that the post text is re-drafted. It does not name or contrast with siblings like create_listing or post_listing, so an agent must infer the boundary itself.

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

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

There is no when/when-not guidance and no mention of the alternative tools (create_listing, post_listing, list_listings) or prerequisites such as needing an existing listing id. Usage is only implied by the tool name.

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