mcp-name: io.github.icohangar-ops/battery-erp
Battery ERP 管理完整的电池价值链——从原材料采购到电芯制造再到电池包组装。每项成本都可追溯到具体的材料、供应商和价格点。
层级 | 作用 |
数据模型 | RawMaterial、CellChemistry、BatteryCell、BatteryPack、BOMItem、Supplier、InventoryRecord、PurchaseOrder、ManufacturingBatch |
业务规则 | BOM 成本汇总、库存状态管理、供应商评分（A-D 综合等级）、制造良率跟踪、价格趋势分析、假设成本场景 |
定价引擎 | 默认材料价格表（20+ 种材料）、AlphaVantage 实时大宗商品价格集成、FRED 宏观数据叠加 |
分析 | 库存健康报告、供应链报告、制造良率报告、化学体系成本对比仪表盘 |
Fabric Lakehouse | 11 张 Delta 表，用于持久化存储和 SQL 分析 |
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.models所有领域数据类：
RawMaterial — 材料目录，含定价、HS 编码、危险品信息
CellChemistry — NMC-111/622/811、NCA、LFP、LMO，含能量密度和循环寿命
BatteryCell — 电芯规格（容量、电压、外形尺寸、重量）
BatteryPack — 电池包组装（电芯 + BMS + 热管理）
BOMItem — 物料清单行项目，含损耗系数
Supplier — 供应商目录，含质量评级、交货周期、认证
InventoryRecord — 仓库库位，含补货逻辑
PurchaseOrder — 采购订单生命周期跟踪
ManufacturingBatch — 生产批次良率跟踪
PriceHistory — 大宗商品价格时间序列
battery_erp.core.rules确定性业务规则：
rollup_bom_cost() — 总 BOM 成本，含材料明细和损耗成本
calculate_cell_bom() — 为任意化学体系生成代表性 BOM
calculate_pack_bom() — 电池包级 BOM（电芯 + 外壳 + BMS + 冷却）
update_inventory_status() — 重新计算 in_stock/low/out_of_stock
check_reorder_suggestions() — 生成采购订单建议
calculate_batch_metrics() — 汇总制造良率
analyze_price_history() — 价格趋势分析，含波动率
estimate_cell_cost_impact() — 假设成本场景建模
calculate_pack_metrics() — 电池包能量密度和效率
battery_erp.supply_chain供应链管理：
score_supplier() — 综合评分（质量 35%、准时交付 35%、交货周期 20%、认证 10%）
rank_suppliers() — 按评分排序，按材料筛选
create_purchase_order() — 根据供应商数据创建采购订单
analyze_po_pipeline() — 采购订单管道分析（逾期检测、交货周期跟踪）
suggest_dual_sourcing() — 双源采购策略建议
battery_erp.pricing大宗商品定价：
get_material_price_table() — 20+ 种电池材料的默认价格
calculate_cell_cost_summary() — 各化学体系的快速成本估算
update_prices_from_alpha_vantage() — 实时大宗商品价格获取
update_prices_from_fred() — 宏观经济指标
battery_erp.analytics报表：
generate_inventory_report() — 完整库存健康仪表盘
generate_supply_chain_report() — 供应商 + 采购订单管道报表
generate_manufacturing_report() — 良率指标
generate_pricing_report() — 化学体系成本对比 + 价格趋势
化学体系 | BOM 成本 | $/kWh | 正极占比 % | 关键特性 |
LFP | 最低 | ~$50-55 | ~35% | 无钴/镍，超安全，4000+ 次循环 |
LMO | 低 | ~$55-60 | ~40% | 低成本，电动工具 |
NMC-111 | 中等 | ~$70-80 | ~50% | 均衡，成熟 |
NMC-622 | 中等 | ~$75-85 | ~48% | 能量与成本平衡良好 |
NMC-811 | 较高 | ~$80-90 | ~52% | 高能量密度，EV 主导 |
NCA | 最高 | ~$85-95 | ~55% | 特斯拉旗舰，270 Wh/kg |
笔记本 | 用途 |
| 创建全部 11 张 Delta 表并写入种子数据 |
| 完整成本分析仪表盘（化学体系对比、电池包成本核算、库存、供应商、价格趋势、场景） |
表 | 关键列 |
| 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 |
运行 fabric_setup_lakehouse.py 创建全部 11 张 Delta 表
运行 fabric_cost_dashboard.py 获取完整分析仪表盘
仪表盘涵盖：化学体系成本对比、电池包级成本核算、库存健康、供应商记分卡、价格趋势、制造良率、成本场景
Battery ERP 是一个领域库，而非托管的 ERP。对于 SMS / 文本行和
代理工作流，共享的 InventoryService 同时位于轻量 REST API 和
MCP 服务器之下。完整详情：docs/INTEGRATION.md。
SMS / ClickSend Cursor / Claude (stdio MCP)
│ │
▼ ▼
REST API (port 8088) battery_erp.mcp
└──────────┬──────────────┘
▼
InventoryService
▼
InMemoryInventoryStore (demo)
▼
Human bin confirmation不要在浏览器中调用 MCP。请将 REST 和 MCP 放在不同的终端中。
使用 python3。给 pip extras 加引号，以免 zsh 将其通配展开：
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/lithium保持终端 A 运行。在新终端中：
cd ~/Desktop/icohangar-repos/battery-erp
export BATTERY_ERP_CONFIRM_TOKEN=dev-secret
PYTHONPATH=src python3 -m battery_erp.mcp该进程在 stdio 上保持静默——这对 MCP 主机来说是正常的。不要将其粘贴到 API 终端中。
添加到 ~/.cursor/mcp.json（使用绝对路径；用 python3 而非 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"
}
}
}
}然后在 Cursor 中重新加载 MCP 服务器。暴露的工具：lookup_inventory、
get_inventory_status、get_inventory_record、list_inventory、
create_bin_check_request、record_bin_confirmation。
表面 | 入口 | 共享层 |
REST |
|
|
MCP | 上述工具（mcp SDK 2.x | 相同 |
变更性的 bin 确认需要 BATTERY_ERP_CONFIRM_TOKEN，并可选择性地
将 JSONL 审计日志写入 BATTERY_ERP_AUDIT_LOG。
目录 / 注册表打包：参见 PUBLISH.md（glama.json、
Dockerfile、server.json）。合并到 main 后，在 Glama 上以
@icohangar-ops/battery-erp 认领。
PYTHONPATH=src python3 -m pytest tests/ -v
# Domain tests + inventory service / REST / MCP scaffold电芯制造商 — 跨化学体系的 BOM 成本跟踪、良率优化
电池包集成商 — 电池包级成本估算、供应商选择
采购部门 — 供应商评分、双源采购、采购订单管道管理
财务部门 — 大宗商品价格风险、假设场景、库存估值
高管层 — 展示 $/kWh 趋势、供应链韧性、降本机会的仪表盘
MIT。参见 LICENSE。
本仓库已通过 共识加固协议（CHP） 加固，这是 Cubiczan 为多代理 AI 系统设计的决策治理层。
R0 门控：所有决策必须通过 Solvable、Scoped、Valid、Worth_it 检查
基础披露：1-3 个最薄弱假设、1-2 个失效条件、1 个关键漏洞
对抗层：在阶段 0 和第 3 轮强制进行魔鬼代言人审查
状态机：EXPLORING → PROVISIONAL → PROVISIONAL_LOCK → LOCKED
第三方验证：锁定前需独立 CONFIRM/REJECT
类别：采矿 / 供应链
基础阈值：75
CFO 准确性防护：已禁用
文件 | 用途 |
| 决策状态转换 |
| 领域校准阈值 |
| 标准化挑战模板 |
| 合规跟踪与审计轨迹 |
cognitive-mesh-orchestrator 0.1.0 | 协议文档
来自实时线索页面的移动端采集 （parts-bin-text-line--icohangar.replit.app）。 短信 → 文本行 → 电池ERP库存检查 → 人工料箱确认。
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
EV-charging site analytics: utilization, demand, peak saturation and corridor benchmarks.
EV-charging site analytics: utilization, demand, peak saturation and corridor benchmarks.