FoundryNet — Industrial Machine Intelligence

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.

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.

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.

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.

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 is faster and cheaper (no ML inference), works on short series (≥4 points), and cross-references normal ranges. It also specifies return value structure. Minor gap: no mention of error handling or prerequisites beyond length constraint.

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 summary, parameter list, and usage guidance. Front-loaded with key info. Pricing detail is somewhat extraneous but not detrimental. Could trim slightly, but overall efficient.

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 complexity (3 params, output schema exists), the description is thorough: explains method, constraints (≥4 points), usage context, and return values. Output schema presumably covers detailed return fields, so no further elaboration needed.

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, but the description fully explains each parameter: 'values' (series to scan, ≥4 points), 'canonical_field' (enables normal-range context), 'sensitivity' (z-score threshold with default and interpretation). Adds meaning beyond type and default.

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 'Flag anomalies' and details the method (z-score, IQR, trend/rate-of-change). It distinguishes from siblings like predict and predict_breach by explicitly stating when to use each, making its unique purpose clear.

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 with concrete examples (real-time monitoring, spot check). Specifically tells when not to use: for predictions use predict or predict_breach. Provides clear alternatives and context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must carry behavioral disclosure. It explains the main outputs and risk bucketing logic, but does not address error handling, invalid inputs, or side effects. Pricing is covered but beyond 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?

The description is well-structured with clear paragraphs for purpose, parameter, and usage. A bit verbose but each sentence adds value; could be tightened slightly.

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 single parameter, no annotations, and presence of output schema, the description covers all key aspects: what the tool does, how to use the parameter, when to use it, and what output to expect. Highly 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?

With 0% schema description coverage, the description fully explains the 'machines' parameter: its shape (matching predict_batch), constraints (≤100 list), and behavior of threshold for risk bucketing. This adds essential meaning absent from 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 rolls up machine predictions into a fleet health dashboard, listing specific outputs like health score and risk distribution. It also distinguishes from sibling predict_batch by contrasting fleet-level vs per-machine numbers.

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' condition tells the agent when to use this tool, and directs them to predict_batch for raw per-machine numbers. Mentions premium pricing, aiding decision-making.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses the full pipeline (normalize → anomaly → forecast → breach → score → recommend), mentions MINT-attested and single payment. It does not describe side effects or idempotency, but it appears to be a read-only compute operation, so no destructive behavior is implied.

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 three sentences that pack substantial information. It is front-loaded with the main purpose and followed by pipeline details. No wasted words, though could be slightly more concise.

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 complexity (multi-step pipeline, 4 parameters, nested objects), the description provides a high-level overview but lacks detail on input format for telemetry and thresholds. Since an output schema exists (context signal), the burden on description for return values is reduced, but input parameter gaps hurt 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?

Schema description coverage is 0%, so the description must compensate. It only explains the 'oem' parameter's effect on normalization. It does not describe 'machine_id', 'telemetry' (format), or 'thresholds'. This leaves significant ambiguity for the agent on how to structure inputs.

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 takes raw telemetry and performs a full pipeline: normalize field names (if oem given), detect anomalies, forecast, predict threshold breaches, compute health score and grade, and assemble maintenance queue. It distinguishes from siblings like normalize_telemetry, detect_anomalies, predict, etc., which are more granular.

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 says 'Complete machine intelligence from raw telemetry in ONE call' and implies when to use this tool vs. individual steps. It mentions the oem normalization condition. However, it does not provide explicit when-not or alternative tool suggestions, but given sibling tools 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.

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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries the burden. It discloses no per-machine training, kernel normalization, auto-detection of cadence, and receives quantile output. However, it does not mention rate limits or explicit read-only nature, though inference implies read-only. Good but not perfect.

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?

Front-loaded with main purpose, followed by args in a structured list, then usage guidance. Every sentence is informative and necessary.

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 output schema exists (not shown but noted), description covers needed behavioral context. Mentions output type (point forecast + quantile bands) and key constraints. No gaps for this 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 has 0% description coverage; description explains each parameter's meaning and constraints (e.g., time_series oldest->newest, horizon range 1-256, frequency for forward-compat). Adds significant value 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?

