Last Price

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

With annotations already declaring destructiveHint=true and openWorldHint=true, the description adds useful context that behavior and side effects are determined by the invoked tool, not by call_tool itself. It also discloses that unlisted tools can be invoked, though it does not elaborate on auth, rate limits, or failure behavior.

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

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

Three short sentences, front-loaded with the core action and then the required discovery workflow. Every sentence carries useful information without repetition.

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

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

For a complex open-world meta-tool with rich annotations and an output schema, the description covers the key workflow and delegated behavior. It is mostly complete, though it could say more about invalid tool names or validation errors.

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

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

Schema coverage is 100%, so the schema already documents name and arguments. The description adds meaningful nuance by saying the name may refer to a tool this connection does not list, which is not captured by 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 gives a specific verb and resource: it runs any Last Price tool by name, including tools not listed by the connection. It also clearly distinguishes this executor from discovery via search_tools.

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

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

It explicitly tells the agent to use search_tools first to find the tool name and arguments, which is strong usage guidance. It does not state when not to use this tool or name other alternatives beyond search_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?

Beyond the annotations, it discloses that nothing is charged until payment is sent, that missing inputs return a named error, and that a result with valid_until is time-bounded. This adds real behavioral context for a non-read-only, open-world tool, though it doesn't discuss auth or rate limits.

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

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

It is front-loaded with purpose and return shape before moving to input modes, and each sentence addresses a distinct concern (inputs, competitor pricing, payment, validity). Slightly dense, but no filler given the tool's breadth.

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

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

With an output schema handling return values and 100% param coverage, the description only needs to convey the operational modes, and it does: cost-plus vs relative pricing, competitive offers, payment flow, and quote expiry. Nothing essential to a correct call 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 schema already documents all 26 parameters in depth. The description restates the core currency/unit_cost/current_price and metadata patterns but adds little semantics the schema doesn't already carry, making the baseline 3 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 opens with a specific verb+resource ('Compute a price') and immediately specifies the return shape: price, producing function, metered cost, and per-stage trace. It is clearly a computation tool, not a verification or receipt tool, though it never explicitly contrasts itself with siblings like verify_price or get_receipt.

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

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

It gives concrete conditional guidance: send currency plus unit_cost or current_price, use metadata for competitor offers, omit payment to read the cost, and set no_explore to suppress per-call variation. It stops short of explicitly stating when to prefer a sibling tool over this one.

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

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

Goes well beyond the read-only/idempotent annotations by disclosing required credential scopes (price compute or billing read), the 403 refusal for unclaimed sandbox keys, and the fact that receipts are materialized lazily rather than generated per call. These are the exact operational facts 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?

Front-loaded with the core action and the id, then layers in laziness, export alternatives, and auth constraints. The enumerated receipt contents are slightly redundant given the output schema, but the overall density and ordering are efficient.

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

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

With annotations, a full input schema, and an output schema already present, the description fills the remaining gaps: credential requirements, workspace-claim failure mode, lazy creation semantics, and the HTTP alternative for CSV/HTML. Nothing material is missing for a correct call.

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

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

Schema coverage is 100% for the single parameter, so the schema already defines usage_event_id. The description still adds meaning by tying that id to both list_usage_events and report_outcome, clarifying where to obtain a valid value.

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

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

States a specific verb (Get) and resource (the receipt for a priced call), keys it to a usage event id, and enumerates what the receipt contains. It distinguishes itself from siblings by naming list_usage_events as the id source and report_outcome as another consumer of that id.

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

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

Explains that receipts are created only on request, references the id-producing sibling, and points to GET /api/receipts/{id} when CSV or HTML is needed. It does not explicitly rule out alternatives like compute_price or verify_price, but the context for when to call it is clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful scope by noting results are limited to the authenticated tenant, but does not mention ordering, pagination, or whether inactive functions are included. With annotations doing the heavy lifting, this is adequate but not rich.

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. Every phrase ("List", "pricing functions", "registered", "authenticated tenant") contributes to correct invocation.

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 read-only listing tool with both annotations and an output schema, the description covers what is needed to call it correctly. It could optionally connect the output to siblings like call_tool, but that is not required for correct invocation.

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

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

The tool takes zero parameters, so parameter semantics are inherently simple and the baseline is 4. The description correctly does not invent parameter details that do not exist.

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

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

The description states a specific verb ("List") and resource ("pricing functions") with a clear scope ("registered for the authenticated tenant"). An agent can distinguish this listing operation from siblings like compute_price, verify_price, and call_tool, which act on pricing functions rather than enumerate 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?

