Skip to main content
Glama

AZPay Monetize — Sepolia Sandbox

Pay and access

pay_and_access
Destructive

Use this only after the person agrees to pay. It is the only tool that spends. prepare_checkout never pays, and get_receipt never charges. Input: offer_id, the confirmation from prepare_checkout, and confirm=true. Pass confirm=false to decline. Public callers get x402 payment requirements instead of a charge. The server wallet signs only for the owner key on Sepolia testnet.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "pay_and_access"
  }
}

Input Schema

NameRequiredDescriptionDefault
confirmNoTrue only after the person agrees to pay. False declines and spends nothing.
offer_idNoAccepted offer id from negotiate_price or prepare_checkout.
confirmationNoSingle-use confirmation returned by prepare_checkout. Required when confirm is true.

Output Schema

NameRequiredDescriptionDefault
kindYes
paidYes
payeeYes
networkYes
optionsYes
paymentYes
testnetYes
offer_idYes
quantityYes
resourceYes
expires_atYes
total_usdcYes
transactionYes
confirmationYes
instructionsYes
network_nameYes
schema_versionYes
uses_remainingYes
expires_at_europe_madridYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • changedInput schema / properties / confirm / description
      Previous value: -"True only after the person agrees to pay. False declines."New value: +"True only after the person agrees to pay. False declines and spends nothing."
    • removedInput schema / properties / confirmacao
      Removed value: -{
      -  "description": "Deprecated alias of confirmation.",
      -  "maxLength": 512,
      -  "type": "string"
      -}
    • removedInput schema / properties / confirmar
      Removed value: -{
      -  "description": "Deprecated alias of confirm.",
      -  "type": "boolean"
      -}
    • changedInput schema / properties / confirmation / description
      Previous value: -"Single-use confirmation from prepare_checkout."New value: +"Single-use confirmation returned by prepare_checkout. Required when confirm is true."
    • removedInput schema / properties / oferta
      Removed value: -{
      -  "description": "Deprecated alias of offer_id.",
      -  "maxLength": 80,
      -  "type": "string"
      -}
    • changedInput schema / properties / offer_id / description
      Previous value: -"Accepted offer id."New value: +"Accepted offer id from negotiate_price or prepare_checkout."
  2. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare destructive=true and openWorld=true, but the description adds behavior they cannot express: an actual charge occurs, the confirmation is single-use, public callers get x402 payment requirements instead of a charge, and the signing wallet is the owner key on Sepolia testnet only. It omits failure modes (expired or reused confirmation) and whether a successful charge is idempotent, which keeps it from a 5.

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-loads the consent gate, then sibling disambiguation, then the input contract, then edge behavior — a sensible order with no filler sentences. Slightly dense in the input enumeration, but every clause carries information.

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 destructive payment tool with an output schema and full schema coverage, the definition covers gating, alternatives, decline semantics, and caller-type divergence. Missing only error/expiry handling and idempotency of the spend, which matter for an irreversible operation.

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

Parameters5/5

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

Schema coverage is 100%, yet the description still adds relationship and conditional knowledge: confirm=true is gated on human agreement, confirm=false declines and spends nothing, confirmation comes from prepare_checkout and is required only when confirm is true, and offer_id originates from negotiate_price or prepare_checkout.

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 — this tool spends money and grants access — and asserts it is the only tool that spends, explicitly differentiating from prepare_checkout and get_receipt. An agent can select it 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?

Explicit when-to-use (only after the person agrees to pay) and when-not (prepare_checkout never pays, get_receipt never charges), plus the decline branch via confirm=false and the divergence for public callers. The selection conditions are fully specified.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources