Provision or retrieve a persistent on-chain 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") plus its Solana wallet_address. 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 on-chain settlements to. Always call this first when a new machine is introduced to the conversation, before normalize_telemetry or create_automation.

Translate raw machine telemetry from any OEM's proprietary format into universal canonical FCS (FoundryNet Canonical Schema) data. 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.

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: a user asks how a machine has been running, wants utilization or throughput or health trends, looks for patterns in alarms or operational state, compares periods ("how was today vs yesterday"), or wants to know 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.

Set up automated monitoring + actions for an industrial machine using natural language. Connect machine telemetry to any business system — ERP, CMMS, MES, Slack, Teams, email, Zapier, n8n — via webhooks already registered as tools on the Forge service.

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 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 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).

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.

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.

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 on-chain settlement tx (settled_tx) once the row has been Merkle-rooted 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 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.

Anchor data on Solana mainnet via the MINT relay for cryptographic proof of work. 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 on Solana. ONE transaction proves dozens to thousands of events. Returns: merkle_root, event_count, event_types breakdown, tx_signature, verify_url (Solscan link). 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 (a Solscan link) in your reply so the user can independently verify on-chain.

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 anchors it on Solana mainnet via the MINT relay. Returns the echo body, the tx_signature, and a Solscan verify_url.

USE WHEN: a developer is evaluating Forge and wants to feel the full loop (a webhook actually fires, a real Solana tx actually settles, the Solscan link actually verifies) without onboarding any machines or paying for the Pro tier. 10 fires lifetime per fnet_ key.

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.

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.