AIProcurement Club

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

Annotations declare destructiveHint=true, openWorldHint=true, and idempotentHint=true, yet the description says nothing about what is destroyed or consumed, that sources are transmitted to an external inference provider (a required consent flag in the schema), or that runs are idempotent and keyed. "Extract ... for human legal review" actively reads as a passive read operation, creating tension with the destructive annotation that the description does not resolve.

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

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

A single front-loaded sentence with zero filler; the extraction targets come first. It is efficient, though its brevity is achieved by omitting content rather than by compressing it, which pushes cost onto other dimensions.

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 six-parameter, nested-object, destructive, open-world tool with no output schema, one sentence is far short of adequate. Nothing is said about how prior-run context is sourced, the plain-text-only document requirement, output format, or what the human review handoff looks like.

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 description explains no parameters at all. With 67% schema coverage, the well-documented fields (context, documents, idempotencyKey, consentExternalProcessing) are fine, but the two parameters with no schema description — sourceFields and sourceRunIds — are the non-obvious chaining controls an agent needs explained, and the 75,000-character combined limit is only visible in the schema's object description.

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

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

The description uses a specific verb ("Extract") with four named extraction targets — obligations, renewal deadlines, service levels, commercial clause concerns — so the agent knows exactly what output this tool produces. However, it does not differentiate itself from adjacent siblings such as xcontracts-summariser, xclause-risk-scoring, or xrenew-radar, which overlap heavily with three of the four named targets.

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?

"for human legal review" hints that the output is advisory and human-in-the-loop, but there is no explicit when-to-use, no exclusions, and no naming of alternatives in a sibling list crowded with contract-analysis tools. An agent choosing between this and xclause-risk-scoring or xcontracts-summariser is given nothing to decide with.

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, openWorldHint=true, and idempotentHint=true, so the safety profile is partly carried structurally. The description adds the analytical contract (separate realized savings from avoidance, surface assumptions) but never explains why the call is flagged destructive, that it transmits sources to an external inference provider, or that it may consume a paid invoice — all of which the agent must dig out of the schema.

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

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

A single front-loaded sentence with three purposeful clauses and no filler; the deliverable leads and the qualifiers follow. It is efficient, though the three clauses compress a fairly complex contract into one line without structural cues.

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 complex nested-payload tool with a required external-processing consent flag, an idempotency key, an optional invoice, and no output schema. The description covers the analytical intent but omits the external-processing/privacy posture and gives no sense of what comes back (a TCO model? a narrative?), leaving meaningful gaps for a first-time caller.

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 67% with the nested `inputs` object documented field-by-field (context, years, currency, documents, cost baselines), so the schema does most of the work. The description adds no parameter-level meaning of its own — notably silent on `sourceFields`/`sourceRunIds` chaining and on the consent flag — but the baseline for this coverage level is met.

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 deliverable — build a TCO and savings case — plus the analytic stance (realized vs. avoided savings, surfaced assumptions). An agent can tell this is a finance/TCO deliverable rather than a data lookup. It stops short of distinguishing itself from the closest sibling, xsavings-narrative, which also produces savings content.

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

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

The phrase 'for finance review' implies the context in which to reach for this tool, but there is no explicit when-to-use or when-not-to-use guidance and no alternative named (xsavings-narrative, xvendorbench, or the category tools are all plausible neighbors). The agent must infer selection from the title alone.

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 destructiveHint=true, openWorldHint=true, and readOnlyHint=false, but the description says nothing about cost, external inference processing, or consequences of a run — even though the required consentExternalProcessing flag signals sensitive data leaves the boundary. The gentle verb 'Find' also understates a destructive, open-world agent invocation, leaving the agent to discover the risk profile from annotations alone.

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

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

A single front-loaded sentence with no padding — the scope keywords come first. It is concise rather than under-specified, but its length is not matched to a tool this complex.

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 six-parameter, nested-input, destructive, open-world agent with a payment path and no output schema, one sentence is far from complete. Nothing explains what a successful run returns (summary, deliverable, financialModel per sourceFields), how prior runs are stitched via sourceRunIds, or when consent must be obtained.

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% and the description contributes no parameter meaning whatsoever — nothing about inputs.context, categoryEvidence, sourceRunIds, sourceFields, paymentInvoiceId, or idempotencyKey. The 75,000-character combined limit and service-specific CSV/date/rubric validation mentioned only in the schema are never surfaced in the description, so callers relying on the description would miss key input 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 ('Find usable sourcing options') plus the category scope ('facilities, professional services, consumables, and indirect materials'), which meaningfully separates it from category siblings like it-hardware, telecom, and mro. It does not, however, say what an 'option' is or how it differs from adjacent tools such as xmatch-supplier-shortlist.

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

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

No when-to-use context, no prerequisites, and no exclusions or named alternatives, despite ~30 sibling tools in this namespace. An agent can only infer that this applies to indirect categories; nothing tells it when to pick this over mro, contracts, or procurement_workflow__* paths.

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, openWorldHint=true, and idempotentHint=true, so the safety profile is partially covered. But the description adds nothing about the significant hidden behaviors implied by the schema: external inference processing requiring explicit consent, a payment/invoice path, and the ability to chain from prior runs. For a destructive, open-world, externally-processing tool this is a real 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?

The description is a single front-loaded sentence with no filler, which is structurally fine. However, the brevity is under-specification rather than disciplined economy: the sentence is a list of topic keywords and carries no operational 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?

The tool has 6 parameters, a nested inputs object, no output schema, and destructive/open-world annotations, yet the description is one topic sentence. An agent gets no sense of what the tool returns, what a run produces, or how the required consent and idempotency keys fit in. Substantially incomplete for this complexity.

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

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

Schema coverage is only 67% and the description explains no parameters at all. Notably, sourceFields and sourceRunIds have no schema descriptions and are semantically non-obvious (they appear to reference prior run outputs), and the consent/payment semantics are undocumented in the description. It adds no meaning beyond 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?

The single sentence names a specific verb (evaluate) and enumerates five concrete evaluation domains: lifecycle cost, warranty, compatibility, secure disposal, and supply continuity. Paired with the name 'it-hardware' this lets an agent distinguish it from siblings like it-software or telecom by subject matter, though the description itself never names or contrasts those siblings.

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

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

There is no guidance on when to invoke this tool versus the many sibling category agents (it-software, telecom, indirect, mro) or versus workflow tools. No prerequisites, no exclusions, no indication of what input quality is expected before calling it. The agent must infer everything from the tool 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?

