Loading ToolBench
A local, keyless simulation of the Forge industrial telemetry kernel. Real canonical schema, real vendor tag mappings, simulated equipment and simulated predictions.
Forge Sandbox demonstrates solid definition quality with comprehensive, production-grade descriptions and well-structured schemas. All 5 tools have detailed docstrings (194 - 500+ chars) explaining WHAT they do, WHEN to use them, and key parameters. Input schemas are present with type declarations and descriptions for all parameters. However, output schemas are not formally documented in the code, and error handling guidance is minimal. Tool naming follows verb_noun convention (normalize_, get_, predict_). The sandbox_tool decorator ensures descriptions are never empty, a good defensive pattern. No security issues detected (read-only tools, no secrets in params). Main gaps: missing output schema documentation, no error recovery guidance, and limited parameter constraints (enums, ranges).
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 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); machines that cannot be scored are reported as unscored, never 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. SANDBOX: this server simulates Forge locally. Canonical field names and vendor mappings are real; equipment readings and forecasts are simulated. No API key, no billing, no persistence. Production: https://forge.foundrynet.io
Ask Forge what it can normalize BEFORE you try: the recognized OEM verticals (CNC / robot / vehicle / AMR / additive / building automation), the canonical-field families, and the field list per family. Optionally pass an `oem` to see which vertical it resolves to. 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, so absence here is a soft signal, not a hard block. SANDBOX: this server simulates Forge locally. Canonical field names and vendor mappings are real; equipment readings and forecasts are simulated. No API key, no billing, no persistence. Production: https://forge.foundrynet.io
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}. Pass `oem` to select the mapping pack; an unrecognized oem still normalizes, using the signal classifier alone. Each call returns the canonical reading plus a per-field mapping record saying HOW each tag resolved (corpus / identity / signal / unknown) and at what confidence. Tags that resolve to nothing keep their raw name and value rather than being dropped. USE WHEN: you have raw machine data — a CSV row, a sensor reading, an MES export, an alarm log line — and need to understand it semantically using canonical field names. SANDBOX: this server simulates Forge locally. Canonical field names and vendor mappings are real; equipment readings and forecasts are simulated. No API key, no billing, no persistence. Production: https://forge.foundrynet.io
Output schemas not formally documented. Tools return complex dicts (normalized readings, field_mappings, stats, etc.) but the response structure is not declared in code or docstrings. LLMs cannot plan downstream calls without knowing what fields to expect.
Parameter constraints missing. 'horizon' accepts 1 - 256 but no min/max declared in schema. 'direction' accepts 'above'/'below' but no enum constraint. Free-form strings invite hallucinated values.
Error handling guidance absent. Tools return dicts but no documentation of error cases, recovery steps, or what to do if a prediction fails or a machine cannot be scored.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 70 | 2026-07-28+ | v2 |
Score many machines in one call and get per-machine predictions back, without the fleet-level rollup. Args: machines list (≤100) of { id, canonical_field?, values:[...], threshold?, direction? }. USE WHEN: you need per-machine breach predictions without the fleet aggregation. SANDBOX: this server simulates Forge locally. Canonical field names and vendor mappings are real; equipment readings and forecasts are simulated. No API key, no billing, no persistence. Production: https://forge.foundrynet.io
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 reproducible. 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 production only; ignored here. 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". The sandbox forecasts with least squares, not TimesFM. The response shape is identical; the numbers are not production's. SANDBOX: this server simulates Forge locally. Canonical field names and vendor mappings are real; equipment readings and forecasts are simulated. No API key, no billing, no persistence. Production: https://forge.foundrynet.io
Batch tools (fleet_health, predict_batch) accept ≤100 machines but no pagination or result limiting documented. If a fleet has 10k machines, behavior is undefined.
Parameter 'machines' in batch tools is an array of objects but the object schema (id, canonical_field, values, threshold, direction) is not formally defined in the input schema, only described in docstring.