forge
Natural language to machine action.
Community: Submitted by a user or imported; check the owner before granting accessOnlineNo sign-inGlobalFreeRead-only
What it can do
- 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, pr
- 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
- 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 timesta
What data it sees
Do you need an account
No: the server works without sign-in
Natural language to machine action. Cross-manufacturer industrial telemetry normalization across 18 OEM families with thousands of confirmed field mappings. 30 MCP tools for machine identity, normalization, history, plain-English automation, TimesFM prediction (forecast, threshold-breach, remaining-life, batch + fleet health, anomaly detection, full-stack machine intelligence), and tamper-evident, hash-verified work attestation.
Server tool list (30)
Raw names from tools/list. Only developers need these.
| 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 attestations 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). |
| 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; the hash can be anchored on an external ledger when configured. 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 anchors 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 anchors the hash. Returns: payload_hash, tx_signature, verify_url. Use for one-off proofs — inspection records, completed work orders, signed reports — where you want a permanent independent timestamp. USE WHEN: a user wants tamper-proof evidence — settlement of a completed work batch, proof a maintenance window happened, anchoring a quality report, rolling up a day's machine activity into a single verifiable hash. 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 verifiable attestation 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: the recognized OEM verticals (CNC / robot / vehicle / AMR), the canonical-field families, and the field list per family. Optionally pass an `oem` to see which vertical it resolves to and whether the cross-vertical gate will engage. USE WHEN: starting a new integration, or deciding whether to call normalize_telemetry — confirm the machine's OEM and your fields are in coverage. Unknown OEMs still normalize (the gate just disables itself), so absence here is a soft signal, not a hard block. |
| 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 anchor 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 anchor 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 | Retrieve an agent's identity card — capabilities, trust scores, governance constraints, and verified work history. Trust scores are COMPUTED from the kernel's attested history, not self-reported, so they can't be inflated. USE WHEN your agent needs to present its credentials to a facility operator, or to evaluate another agent's qualifications before coordinating work. 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 | Discover other agents connected to this kernel — their capabilities, trust scores, and machine access. Trust is COMPUTED from attested history, not self-reported, so it can't be gamed. USE WHEN your agent needs to find another agent 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. |