# FoundryNet/forge-mcp [Health: Active]

**Category:** 🏭 Industrial & IoT  
**Repository:** https://github.com/FoundryNet/forge-mcp  
**GitHub Stars:** 0  
**Views:** 5  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/foundrynet-forge-mcp

## Description
Cross-manufacturer industrial MCP server — 14 tools for machine identity, telemetry normalization across 16 OEM families, plain-English automation, and on-chain (MINT) work attestation.

## Tools
Capabilities this server exposes over MCP:

- **identify_machine** — Provision or retrieve a persistent identity (mint_id) for any
industrial machine. Works for CNC machines, industrial robots, PLCs,
additive manufacturing cells, injection molders, presses, turbines,
pumps, compressors, conveyors — any equipment from any OEM:
Fanuc, Siemens, Haas, DMG Mori, Mazak, Okuma, Hurco, Doosan, Makino,
ABB, KUKA, Universal Robots, Yaskawa, Stäubli, FANUC Robotics,
Komatsu, Caterpillar, John Deere, Trumpf, Bystronic, Amada, EMAG,
Bosch Rexroth, Beckhoff, Rockwell Allen-Bradley.

Returns the mint_id (universal handle, format "MINT-xxxxxx"). Idempotent
— calling again with the same (oem, model, serial) returns the same
mint_id with `created: false`.

USE WHEN: a user references a specific machine by OEM/model/serial and
you need a stable handle to attach normalized data, automations, or
tamper-evident work records to. Always call this first when a new machine is
introduced to the conversation, before normalize_telemetry or
create_automation.
- **normalize_telemetry** — Give your agent a semantic understanding of machine data from any OEM:
translate raw vendor telemetry into one universal canonical schema (FCS,
FoundryNet Canonical Schema) so the agent can reason across vendors it has
never seen before.
Maps vendor-specific column names like "Spindle_Speed", "servo_load_x",
"CoolantTemp", "FeedRateOverride" into standard fields like
spindle_speed_rpm, axes.x_load_pct, sensor_readings.coolant_temp,
feed_override_pct.

Accepts a `data` dict of {raw_field: value}. If `machine_id` (mint_id
or internal_id) is omitted but oem+model+serial are provided, silently
auto-provisions the machine identity (same effect as calling
identify_machine first).

Each call:
  - Returns canonical_data + a per-field mapping_id (use mapping_id
    with /v1/feedback/{mapping_id}/correct if a mapping is wrong)
  - Writes a row to forge_normalized_history (visible via
    query_machine_history)
  - Evaluates active triggers; the response includes a `triggers_fired`
    array if any condition matched. The actual webhooks fire async, so
    the array tells you what was triggered without blocking on remote
    latency.

USE WHEN: you have raw machine data — a CSV row, a sensor reading, an
MES export, an alarm log line — and need to either (a) understand it
semantically using canonical field names, (b) feed an automation that
watches canonical fields, or (c) build up history for the machine.
- **query_machine_history** — Retrieve operational history for an identified machine. Each row is
one /v1/normalize call's canonical output (FCS field → value).

Query options:
  from_dt, to_dt   ISO-8601 timestamps to bound the time range
  fields           comma-separated FCS field names to project; omit for
                   full canonical_data
  limit            max rows (1–1000, default 100)
  summary          true → returns aggregate stats only (row_count,
                   time range, avg coverage_pct, fields_covered set)
                   without the raw rows. Always cheap.

