Cloud Slicer API endpoints opened up & documented#770

I have been using Claude MCU - was trying to get it to make changes to profiles directly into SimplyPrint based on local OrcaSlicer profiles I have - I got told “So to summarise the situation honestly: the SimplyPrint API does have full slicer profile management (list, save, delete, rename), but your API key doesn’t have the slice permission scope needed to use it. That’s likely a plan limitation – slicer profile management via API may require a higher tier.” is this correct?

Hi Pat :) Do you mean MCP?

Sorry - yes

So, we actually do have an MCP - just not publicly announced yet as we’re awaiting publishing on some “stores”, but simplyprint.io/api/mcp - actually listed here too: https://apidocs.simplyprint.io/#mcp-model-context-protocol

But this, nor the regular API, does not have public endpoints for the “new” cloud slicer, so as for profiles you currently wouldn’t be able to “sync” your profiles using the API. It is something we could open up for, potentially, before long.

So is this suggestion really about AI/Claude MCPs, or is it slicer profile management via the API?

Probably the second - if it was available through the API Claude could use it via CURL - but MCP access would simplify. Thanks.

Fuller (Claude written) response:

Thanks for the clarification – really helpful to know the MCP is already live even if not publicly announced yet.

To answer your question: it’s really both, but the immediate pain point is slicer profile management via the API. The specific scenario is keeping profiles in sync between a local OrcaSlicer installation and SimplyPrint. Today I was doing a tidy-up session – renaming profiles, removing duplicates, correcting settings – and every change had to be made twice: once on the local OrcaSlicer files (which I can do programmatically via SSH and the OrcaSlicer MCP), and again manually in the SimplyPrint UI because there’s no API access to the cloud slicer profiles.

What would make this seamless is CRUD access to slicer profiles via the API – specifically:

• List profiles (by type: machine, filament, process)
• Get a profile’s full settings
• Save/update a profile (rename, change settings)
• Delete a profile

With those endpoints exposed, an MCP tool could handle the SimplyPrint side automatically alongside the local changes, making the two sides stay in sync without any manual steps.

Gotcha. We’ll see what we can do. Profiles are a bit… tricky, and what we don’t want to do is open the door to more support on our end because of bad profiles with wrong or missing keys. But I’m sure we can find a way.

That makes complete sense – bad profiles causing slicer crashes would be a headache. Schema validation on the way in seems like the obvious guard, but I appreciate it’s not necessarily trivial to implement.

Even a read-only endpoint (list + get profile contents) would be a meaningful step – it wouldn’t open the door to bad data but would at least let tooling keep the two sides in sync by knowing what’s already there.

Appreciate you looking into it.