バッテリーのバリューチェーン全体をカバー: リチウム、コバルト、ニッケル、マンガン、黒鉛から、セル化学(NMC-811、NCA、LFP、LMO)、BOM原価計算、サプライヤースコアリング、在庫管理、what-ifコストシナリオを備えたバッテリーパックまで。
mcp-name: io.github.icohangar-ops/battery-erp
Battery ERPは、原材料の調達からセル製造、パック組み立てまでのバッテリーのバリューチェーン全体を管理します。すべてのコストは、特定の材料、サプライヤー、価格ポイントにトレース可能です。
レイヤー | 役割 |
データモデル | RawMaterial、CellChemistry、BatteryCell、BatteryPack、BOMItem、Supplier、InventoryRecord、PurchaseOrder、ManufacturingBatch |
ビジネスルール | BOMコストのロールアップ、在庫ステータス管理、サプライヤースコアリング(複合A-Dグレード)、製造歩留まり追跡、価格トレンド分析、what-ifコストシナリオ |
価格エンジン | デフォルト材料価格テーブル(20以上の材料)、ライブコモディティ価格のためのAlphaVantage統合、FREDマクロオーバーレイ |
分析 | 在庫健全性レポート、サプライチェーンレポート、製造歩留まりレポート、化学コスト比較ダッシュボード |
Fabric Lakehouse | 永続ストレージとSQL分析のための11のDeltaテーブル |
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 — 廃棄率を含む部品表(BOM)ラインアイテム
Supplier — 品質評価、リードタイム、認証を含むサプライヤーカタログ
InventoryRecord — 再発注ロジック付きの倉庫ポジション
PurchaseOrder — POライフサイクル追跡
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() — PO提案を生成
calculate_batch_metrics() — 製造歩留まりを集計
analyze_price_history() — ボラティリティを含む価格トレンド分析
estimate_cell_cost_impact() — what-ifコストシナリオモデリング
calculate_pack_metrics() — パックエネルギー密度と効率
battery_erp.supply_chainサプライチェーン管理:
score_supplier() — 複合スコア(品質35%、OTD 35%、リードタイム20%、認証10%)
rank_suppliers() — スコアでランク付け、材料でフィルタリング
create_purchase_order() — サプライヤーデータからのPO作成
analyze_po_pipeline() — POパイプライン分析(遅延検出、リードタイム追跡)
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() — サプライヤー+ POパイプラインレポート
generate_manufacturing_report() — 歩留まり指標
generate_pricing_report() — 化学コスト比較+価格トレンド
化学組成 | BOMコスト | $/kWh | カソード% | 主な特徴 |
LFP | 最低 | ~$50-55 | ~35% | Co/Ni不使用、超安全、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% | Teslaフラッグシップ、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 / text-lineおよびエージェントワークフロー向けに、共有の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を使用してください。zshがグロブしないようにpipのextrasを引用符で囲んでください:
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に追加(絶対パス; pythonではなくpython3):
{
"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 | 同じ |
変更を伴うビン確認にはBATTERY_ERP_CONFIRM_TOKENが必要で、オプションでBATTERY_ERP_AUDIT_LOGにJSONL監査を書き込みます。
ディレクトリ / レジストリパッケージング: 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コスト追跡、歩留まり最適化
パックインテグレーター — パックレベルのコスト見積もり、サプライヤー選定
調達 — サプライヤースコアリング、デュアルソーシング、POパイプライン管理
財務 — コモディティ価格リスク、what-ifシナリオ、在庫評価
経営層 — $/kWhトレンド、サプライチェーンの回復力、コスト削減機会を示すダッシュボード
MIT。 LICENSEを参照してください。
このリポジトリは、CubiczanのマルチエージェントAIシステム向け意思決定ガバナンスレイヤーであるConsensus Hardening Protocol (CHP)で強化されています。
R0ゲート: すべての決定はSolvable、Scoped、Valid、Worth_itチェックを通過する必要があります
Foundation開示: 1〜3の最も弱い仮定、1〜2の無効化条件、1つの主要な脆弱性
Adversarialレイヤー: フェーズ0とラウンド3での必須の悪魔の代弁者
ステートマシン: EXPLORING → PROVISIONAL → PROVISIONAL_LOCK → LOCKED
第三者検証: ロック前の独立したCONFIRM/REJECT
カテゴリ: 鉱業 / サプライチェーン
Foundationしきい値: 75
CFO精度ガード: 無効
ファイル | 目的 |
| 決定状態遷移 |
| ドメイン調整済みしきい値 |
| 標準化されたチャレンジテンプレート |
| コンプライアンス追跡と監査証跡 |
cognitive-mesh-orchestrator 0.1.0 | プロトコルドキュメント
ライブリードページからのモバイルキャプチャ (parts-bin-text-line--icohangar.replit.app)。 SMS → text-line → Battery 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.