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Все доменные dataclass:
RawMaterial — каталог материалов с ценами, кодами HS, опасностями
CellChemistry — NMC-111/622/811, NCA, LFP, LMO с плотностью энергии и сроком службы
BatteryCell — характеристики ячейки (ёмкость, напряжение, форм-фактор, вес)
BatteryPack — сборка пакета (ячейки + BMS + терморегулирование)
BOMItem — позиция спецификации (BOM) с коэффициентом отходов
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%, OTD 35%, срок поставки 20%, сертификаты 10%)
rank_suppliers() — ранжирование по оценке, фильтрация по материалу
create_purchase_order() — создание заказа на поставку из данных поставщика
analyze_po_pipeline() — анализ конвейера заказов (обнаружение просрочек, отслеживание сроков поставки)
suggest_dual_sourcing() — рекомендация стратегии двойного 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 | $/кВт·ч | Доля катода | Ключевая особенность |
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 Вт·ч/кг |
Записная книжка | Назначение |
| Создание всех 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 не интерпретировал их как glob:
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"
}
}
}
}Затем перезагрузите MCP-серверы в Cursor. Доступные инструменты: 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 по химиям, оптимизация выхода
Интеграторы пакетов — оценка затрат на уровне пакета, выбор поставщиков
Закупки — оценка поставщиков, двойной sourcing, управление конвейером заказов
Финансы — ценовой риск на сырьё, сценарии «что если», оценка запасов
Руководство — панель с трендами $/кВт·ч, устойчивость цепочки поставок, возможности снижения затрат
MIT. См. LICENSE.
Этот репозиторий укреплён с помощью Consensus Hardening Protocol (CHP), уровня управления решениями Cubiczan для мультиагентных ИИ-систем.
R0 Gate: Все решения должны проходить проверки Solvable, Scoped, Valid, Worth_it
Foundation Disclosure: 1-3 самых слабых допущения, 1-2 условия инвалидации, 1 ключевая уязвимость
Adversarial Layer: Обязательный адвокат дьявола на Фазе 0 и Раунде 3
State Machine: EXPLORING → PROVISIONAL → PROVISIONAL_LOCK → LOCKED
Third-Party Validation: Независимое CONFIRM/REJECT перед блокировкой
Категория: Горнодобыча / Цепочка поставок
Порог Foundation: 75
CFO Accuracy Guard: Отключён
Файл | Назначение |
| Переходы состояний решений |
| Пороги, откалиброванные по домену |
| Стандартизированные шаблоны вызовов |
| Отслеживание соответствия и аудит |
cognitive-mesh-orchestrator 0.1.0 | Документация протокола
Мобильный захват с живой страницы лида (parts-bin-text-line--icohangar.replit.app). SMS → текст → проверка запасов в 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.