Last Price

open_spend_session

Before a run of small paid calls to one seller (a stream of x402 calls at a cent each, say), open one budget for the run instead of checking every call. Your owner's spend policy judges the session like a purchase of max_amount: allow holds that maximum against today's cap and returns reservation.id, the session id; ask means a person approves the budget first, then send the same request again; deny means do not start. Then call draw_session_spend right before paying each call, and close_spend_session when done, which gives back what you did not draw. A session left open gives its remainder back when it expires. Only where the workspace has sessions switched on (else an error with code not_released: use check_purchase per purchase). 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

Name	Required	Description
`item`	No	Optional: what the calls buy.
`intent`	No	Optional: 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_to`	No	Optional: the wallet address (bare or CAIP-10) or merchant account id the calls pay. Every draw_session_spend must then 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).
`seller`	Yes	Who the calls pay: an API, domain or wallet name.
`agent_id`	No	Only with a workspace-wide key: open it on behalf of this agent. An agent key always acts as itself.
`category`	No	Optional: its category, when the policy limits or budgets categories.
`currency`	No	Three-letter ISO currency code. Defaults to USD.
`max_amount`	Yes	The most the whole run may spend.
`ttl_seconds`	No	How long the session stays open, in seconds. Defaults to 3600.
`agentid_token`	No	Your AgentID ID token, issued for Last Price, when your owner's policy lets only verified agents spend. Sent as the AgentID-Token header.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 25, 2026

addedInput schema / properties / pay_to

Added value: +{
+  "description": "Optional: the wallet address (bare or CAIP-10) or merchant account id the calls pay. Every draw_session_spend must then 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"
+}

AddedOct 23, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the annotations, the description discloses that the owner's spend policy judges the session like a purchase of `max_amount`, with allow holding that maximum, ask requiring human approval and resubmission, and deny preventing start. It also discloses expiry behavior, remainder return, feature-availability errors, required credential scope, and the 403 for unclaimed workspaces.

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

Conciseness5/5

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

The description is front-loaded with the core purpose and then proceeds in workflow order: open, draw, close, expiry, feature gating, credentials, workspace claim. Every sentence provides operational value; none merely restates the tool name or title.

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 a non-idempotent mutation tool with no output schema and ten parameters, the description supplies the missing operational context: policy outcomes, returned session id, follow-up tools, error conditions, credential requirements, and workspace prerequisites. The detailed input schema covers the remaining field-level detail.

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 coverage is 100%, so the field-level definitions already carry most parameter meaning. The description still adds useful semantic context for `max_amount` as the whole run's budget and for the policy treatment of that budget, plus the returned session id, though it does not elaborate on optional fields like `intent`, `pay_to`, or `ttl_seconds` beyond the schema.

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?

The description states a specific verb and resource: open one budget/session before a run of small paid calls to one seller. It clearly distinguishes this from checking every call and from `check_purchase`, so an agent can identify the tool 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.

Usage Guidelines5/5

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

It explicitly says when to use this tool: before a run of small paid calls to one seller, instead of checking each call. It also gives the downstream workflow (`draw_session_spend` before each payment, `close_spend_session` when done), policy outcomes (allow/ask/deny), and the alternative when sessions are disabled.

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

All Last Price tools Inspect

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

Need Help?