Skip to main content
Glama
Sign In
koble-mcp

koble-mcp

Official
by koblesystems
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

import_from_csv

Validates a CSV or Excel file of EBMS records, maps columns to fields, flags invalid or duplicate rows, and drafts read-only ebms_write calls plus an exceptions workbook for rows needing fixes.

Instructions

Review a CSV or Excel (.xlsx) file of records for one EBMS entity — products, units, vendor records, bills of materials, customers, vendors, workers, folders, tax rates or other configuration — and draft the writes, read-only. Maps each column to a field (from EBMS's live metadata), checks every row (blanks, types, lengths, duplicates, folders, vendors, products and units that do not exist), skips rows already in EBMS or already created by an earlier run of the same import, writes an exceptions workbook holding only the rows that need fixing, and returns the exact ebms_write call for each remaining row. It writes nothing to EBMS. Follow the ebms-import skill: show the mapping, problems and a few drafts, get one clear yes for the file, then call ebms_write for each draft in order. Run it again on the same file (or the corrected exceptions file) to continue: what was created is skipped.

Input Schema

NameRequiredDescriptionDefault
csvNoThe file's CSV text, as the user attached or pasted it.
pathNoPath of the file on this computer: .csv, .tsv, .txt or .xlsx (also an exceptions workbook this tool wrote), up to 20 MB. Hidden files and settings folders are refused. Give this or csv.
sheetNoFor a workbook with several sheets: the one to read. Default: the first.
entityYesWhat the file holds: INVENTRY products; INVENUNT units, INVENDOR vendor records, INVENDET bill-of-materials lines (each row names its product in ID); ARCUST customers; APVENDOR vendors; PYEMP workers; INVENTRE / ARCUSTRE / APVENTRE / PYEMPTRE / PYWORKTRE folders; ARTAX tax rates; or a configuration set.
rowsToNo
companyYesRequired. Company, by ID or name.
mappingNoHeader -> field, overriding the automatic match. Map a header to "" to leave the column out.
defaultsNoField -> value for every row whose cell is blank or whose column is missing, e.g. {"TREE_ID": "26", "C_TYPE": 2}. Only what the user chose: never a guessed folder or classification.
importIdNoContinue an earlier import of the same records from a renamed file: the importId an earlier result gave. Or, when a result reports rows where an earlier run created a different record and the user confirms this is a new file, the newImportId that result offered.
rowsFromNoFirst row number to draft (validation always covers the whole file).
maxDraftsNoAt most this many drafts in one result. Default 200.
failedRowsNoRows whose ebms_write failed in this import, with what EBMS said: they go to the exceptions workbook instead of being drafted again.
exceptionsToNoOnly a path the user named: an .xlsx file to save the exceptions workbook as. Default: beside the file as <name>.exceptions.xlsx.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.0

TDQS

A4.3/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 does so: it discloses that nothing is written to EBMS, that it writes an exceptions .xlsx beside the file, that existing/earlier-created rows are skipped (idempotent continuation), and that it reads EBMS's live metadata for mapping. It even names the downstream contract — a returned ebms_write call per remaining row.

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?

Purpose is front-loaded and every clause carries information — no filler. However, the first sentence is a very long run-on stacking validation steps, skipping rules, workbook writing and return values; bullets or shorter sentences would make the same content far more scannable.

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 13-parameter, nested-object tool with no annotations and no output schema, the description covers the full lifecycle: mapping, validation checks, dedupe, exceptions output, draft return, and resumption. An agent can execute the correct sequence without opening any other documentation.

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 92%, so the schema already does most of the work and 3 is the baseline. The prose still adds real semantics the schema lacks: the importId continuation story (renamed file, newImportId after confirmation), the exceptions workbook destination, and the draft-per-row output loop — enough to lift it above baseline.

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

Purpose4/5

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

States a specific verb and resource: review a CSV/.xlsx file of records for one EBMS entity, validate it, and draft (not perform) writes. The scope is unambiguous, but it never distinguishes itself from sibling importers like po_from_csv or batches_from_csv, so an agent must infer which CSV importer applies to purchase orders or batches.

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?

Explicit about the workflow: follow the ebms-import skill, get one clear yes, then call ebms_write per draft; nothing is written here. It also explains the re-run/continuation case (same file or corrected exceptions file) and which record types it covers. The missing piece is routing guidance against the other *_from_csv siblings.

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

Deploy Server

Other Tools