Genieacs MCP vs Predictive Maintenance MCP Server
A side-by-side look at the Genieacs 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 Genieacs 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 Genieacs MCP when
- You need dedicated capabilities in the Industrial & IoT domain.
- You prefer a local stdio subprocess transport.
- You have the keys it needs:
ACS_URL, ACS_USER, ACS_PASS, TRANSPORT, DEVICE_LIMIT, MCP_LISTEN_ADDR, MCP_AUTH_TOKEN, MCP_ALLOWED_HOSTS. - You want tools like
connection_request, delete_task, download_firmware.
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 | 67/100 · Great | 63/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Local subprocess (stdio) |
| Auth | Not declared | Not declared |
| Pricing | Free | Not declared |
| Required env vars | ACS_URLACS_USERACS_PASSTRANSPORTDEVICE_LIMITMCP_LISTEN_ADDRMCP_AUTH_TOKENMCP_ALLOWED_HOSTS | None listed |
| Verified owner | Community listing | Community listing |
| GitHub stars | 18 | 105 |
| Directory activity | 5 views 0 installs 0 upvotes | 1 views 0 installs 0 upvotes |
| Tools | 12 | 34 |
| Full listing | View Genieacs MCP | View Predictive Maintenance MCP Server |
Tools & capabilities
Genieacs MCP tools 12
connection_requestSend a connection request to wake a CPE device without waiting for its periodic inform. Use this tool when you need the device to contact the ACS immediately, for example to execute pending tasks, apply preset changes, or force a parameter refresh. This sends an HTTP connection request to the CPE's management URL as configured in the TR-069 connection request mechanism. Returns 200 on success (the CPE acknowledged the request) or 504 if the CPE is unreachable (behind NAT, offline, or firewall blocking the connection request port). Example: connection_request(device_id="00236A-SmartRG585-SMRT00236a42"). Limitations: the CPE must be network-reachable from the ACS for connection requests to work. Devices behind NAT without STUN/NAT traversal configured will not respond. This does not queue a task — it only triggers the CPE to initiate a CWMP session.delete_taskDelete a pending task from the GenieACS task queue. Use this tool to cancel a task that was queued but has not yet been executed by the CPE, such as a mistakenly queued firmware download or an unwanted reboot. The task_id is the _id field from the task document, obtainable via the genieacs://tasks/{id} resource. Returns a 503 error if the device is currently in an active CWMP session (the task cannot be deleted while the device is communicating with the ACS). Example: delete_task(task_id="67abc123def456"). Limitations: only pending tasks can be deleted. Completed or in-progress tasks cannot be removed. Use retry_task instead if the task faulted and you want to re-run it.download_firmwarePush a firmware image or configuration file to a CPE device via GenieACS TR-069 download mechanism. Use this tool to initiate an OTA firmware upgrade or to push any file (config backups, supplementary data) to a device. The file must already be uploaded to GenieACS — use genieacs://file/{name} to inspect available files. Returns the raw JSON response from the ACS confirming the download task was queued. Limitations: the download is asynchronous — the ACS queues the task and the CPE fetches the file on its next session (periodic inform or connection request). Large firmware files may take minutes to transfer. Verify success by checking genieacs://tasks/{device_id} after allowing time for the transfer. Example: download_firmware(device_id="00236A-SmartRG585-SMRT00236a42", file_id="firmware-v2.0.bin").get_parameterRead specific TR-069 parameter values from the GenieACS cache for a device without contacting the CPE. Use this tool to quickly retrieve known parameter values such as firmware version, serial number, uptime, WiFi SSID, or IP addresses. This reads the last-known values stored in the ACS database — the data may be stale if the device has not informed recently. Use refresh_parameter first if you need a guaranteed fresh value from the CPE. The parameter_path can be a single parameter (e.g. "Device.DeviceInfo.SoftwareVersion") or a comma-separated list for multiple parameters. Returns the matching device document fields as JSON. Limitations: only returns data that the ACS has previously collected. If a parameter has never been read from the CPE, it will not appear in the response.manage_presetCreate, update, or delete a GenieACS preset. Presets define automatic configuration rules that are applied to CPE devices matching a precondition filter. Use action="put" to create or overwrite a preset, providing the full JSON body with weight, precondition, and configurations. Use action="delete" to remove a preset by name. A preset body should contain: weight (integer priority), precondition (a stringified MongoDB-style JSON query, e.g. "{\"_tags\":\"office\"}"), and configurations (array of objects with type "value", "provision", "add_object", or "delete_object"). Example body: {"weight":0,"precondition":"{\"_tags\":\"test\"}","configurations":[{"type":"provision","name":"myScript"}]}. Preset names cannot contain dots. Use genieacs://presets/list to view existing presets before making changes. Limitations: changes take effect on the next CPE inform, not immediately.manage_provisionCreate, update, or delete a GenieACS provision script. Provision scripts are JavaScript functions that run on the ACS during a device's inform session to dynamically configure CPEs. Use action="put" to upload a new provision script or overwrite an existing one. The script argument must be raw JavaScript source code (not JSON). Use action="delete" to remove a provision script by name. GenieACS validates the script syntax on upload — a 400 error means the JavaScript has a syntax error. Provision scripts are referenced by name in presets (via configurations of type "provision"). Use genieacs://provisions/list to view existing scripts before making changes. Example script: log("Device " + args[0] + " informed"); Limitations: provision scripts execute server-side in the GenieACS sandbox with a limited API (declare, commit, ext, log). They cannot make arbitrary HTTP calls or access the filesystem.reboot_deviceReboot a CPE device through the GenieACS TR-069 ACS. Use this tool when a device needs to be restarted, for example after a configuration change, firmware update, or to recover from an unresponsive state. The device must exist in the GenieACS inventory — use genieacs://devices/list to discover valid IDs. Returns the raw JSON response from the ACS confirming the task was queued. Limitations: the reboot is asynchronous — the task is queued on the ACS and executed the next time the CPE contacts the ACS (via its periodic inform or a connection request). There is no confirmation that the device actually rebooted. Example: reboot_device(device_id="00236A-SmartRG585-SMRT00236a42").refresh_parameterRequest a CPE device to report the current value of a specific TR-069 parameter via GenieACS. Use this tool when you need an up-to-date reading of a device parameter — for example, checking the current firmware version, uptime, WiFi SSID, or any CWMP data model path. The refreshed value is stored in the GenieACS device document and can be read afterwards via genieacs://device/{id}. Returns the raw JSON response from the ACS confirming the refresh task was queued. Limitations: the refresh is asynchronous — the value is updated when the CPE next contacts the ACS. Only one parameter path can be refreshed per call; use the full dotted TR-069 object path. Example: refresh_parameter(device_id="00236A-SmartRG585-SMRT00236a42", parameter="Device.DeviceInfo.SoftwareVersion").retry_taskRetry a faulted task in GenieACS. Use this tool when a previously queued task (reboot, firmware download, parameter set, etc.) has failed and you want to re-attempt it. The task_id is the _id field from the task document, obtainable via the genieacs://tasks/{id} resource — look for tasks with fault information. This clears the fault and re-queues the task for execution on the next CPE inform. Example: retry_task(task_id="67abc123def456"). Use genieacs://faults/{id} to understand why the task originally failed before retrying. Limitations: only faulted tasks can be retried. Retrying a non-faulted task has no effect.search_devicesSearch for CPE devices in GenieACS using MongoDB-style query filters. Use this tool to find devices by tag, manufacturer, model, firmware version, last inform time, or any other TR-069 parameter stored in the ACS. The query argument is a JSON string using MongoDB query syntax. Examples: {"_tags":"office"} to find devices tagged "office", {"InternetGatewayDevice.DeviceInfo.Manufacturer._value":"Huawei"} to find Huawei devices, {"_lastInform":{"$lt":"2024-01-01T00:00:00Z"}} to find devices that haven't informed since 2024. For non-underscore-prefixed parameter paths, GenieACS automatically appends "._value" to the query, so you can also query as {"InternetGatewayDevice.DeviceInfo.Manufacturer":"Huawei"}. Returns a JSON array of matching device documents. Use the limit argument to control the maximum number of results (default 50). Limitations: complex aggregation queries are not supported — only standard MongoDB comparison operators ($eq, $ne, $gt, $lt, $gte, $lte, $regex, $in, $nin, $exists).set_parameterSet one or more TR-069 parameter values on a CPE device through GenieACS. Use this tool to change device configuration such as WiFi SSID, management server URL, periodic inform interval, or any writable TR-069 parameter. The parameter_values argument must be a JSON array of tuples, where each tuple is [parameterPath, value] or [parameterPath, value, xsdType]. Example: [["InternetGatewayDevice.LANDevice.1.WLANConfiguration.1.SSID","MySSID","xsd:string"]]. Valid xsd types include xsd:string, xsd:boolean, xsd:unsignedInt, xsd:int, xsd:dateTime. If the type is omitted, GenieACS infers it from the value. The task is queued and a connection request is sent to the CPE for immediate execution. Returns the raw ACS JSON response confirming the task. Limitations: the CPE must be reachable for immediate execution; otherwise the task remains queued until the next periodic inform. Not all parameters are writable — the CPE will fault if you attempt to set a read-only parameter. Use refresh_parameter or genieacs://device/{id} first to discover valid parameter paths.tag_deviceAdd or remove a tag on a CPE device in GenieACS. Tags are labels used to group devices for preset matching, bulk operations, and organizational purposes. Use action="add" to tag a device and action="remove" to untag it. Tags are referenced in preset preconditions (e.g. {"_tags":"office"}) to target specific device groups for automatic configuration. The device must exist in GenieACS — returns a 404 error if the device ID is invalid. Example: tag_device(device_id="00236A-SmartRG585-SMRT00236a42", tag="office", action="add"). Use search_devices with a _tags filter to verify tag assignment after modification. Limitations: tag names are case-sensitive strings. There is no built-in tag listing — use search_devices or genieacs://devices/list to discover existing tags on devices.
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.
Genieacs MCP
{
"mcpServers": {
"geiserx-genieacs-mcp": {
"command": "npx",
"args": [
"-y",
"genieacs-mcp"
],
"env": {
"ACS_URL": "YOUR_ACS_URL_HERE",
"ACS_USER": "YOUR_ACS_USER_HERE",
"ACS_PASS": "YOUR_ACS_PASS_HERE",
"TRANSPORT": "YOUR_TRANSPORT_HERE",
"DEVICE_LIMIT": "YOUR_DEVICE_LIMIT_HERE",
"MCP_LISTEN_ADDR": "YOUR_MCP_LISTEN_ADDR_HERE",
"MCP_AUTH_TOKEN": "YOUR_MCP_AUTH_TOKEN_HERE",
"MCP_ALLOWED_HOSTS": "YOUR_MCP_ALLOWED_HOSTS_HERE"
}
}
}
}
Predictive Maintenance MCP Server
{
"mcpServers": {
"predictive-maintenance-mcp-server": {
"command": "uvx",
"args": [
"predictive-maintenance-mcp"
]
}
}
}
Frequently asked questions
Genieacs 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 Genieacs 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.
Genieacs MCP is listed as free. 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 geiserx-genieacs-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, Genieacs MCP has a quality signal of 67/100 (Great) with 5 views, 0 installs and 18 GitHub stars. Predictive Maintenance MCP Server has 63/100 (Good) with 1 views, 0 installs and 105 GitHub stars.