Skip to main content
Glama
verax-ai

Verax

Official
by verax-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

spend

Asks the body to authorize a payment and records the decision; the body never moves money, so authorized: true is a signed permission for a later payment step, not a transfer.

Instructions

Asks the body to authorize a payment and records the decision; the body never moves money, so authorized: true is a signed permission for a later payment step, not a transfer. Use it before any payment so that amount, currency, payee and reference are checked against the policy: the one currency the policy names, a cap per call, a payee list and a daily limit. A call outside those bounds is refused with a signed deny naming the bound: denied:spend-cap, denied:spend-payee, denied:spend-currency or denied:spend-daily. A call within them is held for an operator on this machine and answers deferred:approval-required:; once that ref is approved (verax approve, or the panel), resending the same call with the same _ref answers allowed:, and the authorization is recorded as {authorized: true, ref, amountMinor, currency, payee, reference}. Without a spend rule in the policy every call answers denied:spend-not-wired.

Input Schema

NameRequiredDescriptionDefault
_refNoOptional reference you choose for this call, 1 to 64 characters of letters, digits, '.', '_' or '-', starting with a letter or digit. Resend the same call with the same _ref after an operator approved it to receive allowed:<ref>; a _ref reused for a different call is refused with denied:ref-reuse.
payeeYesWho is to be paid, spelled exactly as the policy's payee list spells it (a merchant or account name). A payee off the list is refused.
currencyYesISO 4217 code in upper case, for example USD, EUR or TRY. Must equal the currency the policy's spend rule names.
referenceYesYour own reference for this payment, such as an invoice or order id. Recorded with the authorization; verax reconcile does not read it, and matches a card statement row by a verax:<ref> in its description, amount, currency and time.
amountMinorYesAmount in the currency's minor unit as a positive integer: cents, kuruş or pence, so 1250 means 12.50. Compared against the policy's cap per call and daily limit.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.1
    • changedInput schema / properties / reference / description
      Previous value: -"Your own reference for this payment, such as an invoice or order id. Recorded with the authorization and used by verax reconcile to match the card statement."New value: +"Your own reference for this payment, such as an invoice or order id. Recorded with the authorization; verax reconcile does not read it, and matches a card statement row by a verax:<ref> in its description, amount, currency and time."
  2. First observedv0.1.1

TDQS

A4.6/5.0
Behavior5/5

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

No annotations exist, so the description carries the full burden and does so thoroughly: it discloses the non-transfer semantics of authorized:true, the four policy bounds, the specific deny codes for each bound, the deferred/operator-approval path with its response strings, and the unwired-policy fallback (denied:spend-not-wired). It even documents the idempotent resend requirement.

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?

It is front-loaded with the key distinction (authorization vs transfer) and every sentence carries operational information about bounds or responses. It is dense and long, but the length is justified by the number of distinct decision paths it must document.

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?

With no annotations and no output schema, the description must convey behavior and return values — and it does: it enumerates the possible response families (authorized, denied with reasons, deferred, allowed) and the recorded authorization shape. Nothing needed to invoke or interpret the call is missing.

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 100%, so each parameter's meaning, format and constraints are already documented in the schema. The description restates the policy checks (cap per call, daily limit, named currency, payee list) but adds little parameter semantics beyond what the schema provides, so the baseline 3 applies.

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 first clause states a specific verb and resource ('Asks the body to authorize a payment and records the decision') and immediately clarifies the boundary that distinguishes it from a payment tool: 'the body never moves money.' An agent can tell this is an authorization gate, not a transfer, 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?

Explicit when-to-use: 'Use it before any payment so that amount, currency, payee and reference are checked against the policy.' It also spells out the preconditions (a spend rule must exist), the approval round-trip, and the exact resend protocol with the same _ref.

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

Deploy Server

Other Tools