Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@koble-mcp order 10 tubes from Bike Parts Co"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
EBMS (Koble Systems ERP) for Claude. Ask Claude to enter a sales order, raise or receive a purchase order, set up a product, manage a task, or plan what to buy and make — and it does it in EBMS, confirming each change with you and checking afterwards that EBMS stored what was sent.
It is two things in one install:
A small MCP server that owns the EBMS connection: your credentials, which companies it may touch, and a few hard guards (nothing is ever posted, paid or sent; every write is verified).
Skills — the procedures, written down: how to build an order in chunks, what to confirm,
which EBMS quirks to avoid. They live in skills/, and the server also serves them to Claude
apps that cannot install skills themselves.
One command downloads the koble program (checked against the release's checksums), then
koble setup asks for your EBMS serial number, a test company, your username and your password,
checks that they work, stores the password in your system's credential store, and connects the
Claude apps it finds. Run koble doctor any time to check everything.
In PowerShell (Start menu → PowerShell):
irm https://raw.githubusercontent.com/koblesystems/koble-mcp/master/scripts/install.ps1 | iexIt installs koble.exe to %LOCALAPPDATA%\Programs\koble and adds that folder to your PATH.
The password goes to Windows Credential Manager.
If Windows blocks
koble.exe. Releases are not code-signed yet, so SmartScreen may show "Windows protected your PC" — choose More info → Run anyway. On Windows 11 with Smart App Control turned on, unsigned programs are blocked outright; until signed builds are published, use a machine or VM without Smart App Control. Please don't turn it off just for this.
In Terminal:
curl -fsSL https://raw.githubusercontent.com/koblesystems/koble-mcp/master/scripts/install.sh | bashIt installs koble to ~/.local/bin (Apple silicon). The password goes to the macOS Keychain.
Intel Macs are not built yet.
curl -fsSL https://raw.githubusercontent.com/koblesystems/koble-mcp/master/scripts/install.sh | bashx64 and arm64. The password goes to the Secret Service keyring when secret-tool is available,
otherwise to a file in ~/.config/koble that only you can read. Claude Desktop does not run on
Linux; use Claude Code.
Either run the installer above (setup installs the plugin for you), or add it from Claude Code:
claude plugin marketplace add koblesystems/koble-mcp
claude plugin install koble-mcp@koblesystemsThen ask Claude to "set up Koble" (or run /koble-mcp:koble-setup): it installs the program,
saves your settings, and has you type the password into koble login yourself — the password
never goes through the chat.
Point any coding agent at install.md. It is written to be followed step by step.
Claude Desktop: quit and reopen it.
Claude Code: start a new session (or run /mcp).
Ask: "Which EBMS companies can you see?" — Claude should name them.
Settings live in ~/.config/koble (%APPDATA%\koble on Windows). koble update installs the
newest release; koble setup again changes any answer.
Related MCP server: PrintSmith MCP Server
Ask in your own words — "order 10 tubes from Bike Parts Co", "what's open for the bike shop?", "run MRP for the next 60 days" — or start a named workflow:
Workflow | Claude Code | Claude Desktop |
Plan what to buy and make |
| the prompt menu (＋) → koble-mcp |
Create the POs / batches an MRP worksheet approved |
| same |
Sales order, purchase order, receiving, what's on order |
| same |
Products and tasks |
| same |
With the plugin, each skill is also a command in Claude Code, e.g. /koble-mcp:ebms-mrp.
What is safe. Planning is read-only: mrp_plan, mrp_item_view, po_from_csv and
batches_from_csv never write to EBMS. Purchase orders and batches are only created by the second
and third skills, one at a time, after you say yes to each. With EBMS_SANDBOX set, writes can only go to that company: the company is part of a URL
this server builds itself, and a request that would land anywhere else is refused before it is
sent. Leave it set while testing. The PROCESS field is refused in every request body, and
ebms_command runs only a short list of actions, none of which posts, pays or sends.
Testing it? TESTING.md has a checklist and what to send back.
Tool | What it does | Refuses |
| Lists the companies the serial reaches — ID, name, version, and whether writes are allowed. Needs no credentials. | — |
| One GET: a collection or a record, with | anything but |
| One POST, PATCH or DELETE with a JSON body. | a company that is not configured (or not the sandbox, while testing); |
| One bound action: | a company that is not configured (or not the sandbox, while testing); any action that is not on the allow-list ( |
| Serves the skills: the list, one skill, or one reference file. Lets Claude Desktop use them without uploading anything. | — (read-only; only the files it shipped with) |
| Planning and worksheet reading (see Planning). | — (read-only) |
Every result names the company it ran against. Every failure carries uncertain and says
what it means:
uncertain: false with refused: true — this server stopped it, a check before the write
failed, or it could not sign in. Nothing was sent.
uncertain: false with an error.status — EBMS answered and said no. Nothing was saved.
uncertain: true — a timeout, a dropped connection, a response that broke off part-way, a
5xx, a 2xx carrying an error message, or a fault inside this server after the request had gone out. The write may or may not have happened, so read
the record back before sending it again. A resent create or add duplicates.
Paths are parsed and rebuilt, not passed through. The entity name is validated; each key
value may not contain / \ ? %, .. or control characters, and is percent-encoded (so a #
in a PO number is data, not a URL fragment). As a second check the client refuses any finished
URL that is not inside the company's own OData root. That is what makes the company boundary
hold even against text a model was tricked into using.
Actions are allowed by name, not refused by name. EBMS has many bound actions that post,
process, pay or send (ProcessScanner, Post, Unpost, RecordPayment, Send, …); a list of
those could never be complete, so ebms_command runs only EBMS_ALLOWED_COMMANDS — by default MarkAllAsShipped, RecalculateAllPrices, CalculateFreight, ChangeCustomer and LinkInvoice.
A 2xx is not proof. EBMS answers 200 to writes it only partly applies: an unknown @id is
ignored, an unwritable field is dropped, an over-long value is cut, a quantity can come back
as 0. So after each write the server reads back exactly the fields that were sent and
compares them in code — numbers within half a cent, strings ignoring padding and line-ending
style — instead of leaving the arithmetic to a model:
"verification": {
"ok": false,
"checked": 6,
"mismatches": [{ "where": "Details[1] › Materials[2] TEAMJERSEY", "field": "M_QUAN_VIS", "sent": 1, "stored": 0 }],
"problems": [],
"notes": [],
"rows": [ … the stored values of every row the write touched or created … ]
}mismatches — a field stored differently from what was sent.
problems — a row that never appeared, an @id EBMS ignored, a removal that didn't happen.
notes — rows EBMS added on its own, such as an assembly kit's default components. Not a
failure. Pass readBack.children: "Materials" to have new rows checked for them.
rows — what EBMS stored, including anything asked for in readBack.lines
(UNIT_MEAS,UNIT_VIS,SO_AMOUNT) or readBack.record. Report these, not what was sent.
It is generic: it understands OData's shapes (top-level fields, Nav@delta arrays, nested
arrays on a create) and knows nothing about any one entity. New rows are told apart from old
by a light read of row IDs before a PATCH; children are read only for the parent rows the
write touched, because an unfiltered nested expand costs EBMS tens of seconds on a large
document. If the write succeeds and only the read-back fails, the result says exactly that
and tells the caller not to resend. verify: false switches it off.
The write result no longer echoes EBMS's whole record (about a hundred fields); it returns
the record's AUTOID, INVOICE and ID plus the verification.
Two read-only tools sit beside the proxy, for the same reason write verification does: it is arithmetic over hundreds of rows that has to be exact.
Tool | What it answers |
| What to buy and make, by when, and why — for a time frame and a scope (everything, particular vendors, or particular products) that the user gives. It will not assume either. The worksheet comes back attached to the result, so it can be handed to the user in the conversation. |
| Everything needed to build N of one finished good, down every BOM level, against what is available. |
| Reads the planner's approved worksheet and drafts one purchase order per vendor. Creates nothing; the drafts go through |
| Reads the approved |
What is read, and how it is netted (worked out against SBX with someone who knows the database):
Demand — open sales (S) and job (J) lines from ARINVDET, QUAN − SHIP in base units,
dated by the line's SHIP_DATE. A line with a materials list underneath is skipped in favour
of its children. Open batches' consumables (INMFG → ARINVDETs) are demand too.
Supply — open purchase lines through APINV → Details (O_QUAN_VIS − SHIP_VIS), and
open batches' finished goods (INMFG → FinishedDetails, where SHIP_VIS is the quantity
made so far). These are in the line's unit and are converted to base units from INVENUNT.
Parameters — T_ON_HAND, MIN_INVEN (floor), MAX_INVEN (order up to), ORDER_AMT
(reorder increment), PRI_VENDOR, PURC_METH from INVENTRY. Only stocked products and
stocked lines are pooled; drop-ship, sync and associated lines belong to their own orders.
Made or bought — an item is manufactured if it has ever been a batch's finished good;
alsoMade and buyInstead override that for a run. Made items explode through INVENDET,
level by level, so a made component of a made item is planned too.
Two rules for shortage — a projected stock-out pulls in a later receipt (an expedite
message) or plans a dated order; being under the minimum only matters if it is still under at
the end of the time frame. (QUAN2ORDER on the product is not a formula to match: it is
whatever EBMS's own purchasing screen last saved. The worksheet shows it as a reference.)
A receipt with no expected date is counted on the last day of the time frame — late enough that it cannot quietly cover a shortage it may not arrive for, early enough to count toward the minimum. Where it is needed sooner, the plan asks the buyer to confirm it by that date.
What is already on order just after the time frame is not netted, but it is shown: on the worksheet, and beside any item the plan says to buy.
Lead time — kept per product vendor in EBMS (the LEAD_DAYS column, according to Koble) but not published through the API,
so orders carry a needed-by date. leadTimeDays / leadTimes supply it when the user knows.
Manufacturing batches. What creating test batches in EBMS showed, and the drafts are built on:
the finished good must be a Track Count product (anything else is refused); EBMS does not add
consumed materials itself when a batch arrives through the API, as its own screens do, so every
component is sent from INVENDET; and a consumed line's M_QUAN_VIS is the amount for one
finished good, which EBMS multiplies by the batch size. Drafts mark nothing as made or consumed,
state each line's unit, take the warehouse the planner gives or the one the product was last made
in, and carry an EXTERNALID of the run plus the worksheet line so a batch cannot be created
twice (INMFG is covered by the duplicate guard alongside ARINV, APINV and TASK).
The worksheet. mrp_plan writes a CSV (to KOBLE_OUTPUT_DIR, or Documents/Koble MRP) with
every planned item: its status, the recommendation (EXPEDITE, BUY, MAKE, NOT NEEDED, OK),
the numbers behind it, and for purchases the vendor, part number, purchase unit, order quantity in
that unit and cost from INVENDOR (the product's own stock unit when the vendor has none, stated
on the order so EBMS cannot default to a case). A planner edits Order Qty, Approve, Vendor and Notes in a spreadsheet and hands it back.
Spreadsheets reformat dates, turn long numeric product IDs into 3.94E+13 and drop leading
zeros, so the file is not trusted for anything the planner was not meant to edit: mrp_plan
also saves a small run record (runs/<run>.json beside the worksheet), and po_from_csv
takes the item, unit, cost and date from it, keyed by the row's Line. Each row also carries a
Check code over its run, line and product, so a Run cell changed on every row, a worksheet
re-pointed at another run, or a row typed in by hand is refused with or without the record.
A line the planner moves to another vendor has its quantity converted through stock units into
that vendor's unit (2 cases of 24 become 48 each), and says so. Rows added by hand,
duplicated rows, a changed Run cell, unrecognised Approve text and ambiguous quantities
(1,5, 1e3) are named as problems, and each draft lists what the planner changed. If the
record cannot be found (the file moved to another computer) the file is read strictly and the
result says so. Drafts do not send an expected date: on the purchase orders created so far, EBMS stored its own
ETA_DATE (apparently from the vendor's lead time) and ignored the one sent, so the read-back reports it and the skill compares it with the day
the stock is needed. po_from_csv checks each approved row against EBMS, names
any it cannot order (no vendor, zero quantity, inactive product), and drafts one purchase order per
vendor whose EXTERNALID is the run plus the vendor, so the same worksheet cannot order twice.
The file is written and read by code so the numbers a person approves are the numbers ordered.
The engine (src/mrp/engine.ts), the finished-good view (src/mrp/tree.ts) and unit conversion
(src/mrp/units.ts) are pure and unit-tested; src/mrp/snapshot.ts does the reads. A 60-day
plan of SBX takes about 30 s, nearly all of it EBMS answering six reads one after another.
One server can serve several companies on the same serial number.
EBMS_SERIAL_NUMBER=...
EBMS_USERNAME=...
EBMS_PASSWORD=...
EBMS_COMPANIES=sbx,live # optional: narrow to these IDs; unset = every company the serial reaches
EBMS_SANDBOX=sbx # optional, while testing: writes go only here
EBMS_COF_USERNAME=... # optional per-company credentials
EBMS_COF_PASSWORD=...
EBMS_ALLOWED_COMMANDS=MarkAllAsShipped,RecalculateAllPrices,CalculateFreight,ChangeCustomer # optional; this is the default
EBMS_LOG_FILE=./logs/requests.jsonl # optional; method, path, company, status, ms — never bodiesUsers rarely know a company's internal ID, so the server discovers the companies itself: at
startup it asks the serial's unauthenticated company-list endpoint, and ebms_companies
shows the result with names. Every company argument accepts the ID or the name
("Sample Coffee Co"). EBMS_COMPANIES is only needed to narrow that list.
Every available company may be read and written. EBMS_SANDBOX is for testing:
when set, writes go only to that one company, which is readable by implication and need not
be repeated in the list. With one company configured, company may be omitted on reads; on
writes and commands it is always required, and with several companies it is required
everywhere. EBMS_COMPANY_ID (the variable ebms-mcp used) is still honoured.
Nothing in EBMS marks a dataset as live or a copy. Listing a live company means a model can write to it, so the skills' rule of showing the exact request and getting a yes before every write is what protects it — together with the guards below, which are the mistakes a confirmation step does not catch.
Needs Node 22.
git clone https://github.com/koblesystems/koble-mcp.git
cd koble-mcp
npm install
npm run check # builds, then runs the tests; none of them touch the network
node cli.js setup # the same setup, run from source
node scripts/build-single.mjs # the single-file koble for this platform, in dist/The root .mcp.json is the plugin's server entry (Claude Code only picks one up from the plugin root); if you open this repo in Claude Code it will offer to start koble mcp for the project, which you can decline.
The server reads EBMS_* settings from its environment when they are set (see .env.example),
and otherwise from what koble setup stored — so an existing configuration that passes them in
an MCP client's env block keeps working. A release is cut by pushing a tag vX.Y.Z that matches
package.json; the release workflow builds koble for Windows, macOS and Linux and publishes it
with checksums.txt.
The server never decides. No chunking, no resume logic, no planning. Those were the parts that went wrong in the previous design, and they are the parts a skill can fix without a rebuild and a restart. What it does do in code is arithmetic nobody should trust a model with: comparing what was stored against what was sent.
The guards are the ones a model skips under pressure, and only those: an
unconfigured company, PROCESS, duplicate EXTERNALID, actions off the allow-list, and
anything in a path that could leave the company.
Uncertainty is explicit. Timeouts, network failures and 5xx responses are labelled so a skill can tell "EBMS said no" from "nobody knows".
Credentials stay in the process. They are read once, per company, and never enter a result, an error or the log.
stdout belongs to JSON-RPC. Log with console.error only.
MIT — see LICENSE. Security reports: see SECURITY.md.
Turn approved MAKE rows of an MRP worksheet into manufacturing-batch drafts, read-only. For each it checks EBMS will accept the product as a finished good (it must be classified Track Count), lists every component from the bill of materials with its quantity per one finished good (EBMS does NOT add consumed materials itself when a batch arrives through the API), picks the warehouse (the one given, else where the product was last made), and returns the exact body to POST to INMFG with ebms_write. It creates nothing. Drafts mark nothing as made or consumed and never carry PROCESS: finishing and processing a batch is done by a person in EBMS. Show each draft and get a clear yes before writing it.
| Name | Required | Description | Default |
|---|---|---|---|
| csv | No | The worksheet's CSV text, exactly as the user attached or pasted it. | |
| path | No | Path of the worksheet CSV on this computer. Give this or csv. | |
| company | Yes | Required. Company, by ID or name. Must match the worksheet's company. | |
| warehouse | No | Warehouse ID for every batch. ASK the user if they have more than one; when omitted, each product's batch goes where it was last made. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and succeeds. It discloses that EBMS will only accept products classified as Track Count, that consumed materials are not added automatically, that no PROCESS step is included, and that nothing is created or marked as made or consumed. This is unusually transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every clause earns its place. It front-loads the core purpose and read-only nature, then efficiently explains checks, BOM behavior, warehouse selection, and the required confirmation step without unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, yet the description explains what will be returned: the exact body to POST to INMFG with ebms_write. It also covers prerequisites, edge cases like warehouse fallback, and safety expectations, making the tool fully understandable for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful behavioral context beyond field names: the warehouse falls back to the last place the product was made, the company must match the worksheet, and the CSV is the raw worksheet text. This helps an agent invoke parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Turn approved MAKE rows of an MRP worksheet into manufacturing-batch drafts.' It also explicitly says 'read-only' and 'It creates nothing,' which clearly distinguishes it from siblings like ebms_write and po_from_csv.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly defines when to use the tool: on approved MAKE rows, producing drafts, and instructs the agent to 'Show each draft and get a clear yes before writing it.' It does not explicitly enumerate when-not-to-use each sibling, but the read-only draft workflow and reference to POSTing via ebms_write make the intended usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a bound action on one record: POST /ENTITY('')/Model.Entities.. Omit body for a command with no dialog (MarkAllAsShipped, RecalculateAllPrices) — EBMS rejects even {}. Pass the dialog's fields for one that has a dialog (ChangeCustomer). Refused for a company that is not configured (or not the sandbox, while testing), and for any action that is not on the server's short allow-list — nothing that posts, processes, pays or sends. Commands return little; read the record back afterwards.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Required. AUTOID of the record. | |
| body | No | Dialog fields, only for commands that have a dialog. | |
| entity | Yes | Required. The entity, e.g. ARINV | |
| command | Yes | Required. The action name, e.g. MarkAllAsShipped, RecalculateAllPrices, ChangeCustomer | |
| company | Yes | Company, by ID or name as ebms_companies lists them. Required on every write. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers strong transparency: it discloses the HTTP POST method, the fact that EBMS rejects even an empty {} for no-dialog commands, server-side allow-list restrictions (nothing that posts, processes, pays or sends), and that commands return little data. This gives an agent a clear behavioral profile before invoking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: purpose, endpoint, body rules, restrictions, and return behavior are packed into a compact, front-loaded description with no redundancy. The critical nuance about omitting the body is stated early, and the allow-list restriction is explained clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, a nested body, and no output schema, but the description covers all tricky invocation details: body omission, allow-list restrictions, and the fact that commands return little, directing the agent to read the record back. This compensates for the missing output schema and leaves the agent well-equipped to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaningful nuance: it explicitly says to omit the body for no-dialog commands and that EBMS rejects even {}, which goes beyond the schema's generic 'Dialog fields, only for commands that have a dialog.' It also adds the configured-company/sandbox restriction and gives concrete command values for the command parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair, 'Run a bound action on one record,' and gives the exact endpoint pattern, POST /ENTITY('<AUTOID>')/Model.Entities.<Command>. Concrete examples like MarkAllAsShipped and ChangeCustomer differentiate this from sibling tools such as ebms_write or ebms_get, so an agent can identify its purpose without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when the command will be refused (unconfigured company, non-sandbox during testing, actions not on the allow-list) and advises reading the record back afterwards, implying a follow-up read via another tool. However, it never explicitly names sibling tools or states when to choose this over ebms_write/ebms_get; the alternative usage is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the companies (datasets) this server can reach on its EBMS serial number, with name, ID, version and whether writes are allowed. Needs no credentials. Call it when the user names a company you haven't seen, or before the first write of a session, so the company is confirmed by name. Nothing marks a company as live or a test copy; ask if unsure.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well: it discloses that no credentials are needed, and it surfaces the key limitation that nothing marks a company as live or test. The 'list' verb implies read-only and the output fields are enumerated. It stops short of explicitly stating a lack of side effects, but coverage is strong for a listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: what it lists, when to call it, and the live/test caveat. The most important scoping information is front-loaded and there is no filler or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema and no annotations, the description is complete. It enumerates the returned fields in prose, covers authentication requirements, gives trigger conditions, and flags ambiguity about live vs. test copies. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and the schema is empty, so there is nothing to elaborate. Per the baseline for 0-parameter tools, a 4 is appropriate; the description correctly avoids inventing input details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List the companies (datasets) this server can reach') plus the exact fields returned (name, ID, version, write permission). The specifics of a company catalog listing clearly set it apart from siblings like ebms_get, ebms_write, and ebms_command, so an agent can distinguish it without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit, actionable when-to-call guidance: 'Call it when the user names a company you haven't seen, or before the first write of a session.' It also warns that no marker distinguishes live vs. test copies and to ask when unsure. It does not name alternatives or when-not conditions, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read from EBMS OData: a collection (path 'ARINV') or one record (path "ARINV('')"). Always pass select — an unselected read returns every field, many computed, and large ones hit the 2-minute limit. For a collection, count is on by default and the result says whether rows were truncated. Query syntax and the install's quirks are in the ebms-api skill.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | ||
| path | Yes | Required. Entity path only, e.g. ARINV, ARINV('7XQPR42LM8W91000'), EntityMetaData('ARINV'), $metadata. No query string. | |
| skip | No | ||
| count | No | Ask for @odata.count. Default true for collections. | |
| expand | No | ||
| filter | No | $filter, unencoded. | |
| select | No | $select, comma-separated. Include one inside expand too: Details($select=AUTOID,INVEN). | |
| company | No | Company, by ID or name as ebms_companies lists them. May be omitted only when one company is available. | |
| orderby | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and delivers meaningful behavioral disclosure: unselected reads return every field including computed ones, large reads risk a 2-minute limit, count defaults on for collections, and results indicate truncation. This is genuine operational behavior not present in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with purpose, followed by the most operationally critical guidance (select necessity and timeout risk), then count/truncation behavior, ending with a pointer to the skill for depth. Every sentence earns its place with zero filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter tool with no annotations and no output schema, the description covers the critical failure modes (unselected reads, 2-minute limit, truncation) and defers query syntax and install quirks to the ebms-api skill, which compensates for depth. Remaining gaps like expand/orderby semantics are reasonably left to schema and skill.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 56%, so the description must compensate, and it does: path receives explicit syntax examples for both modes, select gets a mandatory-use directive with reasoning, and count gets its default-behavior note. These add real meaning beyond the schema's bare descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair ('Read from EBMS OData') and concretely defines the tool's two invocation forms with real path examples ('ARINV' for collections, "ARINV('<AUTOID>')" for single records). It is clearly differentiated from writes/commands by its 'Read' positioning, though no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong how-to-call guidance ('Always pass select', count defaults on, truncation is reported, query syntax is in the ebms-api skill), but it never states when to prefer this tool over ebms_write, ebms_command, or other siblings, nor does it give exclusions. Usage is implied rather than explicitly routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The procedures for working with EBMS through this server: how to build and change sales orders and purchase orders, receive stock, manage products and tasks, and run MRP. Call it before any task beyond a single read, unless the matching skill is already loaded in this app. With no arguments it lists the skills; with skill it returns that skill; with file it returns one of the skill's reference files. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | A file a skill refers to, as listed, e.g. ebms-purchase-orders/references/receive.md. | |
| skill | No | A skill name from the list, e.g. ebms-purchase-orders. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does carry some of the safety burden by stating 'Read-only' and by explaining the three invocation modes (no args, skill, file). It does not, however, disclose failure modes, behavior when both parameters are supplied, or whether the returned skill/file content has any special structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the tool's purpose, followed by use conditions and invocation modes. Slightly dense but no wasted words. Information is logically ordered.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a guidance tool with no output schema, the description covers purpose, when to call, and invocation modes. It leaves gaps around what 'skill loaded' means, what the list output looks like, and how this relates to specific sibling tools like ebms_get or ebms_write.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already documented. The description reinforces that skill and file each correspond to a reference mode but adds no additional format or interaction semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as the EBMS procedures/guide: it explains sales/purchase orders, stock, products, tasks, and MRP. It differentiates by stating it returns skills/files and is read-only, unlike the operational sibling tools. However, the core verb is 'call it' rather than a domain verb, so it is clear without being maximally explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger: 'Call it before any task beyond a single read' and a conditional exception when 'the matching skill is already loaded.' It does not name the sibling tools directly or specify how to determine whether a skill is loaded, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write to EBMS: POST creates a record (documents take their lines nested as Details), PATCH updates one by quoted AUTOID (lines via a Details@delta array), DELETE removes one. Refused for a company that is not configured (or not the sandbox, while testing), and refused if the body carries PROCESS anywhere or a POST's EXTERNALID already exists. A 2xx is not proof — EBMS silently ignores unknown @ids and unwritable fields — so the server reads back the fields you sent and returns a verification: ok, mismatches (sent vs stored), problems (a row that never appeared or was not removed), notes (rows EBMS added itself) and the stored rows. Treat ok:false as a partly failed write and tell the user. If the result says uncertain, read back before resending — a resent create or add duplicates.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | JSON body for POST and PATCH. Omit for DELETE. | |
| path | Yes | Required. ARINV for a POST; ARINV('<AUTOID>') for PATCH or DELETE. | |
| method | Yes | ||
| verify | No | Default true: after the write the server reads back exactly the fields you sent and reports each mismatch. Set false only for a write whose result you will read yourself. | |
| company | Yes | Company, by ID or name as ebms_companies lists them. Required on every write. | |
| readBack | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and succeeds: it discloses non-obvious EBMS behaviors such as silently ignoring unknown @ids and unwritable fields, 2xx not being proof of success, and the exact verification response shape. It also explains ok:false semantics and the duplicate risk of resending, which are critical for correct use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences cover method semantics, refusal conditions, verification behavior, and retry guidance without filler. The most important behavioral caveats are front-loaded, and every clause contributes operational value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex mutation tool with 6 parameters and no output schema, the description is complete: it covers return values, failure modes, verification fields, retry policy, and company/sandbox restrictions. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, and the description compensates strongly: it explains how body lines work for POST (nested as Details), how PATCH lines are expressed via Details@delta, why verify exists, what readBack fields return, and which body contents are rejected. This adds meaning the schema does not provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource, 'Write to EBMS', then immediately distinguishes the three mutation operations (POST creates, PATCH updates, DELETE removes). This clearly marks it as the write counterpart to sibling read tools like ebms_get and separates it from ebms_command.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit operation selection via path and method, and states concrete refusal conditions (unconfigured company, PROCESS in body, duplicate EXTERNALID). It also tells when not to use verification ('Set false only for a write whose result you will read yourself'), but it does not explicitly name sibling tools as alternatives for read-only work.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The total view of one finished good, read-only: everything needed to build a quantity of it, down every level of its bill of materials, against what is available (on hand + incoming − on order). Stock of a sub-assembly covers its branch before anything is exploded further, and a part used in two branches is only counted once. Returns an indented tree, what to make, what to buy, and canBuildWithoutBuying: true when every purchased part is available, even if sub-assemblies still have to be made from them.
| Name | Required | Description | Default |
|---|---|---|---|
| qty | Yes | Required. How many to build. | |
| item | Yes | Required. Product ID of the finished good. | |
| company | No | Company, by ID or name. May be omitted only when one company is available. | |
| alsoMade | No | Product IDs to treat as manufactured although they have never been on a batch. | |
| buyInstead | No | Made products to plan as purchased for this run (not exploded into components). | |
| availability | No | 'available' (default) = on hand + incoming − on order; 'onHand' = what is on the shelf now. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It clearly discloses read-only behavior, the netting formula (on hand + incoming − on order), the branch-stopping rule for sub-assemblies, the once-only counting of parts used in two branches, and the canBuildWithoutBuying flag. This is rich behavioral context beyond a simple 'view' label.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that front-loads the core purpose and read-only nature, then explains key behaviors. It is efficient and every sentence adds value, though it is slightly long and could be broken into two sentences for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only view tool with no output schema, the description explains the return shape (indented tree, what to make/buy, canBuildWithoutBuying) and the key calculation rules. It does not detail pagination or exact output fields, but the core semantics an agent needs to invoke and interpret the tool are present. The absence of annotations raises the burden, and the description mostly meets it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all six parameters. The description adds context for the overall semantics (e.g., how availability is calculated, how alsoMade/buyInstead affect the explosion) but does not add per-parameter details beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('view'), a resource ('one finished good'), and a precise scope: everything needed to build a quantity down every BOM level, against availability. It clearly distinguishes itself from siblings like mrp_plan by focusing on a read-only total view of one finished good.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when you need a complete indented tree of what to make/buy for a single finished good and whether it can be built without buying. It does not explicitly name alternatives or exclusions, but the read-only framing and single-finished-good scope provide clear context. Sibling names like mrp_plan suggest a broader planning tool, but the description doesn't explicitly contrast them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Material requirements plan for one company, read-only: nets open sales and job demand, open manufacturing batches and open purchase orders against stock, day by day, through the bill of materials, and returns what to buy and make, by when, and why. ALWAYS ask the user two things first and never assume either: the time frame (through, or days) — 'buy and make what is needed to cover everything due by this date' — and the scope: everything, particular vendors, or particular products. EBMS does not publish vendor lead times, so orders carry a needed-by date; pass leadTimeDays only if the user gives one. Only stocked products and stocked lines are planned; drop-ship, associated and sync lines belong to their own orders. The planner's worksheet comes back attached as CSV: give it to the user as a file in the conversation, unchanged.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Time frame as days from today. Give this or through. | |
| items | No | With scope 'products': the product IDs to report. | |
| scope | No | Required. ASK the user: everything, particular vendors, or particular products? Buyers often work one vendor at a time. The whole company is always planned; the scope decides what is reported. | |
| inChat | No | Default true: attach the worksheet's CSV to this result. | |
| saveTo | No | Folder for the worksheet. Default: KOBLE_OUTPUT_DIR, or 'Koble MRP' in the user's Documents. | |
| company | No | Company, by ID or name. May be omitted only when one company is available. | |
| maxRows | No | Rows per section in this result, default 25. The worksheet always has every row. | |
| through | No | Last date to cover, yyyy-mm-dd. Give this or days. | |
| vendors | No | With scope 'vendors': vendor IDs or names. A product belongs to its primary vendor. | |
| alsoMade | No | Product IDs to treat as manufactured although they have never been on a batch. | |
| leadTimes | No | Lead time in days per product ID, overriding leadTimeDays. | |
| worksheet | No | Default true: write the planner's worksheet (CSV). | |
| buyInstead | No | Made products to plan as purchased for this run (not exploded into components). | |
| includeJobs | No | Count job transfers as demand. Default true. | |
| minimumRule | No | How an item that ends the time frame under its minimum is restored. when-crossed (default): the minimum is a reorder point, so the order is dated the day the item went under and can replace an expedite. by-end: the minimum is a level to be back at by the end of the time frame, so the order is dated its last day. It is a company policy; ask once. | |
| leadTimeDays | No | A lead time to assume for every item, only if the user states one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It explicitly says the tool is read-only, requires upfront user clarification, discloses that EBMS does not publish vendor lead times, and explains that drop-ship/associated/sync lines are excluded. It also tells the agent how to deliver the CSV attachment unchanged, leaving little room for surprise.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and front-loaded with the core purpose, then delivers behavioral constraints and output handling. Every sentence earns its place, though it is one long block and could be lightly structured. For a tool with 16 parameters and mandatory user-interaction steps, the length is reasonable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given high complexity, no output schema, and no annotations, the description covers the essential operational context: what the planner returns, that the worksheet comes back as CSV, and that it must be given to the user unchanged. It does not enumerate every parameter or return section, but the schema already documents all parameters, and the description covers key exclusions and required user questions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds decision context beyond the schema: the time frame is expressed as through or days, leadTimeDays should only be passed when the user gives one, scope controls reporting while the whole company is always planned, and only stocked items are considered. This materially helps an agent choose and fill parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: it produces a material requirements plan for one company, read-only. It clearly explains the planning logic (nets sales, jobs, batches, purchase orders, stock, BOM) and what it returns, which distinguishes it from generic EBMS data-access tools and mrp_item_view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit interaction instructions: ALWAYS ask the user for the time frame and scope first and never assume either. It also warns to pass leadTimeDays only if the user states one and limits planning to stocked products and lines. It does not explicitly route to alternatives like mrp_item_view, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn an approved MRP worksheet into purchase-order drafts, read-only. Reads the CSV mrp_plan produced, after the planner set Approve to Y on BUY rows (and perhaps changed Order Qty or Vendor); checks every vendor and product against EBMS; and returns one draft per vendor with the exact body to POST to APINV with ebms_write. It creates nothing. A worksheet handed in twice cannot order twice: ebms_write refuses the duplicate EXTERNALID. Show the drafts and get a clear yes per purchase order before writing.
| Name | Required | Description | Default |
|---|---|---|---|
| csv | No | The worksheet's CSV text, exactly as the user attached or pasted it. | |
| path | No | Path of the worksheet CSV on this computer. Give this or csv. | |
| company | Yes | Required. Company, by ID or name. Must match the worksheet's company. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so well: it clearly states the tool is read-only, creates nothing, checks every vendor and product against EBMS, returns the exact POST body, and explains duplicate protection via ebms_write refusing duplicate EXTERNALID. This is strong behavioral disclosure for a potentially costly workflow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and well-structured, front-loading the core purpose and read-only safety. There is minor redundancy between 'read-only' and 'It creates nothing,' but each clause still contributes useful constraints, so it remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no output schema and no annotations, this covers the essential context: input source, approval precondition, internal checks, output shape (one draft per vendor with a POST body), and the confirmation guardrail. It doesn't spell out the exact draft data structure or error messages, but the agent has enough to use it correctly in the workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents csv, path, and company. The description adds useful context that csv is the mrp_plan worksheet and must contain approved BUY rows, but it doesn't add meaningful format or syntax details beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: turn an approved MRP worksheet CSV into per-vendor purchase-order drafts. It clearly distinguishes itself from siblings by emphasizing read-only behavior, its CSV source from mrp_plan, and its relationship to ebms_write for the actual POST.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the precondition: the worksheet must come from mrp_plan with Approve set to Y on BUY rows, and optionally changed Order Qty or Vendor. It also gives workflow guidance: show drafts and get confirmation before writing. It doesn't explicitly name alternatives or say when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0-rc.1batches_from_csvebms_commandebms_companiesebms_getebms_guideebms_writemrp_item_viewmrp_planpo_from_csvScored across 9 tools
Each tool has a distinct purpose: generic EBMS reads writes and commands, company discovery, MRP planning at company or item level, CSV-to-draft conversion for purchase orders vs batches, and procedural guidance. The two CSV tools are separated by purchase orders vs manufacturing batches, and mrp_plan vs mrp_item_view differ by aggregate vs single-item scope.
The tools fall into recognizable clusters like ebms_* for API operations and mrp_*/csv workflow tools, which keeps names readable, but they mix verb-style names like ebms_get and ebms_write with noun-style names like ebms_command and mrp_plan. The naming is understandable and grouped by prefix, yet not a uniform verb_noun convention.
Nine tools is a well-scoped set for an EBMS/MRP integration server. Each tool covers a necessary part of the workflow—read, write, command, planning, CSV draft conversion, company discovery, and guidance—without redundant or filler tools.
The tool surface covers the core MRP-to-order workflow well: planning, item-level explosion, CSV draft generation, generic OData read/write, command execution, and procedural documentation. The main gap is a lack of dedicated higher-level workflow helpers beyond generic EBMS write operations, but those are workable with ebms_get and ebms_write.
Connect Claude or Cursor to books, invoices, bills, payroll, and sealed closes.
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
Give Claude only the Google Drive files you choose. Every action logged.
Connect AI to store orders, products and inventory with scoped access and human approvals.