The description implies the tool is for discovering available pricing functions, but it does not explicitly say when to use it versus alternatives such as search_tools or pricing_conversation. No exclusions or prerequisites are given, so usage must be inferred.

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 value beyond the annotations: prepare is free and non-computing, compute hits an authenticated pricing API requiring a pre-configured credential, and there are safety rules ("never invent answers", "a continuation is not authorization"). This complements the readOnlyHint=false / idempotentHint=false flags rather than contradicting 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?

Four tight sentences, front-loaded with the prepare-first workflow before the compute path and the safety caveats. Minor deduction for introducing "continuation.request" as if already known, which makes the middle sentence require a second read.

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

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

An output schema exists, so return values need not be explained, and the prepare→answers→compute loop is broadly covered. Gaps remain: no explanation of what a continuation object is, no error behavior, and no differentiation from the compute_price sibling in a set where overlap is likely.

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

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

Schema coverage is 100%, so the baseline is 3; the description goes further by explaining that request is a partial PricingComputeRequest to reuse via continuation.request and that answers are the responses to the questions the previous call returned. That workflow semantics is not derivable from the schema alone.

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

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

The opening sentence gives a concrete verb and resource ("Ask Last Price what pricing inputs are missing") and the action split (prepare vs compute) is spelled out. It falls short of 5 because it never explicitly positions itself against siblings like compute_price or verify_price, so the 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?

It does describe the intended call sequence (start with request: {}, return questions, then send continuation.request and answers) and the condition for compute ("when ready"). But it gives no guidance on when to pick this tool over compute_price or verify_price, and no guidance on failure/precondition handling beyond "configure a credential first."

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 (readOnlyHint=false, destructiveHint=false, idempotentHint=false), the description discloses that the API key is shown once, that a claim link is returned, that daily limits are provided, and how credential propagation differs on hosted vs external MCP. These are important behavioral details for a setup/authentication tool.

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

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

The description is front-loaded and dense, covering creation, output, credential behavior, and parameters in a few sentences. It has some redundancy, e.g. 'no key and no human' is repeated at the end as 'needs no credential', and the name constraints duplicate 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 registration tool with no output schema, the description is complete: it explains what is created, what values are returned, how the credential is used afterward, and the parameter expectations. Nothing essential for invoking it correctly is missing.

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

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

Schema coverage is 100%, so all three parameters are already documented in the input schema. The description repeats the name length/character constraints and notes that contact_email and intended_use are optional, but adds little meaning beyond the schema.

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

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

The description states a specific verb and resource: 'creates a sandbox workspace of your own and returns its API key'. It distinguishes this from credential-requiring siblings by saying it needs 'no key and no human', and names the concrete outputs (key, daily limits, claim link).

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 explains that the tool is public and needs no credential, and that on the hosted MCP server the session continues using the new key while elsewhere the key must be sent as x-api-key. That is clear context, but it never explicitly says when to prefer this over a credential-bearing flow such as use_api_key.

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

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

Adds context the annotations cannot carry: a Last Price credential is required, a self-registered sandbox key is refused with 403 until the workspace is claimed, the hosted MCP endpoint is stateless so the id must be passed there, and rejections inside the outcome window trigger a partial refund. The one-shot 'report once' semantics also qualify the idempotentHint=false annotation.

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

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

Front-loads the action and its trigger, then stacks the credential, statelessness, refund and workspace requirements in short declarative sentences. Dense but every sentence carries an operational constraint.

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

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

An output schema exists, so return values need no explanation, yet the description still flags that the result reports any refund. Auth, workspace claim, statelessness and the accept/reject trigger are all covered for a non-read-only, non-idempotent write tool.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns above that by explaining where usage_event_id comes from ('receipt.id on the compute_price result') and what omission means ('the last price compute_price returned on this connection'). The optional evidence and quality_score parameters are left to the schema.

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

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

States a specific verb and resource ('Report whether a price from compute_price was used') and ties the event directly to the compute_price result. It never mentions verify_price or get_receipt, so the boundary against those siblings 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?

Gives a clear triggering condition ('once the buyer has accepted or turned down a price, report it') and a constraint ('Report only what actually happened'), plus when to pass vs omit usage_event_id. It stops short of naming alternatives such as verify_price or what to do if no price was ever computed.

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 readOnly/idempotent annotations, the description discloses non-obvious behavior: the search is scoped to a subset of a 300+ tool server, matches are returned with full input schemas, and an empty query degrades to a full name listing. It does not mention ranking behavior, result ordering, or any rate limits, but for a read-only lookup the important behavioral traits are surfaced.

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

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

