Skip to main content
Glama
Sign In
koble-mcp

koble-mcp

Official
by koblesystems
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

mrp_plan

Generates a read-only material requirements plan for a chosen timeframe and scope, netting sales, job, batch, and purchase data through the BOM to show what to buy or make, by when, and why.

Instructions

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. Lead times come from EBMS: the product's vendor record (INVENDOR.LEAD_DAYS), else the vendor's (APVENDOR.LEAD_DAYS); 0 means not set. A purchase with a lead time gets an order-by date; one without carries only its needed-by date. Pass leadTimes or leadTimeDays only for figures the user gives. Only stocked products and stocked lines are planned; drop-ship, associated and sync lines belong to their own orders. The planner's worksheet is an Excel workbook saved on this computer (worksheet.savedAt): give the user that path; they approve rows in it. A CSV copy of its rows is attached for reading only.

Input Schema

NameRequiredDescriptionDefault
daysNoTime frame as days from today. Give this or through.
itemsNoWith scope 'products': the product IDs to report.
scopeNoRequired. 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.
inChatNoDefault true: attach a CSV copy of the worksheet's rows to this result, for reading.
saveToNoFolder for the worksheet. Default: KOBLE_OUTPUT_DIR, or 'Koble MRP' in the user's Documents.
companyNoCompany, by ID or name. May be omitted only when one company is available.
maxRowsNoRows per section in this result, default 25. The worksheet always has every row.
throughNoLast date to cover, yyyy-mm-dd. Give this or days.
vendorsNoWith scope 'vendors': vendor IDs or names. A product belongs to its primary vendor.
alsoMadeNoProduct IDs to treat as manufactured although they have never been on a batch.
leadTimesNoLead time in days per product ID, from the user; overrides EBMS's figure for that product.
worksheetNoDefault true: write the planner's worksheet (an Excel workbook).
buyInsteadNoMade products to plan as purchased for this run (not exploded into components).
includeJobsNoCount job transfers as demand. Default true.
minimumRuleNoHow 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.
leadTimeDaysNoA lead time for items EBMS has none for (and for made items), only if the user states one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.1.0
    • changedInput schema / properties / inChat / description
      Previous value: -"Default true: attach the worksheet's CSV to this result."New value: +"Default true: attach a CSV copy of the worksheet's rows to this result, for reading."
    • changedInput schema / properties / leadTimeDays / description
      Previous value: -"A lead time to assume for every item, only if the user states one."New value: +"A lead time for items EBMS has none for (and for made items), only if the user states one."
    • changedInput schema / properties / leadTimes / description
      Previous value: -"Lead time in days per product ID, overriding leadTimeDays."New value: +"Lead time in days per product ID, from the user; overrides EBMS's figure for that product."
    • changedInput schema / properties / worksheet / description
      Previous value: -"Default true: write the planner's worksheet (CSV)."New value: +"Default true: write the planner's worksheet (an Excel workbook)."
  2. 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 does so: it declares the operation read-only, explains that only stocked products/lines are planned and that drop-ship, associated and sync lines are excluded, and documents the side effects — an Excel worksheet written to disk whose path must be given to the user, plus an attached read-only CSV copy. It also discloses where lead times come from (INVENDOR then APVENDOR, 0 means unset) and the resulting order-by vs needed-by distinction.

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?

The critical constraint — ask for time frame and scope first — is front-loaded, and nearly every sentence carries operational weight. It is a dense single block with no line breaks, though, which makes the lead-time sourcing and exclusion rules harder to scan than they need to be.

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 16-parameter planning tool with no annotations and no output schema, the description supplies what an agent needs: output shape in prose (buy/make, by when, why), the worksheet-first approval workflow, defaults, and the demand/exclusion rules. Nothing essential to calling it correctly is left unstated.

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 100%, so the baseline is 3, but the description adds real meaning beyond it: the lead-time precedence chain that leadTimes/leadTimeDays override, the rule that lead-time parameters are passed only when the user supplies figures, and that scope governs reporting while the whole company is always planned. It does not add anything for the remaining 13 parameters, which is acceptable given the schema already documents them.

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 opening sentence names a specific verb and resource ('Material requirements plan for one company'), states the read-only scope, and specifies the mechanism (nets sales/job demand, batches and POs against stock through the BOM) and the return ('what to buy and make, by when, and why'). That is enough to separate it from mrp_item_view and the CSV import/export siblings without opening 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?

It gives an explicit precondition — ALWAYS ask for the time frame and the scope first, never assume — and spells out the three scope choices. It also tells the agent which inputs are user-supplied only ('Pass leadTimes or leadTimeDays only for figures the user gives') and that minimumRule is a policy to ask once.

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