Annotations declare destructiveHint=true, openWorldHint=true, readOnlyHint=false, and idempotentHint=true, but the description says only 'Assess' and does not disclose destructive side effects, external processing, payment requirements, or idempotency behavior. 'Assess' may suggest a safe analytical operation, so the description adds little behavioral context beyond the domain list.

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

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

The description is a single front-loaded sentence with zero boilerplate, leading with the verb and immediately enumerating the assessment areas. Nothing in the sentence is extraneous.

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 complex six-parameter service with a nested inputs object and no output schema, the one-sentence description is insufficient. It does not explain how to invoke the service, what outputs to expect, how consent or payment fields work, or what happens to source documents and prior-agent 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?

Schema description coverage is 67%, with several parameters documented only in the schema, and the description does not explain any invocation parameters such as inputs.context, categoryEvidence, sourceFields, sourceRunIds, consentExternalProcessing, or paymentInvoiceId. It adds thematic context but no parameter-level meaning 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 uses a specific verb, 'Assess,' and names the software/SaaS and cloud buying domain with concrete assessment areas such as licenses, renewals, security, data residency, and exit terms. It distinguishes this category agent from siblings like it-hardware and telecom by domain, though it does not explicitly name the alternatives.

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

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

The description implies usage for software and cloud buying assessments, but it gives no explicit when-to-use guidance, no exclusions, and no routing to sibling tools such as it-hardware or negotiation. The category scope is inferable but not operationalized.

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 destructiveHint=true, openWorldHint=true, and readOnlyHint=false, which are significant traits the description never echoes or explains — an agent gets no warning about what is destroyed or that processing goes to an external inference provider, despite consentExternalProcessing being a required param. The description does not contradict the annotations, but it adds almost no behavioral context beyond restating 'from your supplied sources'.

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 no filler and the core operation front-loaded. Brevity is appropriate in form, though at this length it shades into under-specification for a six-parameter, nested, open-world tool.

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

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

Given six parameters, a nested inputs object with a 75,000-character combined limit, no output schema, destructive and open-world annotations, and required consent plus idempotency key, the description is far too thin. It does not explain what comes back, how sourceRunIds reuse interacts with fresh inputs, or what the caller commits to by invoking it.

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

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

Schema coverage is 67%, below the threshold where the schema carries the load, and the description compensates for none of it. It never explains the relationship between `inputs` (raw evidence), `sourceFields`/`sourceRunIds` (reuse of prior runs), or why `consentExternalProcessing` must be literally true — the single most consequential parameter for the caller.

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 verb 'synthesize' plus the resources (procurement, market, service knowledge) give a rough sense of intent, and the optional provenance-tagged knowledge graph is a concrete artifact. But the actual deliverable is never stated (a brief? a set of findings? a graph?), and nothing distinguishes this from the many category-pack siblings (mro, indirect, it-software) or from procurement_workflow__knowledge_to_negotiation. Purpose is implied rather than pinned down.

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 when-not-to-use, and no named alternative. With ~30 siblings including category-specific tools and a workflow tool literally named knowledge_to_negotiation, the absence of routing information is a real gap. The two sentences describe what happens, not when to pick 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?

Annotations already declare destructiveHint=true, openWorldHint=true, and idempotentHint=true, but the description adds no behavioral context such as external processing consent, what deliverable is created or modified, or how idempotency is handled. It neither contradicts nor 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?

It is a single sentence with no wasted filler and is front-loaded with the MRO domain. However, the phrasing is awkward and the colon-list structure provides little orientation for a complex agent tool.

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

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

For a destructive, open-world agent with nested inputs, six parameters, and no output schema, one sentence is far too thin. It omits what the agent does, expected outputs, external processing, idempotency behavior, and parameter guidance.

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 topic list loosely maps to categoryEvidence, but the description does not explain the required inputs, sourceFields, sourceRunIds, consentExternalProcessing, or idempotencyKey. With only 67% schema description coverage and nested inputs, the description does not compensate for the remaining undocumented parameters.

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

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

The description identifies the MRO domain and lists relevant concerns (critical spares, uptime, lead times, inventory, supplier consolidation), but the verb 'Structure' is vague and does not state what the agent actually produces or returns. It also does not differentiate this category agent from sibling category agents such as indirect or it-hardware.

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 by the MRO topic; there is no explicit when-to-use guidance, no prerequisites, and no mention of when to choose this tool over sibling category agents. An agent must infer applicability from the name and title alone.

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 declare destructiveHint=true, openWorldHint=true, readOnlyHint=false, and idempotentHint=true, so the safety profile is covered. The description adds that preparation is grounded in supplied commercial evidence, but it does not explain external inference processing, consent requirements, or what 'destructive' means in this 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?

The description is a single front-loaded sentence that names the core deliverables without filler. Every phrase contributes to the purpose statement.

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 complex tool with nested inputs, external-processing consent, payment handling, and no output schema, the description covers the main artifact set but omits source selection, consent, idempotency, and sibling alternatives. It is adequate but not complete enough for an agent to call the tool optimally without reading the full 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 67%, with most nested input parameters documented in the schema itself. The description's phrase 'supplied commercial evidence' loosely relates to the inputs, but it does not clarify sourceFields, sourceRunIds, consentExternalProcessing, or idempotencyKey.

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

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

The description uses a specific verb, 'Prepare,' and names concrete negotiation artifacts: BATNA, reservation points, give/get trades, and buyer rehearsal. It is clear what the tool produces, but it does not distinguish itself from sibling tools such as xnegotiate-coach or the negotiation workflow 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?

Usage is implied by 'grounded in supplied commercial evidence,' suggesting the tool is for negotiation preparation when commercial evidence is available. However, there is no explicit when-to-use guidance, no when-not guidance, and no comparison against alternatives in the large sibling toolset.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds genuinely new context: SHA-256 validation gating, an explicit agent:read scope requirement, and a trust disclaimer that the content is untrusted generated analysis rather than evidence or approval. It does not say what happens when validation fails or whether a failed artifact is returned as an error.

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

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

Three short sentences, front-loaded with the action and its validation condition, followed by the trust caveat and the auth requirement. Dense but every sentence carries information; slightly jargon-heavy phrasing ('same-organization generated artifact') costs a little 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?

With one required param, no output schema, and annotations covering the safety profile, the description does the important remaining work: trust framing, auth scope, and validation gating. The main residual gap is return-shape behavior — what an artifact looks like, its size/format, and error semantics when the SHA-256 check fails.

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

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

