The foundry net-industrial server is a cross-manufacturer industrial machine intelligence platform supporting CNC machines, robots, PLCs, and more from 16+ OEM families (Fanuc, KUKA, Siemens, ABB, Universal Robots, etc.). It provides natural-language interfaces for monitoring, telemetry normalization, automation, and on-chain attestation via 14 tools:
Machine Identity Management: Provision or retrieve a persistent on-chain identity (mint_id + Solana wallet) for any industrial machine by OEM, model, and serial number — idempotent and universal across manufacturers.
Telemetry Normalization: Translate raw, vendor-specific machine data into a unified canonical schema (FCS), enabling a single field vocabulary regardless of manufacturer. Also evaluates active automation triggers on each call.
Coverage Inquiry: Check which OEM verticals, canonical field families, and specific fields the normalization engine supports before committing to an integration.
Mapping Correction: Submit feedback when a field is mapped incorrectly, improving normalization accuracy for all users.
Operational History Querying: Retrieve time-bounded historical telemetry with field projection, row limits, and summary/aggregate stats — useful for utilization trends, health analysis, and alarm pattern detection.
Automation Creation: Parse plain-English instructions (e.g., "Alert Slack when spindle load exceeds 90%") into structured triggers for review before activation.
Automation Activation: Arm a reviewed trigger to monitor normalized telemetry in real-time and fire actions (webhooks to Slack, ERP, CMMS, MES, etc.) when conditions are met.
Automation Management: List all active triggers for a machine, pause them temporarily, soft-delete them (recoverable for 30 days), or restore deleted triggers.
Webhook Delivery History: Inspect webhook execution logs — HTTP status codes, response times, retry counts, errors, and on-chain settlement transactions.
On-Chain Work Attestation: Anchor machine activity on Solana mainnet in batch mode (Merkle root of unsettled events) or single-payload mode (hash of arbitrary JSON) for tamper-evident, independently verifiable proof.
Sandbox Demo: Test the full watch→fire→settle loop (real HTTP webhook + real Solana transaction) without any machine onboarding — no setup required.
Allows anchoring work attestations on the Solana blockchain for tamper-evident records.
The cross-manufacturer industrial MCP server. Talk to any CNC, robot, or industrial machine in natural language — machine identity, telemetry normalization across 18 OEM families, plain-English automation, and tamper-evident work records.
Hosted MCP over Streamable HTTP. 32 tools wrap the Forge v1 API: provision a stable machine identity, normalize raw OEM telemetry into a canonical schema, query operational history, parse and activate plain-English automations, predict failures (TimesFM), score fleet health, and record every state-changing action as a verifiable, tamper-evident work record.
Website: https://foundrynet.io/?utm_source=github&utm_medium=readme&utm_campaign=forge-mcp-readme
Docs: https://foundrynet.io/docs?utm_source=github&utm_medium=readme&utm_campaign=forge-mcp-readme · Free key: https://foundrynet.io/signup?utm_source=github&utm_medium=readme&utm_campaign=forge-mcp-readme
MCP endpoint (Streamable HTTP): https://mcp.foundrynet.io/mcp
Legacy SSE endpoint (still served): https://mcp.foundrynet.io/sse
Health: https://mcp.foundrynet.io/health
Server card: https://mcp.foundrynet.io/.well-known/mcp/server-card.json
It normalizes raw OEM telemetry from 18 manufacturer families into one canonical vocabulary with thousands of confirmed field mappings — so an agent writes against one set of field names whether the machine is a Fanuc CNC, a KUKA arm, or a Universal Robots cobot. On top of that it turns plain-English instructions into structured automations (review then activate), and records every state-changing action as a tamper-evident work record.
Related MCP server: Industrial MCP Agent Platform
Pure HTTP proxy. Every tool is a thin wrapper around https://forge.foundrynet.io/v1/*
using a configured fnet_ Bearer key. No state, no shared imports with forge-prod —
separate Railway service, separate dependencies (fastmcp + httpx).
Claude Desktop / agent
│ Streamable HTTP (/mcp) — or legacy SSE (/sse)
▼
foundrynet-mcp on Railway
│ HTTPS + Bearer fnet_…
▼
forge.foundrynet.io/v1/*Identity & data: identify_machine, normalize_telemetry, query_machine_history,
get_coverage, correct_mapping. Automation: create_automation, activate_automation,
list_automations, disable_automation, delete_automation, restore_automation,
query_webhook_history. Prediction (TimesFM): predict, predict_breach, remaining_life,
predict_batch, fleet_health, detect_anomalies, machine_intelligence,
prediction_accuracy. Operations: calculate_oee, fleet_oee, energy_consumption,
shift_report, diagnose_machine, health_index. Guardrails: check_guardrail,
list_guardrails. Agents on your kernel: get_agent_card,
list_agents. Work records: verify_record. Demo: fire_sandbox (the full watch → fire →
settle loop, no card).
get_agent_card and list_agents are scoped to the agents connected to your kernel instance
(their capabilities, trust scores, and machine access) and are included in your subscription —
there is no per-call charge. They are operational tools for coordinating agents on your own
equipment, not cross-platform discovery. For cross-platform agent trust across any framework,
see Assay (assay.foundrynet.io). verify_record creates a tamper-evident, hash-verified record
of completed work.
Free tier exposes the read-only tools; metered pay-per-use unlocks the premium prediction and diagnostics tools (see https://forge.foundrynet.io/pricing?utm_source=github&utm_medium=readme&utm_campaign=forge-mcp-readme).
claude mcp add --transport http foundrynet-forge \
https://mcp.foundrynet.io/mcp \
--header "Authorization: Bearer fnet_YOUR_KEY"Or via claude_desktop_config.json with the mcp-remote bridge:
{
"mcpServers": {
"foundrynet-forge": {
"command": "npx",
"args": ["-y", "mcp-remote",
"https://mcp.foundrynet.io/mcp",
"--header", "Authorization:Bearer ${FNET_KEY}"],
"env": { "FNET_KEY": "fnet_… (get a free key at foundrynet.io/signup)" }
}
}
}Legacy SSE (--transport sse against https://mcp.foundrynet.io/sse) remains supported for
existing configs, but new integrations should use the Streamable HTTP /mcp endpoint above.
Get a free fnet_ key at https://foundrynet.io/signup?utm_source=github&utm_medium=readme&utm_campaign=forge-mcp-readme (50 normalize calls, no card).
Var | Required | Default |
| Yes | — (server boots; tool calls return 401 until set) |
| No |
|
| No | 8080 (Railway sets this automatically) |
| No | 30 (seconds) |
mcp_server.py — the server (32 tools + /health + /.well-known/mcp routes)
gating.py — per-client tier gating (Free vs Pro tool/quota enforcement)
server.json — MCP registry metadata (name, description, keywords, remote endpoint)
smithery.yaml — Smithery listing metadata
requirements.txt — fastmcp>=2.0, httpx>=0.27
Procfile — Railway start command (web: python mcp_server.py)
Proprietary (commercial). © Foundry Labs LLC. Contact: forge@foundrynet.io
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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains behavior: creates live trigger, monitors telemetry, fires actions with variable interpolation on condition match, returns trigger row with id, and notes the impact on machine behavior. Examples of real-world effects are given.
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 sections for inputs and returns, but is slightly verbose. Could tighten some sentences without losing clarity. Still, front-loads purpose 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?
Given 5 parameters with nested objects and an output schema, the description covers all necessary aspects: parameter details, behavior, return value, and usage 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?
Despite 0% schema description coverage, the description adds detailed explanations for all 5 parameters, including types, constraints (e.g., name ≤80 chars), structure of condition and actions, and defaults. This compensates fully 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 the action 'Activate a parsed automation trigger' and the resource 'on a machine'. It distinguishes from siblings like create_automation and disable_automation, providing specific verb+resource context.
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 says 'Call this AFTER create_automation returns a parsed_trigger and the user explicitly confirms' and warns 'Never call this tool without explicit confirmation'. This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| oem | No | ||
| confidence | No | ||
| mapping_id | No | ||
| sample_value | No | ||
| source_field | Yes | ||
| original_canonical | Yes | ||
| confirmed_canonical | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly states that corrections are recorded as corpus-improvement signals, feed an offline retrain, do not hot-patch the live corpus, and that noisy feedback cannot poison others. It also details the return object (ok, feedback_id, action).
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 appropriately sized and well-structured with a main paragraph and a bulleted parameter list. It is slightly verbose (e.g., 'so every agent interaction makes normalization better' is motivational but not essential), but still efficient overall.
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 complexity (7 parameters, output schema exists), the description is remarkably complete. It covers purpose, usage context, parameter meanings, return value, and behavioral implications (offline retrain). No important gaps remain.
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 adds significant meaning for 5 parameters (source_field, confirmed_canonical, original_canonical, oem, mapping_id) with clear explanations. However, two parameters (sample_value, confidence) are present in the schema but not described in the description, leaving a minor gap. Baseline for 0% schema coverage is higher, so overall it compensates well.
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 uses specific verbs ('correct', 'Teach Forge the RIGHT canonical field') and clearly distinguishes this tool from its sibling 'normalize_telemetry' by stating it is used when that tool returned wrong or abstained. The resource (canonical field mapping) is explicit.
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 provides explicit when-to-use conditions ('USE WHEN: you or the user can see normalize_telemetry returned the wrong canonical...') and explains the context (corrections feed an offline retrain, not live). It does not exclude alternatives but the sibling tools list shows this is unique.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses key behaviors: returns parsed_trigger for human review, does not auto-activate, requires explicit POST to /v1/triggers, includes confirmation_required and notes. Very transparent about lifecycle.
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: first paragraph defines tool, second gives examples, third explains return and activation step, fourth gives usage guidance. No fluff, each sentence adds value. 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?
Covers tool purpose, usage, parameters (partially), return format, and follow-up actions. Mentions webhooks but not authentication or permissions. With only two simple params and output schema referenced, it's mostly complete but lacks security context.
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 for two required params. Description compensates for 'instruction' with multiple examples, clarifying its natural language format. However, 'mint_id' is not explained; context suggests machine ID but not explicit. Overall adds significant value for instruction param.
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?
Clearly states the tool creates automated monitoring and actions for industrial machines using natural language. Specific verb 'create' and resource 'automation' distinguishing it from siblings like 'activate_automation' or 'delete_automation'. Examples reinforce purpose.
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 says 'USE WHEN: a user wants to set up monitoring, alerts, or automations for machine state transitions.' Provides clear post-use steps (show parsed_trigger to user, ask confirmation). Lacks explicit when-not-to-use but implied by context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the soft-delete behavior, recoverability (30 days), immediate cessation of evaluation, hiding from list_automations, and preservation of audit trail. It also mentions the permanent deletion parameter.
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 somewhat verbose but each sentence adds value (behavior, recovery, usage condition). It is well-structured and front-loads the key behavior. Minor redundancy could be trimmed, but overall effective.
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 simple parameter and existence of an output schema, the description covers all essential aspects: what it does, effects, recovery, audit trail, and usage guidance. It is complete for a delete 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 coverage, but the description makes it clear that the parameter identifies the trigger to delete. No additional validation or format details are given, but the context is sufficient for a single parameter.
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 it soft-deletes a trigger, explains the recovery window, and distinguishes it from permanent deletion. The verb 'soft-deletes' and resource 'trigger' are specific, and it references the sibling tool restore_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 provides a dedicated 'USE WHEN' section with concrete examples and contrasts with hard delete. It clearly tells the agent when to use this tool and mentions restore_automation as an alternative for undoing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses that the trigger stops evaluating incoming calls but preserves its configuration and history. It also mentions re-enabling via PATCH. However, it does not address permissions, rate limits, or the effect on existing history. The disclosure is good but not exhaustive.
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 informative with two paragraphs: first explains behavior, second provides usage examples and distinction. It is not overly verbose, but could be slightly more concise by removing the PATCH instruction (external to the tool). Overall well-structured.
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's simplicity (one required parameter, no annotations, output schema exists), the description covers behavior, usage context, and sibling differentiation. It does not mention error states or prerequisites, but for a pause operation this is adequate. Slightly more detail on the output would improve completeness.
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 implies a single parameter (trigger_id) by referencing 'the trigger' and the PATCH endpoint, but it does not explicitly describe the parameter or its expected format. Given 0% schema coverage, the description should compensate more; however, the purpose is clear enough that the parameter is likely the trigger ID.
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 deletion, preserving configuration and history. It distinguishes from sibling delete_automation (permanent) and implies relationship with activate_automation. The verb 'pause' and resource 'automation trigger' are specific and unambiguous.
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 provides 'USE WHEN' with examples of temporary stoppage (e.g., planned maintenance) and distinguishes from permanent deletion. This gives clear guidance on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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%". |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool makes an HTTP POST to a sandbox endpoint, hashes the response, and anchors it on Solana mainnet. It also mentions the lifetime limit of 10 fires. This is sufficient transparency for a demo tool, though it could specify authorization needs or potential costs (but the 'Free tier' note implies no cost).
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: first paragraph states purpose and output, second explains the process, third gives usage guidelines. Every sentence earns its place with no fluff.
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, usage context, parameter semantics, behavior, and output. An output schema exists, and the description adequately explains the return values (echo body, tx_signature, verify_url). No gaps for this tool's 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 100% with descriptions. The tool description adds value by explaining how parameters are used in the request (e.g., 'POSTs {message, condition: condition_text, ts}'), which goes beyond the schema definitions.
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: 'Demo the full Forge watch→fire→settle loop against a built-in sandbox endpoint.' It uses specific verbs and resources, and the context distinguishes it from sibling tools which focus on automations and queries. No tautology.
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 explicitly states when to use the tool: 'a developer is evaluating Forge... without onboarding any machines or paying for the Pro tier.' It provides clear context but does not mention when not to use it or name alternatives beyond the implicit context of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description must disclose behavioral traits. It explains that unknown OEMs still normalize (gate disables itself) and that passing optional oem resolves vertical and checks cross-vertical gate. This adds meaningful context, though it could mention read-only nature or side effects.
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: main purpose, then parameter explanation, then usage guidance. Sentences are efficient and informative, avoiding redundancy. Could be slightly more compact, but current length is appropriate.
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 (handling return values), the description covers purpose, usage, parameter semantics, and behavioral notes. It lacks details on output structure, but that is expected from output schema. Overall, fairly complete for a coverage-check 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?
Schema coverage is 0%, so description must compensate. It explains the optional oem parameter: 'see which vertical it resolves to and whether the cross-vertical gate will engage.' This adds semantic value beyond the mere schema definition, though format details are absent.
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 what the tool does: 'Ask Forge what it can normalize BEFORE you try' and lists outputs (OEM verticals, field families, field list). This distinguishes it from sibling tools like normalize_telemetry by emphasizing its role as a prerequisite check.
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 specifies when to use: 'starting a new integration, or deciding whether to call normalize_telemetry'. Also clarifies behavior for unknown OEMs (absence is a soft signal, not a hard block), providing clear guidance on decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses idempotent behavior ('calling again returns same mint_id with created: false') and what is returned (mint_id and wallet_address). However, it does not mention side effects, auth requirements, or rate limits. Still, it provides useful behavioral context.
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, front-loading the purpose, then providing examples, then idempotency, then usage guidance. It is slightly long but every part earns its place. Could be more concise without the extensive list of OEMs, but that adds 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 that the tool has an output schema (mentioned in context signals), the description need not explain return values in detail. It covers core functionality, usage context, and behavior. The optional parameters are not explained, but the core is 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?
Schema description coverage is 0%, so the description must compensate. It mentions oem, model, serial as key triple, but does not explain the optional parameters site and metadata. The description adds some meaning for required parameters but incompletely covers all five.
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: 'Provision or retrieve a persistent on-chain identity (mint_id) for any industrial machine.' It specifies the verb (provision/retrieve), the resource (on-chain identity), and distinguishes from sibling tools by stating it should be called before normalize_telemetry or 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 that specifies when to use the tool: when a user references a specific machine by OEM/model/serial and needs a stable handle. It also advises to call this first when a new machine is introduced. While it doesn't explicitly mention when not to use it, 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.
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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 lists active triggers and returns specific fields. The behavior is fully disclosed for a read-only list operation.
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 concise (about 5 lines), fronts the purpose, then lists return fields, and ends with usage guidance. Every sentence adds value.
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 low complexity (1 parameter, no annotations, output schema present but not shown), the description covers input, output structure, and usage context completely.
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 description adds meaning: machine_id should be the machine's mint_id or internal_id, both resolve. This compensates for the lack of schema descriptions.
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 states 'List all active automations / triggers configured for one machine.' The verb 'List' and resource 'automations/triggers' are clear. It distinguishes from siblings like create_automation, delete_automation, etc.
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 provides example user queries (e.g., 'what automations do I have') and instructs to pass the machine's mint_id or internal_id. This is excellent usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| oem | No | ||
| data | Yes | ||
| site | No | ||
| model | No | ||
| serial | No | ||
| machine_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It fully discloses side effects: auto-provisions machine identity, writes to forge_normalized_history, evaluates triggers, and notes asynchronous webhook firing. No contradictions with annotations.
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 relatively long but well-structured: first sentence defines core purpose, followed by mapping examples, per-call effects in bullet-like format, and a clear 'USE WHEN' section. Could be slightly more concise, but each sentence adds value.
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 6 parameters (1 required), output schema exists, and the tool has side effects, the description is complete. It explains output fields (canonical_data, mapping_id, triggers_fired), database writes, and trigger behavior, leaving no critical gaps for an agent to use it 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 description coverage is 0%, so description must compensate. It explains the 'data' dict, the optional machine_id, and the oem/model/serial combination for auto-provisioning. However, 'site' parameter is not explained. Overall, adds significant meaning beyond the 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?
The description clearly states the tool translates raw machine telemetry from proprietary formats into universal canonical FCS data. It distinguishes from siblings by mentioning auto-provisioning behavior similar to identify_machine and writing history accessible via query_machine_history.
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 lists three specific scenarios (a, b, c) and implies when not to use (e.g., use correct_mapping for fixing mapping errors). Also notes alternative 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.
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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It explains query options and notes summary mode is 'Always cheap'. However, it doesn't state that the tool is read-only or safe, which is implied but not explicit.
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, well-structured with bullet points 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?
Given moderate complexity (6 params, output schema exists), the description covers purpose, usage, parameters, and best practices comprehensively. No missing context.
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 coverage, the description must explain parameters. It covers from_dt, to_dt, fields, limit, and summary well (types, defaults, behavior). However, the required parameter 'mint_id' is not directly explained beyond 'identified machine', leaving ambiguity.
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 retrieves operational history for a machine, with each row being canonical output from normalize calls. It distinguishes from siblings like normalize_telemetry and get_coverage by focusing on historical queries.
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 lists concrete scenarios (utilization, health trends, period comparisons) and advises starting with summary=true. This provides excellent guidance on when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behavioral traits: it returns up to `limit` rows (with default and max), lists the returned fields, and explains that settled_tx appears only after batch settle. It does not explicitly state it is read-only or mention permissions, but the read nature is implied by 'Show' and the context 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 front-loaded: the first sentence states the purpose, followed by a clear list of returned fields, and a dedicated 'USE WHEN' section. Every sentence earns its place without unnecessary verbosity.
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 existence of an output schema (implied by the listed fields), the description already covers the key return values and behavioral nuance (e.g., settled_tx timing). It is complete for a query tool, though it could mention pagination beyond the limit parameter or error handling.
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 compensates by explaining the purpose of `trigger_id` (the webhook trigger) and providing details for `limit`: default 10, max 200, and that it returns the most-recent rows. This adds significant meaning beyond the bare schema types.
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 it shows webhook delivery history for a trigger, using a specific verb ('Show') and resource. It distinguishes from sibling tools, which are about automation management and machine history, making its purpose unambiguous.
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 provides usage scenarios with example user queries ('did the alert actually go out?') and notes that soft-deleted triggers can be queried, offering clear context. However, it lacks explicit 'when not to use' or alternative tool suggestions, which are not critical given the tool's unique purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description fully covers behavioral traits: it describes the 30-day recovery window, re-enabling side effect, return fields, and error codes (410, 409). This is transparent and comprehensive.
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 three short paragraphs, front-loaded with the core action and constraints. Every sentence adds value: purpose, return/errors, usage guidance. No wasted words.
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 simple parameter and an output schema, the description covers purpose, behavior, errors, usage, and expected result thoroughly. It is fully self-contained and meets the needs for correct invocation.
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 trigger_id is not explicitly described in the description, but the context ('Restore a previously soft-deleted automation trigger') clarifies its role. With 0% schema coverage, the description compensates by implying the parameter's purpose. A score of 4 is reasonable given the simplicity of the parameter.
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 restores a soft-deleted automation trigger within a 30-day window. The verb 'Restore' and resource 'automation trigger' are specific, and it distinguishes from siblings like delete_automation or disable_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?
It explicitly provides a 'USE WHEN' section that tells when to use (accidental deletion, undo flow) and suggests pairing with disable_automation as an alternative. This gives clear guidance on context and exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description fully explains the tool's behavior: it anchors data, computes Merkle roots for batches, hashes payloads deterministically, and returns verification links. It does not mention authorization or rate limits, but the core behavior is well covered.
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 headings for each mode and a 'USE WHEN' section. Every sentence is informative and necessary, with no redundancy or fluff. It is concise yet comprehensive.
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 tool with three parameters, no required fields, and an output schema, the description covers all relevant context: purpose, modes, return values (though output schema exists), usage scenarios, and user instructions. It is complete and leaves no ambiguity about when and how to use the 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?
Schema description coverage is 0%, so the description must compensate. It explains all three parameters (batch, mint_id, payload) by linking them to the two modes, specifying which are required per mode, and describing the payload hashing. The mint_id parameter could use more detail (e.g., its format or origin), but overall it adds significant semantic value beyond the 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?
The description clearly states the tool anchors data on Solana via MINT relay, with two explicit modes (batch and single-payload). It uses a specific verb ('anchor') and resource ('data on Solana mainnet'), and it distinguishes itself from sibling tools which focus on automation and 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 description includes a 'USE WHEN' section with concrete examples and instructs to always include the verify_url. It differentiates between batch and single modes. However, it does not explicitly state when NOT to use the tool, which slightly reduces the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0activate_automationcorrect_mappingcreate_automationdelete_automationdisable_automationfire_sandboxget_coverageidentify_machinelist_automationsnormalize_telemetryquery_machine_historyquery_webhook_historyrestore_automationverify_on_chainEach tool has a clearly distinct purpose covering machine identity, telemetry normalization, mapping corrections, coverage checks, history queries, automation lifecycle (create, activate, list, disable, delete, restore), webhook history, sandbox demo, and on-chain verification. No two tools overlap in their core functionality.
All tools follow a consistent verb_noun pattern in snake_case (e.g., identify_machine, normalize_telemetry, create_automation). The naming is predictable and intuitive, making it easy for an agent to infer tool purpose from the name.
14 tools is well-scoped for an industrial IoT platform. Each tool addresses a specific need without unnecessary redundancy. The count supports a comprehensive workflow without overwhelming the user.
The tool set covers the core lifecycle: machine identity, telemetry normalization with correction feedback, history queries, automation CRUD plus activation/disable/delete/restore, webhook monitoring, sandbox demo, and on-chain verification. A minor gap is the lack of a dedicated re-enable tool for disabled automations, but the disable description notes it can be done via PATCH, so agents can adapt.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Data-ontology maps of your business systems, served to AI agents over MCP.
Control plane for autonomous software labor. Agents claim objectives over MCP with audit trail.
Let AI agents query data and act across all your business apps via MCP.
Unified MCP Server is a remote MCP connector for AI agents and vertical AI products that provides access to 22,000+ authorized SaaS tools across 400+ integrations and 24 categories directly inside LLMs (Claude, GPT, Gemini, Cohere). Tools operate only on explicitly authorized customer connections, enabling agents to safely read and write against live third-party systems.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/FoundryNet/forge-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
