Aeroz vs Orcaslicer MCP
A side-by-side look at the Aeroz and Orcaslicer MCP MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
A
AerozIndustrial & IoT · Remote HTTP/SSEProve a physical item is genuine (NFC chip); read its EU Digital Product Passport, recalls, custody.51GoodAuth: not declaredVerdict: choose Aeroz for industrial & iot work over a hosted endpoint; choose Orcaslicer MCP 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?
AChoose Aeroz when
- You need dedicated capabilities in the Industrial & IoT domain.
- You prefer a remote HTTP/SSE transport.
- You have the keys it needs:
PSA_API_TOKEN. - You want tools like
verify_chip, check_recall, dpp_readiness.
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.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | A Aeroz | |
|---|---|---|
| Category | Industrial & IoT | Industrial & IoT |
| Quality signal | 51/100 · Good | 64/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Remote HTTP/SSE | Local subprocess (stdio) |
| Auth | Not declared | No auth required |
| Pricing | Not declared | Free |
| Required env vars | PSA_API_TOKEN | ORCA_MCP_NOTES_DIRPRINT_OUTCOMES_DIR |
| Verified owner | Community listing | Community listing |
| GitHub stars | — | 73 |
| Directory activity | 0 views 0 installs 0 upvotes | 4 views 0 installs 0 upvotes |
| Tools | 30 | 44 |
| Full listing | View Aeroz | View Orcaslicer MCP |
Tools & capabilities
Aeroz tools 30
verify_chipVerify a physical item by its Aeroz chip: the UID plus whatever signature the tap carried. Same answer as GET /v1/verify. Use this before trusting any claim about a physical unit — a database record proves a record exists, not that the object in front of you is the one it describes. Read `proof` and `proves`: proof "presence" means the chip answered a fresh one-time SUN challenge (picc_data + cmac) and was physically there at this tap; proof "identity" means the static `t` signature is the one Aeroz issued for this UID, which a copied tag also carries. verified:false with reason "no_signature" (recognised:true) proves NOTHING about the item — only that the number is on the register. "signature_unchecked" means the signature was not compared (not a mismatch). A failed signature returns NO product data. Each call records the tap and spends the chip's one-time answer, so pass each SUN tap once. A sandbox key answers its seeded sandbox chips as fixtures (mode "sandbox" with a _warning) and any other UID from the register (mode "sandbox", register:true), so a sandbox company can check the test tags it minted.check_recallCheck whether a specific unit is subject to an active recall, from the register: reads only, verifies no signature and spends no chip answer. Returns known (on the register), recalled, and the recall reason, severity, date and id when one applies. recalled:null means the status is UNKNOWN (the UID is not on the register, or the register could not be read) — never report that as "not recalled". This says nothing about whether the item is genuine; use verify_chip for that. Use whenever a unit is about to be shipped, sold, dispensed, or installed. A sandbox key answers its seeded sandbox chips first and any other UID from the register (register:true).dpp_readinessAssess how ready a product category is for an EU Digital Product Passport, against the delegated act that applies to it. Returns the required data fields, which are present, and which are missing. IMPORTANT: this is a readiness signal, not a legal compliance determination — never report its output as confirmation that a product is compliant.list_findingsList findings raised by the Aeroz compliance agents watching this organisation — recall hits, DPP data gaps, regulatory changes, dwell anomalies, and clone detections. Use this to answer "what needs my attention".list_agentsList the Aeroz compliance agents available to this organisation and which are currently enabled. Use this to explain monitoring coverage or to find an agent worth enabling.get_usageReturn this organisation's Aeroz verification volume and outcome breakdown over a recent period. Use for reporting on scan volume, authentication failure rates, and trend. The buckets — authentic, recalled (any tap whose answer carried a recall, verified or not), mismatched (failed static or SUN signature), not_found, unverified (no or unchecked signature, test tag, held or disabled unit) and other — always sum to total.list_sandbox_chipsList the seeded sandbox chips for this organisation, with the UID and signature to pass to verify_chip, one per scenario: authentic, recalled, signature_mismatch (listed with a deliberately WRONG signature) and not_found (a UID that is not on the register). Sandbox only — use when building or testing an integration before physical chips ship.onboarding_statusReport where this organisation stands in Aeroz onboarding: current stage, percentage complete, health, the single next action, and every open step with which side owns it. Use this to answer "what do we still need to do", "why are we not live yet", or "what is Aeroz waiting on". Steps marked side="aeroz" are Aeroz's obligation, not the customer's — say so plainly rather than presenting them as homework.onboarding_next_stepReturn only the single most important next action and how to complete it. Use when the user asks what to do next and does not want the whole checklist.complete_onboarding_stepMark a manual onboarding step complete on behalf of this organisation. Only steps the customer owns and that Aeroz cannot verify automatically can be set this way; an automatically verified step will refuse, because a self-report that contradicts the platform data is worse than no report. Pass the step key from onboarding_status.business_briefThe full picture of this business as Aeroz holds it: declared product categories with their mandate dates and whether each date is fixed or provisional, onboarding state, open findings, and — importantly — which recall sources are NOT being monitored. Use this to orient before answering anything about the account. Never present an empty findings list as evidence of safety without also reporting coverage_gaps.ask_agentAsk this organisation's dedicated Aeroz agent a question in plain language and get a grounded answer. Use it for anything a human at the business would ask their account manager: "what do we still need to do", "when is our deadline", "what is Aeroz waiting on", "what is not being monitored", "how do we go live". The answer carries `grounded`: `computed` means it was read directly from the account's own data; `model` means a model composed it from that data and every date and figure was checked against it; `declined` means the agent does not hold what the question needs and said so — relay that honestly rather than filling the gap yourself. Asking refreshes the account's onboarding state and records the question and answer in the conversation (see agent_conversation). It sends nothing outside Aeroz and changes no product, shipment or passport data.- +18 more on the listing page
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
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.
Aeroz
{
"mcpServers": {
"aeroz": {
"command": "npx",
"args": [
"-y",
"aeroz"
],
"env": {
"PSA_API_TOKEN": "YOUR_PSA_API_TOKEN_HERE"
}
}
}
}
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"
}
}
}
}
Frequently asked questions
Aeroz is categorized under Industrial & IoT and uses a remote HTTP/SSE transport. Orcaslicer MCP belongs to Industrial & IoT and uses a local stdio subprocess. Pick Aeroz for industrial & iot work and Orcaslicer MCP 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.
Aeroz has no declared pricing — check the project's own site. Orcaslicer MCP is listed as free. Auth: no auth required. 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 aeroz and orcaslicer-mcp as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Aeroz has a quality signal of 51/100 (Good) with 0 views, 0 installs and 0 GitHub stars. Orcaslicer MCP has 64/100 (Good) with 4 views, 0 installs and 73 GitHub stars.