Skip to main content
Glama
Sign In
AgentTools

AgentTools

by kulas-100
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

invoice_extract

Extract structured financial data from invoices, receipts, and bills, then verify subtotal plus tax equals total for accounting workflows.

Instructions

Extract structured financial data (vendor, invoice #, PO #, dates, line items, subtotal, tax, total, currency) from invoices, receipts, and bills, verifying mathematical consistency (subtotal + tax == total). Use when processing accounting documents or receipts. Do not use for generic documents. Read-only and idempotent.

Input Schema

NameRequiredDescriptionDefault
urlNoPublic HTTPS URL pointing directly to an invoice image or PDF file (e.g. 'https://example.com/invoice.pdf').
raw_textNoPre-extracted or OCR text content of the invoice to parse directly.
file_base64NoBase64-encoded file content of the invoice or receipt document.
currency_hintNo3-letter ISO 4217 currency code hint (e.g. 'USD', 'EUR', 'GBP') if no symbol is found.USD

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.1.3
    • changedInput schema / properties / currency_hint / description
      Previous value: -"Default currency code (default USD)"New value: +"3-letter ISO 4217 currency code hint (e.g. 'USD', 'EUR', 'GBP') if no symbol is found."
    • changedInput schema / properties / file_base64 / description
      Previous value: -"Base64-encoded invoice file"New value: +"Base64-encoded file content of the invoice or receipt document."
    • changedInput schema / properties / raw_text / description
      Previous value: -"Raw invoice text if already extracted"New value: +"Pre-extracted or OCR text content of the invoice to parse directly."
    • changedInput schema / properties / url / description
      Previous value: -"URL to invoice PDF or image"New value: +"Public HTTPS URL pointing directly to an invoice image or PDF file (e.g. 'https://example.com/invoice.pdf')."
  2. First observedv0.1.0

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations supplied, the description carries the full burden; it does disclose the self-declared read-only/idempotent profile and the added cross-field validation (subtotal + tax == total), which is real behavioral value. It omits what happens when the math fails to reconcile, which of the three input modes takes precedence, and any failure/auth behavior.

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?

Front-loaded with the verb and the extracted field set, then usage guidance, then the safety profile — a sensible order with no filler sentences. The parenthetical field list is dense but justified given there is no output schema.

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?

Because there is no output schema, listing the returned fields is necessary and the description does it. Remaining gaps — precedence between url/raw_text/file_base64 and behavior on failed math verification — are modest but real for a 4-param extraction tool.

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%, so all four parameters (url, raw_text, file_base64, currency_hint) are already documented in the schema, which sets the baseline at 3. The description adds nothing about mutual exclusivity or precedence among the three optional input sources, which is the main semantic risk for this tool.

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 (extract) plus the exact resource and output fields (vendor, invoice #, PO #, line items, subtotal, tax, total, currency), and scopes it to invoices/receipts/bills. The 'do not use for generic documents' line separates it from the pdf_extract sibling.

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?

Gives both a positive trigger ('processing accounting documents or receipts') and an exclusion ('do not use for generic documents'). It stops short of naming the sibling an agent should fall back to for generic PDFs, so the routing is clear but not fully resolved.

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

Deploy Server

Other Tools