Schema coverage is 0% and the single parameter runId is undocumented in the schema, so the description is the only place semantics could be added. It never explains that runId is a procurement run identifier (presumably the same key used by procurement_run__get) or the uuid format requirement, leaving the caller to infer the link between run and artifact.

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 (read a generated artifact) plus qualifying conditions: successful, same-organization, SHA-256 validated. This is far more precise than a tautology, but it never names the adjacent retrieval sibling (procurement_run__get) or explains how the artifact differs from run output, so sibling differentiation is only implicit.

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 preconditions (run succeeded, artifact exists, validation passed) imply when the tool applies, but there is no explicit 'use this instead of X' routing and no statement of when not to call it or what happens on failure. Usage must be inferred from the qualifiers.

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: same-organization scoping, the polling cadence for running states, the authorization scope (agent:read), and an explicit list of content the response excludes (buyer text, deliverables, evidence quotes, execution details). None of this is derivable from the readOnly/idempotent hints.

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 dense sentences with zero filler: purpose first, then the polling rule, then the data-boundary/auth caveat. Everything an agent needs up front.

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 does well to disclose what the response excludes and that a pollAfterSeconds field drives polling. It stops short of describing the status values themselves or the other returned fields, which is the main remaining gap for a polling-status 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?

The single runId parameter has 0% schema description coverage, so the description must carry the meaning. It implies runId identifies a run within the same organization (an access constraint), but never explains the identifier's origin or where to obtain it, leaving a gap for a UUID-typed required 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?

States a specific verb and resource: reading same-organization saved delivery status for a run. It's clear what the tool delivers versus a content-retrieval tool, though it doesn't name the sibling (procurement_artifact__get) that returns the excluded artifacts.

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 operational guidance: if status is running, wait pollAfterSeconds before re-reading, which describes the intended polling loop. It does not explicitly name an alternative tool for fetching deliverables, leaving that routing implicit.

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 information beyond the annotations: per-stage price ($15 each), separate invoices, and the partial-failure rule that completed stages stay consumed if a later stage fails — directly reconciling the destructiveHint with a safer charge model. The source-verification instruction and the no-auto-transfer rule tell the agent what it must do between and after stages, which the annotations cannot express.

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: purpose first, then the verification obligation, then the billing/partial-failure mechanics. Nothing is redundant with the title or schema, and the operative constraints are 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?

Covers cost, ordering, partial failure, and grounding obligations for a destructive, paid, nested two-stage tool with no output schema. One ambiguity remains: `stageInputs` requires both stages up front while the text describes passing generated output from stage one into stage two, and no explanation of how the stage-one result is surfaced to the caller before stage two is paid for.

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 description's cost/sequencing model gives real meaning to `maxChargeUsd` and `paymentInvoiceIds` (per-stage keys matching the two stage names), beyond their terse schema descriptions. It says nothing about the required `consentExternalProcessing` gate or the `idempotencyKey` semantics, but the schema covers both, so the 60% coverage gap is largely absorbed.

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 two-step operation: build a source-grounded category brief from buyer-supplied evidence, then feed that context to a negotiation coach. The explicit sequence 'knowledge → negotiation' distinguishes it from the sibling workflows whose first stage differs (meeting_to_negotiation, renewal_to_negotiation, supplier_risk_to_negotiation).

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 fixed stage ordering and the caveat 'No atomic bundle charge or automatic transfer' make the calling contract clear, and 'Verify every generated point against the original sources before use' signals a post-call obligation. It never states when to choose this workflow over calling `knowledge` and `negotiation` individually, or over `supplier_risk_to_negotiation`, so there are no explicit 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?

Goes well beyond the annotations by disclosing the per-stage price points ($10/$15/$15), the invoicing model, and — most importantly — partial-failure semantics: completed stages stay consumed if a later stage fails, with no atomic bundle charge or automatic transfer. This is exactly the irreversibility context an agent needs before committing money, and it is consistent with destructiveHint=true.

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 three capabilities and the cost model, and every sentence carries operational weight. Minor redundancy between "Each stage is a separately priced service" and "Separate invoices per stage" costs it a point.

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 costly, multi-stage, non-atomic tool it covers sequence, pricing, and failure behavior thoroughly. With no output schema present, however, the description never indicates what each stage returns or how the agent recognizes a partially completed run — the main 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 coverage is 60% with nested objects, so the description usefully maps the three stages onto the stageInputs keys and paymentInvoiceIds entries via the named stage flow. It adds nothing about maxChargeUsd, idempotencyKey, or the mandatory consentExternalProcessing flag, all of which are required for a correct 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 first sentence names three concrete operations (trace meeting evidence to RFP requirements, build a business case from supplied costs, prepare a negotiation brief), and the meeting-transcript starting point implicitly distinguishes it from sibling workflows like renewal_to_negotiation or knowledge_to_negotiation. It stops short of naming any sibling explicitly, so an agent must infer the boundary from the input source alone.

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

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

"Fixed sequence" plus per-stage pricing makes the intended execution order explicit, which is real usage guidance. However, it never says when to pick this chained workflow over the standalone rfp-evidence, finance-business-case, and negotiation tools that exist as siblings, nor when to prefer a different workflow entry point. The when-to-use case relative to alternatives 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?

Adds real behavior beyond annotations: fixed stage sequence, $15 per stage, separate invoices per stage, completed stages stay consumed if a later stage fails, no atomic bundle charge, no automatic transfer, and a warning that earlier agents' dates/recommendations are generated context to be verified. It never explicitly explains why destructiveHint=true (charge consumption is the likely reason) and doesn't spell out the consent gate, but the billing/irreversibility profile is well 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?

Three tight sentences: purpose first, verification warning second, then sequence and billing semantics. No filler, and every sentence 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 multi-stage, paid, non-atomic workflow with no output schema, the description covers sequencing, cost, failure partial-consumption, and verification duties. Gaps remain around per-stage invoices (paymentInvoiceIds), the consent requirement, and what each stage returns, but the contract of the call is largely conveyed.

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 60% and nested stage parameters are documented in the schema itself. The description adds pricing ($15/stage), the fixed ordering of stageInputs, and the meaning of maxChargeUsd as a cross-recipe cap. It does not explain paymentInvoiceIds (undescribed in schema too) or the per-stage invoice mapping, leaving the highest-risk parameter implicit.

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 concrete pipeline: find renewal/notice dates in a contract index, compare buyer costs, then prepare a negotiation plan, and it names the three underlying stage tools. That is specific verb+resource coverage. It does not, however, distinguish itself from the sibling workflow tools (meeting_to_negotiation, supplier_risk_to_negotiation, etc.) that also end in negotiation.

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?

