invoice-check
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_invoicesC | List invoices (contractor, number, date, work order, total). month: 'YYYY-MM', optional. |
| read_invoiceC | Parsed lines plus the original text of one invoice (id such as 'h-2026-0031'). |
| get_work_orderC | One row of the work order export (type, max hours, MU and GA approvals, build year). |
| get_priceB | List price for a code on an execution date (YYYY-MM-DD or DD-MM-YYYY), indexed per Art. 4.2. |
| get_ruleC | Contract text (Dutch and English) and our reading for a rule (R0-R20), decision (Q1-Q21) or article (4.1-4.10). |
| check_invoiceC | Check one invoice. It runs in its batch so duplicates and credit notes are seen. |
| check_allB | Check the batch, write output//review.html (Sanne's one-stop page), review-list.md and one Dutch letter per disputed invoice (letters/.CONCEPT.txt until she decides). |
| record_decisionA | Record Sanne's call in decisions.csv. decision: pay (pay in full), letter_ok (agree with the dispute: letter ready), sent (she sent the letter; sent_date YYYY-MM-DD, default today), hold (optional note), confirmed (unknown work order confirmed), not_ours (whole invoice disputed; reason required), disagree (verdict approve|dispute|hold, optional amount, reason required), resolved (closes a waiting dispute; kind credit_note|corrected_invoice|contractor_right|withdrawn and a reason), let_go (pay in full, all findings small; a repeat needs a reason), undo (back to the previous state). Old names approve, dispute, change still work. An overrule needs a reason. amount_excl_vat: amount disputed (letter_ok, disagree to dispute); defaults to the proposal. |
| open_dashboardB | Start the local dashboard (127.0.0.1 only) and return its URL. Sanne decides there or in the chat; both land in the same decisions.csv. month: 'YYYY-MM' or 'all'. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| monthly_check | The monthly invoice check workflow. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
The data-lookup tools (get_work_order, get_price, get_rule) and the action tools (check_invoice, check_all, open_dashboard, record_decision) are clearly distinct. The main friction is between list_invoices, read_invoice and check_invoice, which all operate on a single invoice but differ only subtly (browse vs. extract text vs. validate); descriptions do help, though an agent could still reach for read when check was meant.
All names are snake_case verb-first (list_, read_, get_, check_, open_, record_), which gives a strong, readable pattern. Minor deviations: check_all drops the object noun and uses the same verb as check_invoice for a batch-wide action, which slightly blurs the verb semantics.
Nine tools is well within the sweet spot and each maps to a distinct step in the invoice-review workflow: enumerate, inspect, fetch reference data, validate, surface UI, and record the outcome. Nothing appears redundant or bolted on.
The lifecycle is essentially end-to-end: list/read invoices, pull work-order, price and rule context, run single or batch checks, open a review dashboard, and persist decisions with a rich state machine. The notable gap is read-back: there is no tool to list prior decisions.csv entries or pending 'waiting disputes' other than via the dashboard, so an agent cannot inspect history in-band.