MRP Calculator MCP Server
Calculadora MRP Servidor MCP
Descripción general
Este servidor MCP proporciona herramientas para el cálculo de la Planificación de Requerimientos de Materiales (MRP). Sigue el Protocolo de Contexto de Modelo (MCP) para exponer su funcionalidad al sistema.
Related MCP server: Supply Chain MCP Server
Características
Cálculo del cronograma de entrega
Determinación de la necesidad de un pedido
Cálculos del período MRP
Herramientas
El servidor proporciona las siguientes herramientas MCP:
calcular_necesidad_de_pedido
Calcula cuándo y cuánto pedir en función de:
niveles actuales de inventario
Períodos de pronóstico
Horarios de entrega
Restricciones de orden
Configuración
El servidor se puede configurar a través del archivo de configuración MCP con:
{
"mcpServers": {
"mrp": {
"command": "node",
"args": ["/path/to/mrp-calculator/dist/index.js"],
"env": {}
}
}
}Desarrollo
Escrito en TypeScript
Utiliza MCP SDK para la implementación del servidor
Incluye casos de prueba para validación.
Estructura del proyecto
mrp-calculator/
├── src/
│ ├── index.ts # Main server implementation
│ ├── calculator.ts # MRP calculation logic
│ ├── types.ts # TypeScript type definitions
│ └── validator.ts # Input validation
├── package.json
├── tsconfig.json
└── README.mdConstruyendo y funcionando
# Install dependencies
npm install
# Build the server
npm run build
# Run the server
node dist/index.jsControl de versiones
Este repositorio usa Git para el control de versiones. Se rastrean los archivos importantes, mientras que los artefactos de compilación y las dependencias se ignoran mediante .gitignore.
Available Tools
1 toolcalculate_order_needC
Calculate MRP order need based on forecast, inventory, and delivery schedule
| Name | Required | Description | Default |
|---|---|---|---|
| analysis_date | Yes | ||
| batch_sizes | No | ||
| current_balance | Yes | ||
| delivery_schedule | Yes | ||
| forecast_periods | Yes | ||
| must_order_point | Yes | ||
| open_orders | Yes | ||
| sku_location | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'calculate' but doesn't specify whether this is a read-only operation, if it has side effects, what permissions are needed, or how results are returned. For a complex tool with 8 parameters, this leaves significant behavioral gaps.
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, efficient sentence with no wasted words. It's front-loaded with the core purpose and uses clear terminology. Every part of the sentence contributes directly to understanding the tool's function.
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 complex tool with 8 parameters, nested objects, no output schema, and no annotations, the description is inadequate. It doesn't explain the calculation logic, output format, error conditions, or how parameters interact. The agent lacks sufficient context to use this tool effectively without guessing.
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 by explaining parameters. It only mentions 'forecast, inventory, and delivery schedule' generically, which maps loosely to some parameters but doesn't clarify the semantics of the 8 specific inputs (e.g., 'batch_sizes', 'must_order_point'). This adds minimal value beyond the schema.
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 tool's purpose: 'Calculate MRP order need based on forecast, inventory, and delivery schedule.' It specifies the verb ('calculate'), resource ('MRP order need'), and key inputs. However, without sibling tools, it cannot demonstrate differentiation from alternatives, so it doesn't reach the highest score.
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, prerequisites, or specific contexts. It only states what the tool does, not when it should be applied, leaving the agent with no usage instructions beyond the basic function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v1.0.0- First observed
calculate_order_need
TDQS
Scored across 1 tool
With only one tool, there is no possibility of ambiguity or overlap between tools. The tool's purpose is clearly defined and distinct by default.
A single tool inherently has perfect naming consistency, as there are no other tools to compare it against. The name follows a clear verb_noun pattern.
One tool is too few for a server named 'MRP Calculator MCP Server', which suggests a domain (Material Requirements Planning) that typically involves multiple calculations or operations. A single tool feels thin and incomplete for this scope.
The tool surface is severely incomplete for MRP. While the tool calculates order need, there are obvious gaps such as inventory management, forecast updates, delivery tracking, or other MRP-related operations, which will likely cause agent failures in real-world scenarios.
Maintenance
Related MCP Connectors
Find the cash trapped in your inventory, then size reorder points, safety stock and EOQ.
Read-only supply-chain decision support: forecasting, reorder policies, ABC-XYZ, data quality.
Calculate required trucks or containers, verify shipment fit, and manage Haulista loading plans.
1TOTVS Protheus ERP for AI: stock, sales, orders, customers and MRP. Read-only, official API.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables AI-assisted planning inquiries by exposing PP/DS OData APIs as MCP tools for SAP S/4HANA, allowing natural language queries about planned orders, production orders, and work centers.-
- FlicenseNot gradedqualityCmaintenanceEnables supply chain management tasks such as tracking shipments, managing inventory, and supplier scorecards through MCP protocol.-
- FlicenseNot gradedqualityBmaintenanceProvides Shopify demand forecasting, reorder recommendations, and dollar-impact reports as MCP tools.-
- AlicenseCqualityBmaintenanceDeterministic Odoo ERP calculators: implementation, migration and upgrade cost, ROI and TCO, US/Canada/EU sales tax and VAT, Canadian payroll source deductions, and inventory maths (reorder point, safety stock, EOQ, landed cost, OEE). 24 tools, each a pure function, the numbers are arithmetic rather than a model's guess. Hosted remote server, no install and no API key; a stdio bridge is included24MIT