Skip to main content
Glama

Whether a payment you were asked to make can actually be paid

singularityagent__inspect_payment
Read-only

Before signing a payment somebody else asked you to make, find out whether it can be paid at all. Takes an invoice or payment intent in the shape it arrived — payee, token, claimed ticker, amount, base units, decimals, expiry — and checks each claim against the chain instead of against the rest of the invoice. Works on Solana and on EVM chains, reading each family's own failure modes. Everywhere: a token address that is well-formed with no token at it, a displayed amount and a base-unit amount that disagree, decimals that do not match the token, a ticker naming one token while the address names another, and an expiry already passed. On Solana it also reads the destination token account — whether it exists, holds that mint, is frozen, or belongs to somebody other than the payee named — and whether the mint charges a transfer fee, which makes the payee receive less than you send. On EVM it reads whether the payee is the zero address, the token's own contract (one of the most common ways ERC-20s are permanently lost), or a contract that may be unable to move the token out again. Reach for it whenever a payment demand arrives from anywhere you do not control — an exchange, an API, a marketplace, another agent — and before building or signing anything against it. verdict is unpayable when at least one finding means signing cannot do what the demand says, payable when every stated claim checked out, and unproven when the chain could not be read, which is not the same as cleared. Read findings before verdict. This reads: it builds nothing, signs nothing and sends nothing, and unpayable means the demand is wrong rather than that the counterparty is dishonest — a typo in somebody else's configuration produces exactly this.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoThe wallet the demand says will be paid.
memoNoText the demand says the payment must carry.
mintNoToken address — the mint on Solana. Omit for the native asset. Never a ticker.
assetNoThe ticker the demand claims, e.g. USDC. Checked against `mint`, never used instead of it.
chainNoChain id or alias, EVM or Solana. Defaults to "solana".
tokenNoAlias for `mint`, for EVM chains where the token is a contract rather than a mint.
amountNoWhole tokens as a decimal string, as the demand displays it.
decimalsNoThe decimals the demand assumes. Checked against the mint.
expiresAtNoWhen the demand stops being valid, ISO 8601.
referenceNoThe Solana Pay reference that would make the payment findable.
tokenAccountNoThe exact destination token account the demand names, where it names one.
amountBaseUnitsNoThe same amount in base units, where the demand states both. They must agree.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / additionalProperties
      Previous value: -trueNew value: +false
    • addedInput schema / properties
      Added value: +{
      +  "amount": {
      +    "description": "Whole tokens as a decimal string, as the demand displays it.",
      +    "type": "string"
      +  },
      +  "amountBaseUnits": {
      +    "description": "The same amount in base units, where the demand states both. They must agree.",
      +    "type": "string"
      +  },
      +  "asset": {
      +    "description": "The ticker the demand claims, e.g. USDC. Checked against `mint`, never used instead of it.",
      +    "type": "string"
      +  },
      +  "chain": {
      +    "description": "Chain id or alias, EVM or Solana. Defaults to \"solana\".",
      +    "type": "string"
      +  },
      +  "decimals": {
      +    "description": "The decimals the demand assumes. Checked against the mint.",
      +    "type": "number"
      +  },
      +  "expiresAt": {
      +    "description": "When the demand stops being valid, ISO 8601.",
      +    "type": "string"
      +  },
      +  "memo": {
      +    "description": "Text the demand says the payment must carry.",
      +    "type": "string"
      +  },
      +  "mint": {
      +    "description": "Token address — the mint on Solana. Omit for the native asset. Never a ticker.",
      +    "type": "string"
      +  },
      +  "reference": {
      +    "description": "The Solana Pay reference that would make the payment findable.",
      +    "type": "string"
      +  },
      +  "to": {
      +    "description": "The wallet the demand says will be paid.",
      +    "type": "string"
      +  },
      +  "token": {
      +    "description": "Alias for `mint`, for EVM chains where the token is a contract rather than a mint.",
      +    "type": "string"
      +  },
      +  "tokenAccount": {
      +    "description": "The exact destination token account the demand names, where it names one.",
      +    "type": "string"
      +  }
      +}
  2. Added

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the readOnlyHint and openWorldHint annotations, the description adds rich behavioral detail: it explains the verdict semantics ('unpayable', 'payable', 'unproven'), warns that 'unpayable' means the demand is wrong rather than the counterparty dishonest, and describes chain-specific checks (Solana token account states, EVM zero address/token contract). This goes well beyond what annotations imply.

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?

Though long, every sentence earns its place. It opens with the core purpose, enumerates specific checks, gives usage context, explains verdicts, and clarifies safety—all in a logical flow. No filler or redundancy.

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?

Given the tool's complexity (12 optional parameters, no output schema), the description is remarkably complete. It explains what the return values mean (verdict and findings), covers chain-specific behaviors, and describes all the failure modes it detects. An agent has everything needed to call it correctly and interpret results.

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 each parameter has a description. The description adds value by explaining how parameters are cross-checked (e.g., 'a displayed amount and a base-unit amount that disagree', 'decimals that do not match the token'), giving semantic context beyond individual field descriptions. It also clarifies relationships like 'asset' vs 'mint' and 'token' as alias.

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 precise purpose: 'find out whether it can be paid at all' by checking each claim against the chain. It clearly identifies the resource (payment demand) and the verb (inspect/verify). It also differentiates from siblings by emphasizing it's a pre-signing verification tool, not a payment or proof tool.

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 says when to use it: 'Reach for it whenever a payment demand arrives from anywhere you do not control — an exchange, an API, a marketplace, another agent — and before building or signing anything against it.' It also explains what it does not do ('builds nothing, signs nothing and sends nothing'), giving clear boundaries for usage.

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.