Skip to main content
Glama

Last Price

by ai.last-price
OverviewDiscussionsAdmin

check_purchase

Before you pay for something, ask whether your owner's spend policy lets you pay this price to this seller. Works for any purchase, whatever wallet or checkout you pay with. Returns a decision (allow, deny or ask), a reason code and a reason. allow comes with a reservation: the amount is held against today's cap, so make the purchase, then call settle_purchase with outcome paid (and the amount paid) or failed. ask means a person approves first; once they have, send the same check again. deny means do not buy. With include_fair_price, or when the policy asks for it, the price is also judged by verify_price and its verdict and band come back with the answer. Needs a Last Price credential with price compute scope. Needs a claimed workspace: a sandbox key from self-registration is refused (403) until a person claims the workspace.

Input Schema

NameRequiredDescriptionDefault
itemNoOptional: what you are buying.
amountYesThe price you are about to pay.
intentNoOptional: what the buyer approved for this purchase, from an American Express intent, an AP2 intent mandate, or declared by you. A purchase that names another seller, costs more than max_amount (counting every purchase under the same intent_id), is in another currency or comes after expires_at is denied, whatever the policy allows. evidence (the token or mandate) is kept only as a hash and is not verified yet. Only where the workspace has intents switched on (else an error with code not_released).
pay_toNoOptional: the wallet address (bare or CAIP-10) or merchant account id the money goes to. A person's approval is then for that account only, and confirm_purchase and settle_purchase must name the same one: another is refused with code payee_changed. Only where the workspace has payee binding switched on (else an error with code not_released).
quotesNoOptional: competing offers for this purchase, yours among them. A procurement policy needs two above its two-quote threshold.
sellerYesWho you are paying: a store, domain, API or wallet name.
agent_idNoOnly with a workspace-wide key: check on behalf of this agent. An agent key always checks as itself.
categoryNoOptional: its category, when the policy limits categories.
currencyNoThree-letter ISO currency code. Defaults to USD.
agentid_tokenNoYour AgentID ID token, issued for Last Price, when your owner's policy lets only verified agents spend. Sent as the AgentID-Token header.
include_fair_priceNoAlso judge the price with verify_price and return its band.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / pay_to
      Added value: +{
+  "description": "Optional: the wallet address (bare or CAIP-10) or merchant account id the money goes to. A person's approval is then for that account only, and confirm_purchase and settle_purchase must name the same one: another is refused with code payee_changed. Only where the workspace has payee binding switched on (else an error with code not_released).",
+  "maxLength": 200,
+  "minLength": 1,
+  "type": "string"
+}
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false) only say 'this mutates state', and the description goes far beyond: it discloses the reservation hold against today's cap, the required Last Price credential with price compute scope, and the 403 refusal for unclaimed sandbox workspaces. Those auth and side-effect details are exactly the context annotations cannot convey.

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

Conciseness4/5

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

Front-loaded with the core question and the decision semantics; every sentence carries operational weight (reservation, resend-on-ask, credential scope, claimed-workspace rule). Some sentences are dense and run-on, but there is no filler.

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

Completeness5/5

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

For an 11-parameter nested-schema tool with no output schema, the description supplies the missing return contract (decision, reason code, reason, fair-price band) and the follow-up obligations after allow. Nothing an agent needs to invoke it correctly or interpret the result is absent.

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

Parameters4/5

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, but the description adds cross-tool meaning the schema cannot: include_fair_price triggers a verify_price judgment whose verdict and band come back, and the intent evidence is stored only as a hash and not yet verified. It does not re-explain seller/amount/currency, which the schema already handles well.

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

Purpose5/5

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

States a specific verb and resource ('check whether your owner's spend policy lets you pay this price to this seller') and distinguishes itself from nearby siblings by naming settle_purchase, verify_price, confirm_purchase and their roles. An agent can tell it apart from get_price_check or reconcile_purchase 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.

Usage Guidelines5/5

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

Explicitly gates timing ('Before you pay for something') and spells out the full decision workflow: allow → make the purchase then call settle_purchase with paid/failed; ask → resend after human approval; deny → do not buy. It also names the alternative path (include_fair_price routes to verify_price), leaving nothing to inference.

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

All Last Price toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources