Mercury Multiorg MCP

by dkaleganov

Overview Schema Source Related Servers Discussions Admin

Python

Local

list_invoice_attachments

Read-onlyIdempotent

Retrieve all attachment IDs and file names for a single invoice. Use to inventory attached documents.

Instructions

Inventory one invoice's attachments (id and file name). File names are verbatim third-party text; no download URLs.

    Use this for the files attached to one invoice; use `get_invoice` for
    the invoice itself and `list_tax_docs` for recipients' tax forms.
    Unpaginated; every attachment is returned.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`entity`	Yes	Exact `entity` key from `list_entities`, not its `display_name`. Required; there is no default.
`invoice_id`	Yes	Invoice id from `list_invoices`.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.1.6Sep 15, 2026

changedInput schema / properties / entity / description

Previous value: -"Entity key from `list_entities`. Required; there is no default."New value: +"Exact `entity` key from `list_entities`, not its `display_name`. Required; there is no default."

First observedv0.1.4Sep 14, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds meaningful behavioral context beyond that: file names are verbatim third-party text, no download URLs, and the unpaginated nature. These details are not redundant with annotations and help the agent set expectations.

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?

Two concise sentences with zero fluff. The purpose is front-loaded in the first sentence, and usage guidance follows immediately. Every phrase earns its place.

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?

For a simple list tool, the description covers everything an agent needs: purpose, parameter implications, return scope (id and file name), and crucial behavioral facts (no URLs, no pagination). The schema covers parameters fully, and the output schema is said to exist. Nothing essential 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% for both parameters; the schema already explains entity (exact key, not display_name, no default) and invoice_id (from list_invoices). The description adds no new parameter-specific semantics, 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 description states a specific verb ('inventory'), resource ('one invoice's attachments'), and scope ('id and file name'), and differentiates from siblings by naming get_invoice and list_tax_docs as alternatives. The 'no download URLs' detail adds precision, making the purpose unmistakable.

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?

It explicitly says 'Use this for the files attached to one invoice' and directs to `get_invoice` for the invoice itself and `list_tax_docs` for tax forms, clearly establishing when to use and when not to use. The note 'Unpaginated; every attachment is returned' adds operational guidance.

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