Skip to main content
Glama
koble-mcp

koble-mcp

Official
by koblesystems

ebms_write

Creates, updates, or deletes EBMS records and reads back sent fields to verify writes, reporting mismatches, missing rows, and EBMS-added entries.

Instructions

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, a POST's EXTERNALID already exists (orders, POs, batches, tasks, customers, vendors, products, workers), or a vendor (APVENDOR) POST has no ID. 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; a create resent by EXTERNALID is refused until a read finds it or confirms it is absent.

Input Schema

NameRequiredDescriptionDefault
bodyNoJSON body for POST and PATCH. Omit for DELETE.
pathYesRequired. ARINV for a POST; ARINV('<AUTOID>') for PATCH or DELETE.
methodYes
verifyNoDefault 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.
companyYesCompany, by ID or name as ebms_companies lists them. Required on every write.
readBackNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0-rc.1

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden and does so thoroughly: it discloses refusal conditions, that a 2xx is not proof, that EBMS silently ignores unknown @ids and unwritable fields, the exact verification payload shape (ok, mismatches, problems, notes), and the duplicate risk on resend. This is precisely the behavioral context an agent needs before a mutation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the operation-to-method mapping, then refusal rules, then verification and resend guidance in a logical progression. It is dense and reads as a long block, but nearly every clause carries actionable information, so waste is minimal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and a mutation surface, the description fully specifies the return contract (verification object with ok/mismatches/problems/notes plus stored rows) and the correct reaction to ok:false and uncertain. Nothing essential for calling this correctly is left unexplained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 67%, and the description compensates by explaining nested line semantics (Details for POST, Details@delta array for PATCH), path quoting by AUTOID, and the PROCESS-in-body rejection, none of which appear in the schema. It stops short of detailing every readBack subfield, but adds substantial meaning beyond the structured fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (write to EBMS) and immediately enumerates the three operations with their targets: POST creates, PATCH updates by quoted AUTOID, DELETE removes one. This clearly separates it from the read-oriented sibling ebms_get without the agent needing to open a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-not conditions (company not configured, sandbox mismatch, PROCESS in body, duplicate EXTERNALID, APVENDOR POST missing ID) and routes the agent on what to do when the result is 'uncertain' (read back before resending). It also states the verify default and when to set false, so method selection and follow-up behavior are both covered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.