This server exposes inventory-management tools for battery ERP, letting you look up parts, check stock status, list SKUs, and run human bin-count confirmation workflows.
lookup_inventory — Get available quantity and stock status for a part number/SKU.
get_inventory_status — Check inventory status and see reorder suggestions when stock is below the reorder point.
get_inventory_record — Fetch the full inventory record for a SKU, including on-hand, reserved, reorder level, and cost.
list_inventory — List status for all seeded inventory SKUs in the demo store.
create_bin_check_request — Create a human bin-count verification task for SMS/warehouse workflows, with optional notes.
record_bin_confirmation — Record a human-confirmed on-hand quantity, requiring an auth token matching BATTERY_ERP_CONFIRM_TOKEN; supports actor, notes, and request ID.
mcp-name: io.github.icohangar-ops/battery-erp
Battery ERP manages the complete battery value chain — from raw material sourcing through cell manufacturing to pack assembly. Every cost is traceable to a specific material, supplier, and price point.
Layer | Role |
Data Models | RawMaterial, CellChemistry, BatteryCell, BatteryPack, BOMItem, Supplier, InventoryRecord, PurchaseOrder, ManufacturingBatch |
Business Rules | BOM cost rollups, inventory status management, supplier scoring (composite A-D grade), manufacturing yield tracking, price trend analysis, what-if cost scenarios |
Pricing Engine | Default material price table (20+ materials), AlphaVantage integration for live commodity prices, FRED macro overlay |
Analytics | Inventory health reports, supply chain reports, manufacturing yield reports, chemistry cost comparison dashboards |
Fabric Lakehouse | 11 Delta tables for persistent storage and SQL analytics |
Related MCP server: foundry net-industrial
# From PyPI — https://pypi.org/project/battery-erp/
python3 -m pip install 'battery-erp[mcp]' # MCP tools
python3 -m pip install 'battery-erp[api]' # REST adapter
# From source
git clone https://github.com/icohangar-ops/battery-erp.git
cd battery-erp
python3 -m pip install -e '.[dev]'
PYTHONPATH=src python3 -m pytest tests/ -v
# Domain modules
python3 -c "
from battery_erp.pricing import calculate_cell_cost_summary, get_material_price_table
prices = get_material_price_table()
for chem in ['NMC-811', 'NMC-622', 'NCA', 'LFP', 'LMO']:
r = calculate_cell_cost_summary(chem, 50.0, prices)
print(f'{chem}: \${r[\"cost_per_kwh\"]:.1f}/kWh (BOM: \${r[\"bom_cost_usd\"]:.2f})')
" ┌──────────────────────────────────────┐
│ Raw Materials (20+ tracked) │
│ Lithium · Cobalt · Nickel · Mn · Gr │
└──────────────┬───────────────────────┘
│ BOM
┌──────────────▼───────────────────────┐
│ Cell Chemistries │
│ NMC-811 · NMC-622 · NCA · LFP · LMO │
└──────────────┬───────────────────────┘
│ cells + components
┌──────────────▼───────────────────────┐
│ Battery Packs │
│ EV · ESS · Consumer · Industrial │
└──────────────────────────────────────┘
Side modules:
┌─────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ Supplier Scoring │ │ Inventory Mgmt │ │ Cost Scenarios │
│ Composite 0-100 │ │ Reorder logic │ │ What-if analysis │
│ A/B/C/D grades │ │ Status tracking │ │ Price shock model │
└─────────────────┘ └──────────────────┘ └──────────────────┘battery_erp.core.modelsAll domain dataclasses:
RawMaterial — material catalog with pricing, HS codes, hazards
CellChemistry — NMC-111/622/811, NCA, LFP, LMO with energy density and cycle life
BatteryCell — cell specs (capacity, voltage, form factor, weight)
BatteryPack — pack assembly (cells + BMS + thermal)
BOMItem — bill of materials line item with waste factor
Supplier — supplier catalog with quality rating, lead time, certifications
InventoryRecord — warehouse positions with reorder logic
PurchaseOrder — PO lifecycle tracking
ManufacturingBatch — production batch yield tracking
PriceHistory — commodity price time series
battery_erp.core.rulesDeterministic business rules:
rollup_bom_cost() — total BOM cost with material breakdown and waste cost
calculate_cell_bom() — generate representative BOM for any chemistry
calculate_pack_bom() — pack-level BOM (cells + casing + BMS + cooling)
update_inventory_status() — recalculate in_stock/low/out_of_stock
check_reorder_suggestions() — generate PO suggestions
calculate_batch_metrics() — aggregate manufacturing yield
analyze_price_history() — price trend analysis with volatility
estimate_cell_cost_impact() — what-if cost scenario modeling
calculate_pack_metrics() — pack energy density and efficiency
battery_erp.supply_chainSupply chain management:
score_supplier() — composite score (quality 35%, OTD 35%, lead time 20%, certs 10%)
rank_suppliers() — rank by score, filter by material
create_purchase_order() — PO creation from supplier data
analyze_po_pipeline() — PO pipeline analysis (overdue detection, lead time tracking)
suggest_dual_sourcing() — dual-sourcing strategy recommendation
battery_erp.pricingCommodity pricing:
get_material_price_table() — default prices for 20+ battery materials
calculate_cell_cost_summary() — quick cost estimate per chemistry
update_prices_from_alpha_vantage() — live commodity price fetch
update_prices_from_fred() — macro economic indicators
battery_erp.analyticsReporting:
generate_inventory_report() — full inventory health dashboard
generate_supply_chain_report() — supplier + PO pipeline report
generate_manufacturing_report() — yield metrics
generate_pricing_report() — chemistry cost comparison + price trends
Chemistry | BOM Cost | $/kWh | Cathode % | Key feature |
LFP | Lowest | ~$50-55 | ~35% | No Co/Ni, ultra-safe, 4000+ cycles |
LMO | Low | ~$55-60 | ~40% | Low cost, power tools |
NMC-111 | Medium | ~$70-80 | ~50% | Balanced, legacy |
NMC-622 | Medium | ~$75-85 | ~48% | Good energy-cost balance |
NMC-811 | Higher | ~$80-90 | ~52% | High energy, EV dominant |
NCA | Highest | ~$85-95 | ~55% | Tesla flagship, 270 Wh/kg |
Notebook | Purpose |
| Create all 11 Delta tables with seed data |
| Full cost analytics dashboard (chemistry comparison, pack costing, inventory, suppliers, price trends, scenarios) |
Table | Key Columns |
| material_id, name, category, unit_price_usd, price_source, hs_code |
| chemistry_id, name, cathode_type, energy_density_wh_per_kg, cycle_life |
| cell_id, sku, chemistry, form_factor, nominal_capacity_ah, energy_wh, weight_kg |
| pack_id, sku, cell_sku, total_cells, nominal_capacity_kwh, pack_weight_kg |
| bom_id, parent_sku, material_name, quantity_per_unit, unit_cost_usd, waste_factor_pct |
| supplier_id, name, country, materials_supplied, quality_rating, lead_time_days |
| record_id, sku, material_name, quantity_on_hand, quantity_reserved, reorder_point |
| po_id, po_number, supplier_name, quantity, total_usd, status, expected_delivery |
| material_name, price_usd, as_of, source |
| batch_id, product_sku, chemistry, quantity_produced, quantity_pass, yield_pct |
| scenario_id, scenario_name, material_name, current_price_usd, scenario_price_usd, pct_change |
Run fabric_setup_lakehouse.py to create all 11 Delta tables
Run fabric_cost_dashboard.py for the full analytics dashboard
Dashboard covers: chemistry cost comparison, pack-level costing, inventory health, supplier scorecard, price trends, manufacturing yield, cost scenarios
Battery ERP is a domain library, not a hosted ERP. For SMS / text-line and
agent workflows, a shared InventoryService sits under both a thin REST API and
an MCP server. Full detail: docs/INTEGRATION.md.
SMS / ClickSend Cursor / Claude (stdio MCP)
│ │
▼ ▼
REST API (port 8088) battery_erp.mcp
└──────────┬──────────────┘
▼
InventoryService
▼
InMemoryInventoryStore (demo)
▼
Human bin confirmationDo not call MCP from a browser. Keep REST and MCP in separate terminals.
Use python3. Quote pip extras so zsh does not glob them:
cd ~/Desktop/icohangar-repos/battery-erp
python3 -m pip install -e '.[dev]' # api + mcp + pytestcd ~/Desktop/icohangar-repos/battery-erp
export BATTERY_ERP_CONFIRM_TOKEN=dev-secret
export BATTERY_ERP_AUDIT_LOG=/tmp/battery-erp-audit.jsonl
PYTHONPATH=src python3 -m battery_erp.api
# Uvicorn → http://127.0.0.1:8088curl -s http://127.0.0.1:8088/health
curl -s http://127.0.0.1:8088/inventory/lookup/lithiumLeave Terminal A running. In a new terminal:
cd ~/Desktop/icohangar-repos/battery-erp
export BATTERY_ERP_CONFIRM_TOKEN=dev-secret
PYTHONPATH=src python3 -m battery_erp.mcpThat process stays quiet on stdio — normal for MCP hosts. Do not paste this into the API terminal.
Add to ~/.cursor/mcp.json (absolute paths; python3 not python):
{
"mcpServers": {
"battery-erp": {
"command": "python3",
"args": ["-m", "battery_erp.mcp"],
"env": {
"PYTHONPATH": "/Users/YOU/Desktop/icohangar-repos/battery-erp/src",
"BATTERY_ERP_CONFIRM_TOKEN": "replace-me",
"BATTERY_ERP_AUDIT_LOG": "/tmp/battery-erp-audit.jsonl"
}
}
}
}Then reload MCP servers in Cursor. Tools exposed: lookup_inventory,
get_inventory_status, get_inventory_record, list_inventory,
create_bin_check_request, record_bin_confirmation.
Surface | Entry | Shared layer |
REST |
|
|
MCP | tools above (mcp SDK 2.x | same |
Mutating bin confirmation requires BATTERY_ERP_CONFIRM_TOKEN and optionally
writes JSONL audit to BATTERY_ERP_AUDIT_LOG.
Directory / registry packaging: see PUBLISH.md (glama.json,
Dockerfile, server.json).
Directory | Link |
PyPI | |
MCP Registry |
|
Glama |
PYTHONPATH=src python3 -m pytest tests/ -v
# Domain tests + inventory service / REST / MCP scaffoldCell manufacturers — BOM cost tracking across chemistries, yield optimization
Pack integrators — pack-level cost estimation, supplier selection
Procurement — supplier scoring, dual-sourcing, PO pipeline management
Finance — commodity price risk, what-if scenarios, inventory valuation
C-suite — dashboard showing $/kWh trends, supply chain resilience, cost reduction opportunities
MIT. See LICENSE.
This repository is hardened with the Consensus Hardening Protocol (CHP), Cubiczan's decision-governance layer for multi-agent AI systems.
R0 Gate: All decisions must pass Solvable, Scoped, Valid, Worth_it checks
Foundation Disclosure: 1-3 weakest assumptions, 1-2 invalidation conditions, 1 key vulnerability
Adversarial Layer: Mandatory devil's advocate at Phase 0 and Round 3
State Machine: EXPLORING → PROVISIONAL → PROVISIONAL_LOCK → LOCKED
Third-Party Validation: Independent CONFIRM/REJECT before lock
Category: Mining / Supply Chain
Foundation Threshold: 75
CFO Accuracy Guard: Disabled
File | Purpose |
| Decision state transitions |
| Domain-calibrated thresholds |
| Standardized challenge templates |
| Compliance tracking & audit trail |
cognitive-mesh-orchestrator 0.1.0 | Protocol Docs
Mobile capture from the live lead page (parts-bin-text-line--icohangar.replit.app). SMS → text-line → Battery ERP inventory check → human bin confirm.
Create a human bin-count verification task for SMS / warehouse workflows.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| part_number | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that a verification task is created, but does not explain side effects, whether an SMS is sent, whether the task is persisted, or what the resulting workflow looks like.
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?
One short sentence, front-loaded with the core purpose and no filler. It is concise and readable, though it sacrifices useful detail for brevity.
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 that there are no annotations and no output schema, the description is too sparse to support reliable invocation. It does not say what happens after the request is created, what part_number refers to, how notes are used, or how this relates to confirmation workflows.
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 description does not explain the two parameters. With 0% schema description coverage, the agent is left to infer that part_number likely identifies the item/bin being checked and notes is an optional attachment, but no explicit meaning, format, or usage context is provided.
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 uses a specific verb and resource: create a human bin-count verification task. It clearly conveys the action and domain (SMS/warehouse workflows), though it does not explicitly distinguish itself from sibling tools like record_bin_confirmation.
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?
There is no explicit guidance about when to use this tool versus alternatives. The phrase 'for SMS / warehouse workflows' only implies context; it does not describe preconditions, exclusions, or how this relates to the inventory lookup and confirmation sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the full inventory record for a SKU (on-hand, reserved, reorder, cost).
| Name | Required | Description | Default |
|---|---|---|---|
| sku | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It implies a read-only operation but doesn't state so explicitly. It also doesn't mention error behavior, rate limits, or consequences. The listing of returned fields is some help, but it lacks explicit behavioral disclosure.
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?
One sentence, front-loaded with the verb 'Return', lists the returned fields. Highly efficient and easy to scan.
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 simple single-parameter lookup tool with no output schema, the description is fairly complete: it states the action, the input, and the contents of the return value. It could mention error behavior or alternative tools, but for its complexity it's probably adequate.
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 0% (the description adds no parameter-level details). The description mentions 'for a SKU' but doesn't explain format, requiredness, or how it maps to the schema. It adds minimal meaning beyond showing the parameter name in context.
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 action ('Return the full inventory record') and the resource (SKU), and lists the fields included. It is clear and unambiguous, though it does not explicitly distinguish this from sibling tools like lookup_inventory or get_inventory_status. The verb+resource is specific enough to convey the primary purpose, but lacks explicit sibling differentiation.
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?
No guidance on when to use this tool versus alternatives like lookup_inventory or get_inventory_status. The description does not mention scenarios, prerequisites, or why one would choose this over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get inventory status plus reorder suggestion when below reorder point.
| Name | Required | Description | Default |
|---|---|---|---|
| part_number | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that a reorder suggestion is included, but does not clarify whether the operation is read-only, what the response format is, or how it behaves if the part number is invalid. The behavioral detail is minimal.
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, front-loaded sentence that packs the core purpose and the key differentiator. It is concise and easy to scan, though it could mention exclusions or alternatives without much bloat.
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 single-parameter tool, the description is adequate at a basic level, but it lacks details about the response structure, error behavior, and how it compares to get_inventory_record. Given no output schema and no annotations, the agent has limited understanding beyond the name. It is minimally complete but leaves room for ambiguity.
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 schema has 0% description coverageyb; the only parameter is part_number with no additional meaning provided. The description does not explain the expected format (e.g., alphanumeric, length) or how it relates to the reorder logic. Some meaning can be inferred from the parameter name, but the description adds no value.
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 uses a specific verb 'get' and resource 'inventory status', and adds the differentiator 'reorder suggestion'. This distinguishes it from list_inventory but not clearly from get_inventory_record, which could also return status. The purpose is clear but sibling differentiation is weak.
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?
No guidance is given for when to use this tool versus the siblings like get_inventory_record or list_inventory. An agent must infer the use case from the name and description. There is no mention of prerequisites or conditions that would select this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List status for all seeded inventory SKUs (demo store).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of disclosing behavior. It only indicates a listing operation, but does not state whether it is read-only, the nature of the response, or any side effects, leaving ambiguity.
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, concise sentence that immediately conveys the purpose. It is front-loaded with the core action and resource, with no 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?
The description provides minimal context. It lacks any detail about the output format, pagination, or the nature of the 'seeded' data, and does not clarify how this list differs from the sibling tools beyond the basic action.
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?
There are no parameters, so schema coverage is complete. The description adds no parameter-specific meaning, but since none exist, the baseline score of 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 clearly states the action ('List') and the specific resource ('all seeded inventory SKUs'), making it distinct from the more targeted sibling tools like lookup_inventory and get_inventory_record.
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?
No guidance is provided on when to use this tool versus the alternatives. It does not mention any exclusions or specific scenarios that would favor this list operation over the lookups or get operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up available quantity and stock status for a part number or SKU.
| Name | Required | Description | Default |
|---|---|---|---|
| part_number | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations and no output schema, so the description carries the behavioral burden. It states the returned data (quantity and stock status) but does not disclose exact response shape, matching behavior, error conditions, or whether multiple identifiers are accepted.
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?
A single, front-loaded sentence with no filler; every word adds meaning.
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 one-parameter read-only lookup, the description is mostly sufficient, but it lacks any output-shape information and does not resolve ambiguity with the three sibling lookup tools. It also leaves open whether the tool returns one record or multiple.
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 0%, but the description adds the useful clarification that the part_number parameter can also be a SKU. It does not, however, specify formats, requiredness beyond the schema, or how to pass a SKU through a field named part_number.
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 uses a specific verb ('Look up') and names the resource and result ('available quantity and stock status'), so an agent understands the core purpose. It does not distinguish itself from siblings like get_inventory_status or get_inventory_record, which likely overlap in behavior.
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?
No guidance is provided for when to choose this tool over get_inventory_status, get_inventory_record, or list_inventory. The description implies a lookup use case but gives no exclusions or alternative routing instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record a human-confirmed on-hand quantity. Requires auth_token matching BATTERY_ERP_CONFIRM_TOKEN.
| Name | Required | Description | Default |
|---|---|---|---|
| actor | No | mcp-operator | |
| notes | No | ||
| auth_token | Yes | ||
| request_id | No | ||
| part_number | Yes | ||
| actual_quantity | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description must carry the full burden of behavioral disclosure. It reveals an auth requirement (auth_token matching BATTERY_ERP_CONFIRM_TOKEN) but does not disclose side effects — whether it updates inventory, overrides existing quantities, or has any other impact. The word 'record' implies a write, but the consequences are undefined.
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 extremely concise and front-loaded: purpose first, then auth requirement. Both sentences earn their place with no filler. However, it is so sparse that it borders on under-specification, but that is more a completeness issue than a conciseness flaw.
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 write operation with no annotations and no output schema, this description is incomplete. It does not explain what happens upon success/failure, whether part_number must exist, the expected format of actual_quantity, or how this confirmation integrates with the inventory workflow. Agents lack essential information to call this tool reliably.
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 0%, so the description must compensate for param meaning. It only explains auth_token (must match the environment token) and implicitly links actual_quantity to 'on-hand quantity', but part_number, actor, notes, and request_id are completely unexplained. This is insufficient given the number of parameters.
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 action ('Record') and a specific resource ('a human-confirmed on-hand quantity'), which clearly distinguishes this from sibling read/lookup tools and from create_bin_check_request. The verb+object combination is unambiguous and informative.
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 provides no guidance on when to use this tool versus alternatives. It does not mention typical trigger conditions (e.g., after a manual count) or contrast with create_bin_check_request. Agents must infer usage from the name and purpose alone.
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.
v1.0.0create_bin_check_requestget_inventory_recordget_inventory_statuslist_inventorylookup_inventoryrecord_bin_confirmationScored across 6 tools
lookup_inventory, get_inventory_status, and get_inventory_record all take a SKU and return overlapping inventory quantities/status, so their boundaries are unclear. list_inventory and the two bin-check tools are distinct, but the three inventory getters could easily be misselected.
All names are snake_case and verb-led, with read operations using lookup/get/list and write operations using create/record. The pattern is mostly predictable, with only a minor inconsistency between lookup_inventory and the get_inventory_* family.
Six tools is a well-scoped set for a focused inventory ERP demo: four query variants plus two bin-count workflow actions. Each tool has a reasonable role, and the count is neither bloated nor too thin.
The set covers inventory queries and the bin-confirmation workflow, but lacks lifecycle operations such as SKU creation/update or any way to list pending bin-check requests. Reorder suggestions are generated but there is no tool to act on them, creating a dead end.
WMS & logistics intelligence: live freight & shipping rates, port data, inventory, fleet, KPIs
Real-time supply chain risk intelligence — 24 tools, proprietary indices, predictive signals
Cross-OEM industrial machine intelligence: identity, normalization, automation, attestation.
Create & manage EU Digital Product Passports with PassportCraft: textiles, batteries, general goods.
