MCP server for ERP quote and order data

MCP — the Model Context Protocol — is how an AI agent picks up tools it did not ship with. Point your agent at this server and it can work your ERP the way a salesperson does: take a customer’s enquiry in the customer’s own words, work out which of your products it means, look the customer up, and draft the offer.

The server is remote and hosted by us, so there is nothing to install or run. It speaks plain HTTP and needs only an API key.

https://erp-agent.com/api/v1/mcp

Everything here sits on the same platform as the REST API: the same organization, the same keys, the same offers.

In Claude Code, add the server with one command. Anything a registered MCP server can do, your agent can then do in the course of a normal conversation.

claude mcp add erp-agent --transport http \
  https://erp-agent.com/api/v1/mcp \
  --header "Authorization: Bearer YOUR_API_KEY"

Claude Desktop and most frameworks take a JSON configuration instead. The shape varies slightly between clients, but the three things that matter are always the same: the transport is http, the URL, and the Authorization header.

{
  "mcpServers": {
    "erp-agent": {
      "type": "http",
      "url": "https://erp-agent.com/api/v1/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_API_KEY"
      }
    }
  }
}

Any client that speaks MCP works — Claude Code, Claude Desktop, or an agent framework of your own. Once connected, ask your agent to call erp_whoami to confirm which organization the key is bound to before you let it do anything else.

Authentication is the same sk_live_… API key as the REST API, sent as a bearer token. One key belongs to exactly one organization and cannot reach another tenant’s data.

Authorization: Bearer sk_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxx

The key must additionally carry the mcp:use scope. Scopes are granted per key by ERP Agent, not self-served: a key that works perfectly well against the REST API may still be missing this one. Without it every tool call comes back as insufficient_scope — if you see that, ask your ERP Agent contact to add the scope to the key.

Keys themselves are issued and scoped by ERP Agent. How they are created, stored and revoked is covered in the API documentation; treat the key as a password and keep it out of anything a user can read.

The server is stateless. There is no session id to carry between calls, and responses come back as plain JSON on the POST rather than as an SSE stream. That makes it safe to put behind a load balancer and cheap for a client to retry.

Two tools look superficially alike and are not. Getting this right is most of what separates an agent that works from one that quietly returns the wrong products.

erp_product_search is a catalogue lookup. It answers does this code exist and what does the catalogue hold for these words. It is fast, synchronous and literal: it searches your catalogue and hands back the rows it finds.

erp_product_match is the identification agent. It answers a harder question — which of our products does this customer’s request mean — and it is the same pipeline that produces offers. It handles the customer’s own part numbers, competitor codes, standards and abbreviations, the things that never appear verbatim in your catalogue.

The rule: use erp_product_match whenever the input is a customer’s wording, and erp_product_search only when you already hold a code you trust, or want to see what the catalogue contains. Searching with a customer’s phrasing is the classic mistake; it finds something, and the something is often wrong.

Ten tools. Two of them start an agent run and return an id; the other eight answer immediately.

erp_product_match and erp_offer_create start real work. They return an id immediately and the result arrives minutes later: roughly one to three minutes in fast mode for about 50 lines, three to eight minutes otherwise. Read the result with erp_product_match_get or erp_offer_get.

This is worth telling your agent in its own instructions, because an agent that has not been told will treat the id as a failure and try again. The pattern that works is: call, tell the user roughly how long it takes, then poll rather than re-submit.

User
  Here's an enquiry from Sähkötukku. Can you quote it?
  "Tarvitsemme 20 kpl 16mm2 kuparikaapelia ja 50 kpl KAA 6x1.5"

Agent → erp_customer_search { "query": "Sähkötukku" }
     ← { "number": "K-10042", "name": "Sähkötukku Oy", … }

Agent → erp_offer_create {
         "text": "Tarvitsemme 20 kpl 16mm2 kuparikaapelia ja 50 kpl KAA 6x1.5",
         "customer_number": "K-10042"
       }
     ← { "id": "9f1c0e2a-…", "status": "processing" }

Agent
  Started the offer for Sähkötukku Oy — it usually takes a few minutes.
  I'll check back.

  … a few minutes later …

Agent → erp_offer_get { "offer_id": "9f1c0e2a-…" }
     ← { "status": "processing" }

     … waits, then polls again …

Agent → erp_offer_get { "offer_id": "9f1c0e2a-…" }
     ← { "status": "completed", "result": { "line_items": [ … ] } }

Agent
  Two lines, both matched: MCM-CU16-100 ×20 and KAA-6X15 ×50.
  The draft is waiting for approval in the dashboard.

Nothing an agent does here reaches the end customer, and nothing is booked in the ERP. erp_offer_create produces a draft, and the draft stays a draft until a salesperson opens it in the ERP Agent dashboard and approves it.

This is the property that makes it sane to hand these tools to an agent at all. The worst case of a confused agent is a draft nobody approves, not a wrong price in a customer’s inbox or a bad row in your ERP.

Attachments are uploaded out of band, not through the tool call. Ask for an upload with erp_file_create, POST the bytes to the presigned URL it returns, then reference the id in file_ids on erp_product_match or erp_offer_create.

# 1. reserve
erp_file_create {
  "filename": "bom.xlsx",
  "content_type": "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet",
  "size": 18300000
}

{
  "id": "1c7a…",
  "upload_url": "https://…",
  "upload_fields": { "key": "…", "policy": "…", "x-amz-signature": "…" }
}

# 2. POST the bytes as multipart/form-data:
#    every upload_fields entry first, file last

# 3. reference the id
erp_offer_create { "file_ids": ["1c7a…"], "customer_number": "K-10042" }

A file may be up to 25 MB, and one request may carry up to 20 of them.

A tool call that is refused comes back as an MCP tool result with isError: true, whose text is the same error envelope the REST API uses. Branch on error.code, never on the message text.

{
  "error": {
    "type": "invalid_request_error",
    "code": "missing_query",
    "message": "Provide 'query' or 'code'."
  }
}

Protocol-level problems are different. An unknown tool name or malformed JSON-RPC comes back as a JSON-RPC error rather than as a tool result — the call never reached a tool, so there is no tool result to carry an envelope.

Each key is limited to 60 requests per minute by default. Exceeding it returns rate_limit_exceeded.

Separately, one key may have 5 agent runs in progress at a time — erp_product_match and erp_offer_create counted together. Starting a sixth returns too_many_concurrent_runs, so have your agent queue its work rather than firing a batch at once.

Attachments are capped at 25 MB per file and 20 files per request.