Skip to main content
Glama
enesjakozh
brandon-butterwick

MRP Calculator MCP Server

by brandon-butterwick
OverviewSchemaRelated ServersScoreDiscussions
JavaScript

MRP Calculator MCP Server

Overview

This MCP server provides tools for Material Requirements Planning (MRP) calculations. It follows the Model Context Protocol (MCP) to expose its functionality to the system.

Related MCP server: PP/DS MCP Server

Features

  • Delivery schedule calculation

  • Order need determination

  • MRP period calculations

Tools

The server provides the following MCP tools:

calculate_order_need

Calculates when and how much to order based on:

  • Current inventory levels

  • Forecast periods

  • Delivery schedules

  • Order constraints

Configuration

The server can be configured through the MCP settings file with:

{
  "mcpServers": {
    "mrp": {
      "command": "node",
      "args": ["/path/to/mrp-calculator/dist/index.js"],
      "env": {}
    }
  }
}

Development

  • Written in TypeScript

  • Uses MCP SDK for server implementation

  • Includes test cases for validation

Project Structure

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.md

Building and Running

# Install dependencies
npm install

# Build the server
npm run build

# Run the server
node dist/index.js

Version Control

This repository uses Git for version control. Important files are tracked while build artifacts and dependencies are ignored via .gitignore.

Available Tools

1 tool
calculate_order_needC

Calculate MRP order need based on forecast, inventory, and delivery schedule

ParametersJSON Schema
NameRequiredDescriptionDefault
analysis_dateYes
batch_sizesNo
current_balanceYes
delivery_scheduleYes
forecast_periodsYes
must_order_pointYes
open_ordersYes
sku_locationYes

TDQS

C2.8/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters2/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3/5.0
Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count2/5

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.

Completeness2/5

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

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • PP/DS MCP Server

    LINZO-AT
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables 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.

  • Supply Chain MCP Server

    CSOAI-ORG
    F
    license
    Not graded
    quality
    C
    maintenance
    Enables supply chain management tasks such as tracking shipments, managing inventory, and supplier scorecards through MCP protocol.

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/brandon-butterwick/MRP_Calculation'

If you have feedback or need assistance with the MCP directory API, please join our Discord server