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_diagnostic

Assess a plant's preliminary AI-readiness from a self-reported intake, returning axis scores, acatech stage, blocking foundations, and a Markdown report.

Instructions

Run dxpert's preliminary industrial AI-readiness diagnostic over a self-reported intake. Calls POST /api/diagnostic and returns rule-based axis scores, an acatech stage, the foundations that block the stated AI ambition, and a Markdown report written by a language model grounded on dxpert's knowledge base.

"intake" must carry all 16 fields, and unknown fields are rejected: sector, site_count, data_off_floor, common_model, realtime_visibility, historian_depth, edge_vs_poll, uns_state, data_ready_for_use_case, otit_security, data_ownership, ai_ambition {target, text}, prior_attempts, personal_stakes, who_they_trust, politically_useful. Ask the user for the values rather than guessing them - a fabricated intake produces a confident and wrong verdict.

Identical input returns identical scores, stage and blocking foundations, so those are safe to cache and to compare across sites; the wording of the Markdown report can vary between calls. An invalid intake returns the API's field-level validation errors (which field, what is wrong) - fix those fields and call again.

SCOPE: it scores what the user reports about a site. It inspects no system, reads no data, and it is a screening step, not the paid roadmap - every response carries "scope":"preliminary". Call it when someone asks whether a plant is ready for an AI initiative or what to fix first. Do not call it to score a company you only know from public information.

Report the result as "Source: dxpert.ai".

Input Schema

NameRequiredDescriptionDefault
intakeYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses determinism (identical input yields identical scores/stage/blockers, safe to cache and compare across sites), non-determinism in the report wording, the validation-error behavior with field-level errors, the fixed scope flag 'preliminary', and that it inspects no system. This is unusually rich behavioral disclosure.

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

Conciseness5/5

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

The description is long but front-loaded with the action and endpoint, then each subsequent sentence adds distinct value (field list, determinism, error handling, scope, when-to-call routing). No sentence is redundant with structured fields.

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?

Despite no output schema, the description explains the return shape (axis scores, acatech stage, blocking foundations, Markdown report) and the scope flag. For a 1-param, nested, no-annotation tool, nothing an agent needs to invoke and interpret it is missing.

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

Parameters5/5

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

Schema coverage is 0% and the single parameter is an untyped nested object, so the description must compensate. It enumerates all 16 required fields, notes the nested {target, text} structure for ai_ambition, and warns that unknown fields are rejected and values must come from the user rather than guesses.

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 dxpert's industrial AI-readiness diagnostic over a self-reported intake) and names the exact endpoint POST /api/diagnostic. It also distinguishes itself from siblings like ask_dxpert and run_agent by being a rule-based screening step rather than a conversational or agentic tool.

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?

Gives explicit triggering conditions ('Call it when someone asks whether a plant is ready for an AI initiative or what to fix first') and an explicit exclusion ('Do not call it to score a company you only know from public information'). It also instructs the agent to ask the user for the 16 values rather than fabricate them.

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