FoundryNet — Industrial Machine Intelligence
Server Details
Cross-OEM industrial machine intelligence: identity, normalization, automation, attestation.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 14 of 14 tools scored.
Each tool serves a unique, clearly defined purpose (e.g., identity, normalization, automation lifecycle, history, sandbox, on-chain proof). No two tools overlap in functionality, minimizing selection ambiguity.
All tool names follow a consistent verb_noun pattern (e.g., identify_machine, normalize_telemetry, create_automation). No mixing of conventions or vague verbs.
With 14 tools, the server covers a broad domain (identity, data ingestion, automation management, feedback, history, sandbox, on-chain verification) without being overwhelming or sparse. Each tool earns its place.
The tool surface is largely complete for industrial machine intelligence, covering provisioning, normalization, automation CRUD (with soft delete/restore), correction, coverage, history, and on-chain anchoring. A minor gap is the absence of a dedicated update_automation tool (aside from enabling via disable_automation's note), but workflows can work around it.
Available Tools
14 toolsactivate_automationAInspect
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).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| actions | Yes | ||
| enabled | No | ||
| condition | Yes | ||
| machine_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details that the tool creates a live trigger, monitors telemetry, fires actions via webhooks with variable interpolation, and activates on every subsequent normalize_telemetry call. However, it omits concurrency limits or error states, leaving minor gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections: summary, input list, return info, usage notes. Front-loaded. Slightly verbose with detailed interpolation fields, but organized effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers behavior, parameters, return value (id), and lifecycle. Missing error handling for invalid machine_id and references external Forge API. Reasonably complete given complexity and sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully explains each parameter: machine_id (ID formats), name (≤80 chars), condition (simple vs compound, ops), actions (list with overrides), enabled (default true). Adds significant meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it activates a parsed automation trigger, using verb 'Activate' and specifying the resource as an automation trigger. It distinguishes from siblings like create_automation (which returns parsed_trigger) and delete_automation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call: 'Call this AFTER create_automation returns a parsed_trigger and the user explicitly confirms they want to arm it.' Also warns: 'Never call this tool without explicit confirmation.' Provides clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
correct_mappingAInspect
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
canonicalfrom that field's entry; use "abstained" if it abstained).oem: the OEM you passed to normalize_telemetry (improves aggregation).
mapping_id: optional — the
mapping_idfrom 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.
| Name | Required | Description | Default |
|---|---|---|---|
| oem | No | ||
| confidence | No | ||
| mapping_id | No | ||
| sample_value | No | ||
| source_field | Yes | ||
| original_canonical | Yes | ||
| confirmed_canonical | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains behavioral traits: corrections are recorded as signals for retraining, not hot-patched, so noisy feedback doesn't affect others. It also describes the return structure and safety properties.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with purpose, then usage, then parameter details. It is longer but each sentence adds value, making it concise without being wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters and no annotations, the description covers the feedback mechanism, safety, and return structure (output schema exists). It is complete enough for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains the required parameters (source_field, confirmed_canonical, original_canonical) and optional ones (oem, mapping_id). However, it does not detail sample_value and confidence, which are in the schema but not described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to correct wrong canonical mappings from normalize_telemetry. It uses specific verbs like 'correct' and 'teach', and distinguishes from sibling tools by focusing on fixing mapping errors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (when normalize_telemetry returns wrong canonical or abstains) and gives examples. It does not explicitly state when not to use it, but the use case is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_automationAInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| mint_id | Yes | ||
| instruction | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool returns parsed_trigger for human review, does not auto-activate, requires explicit POST to /v1/triggers, and notes fuzzy matching. This fully informs the agent about behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with sections: purpose, examples, return protocol, usage. It is front-loaded but somewhat lengthy; could be more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and simple params, description fully explains return value (parsed_trigger) and necessary activation steps. It provides complete context for agent to use tool properly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description provides examples for 'instruction' parameter but does not explain 'mint_id' parameter, leaving its meaning unclear. Partial compensation via examples is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Set up automated monitoring + actions for an industrial machine' with natural language, distinguishing it from siblings like activate_automation and delete_automation. Examples illustrate usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'USE WHEN' clause indicates appropriate scenarios. It advises showing parsed_trigger for user confirmation, but does not explicitly mention when not to use or compare to siblings beyond activation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_automationAInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| trigger_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the behavioral disclosure burden. It details soft-deletion mechanics (30-day recovery, row persistence with deleted_at, audit trail, permanent deletion option with ?permanent=true) and specific side effects on /v1/normalize calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with two paragraphs: one for behaviour and one for usage guidance. It is front-loaded with the core action. Though slightly long, every sentence serves a purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no annotations, and an output schema (not shown), the description covers recovery, audit, and usage well. It lacks explicit error conditions or permission requirements, but overall is sufficient for the stated function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description does not explicitly describe the trigger_id parameter beyond its use in context. The parameter is self-explanatory given the tool name, but the description could add value by specifying how to obtain the ID or any constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action as a soft-delete that is recoverable for 30 days, and distinguishes it from hard deletion. It specifies the resource (trigger/automation) and states immediate effects like stopping evaluation and hiding from list_automations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE WHEN' section explicitly advises using this tool when the user wants to remove an automation, highlighting recoverability as safety. It contrasts with hard delete and mentions restore_automation, but does not directly compare to disable_automation sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
disable_automationAInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| trigger_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains that the trigger stops evaluating against incoming calls but preserves configuration, history, and actions. This covers the main behavioral traits. However, it does not mention required permissions or error conditions, but given no annotations, it is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two paragraphs, each serving a distinct purpose: behavior and usage. Every sentence adds value, no fluff. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description covers purpose, usage, behavior, and even follow-up steps. It does not discuss error handling or prerequisites, but given the tool's simplicity, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the parameter 'trigger_id' is implied by the tool's purpose ('pause an automation trigger'). The description does not explicitly describe the parameter's format or how to obtain it, but the context is clear. A more explicit parameter description would be better.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool pauses an automation trigger without deleting it, and explicitly distinguishes it from delete_automation (permanent). The verb 'disable' with 'automation trigger' is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE WHEN' section provides clear scenarios (temporary stop, planned maintenance) and explicitly contrasts with delete_automation. It also suggests re-enabling via PATCH, guiding the agent on next steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fire_sandboxAInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| message | No | The payload text the sandbox webhook receives. Defaults to a representative example. | Spindle load crossed 85%. Sandbox demo fire. |
| condition_text | Yes | A plain-English description of the condition the sandbox is simulating, e.g. "Spindle load crossed 85%". |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the tool's behavior: it makes an HTTP round-trip, hashes the response, anchors on Solana mainnet, and returns specific fields. It also mentions the lifetime limit of 10 fires per key. No behavioral traits are hidden or contradicted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet comprehensive, with a clear structure: overview, technical details, return values, and usage guidance. Every sentence adds value, and there is no redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (reducing the need for return value descriptions), the description provides sufficient context for a demo tool. It covers the loop, the sandbox nature, the lifetime limit, and the expected outputs. A developer has all information needed to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning beyond the schema: it explains the default value for 'message' and the role of 'condition_text' as a plain-English description of the simulated condition. This helps the agent understand the purpose of each parameter in the sandbox context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool demonstrates the full Forge watch→fire→settle loop against a sandbox endpoint. It specifies the action (POST to /sandbox/echo, hash response, anchor on Solana) and the return values. No sibling tool duplicates this functionality, making it clearly distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a 'USE WHEN' section that clearly identifies the target user (developer evaluating Forge) and context (no machine onboarding, free tier). It lacks explicit statements about when not to use or alternative tools, but the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_coverageAInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| oem | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses that unknown OEMs still normalize (gate disables itself). For a read-only introspection tool, this behavioral context is sufficient. Does not cover rate limits or auth, but those are less critical here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately sized with a clear structure: what the tool does, optional parameter usage, and when to use. A few sentences could be trimmed, but it remains efficient and front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter introspection tool with an output schema, the description covers all necessary aspects: purpose, usage, parameter behavior, and context. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'oem', has 0% schema description coverage, but the description adds meaning: passing an OEM shows which vertical it resolves to and whether the cross-vertical gate engages. This compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool asks Forge what it can normalize, listing specific outputs (OEM verticals, field families, field list per family). It distinguishes from siblings like normalize_telemetry by advising to call this first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'USE WHEN' section advises starting a new integration or before calling normalize_telemetry. Also explains that absence of an OEM is a soft signal, not a hard block, guiding decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
identify_machineAInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| oem | Yes | ||
| site | No | ||
| model | Yes | ||
| serial | Yes | ||
| metadata | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It mentions idempotency and return format but does not disclose side effects like on-chain creation costs, permission requirements, or error handling. More detail on the on-chain aspect would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose, examples, return format, idempotency, and usage guide. It is relatively concise given the amount of information conveyed, though it could be slightly trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description appropriately covers return format, idempotency, and the machine scope. It lacks error conditions, but overall is fairly complete for a tool with moderate complexity and good structured fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the three required params (oem, model, serial) and mentions optional metadata, but does not describe the 'site' parameter or provide validation rules. It adds some value but is not exhaustive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'provisions or retrieves an on-chain identity for any industrial machine', lists many machine types and OEMs, and specifies return values (mint_id, wallet_address). It distinguishes from siblings like normalize_telemetry and create_automation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a 'USE WHEN' section specifying when to call (user references a machine by OEM/model/serial) and ordering: 'Always call this first... before normalize_telemetry or create_automation.' This provides explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_automationsAInspect
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).
| Name | Required | Description | Default |
|---|---|---|---|
| machine_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It states the tool lists 'active' automations and enumerates return fields (id, name, condition, etc.), implying read-only behavior. No mention of side effects, but for a list operation this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line purpose, a bullet list of returned fields, and a 'USE WHEN' section. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and an output schema, the description covers purpose, usage, parameter details, and return values completely. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (machine_id) has no schema description (0% coverage), but the description adds significant meaning: 'Always pass the machine's mint_id (or internal_id — both resolve)'. This tells the agent exactly what values to use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all active automations / triggers configured for one machine', using a specific verb (list) and resource (automations/triggers). It distinguishes from sibling tools like create_automation or delete_automation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes an explicit 'USE WHEN' section with example user queries ('what automations do I have on this machine') and clarifies to pass the machine's mint_id or internal_id. Lacks explicit when-not-to-use or alternative tools, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
normalize_telemetryAInspect
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_firedarray 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.
| Name | Required | Description | Default |
|---|---|---|---|
| oem | No | ||
| data | Yes | ||
| site | No | ||
| model | No | ||
| serial | No | ||
| machine_id | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: auto-provisioning of machine identity, writing to forge_normalized_history, evaluating triggers, and returning triggers_fired array. It does not cover authentication or rate limits but provides sufficient detail for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with examples, a list of side effects, and a use-case section. It is slightly lengthy but each sentence adds value. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description appropriately covers the response structure (canonical_data, mapping_id, triggers_fired) and side effects (history write). It is complete for the agent to understand input, output, and side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the 'data' dict and the role of oem, model, serial, and machine_id, including auto-provisioning behavior. However, the 'site' parameter is not described, and schema description coverage is 0%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool translates raw telemetry to canonical FCS format with specific mapping examples. It distinguishes from siblings like identify_machine and correct_mapping by explaining auto-provisioning as a side effect and mentioning mapping_id for corrections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE WHEN' section explicitly lists three scenarios for using the tool. However, it does not explicitly state when not to use or compare directly to alternatives like identify_machine for identity provisioning.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_machine_historyAInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| to_dt | No | ||
| fields | No | ||
| from_dt | No | ||
| mint_id | Yes | ||
| summary | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains behavior for summary=true ('always cheap'), default limit, parameter formats (ISO-8601, comma-separated fields). Doesn't cover rate limits or auth, but adequately describes key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with bullet points for param options and a clear 'USE WHEN' section. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not detail return values. It covers all input parameters, provides usage guidance, and is complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description thoroughly explains each parameter: from_dt, to_dt, fields, limit, summary, with defaults and usage notes. Adds significant meaning beyond the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve operational history for an identified machine' and specifies it returns rows from /v1/normalize calls. It distinguishes from siblings like query_webhook_history by focusing on machine operational data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes a 'USE WHEN' section listing explicit scenarios (utilization, trends, alarms, period comparisons) and advises to start with summary=true for orientation. Lacks explicit when-not-to-use or direct alternatives, but provides good contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_webhook_historyAInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| trigger_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: returns up to `limit` rows (default 10, max 200), lists all returned fields, and mentions that soft-deleted triggers work. It does not cover rate limits or authentication, but the detail is substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: starts with purpose, then output details, then usage scenarios. Every sentence adds value, and it is appropriately sized for the information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description still fully explains the return fields and context (soft-delete queries). No gaps remain for the intended use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the `limit` parameter (default 10, max 200) but only implicitly mentions `trigger_id` as 'for a trigger' without further detail. This is adequate but not thorough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Show webhook delivery history for a trigger.' It specifies the data returned (HTTP status codes, response times, etc.) and distinguishes itself from siblings which are automation management tools, not query tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a 'USE WHEN' section listing specific user queries that trigger its use, such as 'did the alert actually go out?' and 'show me the last few fires.' It also notes that soft-deleted triggers can be queried, useful for forensic audits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
restore_automationAInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| trigger_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes re-enabling the trigger to evaluate against calls, return values (restored trigger row with restored: true and restored_at), and error codes (410, 409). No annotations provided, but description fully covers behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured with a 'USE WHEN' section. Slightly redundant in mentioning re-enabling and return values, but overall efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Completely covers behavior, error conditions, use cases, and return format. Output schema exists but description adds value by explaining return fields. Suitable for a simple restore tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (trigger_id) with 0% schema description coverage. The description does not explicitly describe the parameter, but its purpose is reasonably inferred from context. Could have benefited from a brief note on expected format or meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool restores a previously soft-deleted automation trigger within a 30-day window, with clear verb and resource. It distinguishes from siblings like delete_automation and disable_automation by mentioning the recovery window and being the 'undo' half of a flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'USE WHEN' section with specific scenarios (accidental deletion, undo flow) and even suggests pairing with disable_automation. Implicitly advises against use when trigger not deleted (409) or past 30 days (410).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_on_chainAInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| batch | No | ||
| mint_id | No | ||
| payload | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains the two modes, including how batch mode computes a Merkle root for multiple events and single-payload mode hashes JSON deterministically. It lists return values and instructs agents to always include the verify_url. However, it could mention that this is a write operation with associated costs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for modes and use cases. It is fairly long but every sentence adds value. A slightly more concise version could reduce a few words, but it remains within acceptable bounds.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, modes, parameters, use cases, return values, and a usage instruction. With an existing output schema, it doesn't need to detail return format further. Missing elements include prerequisites (e.g., MINT relay account) or error handling, but overall it is quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides types and defaults, but the description adds complete semantics: batch mode requires batch=true and mint_id, single-payload mode requires batch=false and payload. It also details that payload is hashed deterministically with sorted keys and no whitespace, which is critical for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool anchors data on Solana mainnet for cryptographic proof of work. It distinguishes two modes (batch and single-payload) and its use cases are unique compared to sibling tools like activate_automation or normalize_telemetry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE WHEN' section provides explicit scenarios such as settlement of work batches or anchoring quality reports. It differentiates the two modes for different needs. However, it does not explicitly state when not to use the tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!