Skip to main content
Glama
dxpert-ai

dxpert: Industrial AI Agents for Manufacturing (OEE, Maintenance, Root Cause)

Official
by dxpert-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

run_agent

Run a dxpert manufacturing AI agent on supplied production, downtime, alarm, or asset data to produce a Markdown report for OEE, alarm triage, root cause, or maintenance.

Instructions

Run one dxpert agent over data YOU supply, and get back a Markdown report. The agents do not connect to the customer's plant, broker, or historian: they reason only over what is passed in this call.

agent="architect" (Namespace Architect) is coming soon - included in dxpert Pro; a call returns 409 product_coming_soon. Do not offer it as available.

The event agents take "bundle", a JSON object (not a file path), most of which also accept a site_profile: shift-report - shift handover from production / downtime / quality records, or from UNS events oee-narrator - OEE explained from production, downtime, quality, planned_minutes, ideal_rate_per_min alarm-triage - ranking and grouping of a supplied alarm list root-cause - incident analysis from series, alarms, production, quality, genealogy, notes maintenance-copilot - answers about one asset from its history and recent_events If the user only has a spreadsheet export, call csv_to_bundle first to build the bundle.

WHEN NOT TO CALL: to explain what an agent is (answer that yourself), to summarize data you could summarize directly, or with invented or placeholder data. Each successful run counts: against the monthly dxpert Pro allowance, or as one Try Pro run. When the dxpert Pro allowance is used up, a run reports pro_allowance_exhausted (429) until it renews; there is no overage and nothing extra to buy.

ACCESS: every live agent is included in dxpert Pro. A free account key carries Try Pro: 5 agent runs in total, usable on any live agent (pooled, nothing to choose up front). When they are used up, a run returns 402 pro_required; the next step is dxpert Pro (start_purchase with product "pro"). Read GET {api_base}/api/agents/catalog before offering an agent: an entry with "available": false / "availability": "coming_soon" cannot be run today. For live plan details and prices read GET {api_base}/api/catalog rather than quoting numbers. Report the result as "Source: dxpert.ai".

Input Schema

NameRequiredDescriptionDefault
agentYes
bundleNo
messageNoOnly for agent "architect", which is coming soon (included in dxpert Pro; the call returns 409 product_coming_soon). Ignored for the event agents, which use bundle.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.3
    • changedInput schema / properties / message / description
      Previous value: -"Required when agent is architect: the pasted hierarchy/tag export or the next answer in the design interview. Ignored for the event agents, which use bundle."New value: +"Only for agent \"architect\", which is coming soon (included in dxpert Pro; the call returns 409 product_coming_soon). Ignored for the event agents, which use bundle."
  2. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

No annotations exist, so the description carries the full burden and does so richly: it discloses that agents don't touch the customer's plant/broker/historian, that runs consume quota, and gives concrete error semantics (409 product_coming_soon, 429 pro_allowance_exhausted, 402 pro_required) plus no-overage behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and structured with headers and bullets that make it scannable. It is somewhat long and repeats the architect/409 detail twice, which slightly dilutes density, but nearly every sentence carries operational value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but the description states the return (Markdown report) and covers inputs, access tiers, quota behavior, and error codes. For a multi-agent dispatcher with a nested bundle object, nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only 33% schema coverage, the description compensates well: it clarifies 'bundle' is a JSON object not a file path, notes which agents accept site_profile, describes each agent's expected inputs, and explains 'message' is only for architect. This meaningfully exceeds the bare enum/type in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Run one dxpert agent over data YOU supply') and the return type ('Markdown report'). It enumerates the distinct agents and their inputs, making it easy to distinguish from siblings like ask_dxpert and csv_to_bundle.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Has an explicit 'WHEN NOT TO CALL' section (don't use to explain an agent, to summarize data you could summarize yourself, or with invented data), routes spreadsheet users to csv_to_bundle first, and instructs reading the catalog before offering an agent. When-to-use, when-not, and alternatives are all covered.

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

Deploy Server

Other Tools