Skip to main content
Glama
klodr

mercury-invoicing-mcp

mercury_get_invoice_pdf

Read-only

Resolve the download URL of an invoice's PDF via Mercury's documented getinvoicepdf endpoint.

Instructions

Resolve the download URL of an invoice's PDF via Mercury's documented getinvoicepdf endpoint.

USE WHEN: you need the actual invoice PDF — to archive it, or to attach it to an email / bank KYB / compliance reply. mercury_list_invoice_attachments does NOT return it (that lists only files a human manually uploaded, empty on a normal invoice). This tool fetches the invoice (for its number / status / slug) and returns downloadUrl = {baseUrl}/ar/invoices/{id}/pdf, the documented endpoint (https://docs.mercury.com/reference/getinvoicepdf) that returns the PDF with Content-Disposition: attachment.

AUTH: downloadUrl is an authenticated Mercury API URL — fetch it with the same Authorization: Bearer <token> and Accept: application/pdf as every other call (it is NOT a public pre-signed link). Because it is derived from the client's configured base URL, it stays correct under the sandbox / proxy host, not just production.

DO NOT USE: for statement PDFs (use mercury_list_statements); for manually-uploaded attachments (use mercury_list_invoice_attachments). A draft invoice that was never issued may return 404 when the URL is fetched.

RETURNS: { invoiceId, invoiceNumber, status, slug, downloadUrl }.

Input Schema

NameRequiredDescriptionDefault
invoiceIdYesThe invoice ID (UUID)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.20.3

TDQS

A4.6/5.0
Behavior5/5

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

Annotations declare readOnlyHint and openWorldHint, but the description adds substantial non-structured context: the returned downloadUrl is authenticated and requires Bearer token + Accept: application/pdf (not a pre-signed link), and it stays correct under sandbox/proxy hosts. It also discloses the 404 behavior for unissued draft invoices, all well beyond what annotations convey.

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?

Well front-loaded with labeled USE WHEN / AUTH / DO NOT USE / RETURNS sections that each carry actionable content. Slightly long, with a docs URL and URL-template notation that are helpful but marginally verbose; still, few sentences could be cut without losing routing or auth information.

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?

No output schema exists, but the RETURNS block enumerates the response fields (invoiceId, invoiceNumber, status, slug, downloadUrl), and auth/error behavior for draft invoices is documented. An agent has everything needed to call it and consume the result correctly.

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?

Only one parameter (invoiceId), and schema coverage is 100% with the UUID pattern fully documented. The description says the tool fetches the invoice for number/status/slug but adds no format or sourcing detail for invoiceId beyond the schema, so baseline 3 is appropriate.

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+resource: 'Resolve the download URL of an invoice's PDF'. It explicitly names siblings it is not (list_invoice_attachments, list_statements) and explains the derived URL format, so the agent can distinguish it from mercury_get_invoice or mercury_list_invoice_attachments without opening schemas.

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?

Provides an explicit USE WHEN block with concrete scenarios (archiving, attaching to email/KYB/compliance), a DO NOT USE block routing to mercury_list_statements and mercury_list_invoice_attachments, and a caveat about draft invoices returning 404. Alternatives are named with the selecting condition.

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