Three sentences, front-loaded with the purpose, then scope, then the call pattern – no filler. The parenthetical list of the 300+ hidden tool categories is somewhat long but earns its place by telling the agent how much is behind this gateway.

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

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

With an output schema present, the description needn't describe return values, and it still covers what an agent must know: what the search covers, how to phrase the query, what comes back (full input schemas), and how to act on results via call_tool. Nothing needed to invoke it correctly is missing.

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

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

Schema coverage is 100%, so both fields are already documented, making 3 the baseline. The description adds real semantic value for `query` by framing it as 'a few words for the job' and by explaining the no-query case, which is a behavioral branch the schema does not convey. `limit` is left entirely to the schema, which is acceptable given its self-explanatory 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 states a specific verb and resource ('Find the ... tool for a task', 'get back the best matching tools with their full input schemas') and distinguishes itself from the sibling call_tool, which it explicitly names as the follow-up step. The scope note ('lists only the tools that reach a price; the server has over 300 more') makes the search domain concrete, though the phrase 'Last Price tool' is product jargon that takes a beat to parse.

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

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

It gives clear sequencing: pass a short query to get matches, then invoke one via call_tool or by name, and with no query it returns every tool name. That covers the main use pattern and names the alternative tool. It stops short of saying when *not* to use it (e.g., when the tool name is already known), which keeps it from a 5.

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

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

Goes well beyond the annotations: discloses that the key becomes the session's identity, that the effect is session-scoped and ends on session end/revocation/rotation, that the key is validated but never echoed, and that existing credentials take precedence. That is exactly the lifecycle and side-effect information an agent needs for a stateful auth operation with destructiveHint=false but readOnlyHint=false.

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

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

Compact and front-loaded — the precondition and the action come first, then consequences, then the security note. The first sentence is an awkward colon-spliced run-on, but no sentence is filler.

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

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

For a single required parameter with full schema coverage and no output schema, the description covers scope, duration, and credential precedence, which is what an agent needs to decide and act. It does not say what happens on an invalid or revoked key at call time, a minor gap given the schema pattern already screens format.

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 already specifies the lp_ + 40-hex pattern, so the baseline is 3. The description adds real value by telling the agent where the value comes from (a saved file or LASTPRICE_API_KEY env var the caller already holds), which the schema does not say.

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 action — authenticating the current MCP session with a Last Price API key the caller already holds — and names the concrete condition (connection was opened without one). No sibling tool in the list does anything comparable, so there is no ambiguity to resolve.

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

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

Gives both the trigger (session opened without a credential) and the exclusion (a connection that already has a credential keeps it, so this call is unnecessary). It also notes the endpoint is public and needs no other credential, removing a common precondition question.

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

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

Annotations only declare readOnly/openWorld/idempotent/destructive; the description goes well beyond them by disclosing the billing model (one verdict per payment, unknown verdicts are never charged), the expiry behavior (quote_expired on stale quotes), the conditional buyer_budget evidence and that it never affects the verdict, and the semantic difference between 'unknown' and 'fair'. The readOnlyHint=false is consistent with the disclosed fact that it can charge and records quote metadata.

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

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

Purpose and return values are front-loaded, and each subsequent clause maps to a distinct concern (judgment semantics, expiry, payment, buyer_budget). It is dense but not padded; the payment sentence stacks several nested clauses and could be split, which is the main structural cost.

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 16-parameter tool with nested objects and an output schema, the description covers the parts that structured fields cannot: the meaning of each verdict including the unknown case, when charging occurs, expiry handling, and the informational-only status of buyer_budget. Return-value detail is already carried by the output schema, so nothing material is left for the agent to guess.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns more by explaining cross-tool provenance for quote_valid_until and the wire format/endpoint for payment (payments.x402.verify_price in /.well-known/agents.json), plus the metadata.category trigger for buyer_budget. It leaves other high-value parameters such as max_price/min_price and outcome_terms entirely to the schema, so it does not fully compensate.

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 subject ('ask whether a price makes sense for its context') and immediately distinguishes itself from the price-generating sibling by the clause 'rather than what the price should be.' It also enumerates the exact return shape (verdict, band, deviation, confidence, evidence), so an agent knows precisely what it gets back and how it differs from compute_price.

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 compute_price vs. verify_price split is explicit, and the description supplies concrete routing instructions: pass quote_valid_until from the compute_price result that produced the price, and use the x402 payment path only when paid verdicts are enabled and no key is present. What's absent is a direct statement of when not to call it (e.g., when no price exists yet, use compute_price first), which is only implied by the quote_valid_until sentence.

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