Skip to main content
Glama

invoice_get

Read-onlyIdempotent

Read an invoice by id (INV-XXXX-XXXX, with or without dashes): requested amount, token, network, receiver, status (open or paid), the paying transaction once paid, and received (the raw amount measured on-chain so far). Pending payments are re-checked on-chain by the read, at most two per read and each at most every 15 seconds. checks lists the paid screening the creator chose (e.g. ["scorechain"]; [] when none), which paying runs on both wallets once analysis.status is paid. analysis.report (Merkle Science only) carries, once the invoice is paid, the detail of both wallets (over the web app, a signed session of the creator also sees the detail of the receiving wallet while it is open): score, severity, summary, main risk category, risk factors and sourceOfFunds (the largest origins of the money, up to 8, with category, entity, percentage, USD amount and direct or indirect exposure). confidential is true only on a private invoice created before 14/10/2026: its receiver reads null here, it can no longer be paid (invoice_pay answers private_invoice_paused), and its paying transaction, once paid, shows the receiver on-chain.

Input Schema

NameRequiredDescriptionDefault
idYesINV-XXXX-XXXX or the 8-character id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: it discloses that pending payments are re-checked on-chain at most twice per read and once per 15 seconds, that confidential invoices can no longer be paid, and that the receiver field is scrubbed under the confidential rule. These are operational traits the annotations do not convey.

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

Conciseness3/5

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

The purpose is front-loaded in the first clause, which is good, but the single paragraph then sprawls into deep nested return detail (analysis.report subfields, sourceOfFunds, confidential legacy rules) that is hard to scan. It is informative rather than wasteful, yet far longer than needed for tool selection.

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?

There is no output schema, so the description must carry return-value semantics, and it does thoroughly: status values, paying transaction, on-chain received amount, checks, analysis.report contents, and confidential edge cases. Nothing an agent needs to interpret a response 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 coverage is 100% and the single id parameter is fully documented in the schema ("INV-XXXX-XXXX or the 8-character id"); the description's mention of dashes being optional duplicates that. No additional parameter meaning is added, 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?

Opens with a specific verb and resource ("Read an invoice by id") and immediately enumerates the exact fields returned, so an agent knows precisely what it gets. It also distinguishes its role from invoice_pay by stating how that sibling behaves on confidential invoices (private_invoice_paused).

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

Usage Guidelines3/5

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

Usage is implied by the read-oriented framing and by the note that a signed web session sees more detail, but there is no explicit "use this when / use invoice_pay or invoice_analysis_pay instead" routing among the many invoice_* siblings. An agent can infer the read case but must guess at boundaries.

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