Skip to main content
Glama

quote_usd

Convert any USD price into an exact XNO payment amount using the median of three independent sources. Receive a short-lived quote with address and expiry to complete payment.

Instructions

Price a call in dollars. Converts the USD price to the exact XNO amount via the MEDIAN of three independent public price sources and returns {request_id, address, price_raw, price_usd, rate_xno_usd, expires_at}. The quote expires in <=30s; pay the exact price_raw to address before that, then call verify_payment(request_id, price_raw). This is pure computation — nothing is held or converted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
price_usdYes
request_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the full burden. It discloses that the operation is pure computation with no holding or conversion, and states the 30-second expiry. It also outlines the required follow-up step. This is transparent about side effects and constraints, though it doesn't cover potential error conditions 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.

Conciseness5/5

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

Three sentences that are information-dense, with the purpose front-loaded and no fluff. The workflow, expiry, and follow-up are all included efficiently. Every sentence earns its place.

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

Completeness4/5

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

For a quote tool with no output schema, it lists the return fields, explains expiry and the verification step. Missing details like request_id purpose and error behavior, but overall sufficient for correct invocation. The core workflow is fully covered.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must explain parameters. It explains price_usd as the USD price to convert, but does not explain the optional request_id parameter. The return fields are listed, but the input semantics for request_id are absent. Thus it partially compensates for the lack of schema descriptions.

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 clearly states the tool's function: pricing a call in dollars and converting to XNO via the median of three sources. It lists the exact return fields, making it distinct from siblings like 'quote' which may be generic. The verb 'price' and resource 'call in dollars' are specific and unambiguous.

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

Usage Guidelines4/5

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

It provides a clear workflow context: pay the exact price_raw to the address before expiry, then call verify_payment. However, it does not explicitly contrast with sibling 'quote' or state when to prefer this tool over alternatives. It implies usage for USD-priced calls but doesn't exclude alternatives.

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