Implicit usage is clear (you have a contract index with upcoming renewals and want a renewal-driven negotiation plan), and the required stage inputs imply prerequisites. But there is no explicit when-to-use/when-not statement and no routing against the many sibling workflow tools, so an agent must infer selection.

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: per-stage pricing ($15 each), separate invoices per stage, non-atomic charging, no automatic transfer, and that already-completed stages remain consumed if a later stage fails. That failure/billing semantics is exactly the kind of thing annotations (readOnly=false, destructive=true, idempotent=true) cannot express, and it is consistent with the destructive/openWorld hints.

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, front-loaded with purpose, then sequence, then billing caveats. No filler; every sentence carries a distinct constraint 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 paid, destructive, five-parameter nested workflow with no output schema, the description covers sequencing, cost ceiling, partial-failure billing and consent expectations well. The gap is return behavior — nothing says what the evaluation stage produces (scores, ranking, disqualification report) — which matters when there is no output schema to fall back on.

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

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

Schema coverage is 60% and the nested stageInputs fields are already well documented in-schema. The description adds real value on cost/authorization semantics (per-stage $15, own invoice per stage), which speaks to maxChargeUsd and paymentInvoiceIds, but it says nothing about idempotencyKey, consentExternalProcessing, or the uuid shape of paymentInvoiceIds — the undocumented remainder 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 two-verb workflow (draft RFP, then evaluate bids) with the exact artifacts and scoring basis (buyer-approved rubric, hard disqualifiers). It also names the underlying stage tools (xrfp-drafter, xscore-bid-evaluation), so an agent can distinguish this bundled recipe from the standalone siblings without opening the schema.

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

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

'Fixed sequence: rfp → evaluation' plus 'Drafted requirements remain provisional' tells the agent this is a coupled two-stage run, not a menu. There is still no explicit statement of when to prefer this over calling xrfp-drafter or xscore-bid-evaluation on their own, so it stops short of naming alternatives/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?

Beyond the annotations (destructiveHint=true, openWorldHint=true), the description discloses the cost per stage ($15 each), the separate-invoice billing model, that completed stages remain consumed if a later stage fails, and that there is no atomic bundle charge or automatic transfer. For a destructive, paid, partial-failure-prone workflow these are the exact non-obvious traits an agent needs before invoking it.

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 sentences, front-loaded with what the workflow does, then the fixed sequence, then billing semantics — no filler. Slightly dense with internal engine names and inline pricing, but every clause carries 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?

Given five nested parameters, no output schema, and a destructive billed workflow, the description covers sequence, cost, and partial-failure behavior well. It does not describe what the caller receives at the end (e.g. a classification CSV plus an exceptions report) or flag the mandatory external-processing consent gate, which are the remaining gaps.

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

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

Schema coverage is 60%, so the schema already documents most nested fields; the description reinforces the stage grouping (classification inputs vs exceptions inputs) and the notion of one invoice per stage, which implicitly explains paymentInvoiceIds. It adds nothing about maxChargeUsd, idempotencyKey, or consentExternalProcessing beyond what the schema text already says, leaving it at 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 multi-stage verb chain (classify → verify row preservation → compare against approved suppliers/contracts/POs) and names the exact underlying paid engines (xspend-taxonomy, xmaverick-detector). It is trivially distinguishable from sibling workflows like renewal_to_negotiation or rfp_to_bid_review because the stages and inputs are enumerated.

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 fixed execution order ('classification → exceptions') and clarifies that the two paid stages are not bundled, so an agent knows this is the orchestrating entry point rather than two separate calls. What's missing is an explicit exclusion such as 'do not call xspend-taxonomy directly if you intend to run the full compliance pass', 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?

Substantially exceeds the annotations by disclosing partial-failure and billing semantics: separate invoices per stage, completed stages stay consumed if a later stage fails, and no atomic bundle charge or automatic transfer. Combined with the destructiveHint=true, this tells the agent exactly what a mid-workflow failure costs. It also surfaces a mandatory consent gate, which annotations do 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?

The effort is front-loaded: the purpose comes first, then the sequence and cost, then the failure and billing constraints. It is dense but almost entirely earned. The a -> b ($15) notation is compact, but the $15 is repeated before it pays off, making it less readable than the prose around it.

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 5 parameters, nested objects and no output schema, the description covers sequencing, cost, consent and partial failure well. The main gaps are that it does not say what each stage returns or how a partially completed run's results are surfaced to the caller, which matters for a destructive, charged, multi-stage 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?

At 60% schema coverage, the description adds real meaning: it explains that the risk-stage output serves as negotiation context, which maps to the negotiation stage's knowledgeContext parameter and clarifies a non-obvious data flow. The per-stage invoice wording also clarifies paymentInvoiceIds. It does not address maxChargeUsd or idempotencyKey, though the schema largely covers those.

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 two-stage operation — risk review of buyer-supplied supplier evidence, then negotiation prep using the review as context — with concrete stage identifiers (supplier-risk, negotiation). It is far more than a restatement of the title. It does not differentiate itself from the other *_to_negotiation workflow siblings (knowledge, meeting, renewal), so differentiating from the family relies on the agent's inference from the input evidence type.

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 states a fixed sequence and a clear context for use: buyer-supplied supplier evidence with risk/freshness gaps feeds a negotiation prep. It also makes the per-stage cost explicit ($15 each), which is exactly the information needed to choose. Missing are the exclusions: nothing says when to pick knowledge_to_negotiation or meeting_to_negotiation instead.

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 destructiveHint=true and openWorldHint=true, but the description says nothing about what is written or destroyed, that sources are sent to an external inference provider requiring consentExternalProcessing, or that a run ID and idempotency key are involved. For a tool flagged destructive and open-world with no output schema, this omits the behavioral facts an agent most 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?

Two tight sentences, front-loaded with the comparison and followed by the trace targets. 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?

The enumerated artifact types partially compensate for the missing output schema by signaling what comes back, and the nested inputs are self-described in the schema. However, with a destructive, open-world, externally-processing tool, the description should at minimum surface the consent/processing model and the role of prior-run reuse.

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% and the description only echoes the rfp/transcript inputs while "exact source quotes" loosely implies quote-level grounding. It adds nothing about sourceFields, sourceRunIds (reusing prior agent runs), consentExternalProcessing, or idempotencyKey, which are the parameters most likely to be misused.

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?

