Last Price

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

With no annotations, the description carries the full behavioral burden, and it only implies a read-only public operation. It says nothing about pagination, result size, filtering behavior, or whether authentication is required for a 'public' catalog.

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; nothing in it is redundant given the tool name.

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 and no annotations exist, so the description must carry more weight than one sentence. It does not explain what a browse result contains, how it is paginated, or how it differs from list_functions, leaving material gaps for an agent to act 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-parameter tool applies.

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

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

The description states a specific verb (browse) and resource (public marketplace catalog of pricing functions), so the agent knows exactly what the tool surfaces. However, it never distinguishes itself from the sibling list_functions, which likely offers a similar enumeration capability, leaving the choice ambiguous.

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

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

There is no guidance on when to use browse_catalog versus list_functions, compute_price, or verify_price, and no stated preconditions or exclusions. The word 'public' hints at a marketplace context but is not framed as a usage rule.

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

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

With no annotations, the description carries the full burden and does well: it enumerates the return payload (price, producing function, token metering/cost) and the trace stages (cache, route, execute, fallback, constrain, meter), and states that missing business inputs return a naming error. It omits auth, rate limits, and determinism/idempotency details.

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

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

Front-loads what it does and returns before usage, and every sentence carries information with little padding. The final two sentences are denser than ideal, mixing metadata workflow with cost-plus conditions, but nothing is wasted.

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

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

No output schema exists and the description compensates by describing the return fields and trace stages; no annotations exist and it discloses error behavior. For a 14-parameter tool this is close to complete, though the relationship to verify_price and any auth/limit constraints are unaddressed.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter workflow beyond the schema: the competitive-offer grouping (competitor_* + competitive_action, undercut requiring undercut_pct) and the cost-plus path (unit_cost with target_margin_pct, or forcing it via function_id from list_functions). This is genuine added meaning on top of an already-rich schema.

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

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

States a specific verb+resource ("Compute a price for a product/context") and names the backing system, so the agent knows exactly what it does. It cross-references the sibling list_functions for function IDs, but never distinguishes itself from verify_price or browse_catalog, so sibling differentiation is incomplete.

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 usage contexts: put competitor_price/currency/action in metadata for a competitive offer, or supply min_price/unit_cost with target_margin_pct, and notes unit_cost is the usual case when pricing a task about to run. No explicit when-not-to-use or routing to verify_price, so it stops short of full selection 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?

With no annotations, the description carries the full burden and does reasonably well: it discloses that 'saved' is false when nothing is stored, that no workspace limit then applies, and that a specific credential/scope is required. It stops short of describing return structure or edge cases beyond the empty case.

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

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

Three tight sentences, front-loaded with the core action, each contributing distinct information. The mid-sentence about 'the defaults set_price_guardrails fills in for an omitted field' is slightly clunky but still 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 zero-parameter tool with no output schema, the description covers the key return semantics ('saved' flag, no-limit case) and auth requirements. It leaves out details like what fields the guardrails contain, but overall it is sufficient to invoke and interpret.

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

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

The tool takes zero parameters, so the baseline is 4. The description adds surrounding context about how omitted fields relate to set_price_guardrails defaults, which is useful but not parameter-level documentation.

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

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

States a specific verb ('Read') and resource ('price guardrails saved for your workspace'), and the phrase 'the defaults set_price_guardrails fills in' explicitly distinguishes it from its sibling write tool. An agent can immediately tell what this returns.

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 read-vs-write relationship with set_price_guardrails is implied, but there is no explicit when-to-use or when-not statement, and no alternatives are named. Usage is inferable but not spelled out.

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

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

No annotations are provided, so the description carries the full disclosure burden. It signals a read operation via "List" and reveals the tenant-scoping/auth context, but says nothing about pagination, ordering, or result limits for a potentially unbounded collection.

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; the resource and its scope are both stated immediately. Nothing could be trimmed without losing 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?

For a trivial 0-parameter read tool with no output schema and no annotations, the description identifies the resource and the tenant scope, which is most of what an agent needs. Adding a note about result volume or pagination would close the remaining gap.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing parameter-related for the description to clarify or compensate for.

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 (List) and resource (pricing functions) plus the scope of the query (authenticated tenant). This clearly separates it from compute_price and verify_price, which act on prices rather than enumerate registrations, though it never names those siblings explicitly.

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

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

The purpose implies discovery usage (listing available functions before calling compute_price), but the description gives no explicit when-to-use guidance or conditions that would route an agent here versus browse_catalog. Usage is inferable rather than stated.

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

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

With no annotations, the description carries the full burden and does notable work: prepare is free and does not compute, compute hits an authenticated API and therefore needs a credential configured first, and it warns never to invent answers or treat a continuation as authorization. It omits error behavior, rate limits, and the exact return shape, but the safety and auth profile is unusually 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?

Dense but efficient: the workflow comes first, readiness second, safety guardrails last, with essentially no filler. The telegraphic phrasing ('Prepare is free and does not compute') is compact rather than padded.

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

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

For a nested, no-output-schema, no-annotation tool, the description covers the dialogue flow but leaves gaps: what prepare actually returns, how the continuation object is shaped, and how errors surface. Adequate to start a call, incomplete for handling the response.

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

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

