Dxpert.ai — industrial AI Readiness & UNS agents vs Predictive Maintenance MCP Server
A side-by-side look at the Dxpert.ai — industrial AI Readiness & UNS agents and Predictive Maintenance MCP Server MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Dxpert.ai — industrial AI Readiness & UNS agents for industrial & iot work as a local process; choose Predictive Maintenance MCP Server for industrial & iot as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose Dxpert.ai — industrial AI Readiness & UNS agents when
- You need dedicated capabilities in the Industrial & IoT domain.
- You prefer a local stdio subprocess transport.
- You want tools like
ask_dxpert, run_agent, run_diagnostic.
Choose Predictive Maintenance MCP Server when
- You need dedicated capabilities in the Industrial & IoT domain.
- You prefer a local stdio subprocess transport.
- You have the keys it needs:
PDM_PROJECT_DIR. - You want tools like
list_signals, generate_test_signal, load_signal.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Industrial & IoT | Industrial & IoT |
| Quality signal | 61/100 · Good | 63/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Local subprocess (stdio) |
| Auth | Not declared | Not declared |
| Pricing | Not declared | Not declared |
| Required env vars | None listed | PDM_PROJECT_DIR |
| Verified owner | Community listing | Community listing |
| GitHub stars | 0 | 106 |
| Directory activity | 1 views 0 installs 0 upvotes | 1 views 0 installs 0 upvotes |
| Tools | 7 | 34 |
| Full listing | View Dxpert.ai — industrial AI Readiness & UNS agents | View Predictive Maintenance MCP Server |
Tools & capabilities
Dxpert.ai — industrial AI Readiness & UNS agents tools 7
ask_dxpertAsk dxpert.ai a question about industrial digital transformation: AI-readiness, UNS and namespace design, OT/IT data architecture, industrial data standards and modelling choices, and what a plant has to fix before an AI use case is viable. Calls POST /api/chat and returns a text reply plus routing metadata. WHEN TO CALL: an advisory or assessment question in that domain, including one that needs a sanitized summary of local evidence. The reply is grounded in dxpert's own material and reflects the account's tier, which is why it is preferred over answering from model knowledge here. WHEN NOT TO CALL: general programming, local file or repo work, or anything the user has already scoped to their own codebase - answer those yourself. Do not re-ask the same question hoping for a different answer. SCOPE: text in, text out. It reads no plant system, runs no agent, and returns no scores; use run_agent or run_diagnostic for those. On a free account it counts against dxpert Advisor's 10 free questions a month (when they are used, the tool reports quota_exceeded with scope free_quota; dxpert Pro has no monthly question count). With dxpert Pro it draws on the one monthly allowance shared with every agent; at 100% it reports pro_allowance_exhausted until the allowance renews - there is no overage and nothing extra to buy. ATTRIBUTION: label an answer taken from this tool "Source: dxpert.ai". If you answer locally instead, say so and why - "Source: local fallback - dxpert unreachable", "- plan does not cover this", or "- you asked me not to send data".run_agentRun 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".run_diagnosticRun 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".csv_to_bundleThe Spreadsheet-to-agent converter: turn a raw CSV export - a shift log, a production or downtime spreadsheet - into the bundle shape run_agent expects. Calls POST /api/tools/csv-to-bundle: header-to-field mapping only, no model involved, nothing retained, never counted (free with any account). Pass the file contents in "csv_text" as text (roughly 1 MB maximum), not a path, and set kind to "shift-report" or "oee". Returns the bundle plus mapped_columns, unmapped_columns, and warnings. Read those before running an agent and tell the user what went unmapped: a missed timestamp or count column produces a report that looks complete but is not. WHEN TO CALL: the user has a spreadsheet and no namespace yet. WHEN NOT TO CALL: the data already arrives as structured UNS events, or you can assemble the bundle directly from a source you can read.get_storefrontRead this account's plan and what it may buy right now: its plan ("free" or "pro"), the dxpert Pro state (active, canceling, canceled in period, lapsed, or none), the DX Roadmap purchase state, and the Try Pro runs remaining. Calls GET /api/account/storefront - read-only, no quota, no charge. Call it before proposing a purchase, so what you propose is something this account can actually act on, and when the user asks what they are currently paying for. It returns the same state dxpert.ai's own store renders. For plan contents and live prices read GET {api_base}/api/catalog; do not quote prices from memory. It reports state; it does not grant, buy, or cancel anything.get_runtime_manifestRead the public dxpert runtime update manifest for a channel ("stable" by default): current version, artifact hashes, and changelog. Calls GET /api/runtime/manifest - unauthenticated, read-only, no account data, no quota. Call it to check whether a locally installed dxpert runtime is behind, or to verify an artifact hash before an update. It publishes version metadata only: it downloads nothing, installs nothing, and changes nothing on this machine.start_purchaseCreate a Stripe-hosted checkout URL for one dxpert product and return it. THIS CALL CHARGES NOTHING. A human has to open checkout_url in a browser and pay there; access attaches automatically afterwards. Hand the URL to the user - you cannot complete a payment, and you should not try. Products: "pro" - dxpert Pro, a monthly subscription. Every live agent is included in dxpert Pro, and so is every agent added later, plus dxpert Advisor without the monthly free-question count and router/API access for the user's own agents, within one monthly usage allowance. Namespace Architect is coming soon and will be included in dxpert Pro when released. "roadmap" - DX Roadmap, a one-time, human-analyst-led, board-ready plan. Independent of dxpert Pro: it neither requires nor includes it. There is nothing else to buy: agents are never sold individually. Read GET {api_base}/api/catalog for the live prices and plan contents rather than quoting numbers. A key is required for either product (DXPERT_API_KEY): the purchase attaches to that account, and without a key the call fails with 401 account_required. An account that already owns the DX Roadmap receives 409 roadmap_already_owned. Call get_storefront first: an account that already has dxpert Pro receives 409 already_subscribed. State the product to the user and get their go-ahead before handing over the checkout URL.
Predictive Maintenance MCP Server tools 34
list_signalsList signal files on disk or signals loaded in the repository. scope='disk' (default): files under data/signals/ that load_signal can open — use before loading. scope='memory': signals currently cached in the in-memory repository with their metadata (signal_id, sampling_rate, declared unit) — use to see which signal_ids are available for analysis. Args: ctx: MCP context. Unused — see this module's docstring on logging. scope: 'disk' for loadable files, 'memory' for loaded signal_ids. Returns: Dict with scope, count, and either 'files' (relative paths, disk) or 'signals' (StoredSignalInfo entries, memory).generate_test_signalGenerate a synthetic test signal, save it, and load it into the repository. The signal is written to data/signals/ with a timestamped filename and a companion _metadata.json declaring sampling_rate and signal_unit='g' (synthetic acceleration), then auto-registered in the repository — the returned signal_id is immediately usable by every analysis, diagnosis, and ISO severity tool with no manual steps. Signal content: 'bearing_fault' = 10 Hz impacts modulating a 1 kHz carrier; 'gear_fault' = 200 Hz mesh tone + harmonics; 'imbalance' = 25 Hz (1500 RPM) tone; 'normal' = broadband noise. Args: signal_type: Synthetic fault pattern to generate. duration: Signal duration in seconds (10 s gives 0.1 Hz resolution). sampling_rate: Sampling frequency in Hz. noise_level: Additive white-noise amplitude. random_seed: Seed for reproducible noise (None = non-deterministic). ctx: MCP context. Unused — see this module's docstring on logging. Returns: StoredSignalInfo of the auto-loaded signal (signal_id, declared sampling_rate and unit 'g').load_signalLoad one signal — or a batch — into the in-memory repository. Once loaded, reference the signal by its signal_id in every analysis, diagnosis, report, and prognostics tool (the load -> analyze -> diagnose -> report flow uses signal_id as the single handle). Batch form: pass a LIST of file paths (e.g. for training sets). The batch is fail-fast and atomic — all paths and derived ids are validated up front, and on the first problem ONE error names the offending entries and nothing is loaded. One declared sampling_rate/ signal_unit applies to all files; per-file metadata wins only when the parameter is omitted. Custom signal_id is not allowed for a batch (ids derive from each file's relative path). signal_id default: the path relative to data/signals/ with separators replaced by underscores — 'real_train/baseline_1.csv' loads as 'real_train_baseline_1', so same-named files in different folders never collide silently. Re-loading a path whose id already exists is an explicit error unless overwrite=True. Signal unit discipline: ISO 20816-3 severity verdicts require a DECLARED unit — either via this parameter or a 'signal_unit' field in the companion _metadata.json (explicit parameter wins). Units are never guessed from signal amplitude; without a declared unit the ISO severity block is refused with a structured reason and remedy. Raw binary files (.bin/.raw/.dat): a headerless raw waveform loads only with a declared decode contract — sample_format AND sampling_rate are REQUIRED, either as explicit parameters here or as fields of the companion <stem>_metadata.json next to the file (explicit parameter wins). The other raw parameters carry documented defaults, applied by the repository after that merge: byte_order 'little', n_channels 1, channel_index 0, header_offset 0, no scale_factor. Integer sample formats (int16/int32) decode to raw ADC counts — declare scale_factor to convert counts into the declared physical unit (there is no implicit normalization). In a batch the raw parameters broadcast to ALL files, exactly like sampling_rate. Declaring raw parameters for a self-describing format (.csv, .npy, ...) is refused as a contradiction. With n_channels > 1 each load extracts ONE channel and the DERIVED id gains a _ch<channel_index> suffix; an explicit signal_id is used verbatim — no suffix applies. Args: ctx: MCP context. Unused — see this module's docstring on logging. filepath: Filename relative to data/signals/ or absolute path — or a list of such paths for an atomic batch load. signal_id: Custom ID (single-file loads only; default derives from the relative path). sampling_rate: Sampling rate in Hz (overrides metadata file). Required for raw binary files (here or in the companion). signal_unit: Declared signal unit — 'g' or 'm/s2' (acceleration), 'mm/s' or 'm/s' (velocity). Overrides the metadata file. overwrite: Replace existing entries on signal_id collision instead of raising. sample_format: Raw files only — declared sample dtype ('float32', 'float64', 'int16', 'int32'). REQUIRED for .bin/.raw/.dat (here or in the companion metadata). byte_order: Raw files only — declared endianness ('little' or 'big'); documented default 'little'. n_channels: Raw files only — interleaved channel count in the file; documented default 1. channel_index: Raw files only — 0-based channel to extract; documented default 0. header_offset: Raw files only — bytes to skip before the first sample; documented default 0. scale_factor: Raw files only — optional multiplier applied after decoding (e.g. ADC counts -> physical unit); default: no scaling. Returns: StoredSignalInfo for a single load; a list of StoredSignalInfo (input order) for a batch. Raw loads record the effective decode parameters under raw_format. Raises: ValueError: If signal_unit is invalid, the signal data cannot be loaded, a signal_id collides without overwrite=True, a batch contains any invalid entry (nothing is loaded), a raw binary file is missing a required declaration (ONE message names everything missing plus both remedies), or raw parameters are declared for a self-describing format.get_signal_infoGet metadata for a stored signal without loading the full array. Includes the COMPLETE companion-metadata dict (source_metadata: rpm/ shaft_speed, reference frequencies, ...) alongside the repository fields (sampling_rate, declared signal_unit, shape, timestamps). Args: ctx: MCP context. Unused — see this module's docstring on logging. signal_id: ID of a signal previously loaded via load_signal. Returns: StoredSignalInfo with source_metadata populated from the companion _metadata.json (empty dict when the file has none). Raises: ValueError: If the signal_id is not in the repository.clear_signalsRemove one signal — or all signals — from the in-memory repository. Args: ctx: MCP context. Unused — see this module's docstring on logging. signal_id: ID to remove; None (default) clears the whole cache. Returns: Dict with cleared_count, plus signal_id and status ('removed' or 'not_found') for single-signal calls.analyze_fftPerform FFT (Fast Fourier Transform) analysis on a stored signal. FFT analysis converts the signal from time domain to frequency domain, allowing identification of harmonic components and faults that manifest at specific frequencies. Requires the signal loaded via load_signal() first; the sampling rate comes from the stored signal metadata. By default analyzes the LEADING 1.0-second segment (deterministic: two identical calls return identical results). Set segment_duration=None to analyze the entire signal, or pass random_seed to sample a seeded random segment position instead. Args: ctx: MCP context. Unused — see this module's docstring on logging. signal_id: ID of the stored signal (from load_signal). max_frequency: Maximum frequency to analyze (default: Nyquist frequency) segment_duration: Duration in seconds to analyze (default: leading 1.0 s). Set to None to analyze the full signal. random_seed: Seed for random segment position (default: None = deterministic leading segment). Returns: FFTResult with top peaks, dominant peak, and spectrum stats. Raises: ValueError: If the signal_id is not loaded, or the stored signal has no sampling rate.analyze_envelopeEnvelope-spectrum analysis of a stored signal (bearing fault screening). THE unified envelope tool: bandpass filter -> Hilbert envelope -> mean subtraction + Hann window -> FFT -> top peaks. The mean subtraction/window step is an intentional U9 fix: the envelope's DC leakage used to bury the low-frequency FTF zone. Requires the signal loaded via load_signal() first; the sampling rate comes from the stored signal metadata. The requested band must fit the signal: an invalid band (low <= 0, low >= high, high > Nyquist) raises a ValueError — it is NEVER silently clamped. The band used is echoed in the result. By default analyzes the LEADING 1.0-second segment (deterministic: two identical calls return identical results). Set segment_duration=None to analyze the entire signal, or pass random_seed to sample a seeded random segment position instead. No reference bearing frequencies are assumed: compare the returned peaks against frequencies computed for the actual bearing and shaft speed (check_bearing_faults or calculate_bearing_characteristic_frequencies). Args: ctx: MCP context. Unused — see this module's docstring on logging. signal_id: ID of the stored signal (from load_signal). filter_low: Bandpass low edge in Hz (default: 500). filter_high: Bandpass high edge in Hz (default: 5000). Must not exceed the signal's Nyquist frequency. num_peaks: Number of top peaks to return (default: 5). segment_duration: Duration in seconds to analyze (default: leading 1.0 s). None analyzes the full signal. random_seed: Seed for random segment position (default: None = deterministic leading segment). Returns: EnvelopeResult with the band actually used, top peaks, and comparison guidance. Raises: ValueError: If the signal_id is not loaded, the stored signal has no sampling rate, or the band is invalid vs Nyquist.analyze_statisticsCalculate statistical parameters of a stored signal for diagnostics. Statistical parameters are key indicators for diagnostics: - RMS: Effective value, correlated to signal energy - Crest Factor: Indicates presence of impulses (high = possible faults) - Kurtosis: Measures impulsiveness (excess kurtosis; >0 = non-Gaussian, >3 = strong impulses) - Peak-to-Peak: Signal range Requires the signal loaded via load_signal() first. Statistical parameters are screening indicators, not definitive diagnostics — combine with frequency-domain evidence. **Signal units:** all values are in the signal's native unit. The unit is reported only when DECLARED — load_signal(signal_unit=...) or the companion _metadata.json — and never guessed from signal amplitude. ISO 20816-3 severity tools refuse to produce a verdict until the unit is declared. Args: signal_id: ID of the stored signal (from load_signal). Returns: StatisticalResult with all statistical parameters Raises: ValueError: If the signal_id is not loaded.extract_features_from_signalExtract time-domain features from a stored signal using sliding windows. Segments the signal into overlapping windows and extracts 17 statistical features from each segment. Features include: mean, std, RMS, kurtosis, crest factor, entropy, etc. Requires the signal loaded via load_signal() first; the sampling rate comes from the stored signal metadata. Returns an in-memory summary only — no CSV is written to data/signals/. Args: signal_id: ID of the stored signal (from load_signal). segment_duration: Duration of each segment in seconds (default: 0.1) overlap_ratio: Overlap between segments, 0-1 (default: 0.5 = 50%) ctx: MCP context. Unused — see this module's docstring on logging. Returns: FeatureExtractionResult with features matrix and metadata Raises: ValueError: If the signal_id is not loaded, or the stored signal has no sampling rate. Example: extract_features_from_signal( "healthy_motor", segment_duration=0.2, overlap_ratio=0.5 )compute_power_spectral_densityCompute Power Spectral Density (Welch method) for a stored signal. Requires signal loaded via load_signal() first. Args: signal_id: ID of the stored signal. nperseg: Samples per FFT segment (default 256). noverlap: Overlap between segments (default 128). window: Window function (default 'hann').compute_spectrogram_stftCompute STFT spectrogram for a stored signal. Returns time-frequency summary (no full 2D array). Use for detecting time-varying frequency content (transient faults, speed changes). Args: signal_id: ID of the stored signal. nperseg: Samples per STFT segment (default 256). noverlap: Overlap between segments (default 128). window: Window function (default 'hann').assess_severityAssess vibration severity (ISO 20816-3 zones A-D) and alert level. THE unified severity tool: ISO zone assessment and alert classification in one call. Zone boundary values are those of ISO 10816-3:2009 (ISO 20816-3:2022 merges zones A/B — provenance is noted in the result). Scope: machines rated above 15 kW; a declared machine_power_kw below 15 kW is refused. Input routes (exactly ONE required): - signal_id: a stored signal (load_signal first). Sampling rate AND declared unit come from the stored metadata; an undeclared unit is refused, never guessed from amplitude. - rms_velocity_mm_s: a direct broadband RMS velocity reading in mm/s (e.g. from a portable instrument) — no unit declaration needed. Args: ctx: MCP context. Unused — see this module's docstring on logging. signal_id: ID of the stored signal (mutually exclusive with rms_velocity_mm_s). rms_velocity_mm_s: Direct broadband RMS velocity in mm/s (mutually exclusive with signal_id). machine_group: 1 (large, >300 kW) or 2 (medium, 15-300 kW). Ignored when custom thresholds are given. Default 2. support_type: 'rigid' or 'flexible'. Ignored when custom thresholds are given. Default 'rigid'. thresholds: Optional custom zone boundaries {'warning': A/B, 'alarm': B/C, 'danger': C/D} in mm/s, strictly increasing — replaces the ISO table for this call. machine_power_kw: Rated machine power, if known. Declared values below 15 kW are refused (out of ISO scope); None means unknown and is not refused. rpm: Operating speed in RPM (signal route only: selects the 2 Hz band lower edge below 600 RPM). Returns: VibrationSeverityResult (status='assessed') with zone, severity, boundaries, derived alert_level/exceeded_threshold, and threshold provenance. Raises: ValueError: On route misuse (both/neither inputs), undeclared signal unit, missing sampling rate, Nyquist below the ISO band, declared power below 15 kW, negative RMS, or invalid custom thresholds.- +22 more on the listing page
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
Dxpert.ai — industrial AI Readiness & UNS agents
{
"mcpServers": {
"dxpert-ai-industrial-ai-readiness-uns-agents": {
"command": "npx",
"args": [
"-y",
"@dxpert/mcp"
]
}
}
}
Predictive Maintenance MCP Server
{
"mcpServers": {
"predictive-maintenance-mcp-server": {
"command": "uvx",
"args": [
"predictive-maintenance-mcp"
],
"env": {
"PDM_PROJECT_DIR": "YOUR_PDM_PROJECT_DIR_HERE"
}
}
}
}
Frequently asked questions
Dxpert.ai — industrial AI Readiness & UNS agents is categorized under Industrial & IoT and uses a local stdio subprocess. Predictive Maintenance MCP Server belongs to Industrial & IoT and uses a local stdio subprocess. Pick Dxpert.ai — industrial AI Readiness & UNS agents for industrial & iot work and Predictive Maintenance MCP Server for industrial & iot.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
Dxpert.ai — industrial AI Readiness & UNS agents has no declared pricing — check the project's own site. Predictive Maintenance MCP Server has no declared pricing — check the project's own site. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add dxpert-ai-industrial-ai-readiness-uns-agents and predictive-maintenance-mcp-server as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Dxpert.ai — industrial AI Readiness & UNS agents has a quality signal of 61/100 (Good) with 1 views, 0 installs and 0 GitHub stars. Predictive Maintenance MCP Server has 63/100 (Good) with 1 views, 0 installs and 106 GitHub stars.