forecast-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct action: listing, classifying, forecasting, evaluating, recommending, and explaining. There is no overlap between classification and explanation, and forecast_series complements rather than duplicates classify_demand_pattern.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (list_skus, classify_demand_pattern, forecast_series, evaluate_forecast, recommend_replenishment, explain_forecast). No mixed conventions or vague verbs.
Tool Count5/5
Six tools is well within the 3-15 range and each covers an essential function for the forecasting domain. The set feels neither sparse nor bloated.
Completeness4/5
The set covers the core workflow: listing SKUs, classifying demand, forecasting, backtesting, replenishment, and explanation. A minor gap is lack of a dedicated tool to inspect raw historical demand data, but agents can work around it via the other tools.
Average 3.9/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits beyond the action itself. It does not indicate whether the tool is read-only, requires specific permissions, or has any side effects. The description fails to compensate for the missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the key action and classification details. It is concise without being overly terse, though it could be more structured (e.g., separating the classification categories from the model tier).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and classification categories, but it does not explain what the 'model tier it routes to' means or how the classification is determined. The presence of an output schema might compensate, but the description itself leaves some ambiguity for a tool with moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter unique_id with 100% coverage, including an example and a reference to list_skus. The description adds no additional meaning to the parameter beyond what the schema already provides, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'classify', the resource 'SKU's demand pattern', and lists the specific classification categories (Syntetos-Boylan: smooth/erratic/intermittent/lumpy/cold_start) plus the model tier routing. This clearly distinguishes it from sibling tools like list_skus, forecast_series, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need to classify a SKU's demand pattern), but it does not explicitly state when not to use it or provide alternatives. The parameter description indirectly references list_skus as a prerequisite, but the main description lacks explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 disclosing behavior. It only describes the output (plain-language explanation) but does not mention that the tool is read-only, what happens if the SKU does not exist, or any side effects. For a read-operation with no destructive potential, a statement about being safe to call would be valuable.
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 sentence that is front-loaded, concise, and free of unnecessary words. Every element contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, an output schema (not shown but exists), and no annotations, the description is largely complete. It specifies the output type (plain-language explanation) and audience (non-technical user). However, it could be slightly more complete by mentioning error handling (e.g., invalid SKU) or that it is a read-only operation. For a simple tool, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% – the parameter `unique_id` is described as 'SKU identifier.' The tool description adds context by stating the tool explains why a SKU was routed to a model tier, but it does not add parameter-specific details like format examples or constraints. The description reaffirms the tool's purpose rather than the parameter's semantics, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Return a plain-language explanation of why a SKU was routed to the model tier it was, for surfacing to a non-technical user.' It specifies the verb ('return'), the resource (SKU routing decision), and the output format (plain-language). This distinguishes it from siblings like list_skus (listing SKUs) and classify_demand_pattern (classifying patterns).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when a non-technical explanation of tier assignment is needed), but it does not explicitly state when to use it vs. alternatives, nor does it provide exclusions or prerequisites. For example, it could clarify that this is not for evaluating forecast accuracy (evaluate_forecast) or generating forecasts (forecast_series).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It reveals the internal routing logic (mean fallback, TSB, AutoETS) but does not mention authorization needs, error behavior, or operational constraints such as required permissions or data prerequisites.
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 concise with two sentences. The first sentence states the core purpose, and the second elaborates on the internal routing. Every word serves a purpose, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, an output schema exists, and parameters are well-covered in the schema, the description covers the essential algorithmic behavior. It could mention prerequisites (e.g., valid SKU) or edge cases, but overall it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no additional meaning to parameters beyond what the schema already provides (horizon default/description, unique_id description with pointer to list_skus). The description does not elaborate on parameter usage or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Forecast future demand' and the resource 'a SKU'. It distinguishes from siblings by explaining the automatic classification and routing to different models, making the unique purpose evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates when to use this tool (to forecast a SKU's demand) but does not explicitly state when not to use it or suggest alternatives like classify_demand_pattern or evaluate_forecast for related tasks. The context is clear but lacks exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly explains the process (hold out days, forecast from history, score with MASE) and notes that MASE is scale-free and comparable. It does not explicitly state no side effects or required permissions, but the analytical nature is clear.
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, front-loaded sentence that efficiently communicates the purpose, process, and key metric property. No superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's relative complexity (backtesting, forecasting, scoring), the description covers the essential aspects. An output schema exists, so return values need not be described. The mention of MASE's scale-free nature addresses comparability. The description is complete for an agent to understand when and how to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds minimal meaning beyond the schema: it restates that test_size is the number of recent days to hold out and that unique_id is a SKU identifier, but the schema already provides these details with defaults and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Backtest') and resource ('SKU's forecast'), clearly defining the action. It distinguishes from sibling tools like forecast_series (which generates forecasts) and explain_forecast (which explains), as evaluate_forecast is about validation and scoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when you need to validate forecast accuracy for a SKU) but does not explicitly state when not to use it or suggest alternatives. No mention of prerequisites or comparison with siblings like classify_demand_pattern or recommend_replenishment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 describes the tool as recommending a replenishment quantity using forecast and formula, but does not disclose potential side effects (e.g., does it modify data? is it read-only?), whether it requires any authentication beyond the SKU, or what happens with invalid inputs. The description is functional but lacks safety or permission context.
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, front-loaded sentence that efficiently communicates the tool's purpose and method without waste. Every word contributes meaning, making it easy for an AI agent to quickly grasp the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully explains the tool's purpose and the parameters are well-documented in the schema (100% coverage). The presence of an output schema compensates for not explaining return values. However, given the complexity of the replenishment recommendation, additional context about assumptions (e.g., demand distribution, formula specifics) or edge cases (e.g., zero stock) could be valuable but is not strictly necessary for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the high-level logic (forecast demand, apply reorder-point/safety-stock formula), which helps the AI agent understand how parameters like 'current_stock', 'service_level', and 'lead_time_days' interact, beyond their individual schema descriptions. This contextualizes the parameters in the overall algorithm.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'recommend' and the resource 'reorder quantity for a SKU', and distinguishes its function by mentioning forecasting demand and applying a reorder-point/safety-stock formula against current stock. This differentiates it from sibling tools like 'forecast_series' or 'classify_demand_pattern' which do not produce a replenishment recommendation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when a reorder recommendation is needed for a SKU based on demand forecast and stock levels, and the sibling list provides context that other tools exist for forecasting or classification. However, it does not explicitly state when not to use this tool (e.g., when only a forecast is needed, use 'forecast_series' instead) or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry more weight. It states that it lists 'every' ID in the dataset, but is otherwise silent on behavioral aspects like whether it returns duplicates, how the dataset is loaded or refreshed, or what happens if the dataset is empty. Given the tool's simplicity and zero parameters, the description is adequate but lacks nuance.
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?
Single sentence, 7 words, front-loaded with the action and object. Every part is informative and there is no redundancy. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no parameters, the output schema exists (so return values are documented), no nested objects, and the tool's purpose is straightforward, the description is entirely sufficient. An agent can determine when to call this tool (to discover available IDs) with complete confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameters and schema description coverage is 100%, so there is nothing for the description to add about parameter meaning. The baseline for zero-parameter tools is high, and the description does not need to elaborate, earning a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('list') and resource ('SKU/series id'), and the scope is clearly defined ('in the loaded dataset'). It distinguishes itself well from sibling tools like 'classify_demand_pattern' or 'forecast_series', which are analytical or predictive rather than listing identifiers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that use of this tool is appropriate before performing tasks that require specific SKU/series IDs. However, there is no explicit guidance on when not to use it or how it relates to siblings—for example, whether listings from other tools differ. Still, the context is clear enough for an agent to decide, especially given it has no parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![forecast-mcp MCP server](https://glama.ai/mcp/servers/RohanSingh02/forecast-mcp/badges/card.svg)](https://glama.ai/mcp/servers/RohanSingh02/forecast-mcp)

Score Badge

Copy to your README.md:

[![forecast-mcp MCP server](https://glama.ai/mcp/servers/RohanSingh02/forecast-mcp/badges/score.svg)](https://glama.ai/mcp/servers/RohanSingh02/forecast-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/RohanSingh02/forecast-mcp'

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