The description clearly states it forecasts the next horizon readings of a canonical telemetry series using TimesFM, specifying output as point forecast plus quantile uncertainty bands. It distinguishes from sibling tools like predict_breach and remaining_life.

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' for trend questions and directs threshold/failure questions to alternatives. Also notes premium/pro tier and approximate cost, providing clear when-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Describes operation as batch prediction, mentions output format, but lacks details on side effects, authentication, rate limits, or data handling. Reasonable 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?

Two concise sentences, each adding value. First states core functionality, second provides concrete example and clarifies outputs. No redundant 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?

High-level purpose and output are clear, but lacks input formatting details required for correct invocation. With an output schema existing but not shown, return values might be implicit, but input structure remains underdescribed.

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 'machines' (array of objects). Description says 'pass them all here' but does not specify expected structure or fields per machine object. Schema coverage is 0%, and description fails to compensate.

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 predicts for an entire FLEET in one call, contrasts with per-machine requests, and specifies outputs (scored fleet overview plus per-machine predictions). This distinguishes it from sibling tools like 'predict'.

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 contrasts with one request per machine and provides a concrete example (200-machine factory). Implies when to use (multiple machines) and suggests alternative (single machine use 'predict'), though not explicitly stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully discloses return values (will_breach, estimated_steps_to_breach, confidence, breach_window), cryptographic data_hash, MINT audit events, and optional on-chain settlement. It also mentions the premium tier and cost (~$0.05/call), providing complete 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 with a clear summary of returns, an Args list, and a Use When section. It is slightly verbose (e.g., 'cryptographically provable') but every sentence adds value. Could be more front-loaded with the core purpose, 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 7 parameters, an output schema exists (though not shown), and the tool is complex with optional on-chain behavior, the description covers all aspects: parameter details, return values, use cases, cost, and prerequisite (premium tier). It is fully complete for an agent to select and 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 description coverage is 0%, so the description must explain all parameters. It does so thoroughly: time_series (historical values, oldest→newest, ≥16 recommended), threshold, canonical_field, direction, horizon (1–256, default 96), mint_id (optional, for provenance), and settle (boolean, on-chain anchor). Examples and defaults are provided, adding 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 it predicts whether and when a canonical series will cross a threshold, and explicitly calls it the 'parametric-insurance primitive'. This distinguishes it from sibling tools like 'predict' by specifying the breach-with-threshold use case.

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 like 'will spindle load breach 95% this shift'. It does not explicitly state when not to use or compare to alternatives, but the examples are sufficient for typical use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses the tool is free, accuracy improves over time, and predictions are logged with tamper-evident hash. It does not mention side effects but as a read-only report, no contradiction.

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 a concise overview, then a highlighted free nature and use case section. Slightly verbose but 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 zero parameters and the presence of an output schema, the description fully explains the output content and context. It ties into the broader use case of verifying trust before spending, making it 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?

No parameters exist, so schema coverage is 100% by default. The description compensates by detailing what the output contains (total counts, accuracy %, etc.), adding meaning beyond the empty 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 reports prediction accuracy metrics (total/evaluated counts, breach accuracy %, MAE, breakdown by field). It distinguishes itself from siblings like predict and predict_breach by positioning itself as a trust signal.

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' to gauge trust before spending on predictions, and directly advises checking it before paying for a prediction. Provides clear context for 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.

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.

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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries burden. It describes return values and mentions it's a forecast (implied read-only), but does not explicitly state if it's destructive or has side effects. Adequate but missing some behavioral detail like rate limits or permission requirements.

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: starts with purpose, then output, then parameter list, then usage. Each sentence adds value, but could be slightly more concise (e.g., the parameter list is somewhat redundant with schema).

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 tool complexity (7 params, output schema exists, no annotations), description is very complete. It explains all inputs, output structure (including specific fields and recommendation categories), and usage context. The presence of output schema reduces need for return value details, but description still provides them.

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 fully explains all 7 parameters: time_series, failure_threshold, canonical_field, direction, horizon, mint_id, settle. It provides defaults, constraints (e.g., horizon 1-256), and examples. Completely compensates for 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 clearly states the tool estimates remaining useful life and provides maintenance recommendation. It distinguishes itself from sibling predict_breach by calling it a 'maintenance-planning reframing'. The verb 'estimate' and resource 'machine's remaining useful life' are specific.

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 with concrete examples ('how long until this bearing needs service') and context (premium tier, cost). Could be more explicit about when not to use, but the comparison to predict_breach provides some alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.