Uses specific verbs (compare, trace) on a clearly named resource pair (transcript vs. RFP requirements), and the four enumerated artifact types (commitments, contradictions, gaps, follow-up questions) make the output shape concrete. It does not name or distinguish itself from plausible siblings like xscore-bid-evaluation or xrfp-drafter, so an agent must infer the boundary.

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?

"Compare what was said with RFP requirements" implies the precondition of having both a transcript and an RFP, but there is no explicit statement of when to use this versus bid scoring, RFP drafting, or the rfp_to_bid_review workflow. No exclusions or alternatives are given, leaving routing 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 disclose that the operation is destructive, open-world, non-read-only, and idempotent. The description adds useful scope by saying it builds an evidence-based review and flags stale or missing data, but it does not explain destructive effects, external processing consent, or payment requirements beyond what structured fields provide.

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

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

The description is two tightly written sentences with no filler. The core purpose and the data-quality flag are front-loaded and easy to parse.

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 complex nested-input, destructive, open-world service with no output schema, the description is somewhat thin. It communicates the review scope and stale/missing-data behavior, but it does not explain output expectations, source reuse via sourceFields/sourceRunIds, or how this fits into the supplier-risk-to-negotiation workflow.

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

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

Schema description coverage is moderate at 67%, with useful descriptions for context, documents, constraints, idempotencyKey, paymentInvoiceId, and consent. The description adds no parameter-level guidance for sourceFields or sourceRunIds, so it does not compensate for those remaining gaps.

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

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

The description uses a specific verb and resource: 'Build an evidence-based supplier review' covering named risk domains. It is clearly a supplier-risk service, but it does not explicitly distinguish itself from siblings such as xrisk-monitor, xvendorbench, or xesg-scoring.

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 states what the tool produces but gives no explicit when-to-use guidance, exclusions, prerequisites, or alternatives. An agent must infer usage from the tool name and sibling list rather than from 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?

Annotations already flag destructiveHint=true, openWorldHint=true, and idempotentHint=true, so the safety bar is lower, but the description adds nothing about what external processing occurs, what the required consent flag authorizes, that this is a paid/consuming inference call, or what side effects 'destructive' refers to. For a destructive, open-world tool nothing beyond topic keywords is disclosed.

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

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

The single sentence is short and front-loads the domain, so there is no waste, but its brevity reflects under-specification rather than tight writing — it spends its one clause enumerating topics instead of stating purpose or 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?

For a complex tool with a nested 4-field inputs object, 6 parameters, consent gating, source-reuse options, and no output schema, one topic sentence is far from sufficient. An agent cannot tell what the return value looks like, what evidence is required, or what 'destructive' implies here.

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%, and the description contributes zero parameter guidance. Notably the non-obvious parameters — sourceFields/sourceRunIds (reusing output from prior runs) and consentExternalProcessing — are unexplained in the description and only partially documented in the schema, which is a meaningful gap for an agent trying to construct a valid 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 lists a range of telecom comparison topics (carrier options, SLAs, roaming, switching cost), which does convey the subject domain of the agent. However, the verb 'Compare' is ambiguous about what the tool actually produces (a report? a scored recommendation?), and nothing in the sentence distinguishes it from category siblings like it-hardware, it-software, or contracts beyond the noun 'telecom'.

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 indication of when to call this tool versus the many siblings (negotiation, contracts, procurement_workflow__renewal_to_negotiation, xrenew-radar), nor any prerequisite context. The agent is left to infer that 'telecom category work' is the trigger.

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 destructiveHint=true, openWorldHint=true and readOnlyHint=false, yet the description's sole verb, "Model", reads as harmless analysis. Nothing warns that data leaves the boundary (the schema requires consentExternalProcessing) or that a payment invoice (paymentInvoiceId) may be involved — that is precisely the context the annotations cannot convey in prose and the agent needs before invoking.

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 clause, front-loaded with the verb and the concrete artefacts produced, with zero filler. The problem is coverage, not bloat — every word present 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?

For a tool with a nested six-field input object, required explicit external-processing consent, an idempotency key and a destructive annotation, one sentence is far short. With no output schema, the description also owes the agent some notion of what comes back (summary, financial model, supplier-pushback findings).

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 67% and the schema already documents apData's CSV shape, dpoTarget examples and constraints guidance, so the description need only fill residual gaps. It fills none: no mention of dpoTarget formats, costOfCapitalPercent, the optional dynamicDiscount hurdle rate, or how sourceRunIds/sourceFields chain prior runs.

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 ("Model") plus three concrete outputs — payment-term changes, working-capital impact, supplier pushback — grounded in a named input (AP data). It is clearly a modelling/analysis tool rather than a document fetcher, but it never differentiates itself from near-neighbours like xnegotiate-coach or xspend-taxonomy, so the agent must guess on that axis.

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, when-not-to-use, or named alternative anywhere in the sentence. Nothing tells the agent whether this is the right tool for a supplier-negotiation question versus a spend-taxonomy or negotiation-coaching question in the sibling list.

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

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

Annotations declare destructiveHint=true, openWorldHint=true and idempotentHint=true, but the description says nothing about what is persisted or destroyed, that sources are sent to an external inference provider, or that payment may be required — all of which the schema hints at but never explains behaviorally. The 'find' framing actively understates the destructive/open-world profile without resolving it.

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 front-loaded sentence with no filler, naming outcome and deliverable early. It is efficient, though the terseness is part of why behavior and parameters go unexplained.

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?

A complex, nested-schema, open-world, destructive-flagged tool with no output schema and no explanation of what a report contains, how scope controls output depth, or how sourceRunIds/payment paths work. Too much is left to the schema for an agent to invoke 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 coverage is only 67% across 6 parameters plus a nested inputs object, and the description adds no meaning to scope, playbook, riskAppetite, lessons, sourceRunIds, or the consentExternalProcessing gate. Critically, the mandatory external-processing authorization and idempotencyKey conventions are left entirely to schema reading.

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: clause-level risk scoring against a buying playbook, plus the produced artifact (proposed redlines). An agent can roughly tell it apart from the summariser/ESG/maverick siblings, though it never explicitly names or excludes them.

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

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

Gives no when-to-use, when-not-to-use, or prerequisite conditions beyond the passing phrase 'for legal review'. Nothing tells the agent how this differs from xcontracts-summariser, xnegotiate-coach, or xmaverick-detector when reviewing the same contract.

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 destructiveHint=true, openWorldHint=true and readOnlyHint=false, but the description presents the operation as a benign summarisation and says nothing about side effects, external processing, consent requirements or idempotency. The description does not directly contradict the annotations, but it omits the behavioral context an agent needs for a potentially destructive, externally processing job.

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

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

