acumulus-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ACUMULUS_TESTMODE | No | Set to 1 to have Acumulus validate write calls without persisting them — do a dry run before pointing it at the live administration. | |
| ACUMULUS_USERNAME | Yes | Your Acumulus username | |
| ACUMULUS_API_TOKEN | Yes | Your Acumulus API token, generated in Acumulus under your profile; it travels in the API's <password> field | |
| ACUMULUS_CONTRACT_CODE | Yes | Your Acumulus contract code |
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 |
|---|---|
| acumulus_requestA | Call any Acumulus function endpoint directly. Use this for endpoints not covered by the dedicated tools below. Args: api_path: Path below the stable base, matching the Acumulus docs, e.g. "picklists/picklist_vattypes.php", "invoices/invoice_add.php", "invoices/invoice_set_payment_status.php", "entry/entry_info.php". fields: Extra fields merged into the request envelope. Nested dicts become nested elements; a list value repeats its element (e.g. {"customer": {"invoice": {"line": [{...}, {...}]}}}). Do NOT include the contract/credentials block — that is added for you. Returns: JSON-encoded response from Acumulus. |
| list_picklistA | List an Acumulus picklist (reference data for dropdowns/validation). Args: picklist: The picklist name. Common values: "accounts" (bank/ledger accounts), "contacts", "products", "vattypes", "costcenters", "costheadings", "companytypes". The endpoint called is picklists/picklist_.php. Returns the parsed response plus the extracted item list under |
| create_invoiceA | Add an invoice to Acumulus (invoices/invoice_add.php). Args: customer: Customer-block fields. Common ones: type, contactid, companyname1, fullname, address1, postalcode, city, countrycode, vatnumber, email, overwriteifexists. lines: One dict per invoice line. Common fields: product, itemnumber, unitprice (excl. VAT, 4 decimals), vatrate (defaults to 21), quantity (defaults to 1), nature. invoice: Optional invoice-block fields: concept, number, vattype, issuedate, costcenter, accountnumber, paymentstatus, paymentdate, description, template, invoicenotes. Set ACUMULUS_TESTMODE=1 to validate without persisting. |
| whoamiA | Sanity-check the Acumulus connection by listing the account picklist. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
whoami and list_picklist with picklist="accounts" perform essentially the same call, creating genuine redundancy. acumulus_request also overlaps with every dedicated tool by design, though its description explicitly steers usage toward uncovered endpoints, which mitigates the fuzziness.
create_invoice and list_picklist follow a clean verb_noun pattern, but whoami is a bare verb-less word and acumulus_request is a namespaced prefix_noun, so the set mixes three conventions. Still readable but not predictable.
Four tools is on the thin side, but for an API wrapper the generic acumulus_request plus two focused helpers and a connection check is defensible. whoami is arguably redundant given list_picklist, keeping it just shy of ideal.
acumulus_request makes any Acumulus endpoint reachable, so there are no true dead ends. However dedicated coverage is sparse — invoice creation exists but no dedicated get/update/delete invoice or payment-status tools, leaving common lifecycle operations to the generic escape hatch.