Schema coverage is only 33%, so the description should compensate more than it does. It usefully clarifies that request starts empty and that answers pair with the returned questions, but it also references 'continuation.request', a field absent from the schema, which introduces ambiguity rather than resolving the nested request structure.

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 concrete two-phase purpose: elicit missing pricing inputs ('Ask Last Price what pricing inputs are missing') and then compute. The verb/resource are identifiable, but it never contrasts itself with the sibling compute_price, so an agent cannot tell from this text alone when to prefer one over the other.

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

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

It gives explicit sequencing: start with request {}, return the questions to the caller, then send continuation.request plus answers, and switch to action compute only 'when ready'. Clear calling protocol, but it names no alternatives (e.g. compute_price, verify_price) or conditions that would rule this tool out.

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

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

With no annotations, the description carries the full behavioral burden and does well: it discloses the auth requirement (Last Price credential), the outcome-pricing refund behavior (a rejection within the outcome window refunds part of the cost, reflected in the result), and the downstream learning effect. It does not cover idempotency, retry/error semantics, or whether an outcome can be amended, which are notable gaps for a write 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?

Front-loaded with the core action and the key parameter linkage, then layers in credential and refund caveats. Every sentence carries information, though the description packs several distinct concepts (feedback loop, refund behavior, auth) into a fairly dense block with no visual separation.

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 tool with no output schema and no annotations, the description covers the essential linkage to compute_price, credential needs, and refund consequences. It is close to complete, but leaves the result shape (beyond refunds), error handling, and re-reporting behavior unaddressed.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters. The description's instruction to pass receipt.id as usage_event_id largely restates the schema's own wording, adding no new syntactic or format detail beyond it. Baseline 3 applies when the schema does the heavy lifting.

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

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

The description states a specific verb and resource (report whether a price from compute_price was used) and explicitly ties this tool to the output of the compute_price sibling. An agent can distinguish it from compute_price, verify_price, and pricing_conversation without opening any schema.

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

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

It tells the agent exactly what to pass (receipt.id from the compute_price result as usage_event_id) and constrains behavior with 'Report only what actually happened.' It gives clear positive context and purpose (feeding routing and confidence), but names no explicit when-not condition or alternative tool to prefer.

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

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

No annotations are provided, so the description carries the full burden and does so well: it discloses the destructive replace-all semantics, that omitted fields silently fall back to defaults, and the required auth scope. It also distinguishes the enforcement fields (which hold every final price) from the search-band fields (which only constrain optimizer/elasticity search), a behavioral distinction not visible in 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?

Front-loaded with the action, then the field semantics, then the replace warning, then the auth requirement. Every sentence carries distinct information; nothing is redundant with the schema.

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

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

For a five-parameter mutation tool with no annotations and no output schema, the description covers the critical unknowns: replace-vs-merge behavior, default fallback, field scoping, and credential requirements. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3; the description earns an extra point by explaining the differing roles of the parameters — max_change_pct/min_margin_pct/never_below_cost bind every pricing call, while band_lower_ratio/band_upper_ratio apply only when a call sends no minimum or maximum. It does not restate defaults or units, which the schema already covers.

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 ('Save the price guardrails for your workspace') and immediately differentiates itself from the read counterpart by instructing the agent to call get_price_guardrails first. An agent can tell this apart from browse_catalog or compute_price without opening any schema.

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

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

Explicitly routes the agent: read get_price_guardrails before saving, and send every rule you want to keep because this is a full replace. It also names the credential/scope prerequisite (Last Price credential with routing write scope), which is exactly the pre-invocation guidance an agent needs.

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

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

With no annotations and no output schema, the description carries the behavioral burden and does so well: it enumerates the return fields (verdict, band, signed deviation, confidence, evidence) and clarifies the non-obvious edge case that 'unknown' is not equivalent to 'fair'. It stops short of stating whether the call is purely read-only or whether it has side effects, which is the main remaining gap for an unannotated 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?

Three tightly packed sentences: purpose first, return contract second, edge-case semantics last. No filler, and the important scoping clause is front-loaded.

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

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

The description covers purpose, the full result contract, and the ambiguous 'unknown' outcome, which is sufficient for a 10-parameter tool with full schema coverage and no output schema. It could be more complete by naming the sibling to defer to for price computation, but nothing needed to invoke the tool correctly is missing.

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

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

Schema coverage is 100% and each parameter (including the binding min_price/max_price semantics and the optional current_price note) is already documented in the schema. The description adds no per-parameter meaning beyond what the schema provides, so the 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?

The description gives a specific verb and subject ('ask whether a price makes sense for its context') and immediately scopes the tool by contrast with the sibling that answers 'what the price should be' (i.e. compute_price). An agent can distinguish this from compute_price and browse_catalog without opening a schema.

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

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

It clearly states the evaluation context (judging an existing/proposed price) and implicitly routes the 'what should it be' case elsewhere, giving an agent a usable when-to-use signal. It stops short of naming the alternative tool explicitly or listing exclusions/limitations, so it is clear context rather than full routing guidance.

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