The description is a single, front-loaded sentence with no wasted wording. It is appropriately sized as a purpose statement, though its brevity contributes to the missing usage and behavioral 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?

The tool has six parameters, a nested input object, no output schema, and destructive/open-world annotations. A one-sentence description is not complete enough to explain when to use it, what happens to the contract data, or how the consent and idempotency requirements work.

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 67% and the schema already documents the main input fields, but the description adds no meaning about inputs, sourceFields, sourceRunIds, consentExternalProcessing or paymentInvoiceId. For a nested six-parameter tool, the description does not compensate for the remaining schema gaps.

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: turning a supplier contract into a summary covering obligations, service levels, liability and exit terms. It is clear what the tool produces, but it does not differentiate itself from related siblings such as xclause-risk-scoring or contracts.

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 explicit when-to-use guidance, no exclusions, and no named alternatives. An agent can infer that it applies when summarising a supplier contract, but nothing tells it when to choose this instead of xclause-risk-scoring, xnegotiate-coach or other contract-adjacent 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 declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, yet the description never mentions that this is a mutating operation, what it writes or destroys, or what permissions/consent it needs. It also omits that supplier data and prior-agent context are transmitted to an external inference provider (the consentExternalProcessing parameter is the only clue), and says nothing about the payment/invoice path.

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?

It is a single front-loaded sentence with no filler, which is structurally sound, but the brevity is under-specification rather than economy given the tool's complexity. Nothing about the input contract or the write behavior is front-loaded because nothing is said at all.

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?

A destructive, open-world, six-parameter tool with a required nested input object, a mandatory consent flag and no output schema needs far more description than one clause. Critical facts an agent must know before calling — that it mutates state, that external processing requires consent, that an idempotency key is required — are absent from the description.

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 67% schema coverage the baseline would be 3, but the description adds zero meaning beyond the schema for any of the six parameters. It does not mention the mandatory framework choice (CSRD/GRI/SASB), the vendor-master CSV shape, the 75,000-character combined limit, idempotencyKey semantics, or sourceRunIds/sourceFields chaining to prior runs.

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 verb-plus-resource ("Assess ... supplier ESG evidence, disclosures and certifications") is identifiable and the trailing clause hints at gap reporting, so an agent can tell this is an ESG assessment tool rather than risk scoring or bid scoring. But the actual deliverable — a score? a rating? a gap report? — is never stated, and the name/title promise "scoring" that the description only implies.

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 prerequisites, and no routing to or away from any of the many siblings (supplier-risk, xclause-risk-scoring, xscore-bid-evaluation, xvendorbench). An agent must infer the selection criteria entirely from the tool 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?

Annotations already declare destructive, open-world, and idempotent behavior, but the description does not explain what is destructive, that sources are sent to an external inference provider, or that consent and payment may be required. It adds little beyond restating that a brief is created.

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

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

A single front-loaded sentence with no wasted wording. It is concise, though almost too terse for a tool with nested inputs and multiple required operational parameters.

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 complex, destructive, external-processing tool with no output schema, the description omits critical context: consent requirements, payment flow, idempotency behavior, evidence validation constraints, and what the resulting brief contains. It is not complete enough for safe 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?

The description maps loosely to category and datedEvidence, while the schema already documents most top-level and nested fields. It does not clarify sourceFields, sourceRunIds, or the operational implications of consentExternalProcessing and paymentInvoiceId, so it only partially compensates for the remaining coverage gaps.

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 category or commodity brief from dated market evidence. That is clear, but it does not distinguish this tool from adjacent sibling brief/risk/monitor 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?

Only implies usage by saying the brief is created from evidence the caller provides. It gives no when-to-use guidance, no exclusions, and no alternatives among the many sibling procurement and market 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 disclose that the tool is not read-only, is destructive, open-world, and idempotent. The description adds no context about what is destructive, why external processing consent is required, or what side effects or costs may occur, so it does little beyond 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?

The description is a single front-loaded sentence with no wasted words. It is concise, though for a complex multi-parameter tool it could benefit from slightly more structure or a compact usage hint.

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 has six parameters, a nested input object, no output schema, and destructive/open-world annotations, yet the description does not cover output shape, external-processing consent, idempotency behavior, or validation limits. It is insufficiently complete for an agent to understand the full contract from prose 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 coverage is 67%, and the description does not explain any parameter meaning beyond a vague mapping to 'supplier profiles' and 'requirements'. Important parameters such as sourceFields and sourceRunIds remain undocumented in both the description and schema, leaving gaps for an agent invoking the tool.

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

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

The description states a specific verb ('Compare') and resources ('supplied supplier profiles' against 'requirements') plus the output ('a reasoned shortlist'). It is clear what the tool does, but it does not explicitly differentiate itself from nearby procurement sibling tools such as xvendorbench or supplier-risk.

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 phrasing implies a supplier-shortlisting scenario, but it gives no explicit when-to-use guidance, prerequisites, or alternatives. An agent must infer that this tool is for shortlist generation rather than vendor benchmarking, risk review, or bid evaluation.

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 destructiveHint=true and openWorldHint=true, yet the description says nothing about what is mutated or overwritten, that data is sent to an external inference provider, or that results may be provisional. For a destructive, open-world tool the description should carry this context explicitly; it does not. The only hints live in the schema, not the description.

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

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

A single front-loaded sentence with no filler. Efficient, though its brevity contributes to the gaps elsewhere rather than reflecting deliberate economy.

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 high-complexity tool with nested inputs, a 75k character limit, consent gating, idempotency keys, prior-run sourcing and destructive semantics — and no output schema to explain returns. The description covers none of it, leaving an agent without enough to call it safely or correctly.

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

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

Schema coverage is 67%, and the description contributes zero parameter meaning. Two parameters (sourceFields, sourceRunIds) have no schema descriptions at all and are completely unexplained — their role in pulling prior-agent context is invisible unless the agent reads the enum values. Baseline can't be raised because the description adds nothing beyond structured fields.

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

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

States a specific verb (Find) and resource (spend data) plus three concrete detection targets: off-contract purchases, unapproved suppliers, split orders. An agent can grasp the deliverable immediately. It does not differentiate itself from siblings like xspend-taxonomy or xscore-bid-evaluation, which keeps it from a 5.

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

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

