ConsumerSim MCP Proxy
The ConsumerSim MCP Proxy server provides consumer confidence forecasts for three markets (US, EU27, JP) via two tools:
forecast_lookup: Retrieve a consumer confidence forecast for a specific region and time period.Required:
region(US, EU27, or JP) andmonth(YYYY-MM format)Optional:
week(1–4) for a weekly forecast within the monthReturns the forecast value, confidence interval (low/high), signal description, and interpretation
forecast_times: Discover available forecast periods.Optional:
region(US, EU27, or JP) to filter by marketReturns the list of periods you can query
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@ConsumerSim MCP Proxywhat's the consumer spending forecast for US in July 2026?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
ConsumerSim Forecast Interface
ConsumerSim provides consumer confidence forecasts for three markets:
USEU27JP
Users can access the forecasts in two ways:
View the public forecast website hosted from this repository.
Connect to the MCP server and ask for forecasts by region, month, and optional week.
This repository is an interface package only. It does not publish the private forecasting pipeline, model prompts, data refresh logic, source API keys, or private datasets.
What You Can Ask For
Use forecast_lookup when you need a forecast value.
Monthly forecast:
{
"region": "US",
"month": "2026-07"
}Weekly forecast:
{
"region": "EU27",
"month": "2026-07",
"week": 1
}Supported inputs:
region:US,EU27, orJPmonth: target month inYYYY-MMformatweek: optional week number within that month, such as1,2,3, or4
Use forecast_times to see which forecast periods are available.
{
"region": "JP"
}Related MCP server: data-science-mcp
Typical Response
forecast_lookup returns a forecast snapshot like this:
{
"region": "EU27",
"cadence": "weekly",
"requested_month": "2026-06",
"requested_week": "Jun W4",
"target_month": "2026-07",
"target_period": "Jul-26",
"week_label": "Jun W4",
"as_of": "2026-07-04",
"forecast": -13.32,
"interval_low": -14.71,
"interval_high": -12.39,
"signal": "Softening signal",
"interpretation": "Weekly nowcast through 2026-06-27 from the ConsumerSim pipeline."
}The exact fields may vary by backend version, but the response is designed to include the requested region and time, the forecast value, a confidence band, and a short interpretation.
Run As An MCP Server
Install the package:
python -m pip install -e .Configure the private backend endpoint:
$env:CONSUMERSIM_API_BASE_URL = "https://your-consumersim-backend.example.com"
$env:CONSUMERSIM_API_KEY = "<your access token>"Start the MCP server:
consumersim-mcpThe MCP server exposes:
forecast_lookupforecast_times
It forwards requests to the configured ConsumerSim backend and returns the backend result to the MCP client.
Run The Website Locally
The website is a static forecast dashboard under site/.
For a local preview backed by the private API:
python -m pip install -e .
$env:CONSUMERSIM_API_BASE_URL = "https://your-consumersim-backend.example.com"
$env:CONSUMERSIM_API_KEY = "<your access token>"
consumersim-webOpen:
http://127.0.0.1:4173The local web bridge serves the static site and proxies /api/site-data to the
private backend. This keeps backend credentials out of browser JavaScript.
Public Website Deployment
The recommended public deployment is GitHub Pages.
The included workflow:
.github/workflows/refresh-site.ymldoes the following:
Optionally writes
site/site-config.jsfromCONSUMERSIM_SITE_DATA_URL.Runs the public interface tests.
Deploys the
site/directory to GitHub Pages.
The repository does not commit site/data/consumersim_site_data.csv. The
website reads site data at runtime from window.CONSUMERSIM_SITE_DATA_URL or
from /api/site-data when served by the local web bridge.
The browser checks the runtime site-data endpoint every 60 seconds and refreshes
the rendered values when the CSV response changes. Set
window.CONSUMERSIM_SITE_DATA_REFRESH_MS in site/site-config.js to override
that interval, or set it to 0 to disable polling.
Repository setup:
Set Pages source to
GitHub Actions.Add
CONSUMERSIM_SITE_DATA_URLas a repository variable when deploying to GitHub Pages.
Do not put source data API keys or model API keys in GitHub. Those belong only on the private backend server.
Backend Settings
Required:
CONSUMERSIM_API_BASE_URL
Usually required:
CONSUMERSIM_API_KEY
Optional:
CONSUMERSIM_FORECAST_PATH, default/forecastCONSUMERSIM_TIMES_PATH, default/forecast/timesCONSUMERSIM_SITE_DATA_PATH, default/site-dataCONSUMERSIM_API_KEY_HEADER, defaultAuthorizationCONSUMERSIM_API_KEY_SCHEME, defaultBearerCONSUMERSIM_TIMEOUT_SECONDS, default30
Backend Contract
The proxy calls these backend routes:
POST {CONSUMERSIM_API_BASE_URL}/forecastGET {CONSUMERSIM_API_BASE_URL}/forecast/timesGET {CONSUMERSIM_API_BASE_URL}/site-data
Expected POST /forecast request:
{
"region": "EU27",
"month": "2026-06",
"week": 4
}Expected GET /site-data response:
as_of,record_type,region,...
2026-07-04,monthly_prediction,us,...Repository Boundary
This public repository should contain only:
MCP proxy code
public website assets
GitHub Pages deployment workflow
tests for the public interface
examples and documentation for users
Do not commit:
generated site CSV files
private forecasting pipeline code
model prompts or internal simulation logic
private data refresh scripts
source API keys
LLM API keys
private datasets
The private backend can update forecasts without exposing the internal ConsumerSim implementation.
Available Tools
2 toolsforecast_lookupD
| Name | Required | Description | Default |
|---|---|---|---|
| week | No | ||
| month | Yes | ||
| region | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forecast_timesD
| Name | Required | Description | Default |
|---|---|---|---|
| region | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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. Dates show when Glama detected each change.
2 tool updates
v0.1.0- First observed
forecast_lookup - First observed
forecast_times
TDQS
Both tools start with 'forecast_' and have no descriptions, making it impossible to distinguish their purposes. They likely overlap in functionality.
Both tools use consistent snake_case naming with the 'forecast_' prefix, following a clear pattern.
Only 2 tools for a server named 'ConsumerSim MCP Proxy' suggests an extremely narrow scope, likely insufficient for typical simulation tasks.
The server name implies simulation capabilities, but only forecast tools are present. Critical operations like simulation control or data retrieval are missing, making the surface severely incomplete.
Maintenance
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
Forecast product demand using historical sales and market signals.
Remote MCP endpoint for U.S. home forecasts, public benchmark data, and permit or zoning readiness.
PredictOracle - 12 forecasting tools: time-series, scenario analysis, risk projections.
Access US federal award, recipient, agency, and spending analytics data from USAspending.gov.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceExposes tools for retrieving weather forecasts and alerts using the National Weather Service API.-
- AlicenseNot gradedqualityCmaintenanceEnables time-series analysis and forecasting through a structured tool catalogue, including data loading, quality repair, diagnostics, and forecasting with ARIMA, exponential smoothing, Chronos-2, Toto 2.0, and AutoML.1MIT
- AlicenseAqualityCmaintenanceProvides curated US economic data from Treasury, FRED, BLS, BEA, and other sources through an MCP interface. Enables querying economic series, fetching data with provenance tracking, and accessing cached artifacts.9MIT
- AlicenseNot gradedqualityCmaintenanceEnables access to U.S. Bureau of Economic Analysis data through tools for retrieving parameter values and economic data.MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/RunRiotComeOn/ConsumerSim-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server