Orcaslicer MCP vs Predictive Maintenance MCP Server
A side-by-side look at the Orcaslicer MCP 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 Orcaslicer MCP 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 Orcaslicer MCP when
- You need dedicated capabilities in the Industrial & IoT domain.
- You prefer a local stdio subprocess transport.
- Its auth model fits you: No auth required.
- You have the keys it needs:
ORCA_MCP_NOTES_DIR, PRINT_OUTCOMES_DIR. - You want tools like
get_status, get_config, set_config.
Choose Predictive Maintenance MCP Server when
- You need dedicated capabilities in the Industrial & IoT domain.
- You prefer a local stdio subprocess transport.
- 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 | 63/100 · Good | 63/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Local subprocess (stdio) |
| Auth | No auth required | Not declared |
| Pricing | Free | Not declared |
| Required env vars | ORCA_MCP_NOTES_DIRPRINT_OUTCOMES_DIR | None listed |
| Verified owner | Community listing | Community listing |
| GitHub stars | 73 | 105 |
| Directory activity | 3 views 0 installs 0 upvotes | 1 views 0 installs 0 upvotes |
| Tools | 44 | 34 |
| Full listing | View Orcaslicer MCP | View Predictive Maintenance MCP Server |
Tools & capabilities
Orcaslicer MCP tools 44
get_statusSnapshot of the current OrcaSlicer session: app and project info, the active print/filament/printer presets with which of their keys are modified (dirty), whether the last slice is still valid, and whether a slice is running. Read-only. Call it first to orient before slicing or editing, to see which settings drift from their preset, or to check slice_result_valid before trusting earlier stats.get_configRead merged config values (optionally filtered to `keys`).set_configApply config changes to the active project as unsaved overrides, atomically: if any key is invalid the whole batch is rejected and nothing changes. Returns {applied, errors}. Overrides show as modified in get_status, are not written to any preset file, and revert if the preset is reselected; call save_preset to persist them. Each apply invalidates the last slice, so re-slice afterwards. It does not run the physics gate, so for temperature, speed, acceleration, or flow keys run check_profile_physics before trusting the result. To edit a stored preset rather than the live project, use edit_preset.sliceStart slicing the current plate in the background and return immediately, without waiting for the result. The reply is 'started' (a slice began), 'already_valid' (the plate is unchanged and the last result still holds), or a conflict if a slice is already running. Fire-and-forget: poll get_slice_status for progress and stats, or cancel_slice to stop it. Prefer slice_and_wait when you want the finished stats back in one call.get_slice_statusState of the current or most recent slice: state (slicing, done, error, or idle), stats (print time and filament use when done), and any warnings or errors. Read-only. Poll this after slice to follow progress and read the result; 'idle' means no slice has run or it was cancelled. For only the pass/fail warnings use get_slice_warnings; for a per-feature time and filament breakdown use get_slice_breakdown.get_slice_warningsJust the warnings/errors from the last (or current) slice, plus validity - the fast 'did anything go wrong' check and the way to confirm a fix cleared. NOTE: only as complete as the API exposes. On the current fork build this may report valid with an empty warnings list even when the GUI shows a plate-boundary toast - the fork must populate the plater warning list (tracked as the fork batch). Once it does, this reports the real warnings with no change here.get_slice_breakdownPer-feature breakdown of the last slice + a stateless predicted-vs-observed flow check. Returns per-role time/filament + speed/flow ranges, global time-weighted metric distributions, per-layer aggregates, and a prediction_check flagging where the profile's speed was silently throttled at the flow ceiling ('clamped'). Answers 'which feature is the time hog' directly instead of by trial slicing. Degrades to {"available": false, "reason": ...} on fork builds that don't emit the breakdown, or when there is no valid slice.cancel_sliceAbort a running slice, or unwedge a stale 'slicing' state (e.g. after an object outside the bed). Safe when idle.slice_and_waitSlice the current plate and block until it finishes, then return the final stats and warnings in one call. If the plate is already sliced and unchanged, it returns the existing result without re-slicing. This is the usual way to slice when you want the outcome immediately. For a non-blocking start, use slice then poll get_slice_status; to sweep one setting across values, use compare_settings.apply_and_sliceApply config overrides and then slice in one step, returning {applied, errors, result} with the resulting stats and warnings. The changes are atomic (any invalid key rejects the whole batch) and unsaved, exactly like set_config, so they revert if the preset is reselected. Use this to test the effect of a tweak in a single call. Use set_config then slice_and_wait to keep the steps separate, or compare_settings to try several values of one key.compare_settingsFor each value of `key`, slice and collect stats/warnings; restore the original when done. Non-destructive: the original value of `key` is put back even on error.compare_slicesSlice the current plate under several named variants and compare the cost of each. Each variant is {"name": str, "changes": {setting: value}}; changes={} means the current config as-is (a natural baseline row). Applies each variant over the ORIGINAL config (resetting between variants, so they don't stack), slices it, then restores your config exactly as it was - nothing is left changed (slice validity is left false, as after any un-resliced edit). Returns a ready-to-relay `headline` and `table_markdown`, plus structured `variants`. All deltas and percentages are ALREADY computed and rounded against `baseline` (defaults to the changes={} variant, else the first) - relay them as given rather than recomputing. `recommended` names one pick; `recommended_is_dominant` says whether it beats every variant on every axis (time, filament, warnings) or is only the fastest warning-free option amid a genuine trade-off (`tradeoff` then names the frontier). Each variant is a full slice (minutes); capped at 8. Set detail=True only when a per-feature (wall/infill/support) split is wanted - it grows the response ~N x. With more than ~5 variants, lead with the recommendation and the extremes, not all rows.- +32 more on the listing page
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.
Orcaslicer MCP
{
"mcpServers": {
"orcaslicer-mcp": {
"command": "uvx",
"args": [
"orcaslicer-mcp"
],
"env": {
"ORCA_MCP_NOTES_DIR": "YOUR_ORCA_MCP_NOTES_DIR_HERE",
"PRINT_OUTCOMES_DIR": "YOUR_PRINT_OUTCOMES_DIR_HERE"
}
}
}
}
Predictive Maintenance MCP Server
{
"mcpServers": {
"predictive-maintenance-mcp-server": {
"command": "uvx",
"args": [
"predictive-maintenance-mcp"
]
}
}
}
Frequently asked questions
Orcaslicer MCP 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 Orcaslicer MCP 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.
Orcaslicer MCP is listed as free. Auth: no auth required. 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 orcaslicer-mcp and predictive-maintenance-mcp-server as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Orcaslicer MCP has a quality signal of 63/100 (Good) with 3 views, 0 installs and 73 GitHub stars. Predictive Maintenance MCP Server has 63/100 (Good) with 1 views, 0 installs and 105 GitHub stars.