Skip to main content
Glama
koblesystems

koble-mcp

Official
by koblesystems

ebms_write

Create, update, or delete EBMS ERP records, then verify each write by reading back sent fields and reporting mismatches, problems, and notes.

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 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.

Input Schema

TableJSON 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?

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.