No when-to-use guidance, no prerequisites (e.g. that approvalPolicy defaults stay provisional, or that consentExternalProcessing is mandatory), and no named alternatives among the many sibling spend/compliance tools. The agent must infer placement in a workflow from the name alone.

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 destructiveHint=true, openWorldHint=true and idempotentHint=true, yet the description says nothing about cost, external inference processing, or the mandatory consent gate — the `consentExternalProcessing` const-true parameter implies data leaves the boundary, which an agent must disclose before invoking. It also omits that this is a paid service requiring an idempotency key, a material fact for a mutation-shaped call. No contradiction, but the description adds essentially no behavioral context beyond the annotations.

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

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

A single front-loaded sentence with no filler, which is structurally clean. But the brevity comes at the cost of under-specification rather than efficiency — the whole definition is 12 words for a six-parameter, destructive, externally-processed tool.

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

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

Given nested required inputs, a consent flag, idempotency key, source-run chaining, no output schema and destructive annotations, the description is far too thin. It says nothing about what the tool returns, that it consumes prior run outputs, or that invocation has cost and data-residency implications.

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% and the description supplies zero parameter guidance — no mention of `persona` selection, BATNA discipline, deadline format, `sourceRunIds`/`sourceFields` result chaining, or the 75,000-character combined limit. For a nested schema with a required object plus external-processing consent, that leaves the agent to infer call shape entirely from the schema.

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

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

The description names two concrete actions (prepare strategy, rehearse objections) and a specific resource domain (supplier negotiation), so an agent can tell it produces negotiation prep rather than contract analysis. It stops short of distinguishing itself from the sibling `negotiation` tool or the `procurement_workflow__*_to_negotiation` family, and never states what artifact comes back.

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?

"Before the meeting" is the only usage cue, implying a pre-meeting timing window, but there is no explicit when-to-use versus `negotiation`, `xclause-risk-scoring`, or the meeting-to-negotiation workflow. No prerequisites, no exclusions, no statement of what a caller should bring versus what the tool generates.

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, destructiveHint=true, openWorldHint=true and idempotentHint=true, but the description's framing ("Find...") reads like a harmless lookup and discloses none of the write/destructive character. It is also silent on the required consentExternalProcessing authorization for sending contract data to an external inference provider and on the paymentInvoiceId path — both material preconditions for calling it.

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, verb-first, with the outputs front-loaded and no filler. It is efficient, though its brevity is arguably under-specification rather than disciplined concision for a tool this complex.

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 six parameters, a nested inputs object, a hard consent const, a payment path, destructive semantics, and no output schema, one sentence cannot cover what the agent needs. Nothing tells the caller what it gets back (findings? a ranked renewal table?) or what the side effects are.

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 most parameters are documented in the schema itself (lookaheadDays, currentDate, contractIndex formats, idempotencyKey pattern). The description only tangentially adds meaning by saying the contracts are ones "you supply," loosely pointing at inputs.contractIndex, so 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?

Uses a specific verb ("Find") with three concrete outputs — upcoming renewals, notice deadlines, price changes — over a stated scope ("the contracts you supply"). That is well beyond a tautology. It stops short of 5 because it never distinguishes itself from adjacent siblings such as procurement_workflow__renewal_to_negotiation, which an agent could easily confuse with this.

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 explicit when-to-use or when-not-to-use guidance, and no alternative tool is named. The only usable signal is the phrase "contracts you supply," which implicitly tells the agent it must bring its own contract data, but nothing routes the agent between this and the renewal/negotiation siblings.

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 destructiveHint=true, openWorldHint=true and idempotentHint=true, so this tool sends data externally and is flagged destructive. The description says nothing about external processing consent, what artifacts are created or overwritten, or the payment/invoice path that the schema implies. With such a consequential operation, the description leaves the agent uninformed.

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

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

A single, front-loaded sentence with no wasted words. However, it is under-specified rather than appropriately concise for a destructive, open-world operation with nested inputs.

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, six parameters including a nested inputs object, external data transmission and a destructive flag — this is a high-consequence tool that warrants more than one sentence. Missing: what the RFI output looks like, how prior-agent sources are used, and how idempotency/subsequent calls behave.

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 67% and the nested 'inputs' object is well annotated, so the schema carries most of the burden. The description adds no parameter guidance, and required fields like consentExternalProcessing, idempotencyKey and sourceFields semantics are left entirely to the schema. Baseline 3 applies.

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

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

Clear verb+resource ('Create a focused RFI') with a stated goal ('qualify suppliers'). The clause 'before starting an RFP' implicitly contrasts with the sibling xrfp-drafter, though the distinction is only implied rather than 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 timing hint 'before starting an RFP' gives implied usage context, but there is no explicit when-not-to-use, no naming of alternatives such as xrfp-drafter, and no mention of prerequisites like source runs or consent.

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 destructiveHint=true, openWorldHint=true and idempotentHint=true, but the description discloses none of this. Most importantly, it never warns that inputs and prior-agent context are sent to an external inference provider (the required consentExternalProcessing flag) or that a confirmed payment invoice may be required — material facts an agent cannot infer from a single marketing sentence.

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 front-loaded sentence with zero waste, but it is sized for a landing page rather than a tool definition. Conciseness here comes at the cost of omitting anything operationally relevant.

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 complex tool: six parameters, a nested required inputs object, a consent gate for external processing, and a destructive annotation — with no output schema to lean on. A single sentence is far too thin to prepare an agent for those obligations, though the relatively rich schema keeps this from being a total 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 67% and the nested inputs object is well documented field-by-field, so the schema carries most of the load. The description itself adds no parameter meaning whatsoever — nothing about sourceRunIds/sourceFields pulling prior artifacts or about how idempotencyKey behaves on retries.

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 verb and artifact: turning a category brief into an RFP draft with requirements and weighted evaluation criteria. That is enough to tell it apart from evaluation/scoring tools, but it never mentions the sibling xrfi-drafter or the rfp_to_bid_review workflow, so the RFP-vs-RFI boundary is left to 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?

There is no when-to-use guidance, no prerequisite (e.g. needing prior run IDs), and no mention of alternatives such as xrfi-drafter or the negotiation workflows. The agent must guess when this is the right entry point versus drafting an RFI or going straight to bid review.

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, openWorldHint=true, and idempotentHint=true, so the description's only added value is 'using your supplied evidence' and 'on-demand review'. It says nothing about what the destructive operation touches, that external inference processing requires consent, or that a paid invoice may be needed — all material for a mutation-class 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 short sentences with no filler and the purpose is front-loaded, so nothing is wasted. However, for a tool with three modes, a nested object, consent, and idempotency, this level of terseness reads as under-specification rather than disciplined conciseness.

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 complex — 6 top-level params, a 20-property nested input object, three operating modes, external processing consent, and payment — and there is no output schema to fall back on. The description covers none of the mode-dependent behavior, cost/consent prerequisites, or result shape.

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% and the nested 'inputs' object documents CSV formats and date formats reasonably well, so the schema carries most of the load. The description adds no parameter meaning at all — notably it never explains mode selection (monitoring vs scorecard vs postmortem) or which fields become required per mode, leaving a real 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 a specific verb and resource: assess supplier health, performance, or an incident, from caller-supplied evidence. It is clear what the tool does, but it never distinguishes itself from close siblings such as supplier-risk, xvendorbench, or xesg-scoring, and it omits the 'scorecard' mode that the schema exposes.

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?

