FoundryNet Forge MCP server
Commit Nov 13, 2026Enables AI agents to interact with industrial machines through telemetry normalization, plain-English automation, and predictive maintenance tools.
Also known as FoundryNet/forge-mcp, forge-mcp
- Stars
- 0
- Tools
- β
- Downloads, 30 days
- β
- Latest version
- 1.1.0
- Last commit
- Nov 13, 2026
- License
- β
What is FoundryNet Forge MCP?
FoundryNet Forge enables AI agents to interact with industrial machines through telemetry normalization, plain-English automation, and predictive maintenance tools.
Summary generated from the project's README
About FoundryNet Forge MCP server
FoundryNet provides an industrial intelligence layer that allows AI agents to communicate with diverse manufacturing hardware. It functions as an HTTP proxy that normalizes telemetry from 18 different manufacturer families into a single canonical schema. This enables an agent to interact with various machines, such as Fanuc CNCs or KUKA robotic arms, using a consistent vocabulary regardless of the original equipment manufacturer.
Developers can connect this server to clients like Claude Desktop or Cursor using Streamable HTTP. Setup requires a Forge API key provided via an Authorization Bearer header. The server offers 36 tools that cover machine identity, operational history, and predictive maintenance. While the free tier provides read-only access to basic telemetry, premium features like failure prediction using TimesFM and advanced diagnostics require a paid subscription.
Every state-changing action is recorded as a tamper-evident work record to ensure accountability. The system is designed for industrial environments where agents need to parse plain-English instructions into structured automations and monitor fleet health through metrics like OEE and energy consumption.
What you can do with it
- 1Normalize diverse machine telemetryAn AI agent can query data from different robot brands using a single set of field names.
- 2Execute natural language automationsA developer can instruct an agent to convert simple English commands into machine-executable tasks.
- 3Predict industrial equipment failuresThe system can use TimesFM to forecast when a machine might experience a breakdown.
- 4Maintain verifiable operational logsEvery command that changes a machine state is saved as a secure, unchangeable record.
Written from the project's README. Every use case is checked against a quote from it.
How to install FoundryNet Forge MCP
Formats verified 10 Nov 2026Add to CursorAdd to GooseInstall FoundryNet Forge MCP in Claude Code
$ claude mcp add --transport http forge-mcp https://foundrynet-mcp-production.up.railway.app/mcpInstall FoundryNet Forge MCP in Cursor
~/.cursor/mcp.json
{
"mcpServers": {
"forge-mcp": {
"url": "https://foundrynet-mcp-production.up.railway.app/mcp"
}
}
}Install FoundryNet Forge MCP in VS Code
.vscode/mcp.json
{
"servers": {
"forge-mcp": {
"type": "http",
"url": "https://foundrynet-mcp-production.up.railway.app/mcp"
}
}
}Install FoundryNet Forge MCP in VS Code CLI
$ code --add-mcp '{"name":"forge-mcp","type":"http","url":"https://foundrynet-mcp-production.up.railway.app/mcp"}'Install FoundryNet Forge MCP in Codex
$ codex mcp add forge-mcp --url https://foundrynet-mcp-production.up.railway.app/mcpInstall FoundryNet Forge MCP in Codex config.toml
~/.codex/config.toml
[mcp_servers.forge-mcp] url = "https://foundrynet-mcp-production.up.railway.app/mcp"
Install FoundryNet Forge MCP in Gemini CLI
$ gemini mcp add -s user --transport http forge-mcp https://foundrynet-mcp-production.up.railway.app/mcpInstall FoundryNet Forge MCP in Gemini settings.json
~/.gemini/settings.json
{
"mcpServers": {
"forge-mcp": {
"url": "https://foundrynet-mcp-production.up.railway.app/mcp",
"type": "http"
}
}
}Configuration
FNET_KEY
| Name | Description | |
|---|---|---|
| FNET_KEY | β |
Automated checks
Ran Nov 15, 2026Full report βNot verified yet. A server needs a score of 80, no serious finding, and enough data for us to check. How checks work Β· What to fix for more points
- Source repository linked and reachablefoundrynet/forge-mcp is public and reachablegithub.com/foundrynet/forge-mcp βPass
- Package names this repository as its sourceNot checked
- Build provenance (Sigstore attestation)Not checked
- Open source license (OSI)No licenseFinding
- Commit or release in the last yearLast commit or release 2026-11-13github.com/foundrynet/forge-mcp βPass
- OpenSSF ScorecardNot checked
- Package name not close to a popular packageNot checked
- No critical advisory in the package or its dependenciesNot checked
- No hidden instructions to the model0 tool descriptions and the README read; no override phrases, credential paths or hidden charactersPass
- Destructive tools are labelledNot checked
- Remote endpoint answers the MCP handshakeEndpoint did not answer initialize: HTTP 400Finding
README
View on GitHubForge by FoundryNet β Industrial Machine Intelligence
The cross-manufacturer industrial MCP server. Talk to any CNC, robot, or industrial machine in natural language β machine identity, telemetry normalization across 52 vendor packs in 20 verticals, plain-English automation, and tamper-evident work records.
Hosted MCP over Streamable HTTP. 36 tools wrap the Forge v1 API: provision a stable machine identity, normalize raw OEM telemetry into a canonical schema, query operational history, parse and activate plain-English automations, predict failures (TimesFM), score fleet health, and record every state-changing action as a verifiable, tamper-evident work record.
- Website: https://foundrynet.io/?utm_source=github&utm_medium=readme&utm_campaign=forge-mcp-readme
- Docs: https://foundrynet.io/docs?utm_source=github&utm_medium=readme&utm_campaign=forge-mcp-readme Β· Free key: https://foundrynet.io/signup?utm_source=github&utm_medium=readme&utm_campaign=forge-mcp-readme
- MCP endpoint (Streamable HTTP):
https://mcp.foundrynet.io/mcp - Legacy SSE endpoint (still served):
https://mcp.foundrynet.io/sse - Health:
https://mcp.foundrynet.io/health - Server card:
https://mcp.foundrynet.io/.well-known/mcp/server-card.json
What it does
It normalizes raw OEM telemetry from 18 manufacturer families into one canonical vocabulary with thousands of confirmed field mappings β so an agent writes against one set of field names whether the machine is a Fanuc CNC, a KUKA arm, or a Universal Robots cobot. On top of that it turns plain-English instructions into structured automations (review then activate), and records every state-changing action as a tamper-evident work record.
Architecture
Pure HTTP proxy. Every tool is a thin wrapper around https://forge.foundrynet.io/v1/*.
No state, no shared imports with forge-prod β separate Railway service, separate
dependencies (fastmcp + httpx).
Claude Desktop / agent
β Streamable HTTP (/mcp) β or legacy SSE (/sse)
β Authorization: Bearer <the CALLER's Forge API key>
βΌ
foundrynet-mcp on Railway
β gate: validate key β tier β cap β bind caller
β HTTPS, Authorization: Bearer <the SAME caller's key>
β X-Forge-Caller-Key-Id: <their forge_api_keys.id>
βΌ
forge.foundrynet.io/v1/* β scopes every row to that caller
Tenancy. The upstream call is made as the CALLER, not as this server. It used
to be made with the server's own FOUNDRYNET_API_KEY for every caller, with no
caller named: forge-prod scopes rows to the authenticated key's owner, so every
MCP tenant read and wrote inside one shared Forge account β and fleet_oee,
shift_report, list_agents and prediction_accuracy take no machine argument,
so they returned that whole account. The upstream hop now REFUSES to run when it
cannot name the caller: there is no fallback, because the only fallback is the
shared key. OAuth access tokens carry a key id but not a key, so they cannot be
presented upstream and are refused on tool calls with
tenant_context_unavailable.
POST /a2a/tasks and GET /a2a/agents go through the same gate function
(gating.enforce_call) as tools/call, by skillβtool mapping. They previously
authenticated the caller and then dispatched with no tier check, no cap and no
payment gate, which made the A2A route a free pass to the paid inference tools.
Tests and the release gate
python3 -m venv .venv && .venv/bin/pip install -r requirements.txt pytest pytest-asyncio
.venv/bin/python -m pytest tests/ -q # 229 checks
scripts/release_gate.sh # tree, deps, import, suite, version
The suite drives the real ASGI app over real Streamable HTTP through the real
gate; only Supabase and the upstream hop are substituted, and the upstream
substitute RECORDS requests, because what identity this server presents to
forge-prod is the thing most worth asserting. tests/test_rest_mcp_parity.py
measures free-tier parity against forge-prod's own _endpoint_to_billing_meter,
read out of its source at test time rather than copied.
CI runs the whole tree on every push and pull request
(.github/workflows/release-gate.yml, pinned to ubuntu-24.04): measured
223 passed, 6 skipped, 229 collected in 2m04s. The 6 skips are the checks
that read forge-prod's api.py off the local disk β 5 parity plus the
cost-ledger single-writer check β and they skip loudly, with their reason
printed, because forge-prod is a separate private repo and is not on the runner.
A visible skip beats a green tick over a check that was quietly dropped.
Deploying
cd ~/forge-mcp && git checkout main && git pull --ff-only && ./deploy.sh
Never railway up by hand. deploy.sh does seven things in order, and five of
them exist because of a specific way a deploy has gone wrong:
- refuses a dirty tree or a branch that is not
mainβrailway upuploads the WORKING TREE, so with uncommitted changes no commit describes what ships; - runs
scripts/release_gate.shand refuses if it is red. There is no override flag, deliberately; - takes a deploy lock (
~/.forge-mcp-deploy.lock, atomicmkdir) so two concurrent deploys cannot race on the upload and on the verification; - refuses if
railway upwould archive the wrong directory. It archives the CLOSEST LINKED project directory from~/.railway/config.json, walking UP β not$PWD. This directory once inherited$HOME's link, which names a DIFFERENT SERVICE; - runs
stamp_build.py, which writesbuild_info.json(commit, dirty state,content_hashover the uploaded file set, build time); railway up --service 162115b7-β¦β the id is explicit, because a barerailway upresolves the service from that same ancestor link;- polls
https://mcp.foundrynet.io/healthuntilbuild.commit_shortANDbuild.content_hashboth equal the stamp it just wrote, then asserts the status. Railway reporting SUCCESS only means the upload and build succeeded β a crash-looping new container leaves the OLD one serving and the deploy looks fine.content_hashis checked as well as the commit becauserailway upuploads a tree: the same commit with a different tree is a different deployment.
/health carries a build block using the same key names as forge-prod's, so
one verifier reads both services. When build_info.json is absent it says so in
words β build_info.json absent β deploy did not run stamp_build.py, with
commit, content_hash and built_at present and null β because a null that
looks like a missing field is indistinguishable from a stamped build.
Tools (36)
Identity & data: identify_machine, normalize_telemetry, query_machine_history,
get_coverage, correct_mapping. Automation: create_automation, activate_automation,
list_automations, disable_automation, delete_automation, restore_automation,
query_webhook_history. Prediction (TimesFM): predict, predict_breach, remaining_life,
predict_batch, fleet_health, detect_anomalies, machine_intelligence,
prediction_accuracy. Operations: calculate_oee, fleet_oee, energy_consumption,
shift_report, diagnose_machine, health_index. Guardrails: check_guardrail,
list_guardrails. Agents on your kernel: get_agent_card,
list_agents. Work records: verify_record. Demo: fire_sandbox (the full watch β fire β
settle loop, no card).
get_agent_card and list_agents are scoped to the agents connected to your kernel instance
(their capabilities, trust scores, and machine access) and are included in your subscription β
there is no per-call charge. They are operational tools for coordinating agents on your own
equipment, not cross-platform discovery. For cross-platform agent trust across any framework,
see Assay (assay.foundrynet.io). verify_record creates a tamper-evident, hash-verified record
of completed work.
Free tier exposes the read-only tools; metered pay-per-use unlocks the premium prediction and diagnostics tools (see https://forge.foundrynet.io/pricing?utm_source=github&utm_medium=readme&utm_campaign=forge-mcp-readme).
Connect (Claude Desktop, Cursor, any MCP client)
claude mcp add --transport http foundrynet-forge \
https://mcp.foundrynet.io/mcp \
--header "Authorization: Bearer fnet_YOUR_KEY"
Or via claude_desktop_config.json with the mcp-remote bridge:
{
"mcpServers": {
"foundrynet-forge": {
"command": "npx",
"args": ["-y", "mcp-remote",
"https://mcp.foundrynet.io/mcp",
"--header", "Authorization:Bearer ${FNET_KEY}"],
"env": { "FNET_KEY": "fnet_β¦ (get a free key at foundrynet.io/signup)" }
}
}
}
Legacy SSE (--transport sse against https://mcp.foundrynet.io/sse) remains supported for
existing configs, but new integrations should use the Streamable HTTP /mcp endpoint above.
Get a free fnet_ key at https://foundrynet.io/signup?utm_source=github&utm_medium=readme&utm_campaign=forge-mcp-readme (50 normalize calls, no card).
Required environment (server-side)
| Var | Required | Default |
|---|---|---|
FOUNDRYNET_API_KEY |
No longer used on the tool path | Kept for the boot-time config report only; tool calls run as the caller's own key |
SUPABASE_URL / SUPABASE_SERVICE_KEY |
Yes for gating | unset = gating disabled, fail-open |
ENABLE_OAUTH_EXCHANGE |
No | default false: /oauth/token and its metadata answer 501 and JWTs are not accepted (G9). true re-enables the client-credentials flow |
MCP_JWT_SECRET |
No | with the exchange enabled: unset = issuance answers 503; key auth unaffected |
FORGE_BASE_URL |
No | https://forge.foundrynet.io |
PORT |
No | 8080 (Railway sets this automatically) |
REQUEST_TIMEOUT |
No | 120 (seconds) |
Files
mcp_server.pyβ the server (36 tools +/health+/.well-known/mcproutes)gating.pyβ per-client tier gating (Free vs Pro tool/quota enforcement)server.jsonβ MCP registry metadata (name, description, keywords, remote endpoint)smithery.yamlβ Smithery listing metadatarequirements.txtβfastmcp>=3.4.5,<4,httpx>=0.27,PyJWT>=2.14.0,supabase,stripetests/β the behavioural suite (auth, tenancy, parity, idempotency, cache scope)scripts/release_gate.shβ must be green on the exact commit before a deploydeploy.shβ the only path to production; gated, locked, stamped and verifiedstamp_build.pyβ writesbuild_info.json; what/health'sbuildblock reportsProcfileβ Railway start command (stamps, thenpython mcp_server.py).github/workflows/release-gate.ymlβ CI; the whole suite on push and PR
License
Proprietary (commercial). Β© Foundry Labs LLC. Contact: foundrynet@proton.me
FoundryNet Forge MCP questions
How do I add FoundryNet Forge MCP to Claude Code?
Run claude mcp add --transport http forge-mcp https://foundrynet-mcp-production.up.railway.app/mcp in your terminal. Add --scope user to make it available in every project.
How do I add FoundryNet Forge MCP to Cursor?
Open ~/.cursor/mcp.json and add the server under mcpServers, using the Cursor config shown in the install section above.
What kind of machines can I control?
You can interact with various industrial machines including CNCs, robots, and cobots from different manufacturers like Fanuc and KUKA.
How does the server handle different machine brands?
It normalizes raw OEM telemetry from 18 manufacturer families into a single canonical vocabulary.
Can I use plain English to automate my machines?
Yes, the server can parse and activate automations based on plain-English instructions.
Is there a free tier available?
Yes, the free tier provides access to read-only tools, and you can get a free key for testing.