USE WHEN: your agent needs to reason over how a machine has been running,
surface utilization or throughput or health trends, find patterns in
alarms or operational state, compare periods ("how was today vs
yesterday"), or discover what data is even available for a machine. Prefer
`summary=true` first to orient on volume + which fields are present,
then drill in with field projection on a smaller time window.
- **create_automation** — Let your agent wire machine telemetry to any business system in plain
English — ERP, CMMS, MES, Slack, Teams, email, Zapier, n8n — via webhooks
already registered as tools on the Forge service. The agent describes the
condition and the action; Forge parses it into a structured trigger.

Examples of `instruction`:
  "Alert maintenance Slack when spindle load exceeds 90 percent."
  "Create a Fiix work order when coolant temperature stays above 35°C
   for five minutes."
  "Notify the supervisor when part_count hits 500."
  "When the maintenance_type changes to CORRECTIVE, post to the ops
   channel."

Returns a `parsed_trigger` JSON for HUMAN review — DOES NOT
auto-activate. The caller (you, with user confirmation) must
explicitly POST the parsed_trigger to /v1/triggers on the Forge API
to actually create it. The response includes
`confirmation_required: true` and may include `notes` if the parser
had to make a fuzzy match (e.g. resolved an ambiguous field name to
its closest canonical match).

USE WHEN: a user wants to set up monitoring, alerts, or automations
for machine state transitions. Always show the parsed_trigger to the
user verbatim and ask "Confirm to activate?" before they activate it.
- **activate_automation** — Activate a parsed automation trigger on a machine. Call this AFTER
create_automation returns a parsed_trigger and the user explicitly
confirms they want to arm it.

Creates a live trigger that monitors the machine's normalized telemetry
and fires the listed actions when the condition matches. Each action
references a registered tool by tool_id; on fire, the tool's webhook
is POSTed with {{variable}} interpolation against the canonical data
context (mint_id, oem, model, serial, site, field, value, threshold,
plus every canonical field on the matched record).

Inputs:
  machine_id  mint_id ("MINT-…") or internal_id; resolved to canonical mint_id
  name        short human label, ≤ 80 chars (e.g. "high spindle load")
  condition   simple {field, op, value|threshold} OR compound {all: [...]}
              ops: >, <, >=, <=, ==, !=
  actions     list of {tool_id, payload_overrides?, headers_overrides?}
  enabled     defaults to true; pass false to create the trigger paused

Returns the persisted trigger row including `id` (use it later to
pause/edit/delete via the Forge API). Once active, the trigger fires
on every subsequent normalize_telemetry call where the condition
matches — no further activation needed.

USE WHEN: the user has reviewed the parsed_trigger from
create_automation and said something like "yes, activate it" /
"go ahead" / "arm it." Never call this tool without explicit
confirmation — it changes machine behavior in a way the user can
feel (real Slack messages, real ERP work orders).
- **list_automations** — List all active automations / triggers configured for one machine.

Returns each trigger with: id, name, condition (field/op/value or
compound `all`), actions (each resolved to its tool name + url +
method), enabled state, fire_count, last_fired_at, last_error.

USE WHEN: the user asks "what automations do I have on this machine"
/ "show me my triggers" / "what alerts am I getting" / "what's
monitoring this machine right now". Always pass the machine's
mint_id (or internal_id — both resolve).
- **list_guardrails** — List the hard safety guardrails configured on one machine.

Returns each guardrail with: id, name, the plain-English instruction it
was created from, its structured condition, scope, and enabled state.

Guardrails are NOT automations. An automation fires an alert and a human
decides; a guardrail blocks the action and nothing decides. You cannot
create, edit, disable, or override a guardrail through this MCP server —
that requires a human administrator. Attempting a write returns 403.

USE WHEN: before proposing or activating anything on a machine — "what
are the limits on this machine", "what am I not allowed to do here",
"why was my automation rejected". Reading this first is cheaper than
being rejected: pair it with check_guardrail to test a specific value.
- **check_guardrail** — Test whether a proposed action would be blocked, WITHOUT attempting it.

`proposed` is a dict of canonical field -> value you are considering, e.g.
{"spindle_speed_rpm": 13000}.

TWO LAYERS ANSWER, AND ONLY ONE OF THEM ALWAYS EXISTS.

  1. Registry-wide PHYSICAL BOUNDS. Always checked, nothing to configure.
     These are possibility envelopes for the canonical field, not limits for
     your machine: spindle_speed_rpm is declared [-50000, 50000] for every
     machine in the fleet.
  2. Per-machine GUARDRAILS written by an engineer. These carry the real
     operating limits — and they are OPT-IN. A machine nobody has authored
     rules for has NONE, and `list_guardrails` returns {"count": 0}.

So on a freshly provisioned machine:

  check_guardrail(mid, {"spindle_speed_rpm": 13000})
    -> {"would_block": false, "guardrail": null, "reason": null,
        "violations": [], "guardrails_evaluated": 0,
        "declared_bounds": {"spindle_speed_rpm": [-50000.0, 50000.0]},
        "physical_bounds_checked": true}

`would_block: false` with `guardrails_evaluated: 0` does NOT mean 13000 rpm
is safe for that spindle — it means nobody has told Forge what the spindle's
limit is, and 13000 is not physically impossible. DO NOT read it as
permission. Check `guardrails_evaluated`; if it is 0, say so to the user
rather than acting on the absence of a rule.

Once a rule exists the shape is what you would expect:

  -> {"would_block": true, "guardrail": "Spindle overspeed protection",
      "reason": "spindle_speed_rpm 13000 > limit 12000", "violations": [...]}

A field that resolves to no canonical at all is REFUSED, not passed:
`unresolvable_fields` is returned and the action is blocked, because an
unplaceable field cannot be range-checked.

This is a dry run: it writes nothing and is not recorded as a blocked
attempt. Call it BEFORE acting so you can self-correct to a safe value
instead of being rejected. If would_block is true, do not retry the same
value — adjust to satisfy the stated limit, or tell the user that a human
administrator must change the guardrail.

USE WHEN: you are about to recommend or set a value on a machine and want
to confirm it is inside the safe envelope — and to find out whether an
envelope has been declared at all.
- **disable_automation** — Pause an automation trigger without deleting it. The trigger stops
evaluating against incoming /v1/normalize calls but its configuration
(condition, actions, history) is preserved. Re-enable later by
PATCHing /v1/triggers/{id} with `{"enabled": true}` (or by asking
the user to confirm and creating a follow-up tool for resume).

USE WHEN: the user wants to TEMPORARILY stop an automation — e.g.
"pause the high-spindle alert during planned maintenance," "stop
that alarm for now, I'll re-enable it tomorrow." Distinct from
delete_automation, which is permanent.
- **delete_automation** — Soft-deletes the trigger (recoverable for 30 days via
restore_automation). The trigger immediately stops evaluating against
/v1/normalize calls and is hidden from list_automations, but the row
persists with deleted_at set so an accidental delete can be undone.
Use restore_automation to undo. For permanent deletion, the API
supports ?permanent=true.

Past forge_trigger_executions rows for this trigger remain in either
case (audit trail).

USE WHEN: the user wants to remove an automation they no longer need —
"delete the coolant alert," "remove that trigger." Safer than hard
delete because misclicks are recoverable; tell the user about
restore_automation if they later change their mind.
- **query_webhook_history** — Show webhook delivery history for a trigger — HTTP status codes,
response times, retry counts, errors. Use to verify webhooks are
actually delivering.

Returns up to `limit` most-recent execution rows (default 10, max 200),
each with: fired_at, http_status, attempt_count, response_time_ms,
error (if any), tool_name, target_url, and the settlement reference
(settled_tx) once the row has been rolled up via batch settle.

USE WHEN: a user asks "did the alert actually go out?" / "why didn't
Slack get pinged?" / "is the trigger working?" / "show me the last
few fires." Soft-deleted triggers can still be queried — useful for
forensic audits after a misclick + restore.
- **restore_automation** — Restore a previously soft-deleted automation trigger within its 30-day
recovery window. Re-enables the trigger so it evaluates against
incoming /v1/normalize calls again.

Returns the restored trigger row plus `restored: true` and the
`restored_at` timestamp. 410 (Gone) if the trigger was deleted more
than 30 days ago and is past the restorable window. 409 if the
trigger isn't actually deleted.

USE WHEN: a user accidentally deleted a trigger and wants it back.
Also useful as the "undo" half of a "delete then change my mind"
flow — pair with disable_automation when the user wants to pause
rather than delete in the first place.
- **verify_record** — Create a tamper-evident, independently verifiable record of work. The
record is hash-chained so anyone can confirm it has not been altered.
Two modes:

BATCH MODE (`batch=true`, requires `mint_id`):
  Collects every unsettled event for that machine — normalize calls,
  trigger fires, webhook executions — since the last batch. Computes
  a Merkle root of their event hashes and records that single root as
  one verifiable settlement. ONE settlement proves dozens to thousands
  of events. Returns: merkle_root, event_count, event_types breakdown,
  tx_signature, verify_url. Cost-efficient — call this
  once an hour or once a shift per machine, not per event.

SINGLE-PAYLOAD MODE (`batch=false`, requires `payload`):
  Hashes an arbitrary JSON `payload` deterministically (sorted keys,
  no whitespace) and records the hash. Returns: record_ref,
  payload_hash. Use for one-off proofs — inspection records, completed
  work orders, agent-to-agent handoffs — where you want an independent
  timestamp you can cite later.

  Off-chain by DEFAULT (`on_chain=false`): the record is a reversible
  database row, so it can be deleted, and creating one has no
  settlement cost. This is the right mode for ordinary agent work
  records. Pass `on_chain=true` to settle it permanently instead, which
  returns a tx_signature and verify_url and CANNOT be undone.

USE WHEN: a user wants tamper-proof evidence — a completed work batch,
proof a maintenance window happened, a hash-verified quality report,
rolling up a day's machine activity into a single verifiable work
record. ALWAYS include the `verify_url` in your reply so the user can
independently verify the record.
- **fire_sandbox** — Demo the full Forge watch→fire→settle loop against a built-in sandbox
endpoint. Free tier; no machine onboarding required.

The MCP server POSTs `{message, condition: condition_text, ts}` to its
own /sandbox/echo route — a real HTTP round-trip with a real response
body — then hashes the response and records a tamper-evident, verifiable
work record of it. Returns the echo body, the tx_signature, and a verify_url.

USE WHEN: a developer is evaluating Forge and wants to feel the full
loop (a webhook actually fires, a real settlement actually records, the
verification link actually resolves) without onboarding any machines or
paying for the Pro tier. 10 fires lifetime per fnet_ key.
- **correct_mapping** — Teach Forge the RIGHT canonical field for a source column that
normalize_telemetry mapped wrong (or abstained on). Each correction is
recorded as a corpus-improvement signal the retrainer uses to fix the
mapping for everyone — so every agent interaction makes normalization better.

USE WHEN: you or the user can see normalize_telemetry returned the wrong
canonical for a field (e.g. it mapped an oil-pressure column to a tire-
pressure field), or it abstained on a field whose meaning you know.

- source_field: the raw column name exactly as it appeared in your data.
- confirmed_canonical: the canonical field it SHOULD map to.
- original_canonical: what normalize_telemetry actually returned (pass the
  `canonical` from that field's entry; use "abstained" if it abstained).
- oem: the OEM you passed to normalize_telemetry (improves aggregation).
- mapping_id: optional — the `mapping_id` from the normalize_telemetry field
  entry. If omitted it is derived deterministically from (source_field, oem).

Returns {ok, feedback_id, action:"correct"}. Corrections feed an offline
retrain (they don't hot-patch the live corpus), so noisy feedback can't
poison other users' mappings.
- **get_coverage** — Ask Forge what it can normalize BEFORE you try.

Returns, straight from the kernel so this description cannot go stale:

  vertical_oems                   every OEM string that routes to a
                                  vertical, grouped by the vertical it
                                  actually resolves to
  verticals_without_oem_routing   verticals that ship vendor packs but have
                                  no OEM string to pass, so the
                                  cross-vertical gate cannot engage for them
  canonical_families              the canonical-field families and the field
                                  list per family
  canonical_field_count           fields in the registry
  vertical_packs                  packs loaded, mappings, and every vertical

READ THE RESPONSE, DO NOT TRUST A LIST IN THIS DESCRIPTION. This docstring
used to name "CNC / robot / vehicle / AMR" as the recognized verticals —
four of twenty. An agent that believed it would have concluded Forge does
not handle solar, energy, geothermal, water, mining, pharma, HVAC or data
centre assets, all of which ship packs, and the energy vertical is fully
gated with 30+ working OEM strings.

Optionally pass an `oem` to resolve it: the reply gives `vertical` and
whether `vertical_gate` is active. Unknown OEMs still normalize (the gate
disables itself), so absence is a soft signal, not a hard block — but it is
not a free one: with no gate, candidate canonicals from every other vertical
compete on cosine alone, which is how a geothermal brine inlet temperature
reached for `vehicle.air_inlet_temp`.

USE WHEN: starting a new integration, or deciding whether to call
normalize_telemetry — confirm the machine's OEM resolves and your fields
are in coverage.
- **predict** — Forecast the next `horizon` readings of a canonical telemetry series using
TimesFM (Google's time-series foundation model). Returns a point forecast
plus quantile uncertainty bands (q0.1 … q0.9) — no per-machine training
required. The kernel already normalizes raw OEM telemetry into canonical FCS
fields; this predicts where a field is headed next.

Args:
  time_series      historical canonical values, oldest→newest (≥16 recommended)
  canonical_field  the FCS field the series represents (e.g. "spindle_load_pct"),
                   carried through for labeling/provenance
  horizon          number of steps to predict (1–256, default 24)
  frequency        accepted for forward-compat; TimesFM 2.5 auto-detects cadence

USE WHEN: a user wants to know where a metric is trending — "what will spindle
load look like over the next 2 hours", "project coolant temperature", "forecast
throughput". For threshold/failure questions use predict_breach or
remaining_life instead. PREMIUM (Pro tier) — runs ML inference (~$0.05/call
once metered billing is active).
- **predict_breach** — Predict whether — and when — a canonical series will cross a threshold.
This is the parametric-insurance primitive: it answers "will this machine's
<field> exceed <threshold> within the forecast window, and how soon?".

Returns will_breach, estimated_steps_to_breach, a confidence, and a
quantile-derived breach_window {earliest, latest}. Every result carries a
deterministic data_hash so the prediction is cryptographically provable. Pass
a caller-owned `mint_id` to write an audit event tying the prediction to a
specific machine; add `settle=true` to record it as a verifiable settlement
for an insurance-grade, tamper-evident record.

Args:
  time_series      historical canonical values, oldest→newest (≥16 recommended)
  threshold        the value to test for a crossing (e.g. 95.0 for 95% load)
  canonical_field  FCS field the series represents (e.g. "spindle_load_pct")
  direction        "above" (default) or "below" — which side is the breach
  horizon          steps to look ahead (1–256, default 96)
  mint_id          caller-owned machine to record provenance to (optional)
  settle           if true and mint_id is owned, record a verifiable settlement (costs a fee)

USE WHEN: a user asks if/when a limit will be hit — "will spindle load breach
95% this shift", "is coolant temp going to exceed 35°C", "alert me before
pressure drops below 2 bar". PREMIUM (Pro tier), ~$0.05/call.
- **remaining_life** — Estimate a machine's remaining useful life before a failure threshold is
crossed, with a maintenance recommendation. A maintenance-planning reframing
of predict_breach: same TimesFM forecast, expressed as time-to-failure.

Returns remaining_steps (None if no failure forecast), remaining_useful_life_pct
(headroom to the threshold), failure_predicted, failure_window, a trend, and a
recommendation — one of immediate_maintenance / schedule_maintenance / monitor
/ healthy. Same provenance + optional verifiable settlement as predict_breach.

Args:
  time_series        historical canonical values, oldest→newest (≥16 recommended)
  failure_threshold  the value whose crossing constitutes failure
  canonical_field    FCS field the series represents (e.g. "bearing_vibration_mm_s")
  direction          "above" (default) or "below" — failure side
  horizon            steps to look ahead (1–256, default 96)
  mint_id / settle   optional provenance / verifiable settlement (see predict_breach)

USE WHEN: a user asks about maintenance timing or equipment health runway —
"how long until this bearing needs service", "remaining life on the spindle",
"should I schedule maintenance now". PREMIUM (Pro tier), ~$0.05/call.
- **predict_batch** — Predict for an entire FLEET in one call instead of one request per machine.
A 200-machine factory shouldn't make 200 round-trips — pass them all here and
get back a scored fleet overview plus per-machine predictions.
- **fleet_health** — Roll a fleet of machine predictions up into a single health dashboard: a
fleet health score, a critical/elevated/moderate/healthy risk distribution,
per-canonical-field risk rollups, and a maintenance priority queue with a
plain-English recommendation.

Args:
  machines  same shape as predict_batch — list (≤100) of
            { id, canonical_field?, values:[...], threshold?, direction? }.
            Machines with a `threshold` are bucketed by steps-to-breach
            (critical <6, elevated <24, moderate otherwise); the rest count
            as healthy.

USE WHEN: your agent needs to concentrate on where fleet risk is — "how
healthy is my fleet", "give me the maintenance queue", "where's my risk
concentrated". For raw per-machine numbers use predict_batch. PREMIUM (Pro
tier) — $0.50 per fleet assessment.
- **detect_anomalies** — Flag anomalies in a time series WITHOUT running a full forecast — z-score +
IQR outlier detection plus trend and rate-of-change (accelerating/steady/
decelerating). No TimesFM inference, so it's faster and cheaper than predict
and works on short series (≥4 points). Cross-references the canonical field's
known/derived normal range when one is available.

Args:
  values           the series to scan (≥4 points)
  canonical_field  FCS field the series represents (enables normal-range context)
  sensitivity      z-score threshold (default 2.0 ≈ 95%); higher = fewer flags

Returns anomaly_count, per-anomaly detail (index, value, z_score, deviation,
severity: critical/warning/minor), summary statistics, and an attestation hash.

USE WHEN: real-time monitoring or a spot check — "is this reading abnormal",
"any outliers in the last hour", "flag spikes in vibration". For 'where is it
headed' use predict; for 'will it cross X' use predict_breach. PREMIUM (Pro
tier) — $0.02/call (no ML inference).
- **machine_intelligence** — Complete machine intelligence from raw telemetry in ONE call: normalize the
field names (when `oem` is given), detect anomalies on every field, forecast
and predict threshold breaches where there's enough history, compute an overall
health score + letter grade (A–F), and assemble a maintenance queue — all
attested. This is the full stack: normalize → anomaly → forecast → breach
→ score → recommend, behind a single endpoint and a single payment.
- **prediction_accuracy** — Report how well the kernel's predictions have matched reality: total and
evaluated prediction counts, breach-prediction accuracy %, forecast mean
absolute error, and accuracy broken down by canonical field.

FREE — this is a trust signal. Check it BEFORE deciding to pay for a
prediction: "87% breach accuracy across 500 predictions" is the best evidence
that the paid forecast is worth buying. Accuracy improves over time as more
predictions are tracked and verified against actuals (each is logged with a
tamper-evident hash).

USE WHEN: a user (or you, on their behalf) wants to gauge how much to trust the
forecasts before spending on predict / predict_breach / machine_intelligence.
- **calculate_oee** — Overall Equipment Effectiveness (OEE = Availability × Performance ×
Quality) for one machine over a period, computed from telemetry the kernel
already collects. Returns the three-factor breakdown, a letter grade, and an
honest `available:false` with a reason when there isn't enough data.

Args:
  machine_id  the machine's id (e.g. "DEMO-FANUC-01")
  period      "shift" (default), "day", or "week"

USE WHEN: your agent needs to report how a machine is performing, locate
where the losses are, or produce a single number for a line. FREE — OEE is
the metric that embeds Forge in daily operations.
- **fleet_oee** — Fleet-wide OEE: per-machine cards plus a fleet-average OEE, worst
performers surfaced first.

Args:
  period  "shift" (default), "day", or "week"

USE WHEN: your agent needs to assess the whole floor in one call and
surface the worst performers ("how is the plant running this shift?"). FREE.
- **energy_consumption** — Energy consumption and cost for a machine over a period, derived from the
cumulative energy_kwh counter, with baseline comparison and anomaly
detection when a baseline exists.

Args:
  machine_id  the machine's id
  period      "shift" (default), "day", or "week"

USE WHEN: your agent needs to compute what a machine costs to run, or catch
an energy anomaly (a spike vs the rolling baseline).
- **shift_report** — A shift handover report across the fleet: OEE, energy, alerts, and actions
per machine, plus an AI-generated narrative summary. Auto-generated at each
shift change, no spreadsheet required.

Args:
  which  "current" (so-far this shift, default), "last" (the most recent
         completed shift), or "recent" (the last few reports)

USE WHEN: your agent needs to generate a shift handover across the fleet,
or a written summary of what happened, without a spreadsheet. FREE.
- **diagnose_machine** — Automated root-cause analysis for a machine event: correlates the
telemetry around the event (3σ anomaly detection + timeline) and reasons over
it to name the most likely cause, the evidence, and a recommended action.

Args:
  machine_id  the machine's id
  event_time  ISO 8601 timestamp of the event (defaults to now)
  symptom     what was observed, e.g. "machine stopped" or "vibration spike"

USE WHEN: something went wrong and your agent needs a first-pass root cause
to reason from. PREMIUM ($0.25/call) — runs LLM reasoning over the telemetry.
- **get_agent_card** — Get the credentials and trust score of an agent connected to this kernel —
its capabilities, computed trust score, governance constraints, and verified
work history on this kernel. Trust scores are COMPUTED from this kernel's own
verified work history, not self-reported, so they can't be inflated.

Scoped to agents connected to this kernel instance; included in your
subscription (no per-call charge). For cross-platform agent trust across any
framework, see Assay (assay.foundrynet.io).

USE WHEN your agent needs to present its credentials to a facility operator,
or to check another agent connected to this kernel before coordinating work
on your equipment.

Args:
  agent_id  the connected agent's id. Omit to get the built-in Forge
            Intelligence card (the kernel's own credentials + NASA benchmark).
- **list_agents** — List other agents connected to this kernel instance — their capabilities,
trust scores, and machine access. Trust is COMPUTED from this kernel's own
verified work history, not self-reported, so it can't be gamed.

Scoped to agents connected to this kernel instance; included in your
subscription (no per-call charge). For cross-platform agent trust across any
framework, see Assay (assay.foundrynet.io).

USE WHEN your agent needs to find another agent connected to this kernel with
a specific capability to coordinate with or delegate work to — e.g. a
monitoring agent that detected a bearing fault finding a maintenance agent
qualified to fix it. Compare the returned cards (trust, jobs, first-fix rate)
before selecting one.

Args:
  capability       keyword filter on capabilities (e.g. "bearing",
                   "vibration", "maintenance"). Substring match.
  min_trust_score  only return agents at/above this trust score (0.0-1.0).
  machine_id       only return agents that have accessed this machine.
- **health_index** — Compute a composite health index (0-1) for a machine by fusing ALL
available sensor readings against a healthy baseline. USE WHEN your agent
needs to assess overall machine health from multiple sensors simultaneously —
especially for detecting gradual degradation that no single sensor threshold
would catch (the failure mode univariate predict_breach misses).

Returns the current health score (1.0 = healthy, 0.0 = failed), trend
(declining / stable / improving), degradation rate, estimated remaining
useful life in steps, and the top factors driving the decline.

## Claude Desktop Quick Installation
Remote MCP endpoint (confidence: high). Install path detected from listing signals. Add as a URL/SSE server in your client:

```json
"mcpServers": {
  "forge-mcp": {
    "url": "https://mcp.foundrynet.io/mcp"
  }
}
```

## Documentation

## What FoundryNet/forge-mcp MCP server does

FoundryNet/forge-mcp MCP server connects MCP clients to FoundryNet's Forge v1 API for industrial machine intelligence. It is designed for CNCs, robots, and other industrial equipment from different manufacturers. The service presents a common interface for machine identity, telemetry, automation, prediction, operations reporting, guardrails, agent coordination, and work verification.

Telemetry from 18 manufacturer families can be converted into a canonical vocabulary with confirmed field mappings. This lets an agent use consistent field names across equipment such as Fanuc CNCs, KUKA arms, and Universal Robots cobots. The server also supports plain-English automation workflows, where an automation can be created and reviewed before activation.

## How it works

FoundryNet/forge-mcp MCP server is a stateless HTTP proxy. An MCP client sends tool requests to the hosted endpoint, and the proxy forwards them over HTTPS to `forge.foundrynet.io/v1/*` with a configured `fnet_` Bearer key. The repository describes the service as a separate Railway deployment with its own dependencies, including FastMCP and HTTPX.

The preferred endpoint uses Streamable HTTP at `https://mcp.foundrynet.io/mcp`. A legacy Server-Sent Events endpoint remains available at `https://mcp.foundrynet.io/sse`. Health and server-card endpoints are also provided. Because the proxy has no state of its own, machine and Forge data handling occurs through the upstream API.

## Setup and configuration

Create a FoundryNet account and obtain an `fnet_` API key, then configure the MCP client with the Streamable HTTP endpoint and an `Authorization: Bearer` header. Claude Desktop can use the `mcp-remote` bridge, while clients with native HTTP transport can connect directly. The README provides a Claude CLI example and a Claude Desktop configuration using `FNET_KEY`.

For a server-side deployment, set `FOUNDRYNET_API_KEY`. `FORGE_BASE_URL` defaults to `https://forge.foundrynet.io`, `PORT` defaults to `8080`, and `REQUEST_TIMEOUT` defaults to 30 seconds. The API key is required for successful tool calls; the process can boot without it, but requests return 401 until the key is supplied.

## Tools and capabilities

The 32 tools are grouped into the following areas:

- Identity and data: identify machines, normalize telemetry, query machine history, inspect coverage, and correct mappings.
- Automation: create, activate, list, disable, delete, and restore automations, plus query webhook history.
- Prediction: forecast values, predict threshold breaches, estimate remaining life, run batch predictions, score fleet health, detect anomalies, inspect machine intelligence, and review prediction accuracy.
- Operations: calculate OEE, calculate fleet OEE, measure energy consumption, produce shift reports, diagnose machines, and calculate a health index.
- Guardrails and agents: check or list guardrails, inspect the connected agents on the kernel, and list those agents.
- Work records and demonstration: verify completed work records or run the `fire_sandbox` watch-to-settle demonstration loop.

The free tier exposes read-only tools. Premium prediction and diagnostics tools use metered pay-per-use access. Agent-card and agent-list tools cover agents connected to the user's kernel and are not cross-platform discovery tools. `verify_record` creates a hash-verified, tamper-evident record of completed work.

## Limitations and notes

Access depends on a FoundryNet API key and the applicable subscription tier or usage charges. The repository identifies the software as proprietary commercial software owned by Foundry Labs LLC. New integrations should use Streamable HTTP rather than the retained SSE endpoint.

_Full upstream README: https://allmcps.com/mcp/foundrynet-forge-mcp/readme_