'Each request is an on-demand review' hints at invocation style but gives no when-to-use vs when-not-to-use guidance. With ~20 sibling tools in the procurement/risk family, an agent has no way to know whether this or supplier-risk / xesg-scoring / xclause-risk-scoring is the right 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 destructiveHint=true, openWorldHint=true, and idempotentHint=true, so the safety profile is covered. The description adds no behavioral context — it doesn't mention that sources and prior-agent context are sent to an external inference provider (a consent gate exists in the schema) or that the operation is destructive/non-free. It does not contradict annotations, but contributes little beyond them.

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 well-formed sentence with no waste, but it is under-specified rather than concise — for a 6-param, nested, destructive, open-world tool one sentence leaves too much unstated.

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 a nested object, external-processing consent requirement, destructive/open-world annotations, and no output schema, the description is too thin. It doesn't explain return format, the external-send implications, or the two distinct modes (deal vs QBR board update) that the schema hints at.

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 67% with a nested inputs object, and the description adds nothing about the parameters (mode, currency, savingsType, fxEvidence, consent gate). It fails to compensate for the undocumented third of parameters or clarify how dealRecords/qbrInputs map to the two output types.

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 output (turn deal results/performance data into a finance-reviewable savings report or board update), so the agent understands what it produces. It doesn't differentiate from the many sibling procurement/analysis tools, but the resource and deliverable are clear.

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

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

No when-to-use vs alternatives guidance; nothing says when to pick this over xcash-working-capital, finance-business-case, or the report-producing siblings. The only implied context is 'when you need a finance-reviewable savings or board deliverable', with 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?

Annotations already disclose readOnlyHint=false, destructiveHint=true, openWorldHint=true, and idempotentHint=true, but the description adds nothing about them — no word on what is destroyed, that inputs are sent to an external inference provider requiring explicit consent, or that runs are keyed/idempotent. "Evidence and gaps to review" is the only added context and it is thin for a destructive, open-world 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?

A single front-loaded sentence with no filler, and the core operation leads. It is efficient but borders on under-specification given the tool's structural complexity.

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 nested six-parameter tool with a required consent flag, idempotency key, and destructive/open-world annotations, the one-liner leaves major questions unanswered: how runs are chained via sourceRunIds, how the combined 75,000-character and 45,000-per-field limits affect input size, and what a result contains. With no output schema, the description's "evidence and gaps" hint partially covers the return shape but not enough.

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%, below the high-coverage threshold, so the description should carry weight it does not: it never mentions the rubric/weights requirement, the supplier responses, disqualifiers, or source run chaining. The two parameters with no schema description at all, sourceFields and sourceRunIds, go entirely unexplained 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 and resource — "Compare supplier bids" — plus the method (weighted scoring matrix) and outputs (evidence and gaps). It is clear enough to distinguish from drafting tools like xrfp-drafter, though it never names the nearest sibling such as xvendorbench or xmatch-supplier-shortlist to draw the boundary 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?

No when-to-use guidance, no prerequisites, and no alternatives named despite a crowded sibling set containing xvendorbench, xmatch-supplier-shortlist, and xclause-risk-scoring. The agent must infer from the tool name alone whether this or a sibling is appropriate.

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 disclose destructiveHint=true, openWorldHint=true, and idempotentHint=true, but the description adds nothing about what is destroyed, external processing consent, required permissions, or rate limits. 'Uncertain entries flagged' is output behavior, not operational transparency, so the description does little beyond the safety profile already provided.

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

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

The description is a single front-loaded sentence with no wasted words. It immediately states the action, input, output, and a notable output trait.

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 complex tool with a nested inputs object, required external-processing consent, destructive/open-world annotations, and no output schema. The one-sentence description does not explain consent requirements, data handling, what 'four-level taxonomy' entails, or what the response contains, leaving critical context missing.

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

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

Schema description coverage is moderate at 67%, with sourceFields and sourceRunIds lacking descriptions. The tool description provides no parameter-level meaning to compensate, so it adds nothing beyond what the schema already documents for the required inputs.

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

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

The description states a specific verb (Classify) and resource (GL or AP export) and names the output (four-level spend taxonomy with uncertain entries flagged). It is clear enough to distinguish from most sibling tools, though it does not explicitly differentiate itself from related procurement workflow 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?

The description implies usage by saying 'Classify your GL or AP export', but it gives no explicit when-to-use guidance, no prerequisites, no exclusions, and no alternatives among the many sibling procurement tools. It leaves selection entirely to inference.

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

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

Annotations already flag destructiveHint=true, openWorldHint=true and idempotentHint=true, yet the description says nothing about what is destroyed or sent externally. It omits the explicit external-processing consent requirement, the idempotency key, and the payment/invoice path — all significant for a tool the annotations mark as destructive.

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 tight sentence with the key concept front-loaded and no filler. It is efficient, though arguably too thin for a tool with six parameters, nested objects, and destructive semantics.

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 complex tool with nested inputs, a mandatory external-processing consent flag, and destructive annotations, one sentence is inadequate. Nothing is said about what the benchmark returns, how sources are handled outside the system, or what the caller must prepare beyond a shortlist.

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% and the schema itself documents the vendors, constraints, datedEvidence CSV format, and consent fields in detail. The description adds only the framing 'against your constraints,' contributing no syntax, format, or validation detail beyond what the schema already provides.

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

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

States a specific verb (compare) and resource (a vendor shortlist) plus the output shape (source-backed strengths, gaps, tradeoffs). It is distinguishable from siblings like xmatch-supplier-shortlist or xscore-bid-evaluation in spirit, but never names them or explicitly delineates the boundary.

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 when-to-use guidance, no prerequisites, and no alternatives among the many sibling procurement tools. An agent must infer from the name alone whether this replaces or complements xmatch-supplier-shortlist, xscore-bid-evaluation, or supplier-risk.

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