Skip to main content
Glama

generate_invoice

Generate client invoices from cryptographically signed receipts for AI agent work. Aggregates costs, token usage, and receipt counts by agent, action, or day, with verifiable line items referencing signed receipts.

Instructions

Generate a client invoice from cryptographically signed receipts within a date range. Aggregates receipt data by agent, action, or day and calculates total costs, token usage, and receipt counts. Supports JSON, CSV, and Markdown output formats. Each line item references a signed receipt for verifiable billing. Use to bill clients for AI agent work with cryptographic proof of every billed action.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fromYesInvoice period start date in ISO 8601 format (e.g., "2026-01-01" or "2026-01-01T00:00:00Z")
toYesInvoice period end date in ISO 8601 format (e.g., "2026-01-31" or "2026-01-31T23:59:59Z")
client_nameNoClient or bill-to name for the invoice header
client_emailNoClient email address
provider_nameNoYour company or provider name
provider_emailNoYour email address
group_byNoHow to group line items: "action" (by action name), "agent" (by agent ID), "day" (by date), or "none" (single total)
formatNoOutput format: "json" (structured data), "csv" (spreadsheet), or "md" (markdown table)
include_receiptsNoIf true, includes full receipt objects in JSON output for full auditability
agent_idsNoFilter to specific agent IDs only
actionsNoFilter to specific action names only
constraints_passed_onlyNoIf true, only include receipts where all constraints passed
notesNoAdditional notes to include in the invoice
payment_termsNoPayment terms text (e.g., "Net 30", "Due on receipt")
Behavior4/5

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

With no annotations, the description carries full burden. It explains the aggregation, calculation, and output formats, and mentions each line item references a signed receipt for verifiability. It does not disclose potential side effects or limitations, but the generative nature is implied and the description is otherwise transparent.

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?

The description is a single paragraph of five sentences, each sentence adding value. It is front-loaded with the main purpose and efficiently covers key aspects without redundancy.

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?

Given the tool's complexity (14 parameters, no output schema), the description adequately covers purpose, outputs, and usage. It explains the output formats and the inclusion of signed receipts, though it could elaborate on the exact structure of the generated invoice or error conditions.

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?

All 14 parameters have descriptions in the input schema, so schema coverage is 100%. The description adds high-level context for grouping and output formats but does not provide additional per-parameter meaning beyond the schema.

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 clearly states the tool generates invoices from signed receipts within a date range, specifying aggregation and output formats. It distinguishes itself from sibling receipt-related tools by focusing on billing-oriented aggregation and cryptographic proof.

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

Usage Guidelines4/5

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

The description explicitly says 'Use to bill clients for AI agent work with cryptographic proof,' which provides clear usage context. However, it does not mention when not to use it or contrast it with alternatives like list_receipts or verify_receipt.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/webaesbyamin/agent-receipts'

If you have feedback or need assistance with the MCP directory API, please join our Discord server