erp-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ERP_API_KEY | Yes | API key for the ERP REST API. The API key lives in the client module and never appears in tool input or output. | |
| ERP_BASE_URL | No | Base URL of the ERP REST API, e.g. http://127.0.0.1:8080. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Tools for looking up vendors and purchase orders and for posting vendor invoices. Look the vendor up before posting. post_vendor_invoice only posts when confirm is true; call it without confirm first, show the preview to the user and post after they agree.
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_vendorsA | Find vendors by name or tax number. Returns at most 10 matches. |
| list_purchase_ordersB | List a vendor's purchase orders with the amount still open on each. |
| get_purchase_orderC | Get one purchase order by its number. |
| post_vendor_invoiceB | Post a vendor invoice. Without confirm it only runs the checks and returns a preview. Posting is idempotent: repeating a confirmed call with the same vendor and reference returns the document that was already created. |
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
Each tool targets a distinct resource and action: vendor search, PO listing, single PO retrieval, and invoice posting. There is no overlap between listing purchase orders and getting one order, since one is scoped per-vendor and the other per-document.
All four names follow a strict verb_noun snake_case pattern (search_vendors, list_purchase_orders, get_purchase_order, post_vendor_invoice). Verbs are well chosen and consistently distinguish read vs. write operations.
Four tools is on the lean side but each supports a step in the vendor-invoice workflow, so nothing is redundant. A slightly broader surface (e.g. retrieving posted invoices) would make the set feel less minimal.
The core workflow — find vendor, inspect open PO amounts, read a PO, then post/preview an invoice — is fully covered, including idempotency. Minor gaps remain: no way to list or fetch invoices by vendor/reference outside of a repeat post, and no vendor-detail retrieval.