Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
With the Onshape MCP we need a way to share FeatureScript without giving away the source
Arthur_Hobden
Member Posts: 1 PRO
The upcoming Onshape MCP edition and the push toward AI-driven CAD is genuinely exciting. The moment an AI agent can read a model, reason about intent, and call custom FeatureScript to do real work, custom features stop being a nice-to-have and become the building blocks of everything. That is a huge opportunity for the people who write good FeatureScript.
But I think that same release exposes a barrier that is going to hold the ecosystem back, and I want to raise it now while there is momentum to fix it.
Here is the problem. Today, if I want anyone (or any agent) to use one of my custom features, I have to give them view access to the document that holds the Feature Studio. The instant I do that, they can open the Feature Studio, read all of my FeatureScript, copy it, and save it as their own. Use and read are the same permission. There is no way to let someone run my tool without also handing them the source that makes it valuable.
Now layer the AI edition on top of that. We are about to make it far easier to build powerful, agent-callable FeatureScript tooling. But the more powerful and valuable that tooling becomes, the stronger the reason to never share it, because sharing it means giving it away. So the best work gets built and then withheld. That is the opposite of what you want at the exact moment you are trying to grow adoption and make Onshape the place where AI-augmented CAD happens.
I have been building a library of custom features and I want to bring collaborators and clients of my CAD training service. I cannot, because I cannot share a working tool without also shipping the code. In practice the only people I can share with are people I would be handing my entire toolkit to.
The fix, in my mind, is to separate the right to use a feature from the right to read its source. Two flavors, in order of usefulness:
- Invite-based / licensed access. As an author, I grant specific users (or their agents) permission to add my feature to their toolbar and insert it into their documents. They get a fully working, callable feature. They do not get read access to the Feature Studio behind it. This is how plugins and apps get distributed everywhere else.
- Public, discoverable use. A lighter version: any Onshape user can search for and insert my published feature, still without exposing the source. Open audience, same source protection.
The shared idea is an opt-in "closed-source" distribution mode for custom features, versioned like everything else, where the author controls who can use it and the code stays with the author. This matters even more in an AI context, because an agent invoking a feature does not need to read its source to call it. It needs a stable, documented interface. That is exactly the boundary a use-without-source mode would create.
I know the usual position is that FeatureScript is open on purpose, and I love that for learning and for the standard library. This is not a request to change that default. It is a request for an opt-in mode so that authors who want to build and sell AI-ready tooling on Onshape can actually do it without giving the work away.
Questions for others building custom features, especially with the AI edition in mind:
- Would a use-without-source mode change what you would be willing to publish, sell, or expose to an agent?
- Invite-only, public, or both?
- How should this interact with MCP and agent access specifically? Should "an agent can call it" be its own grant separate from "a human can read it"?
- What would you expect around versioning, and what happens to a user's documents if an author revokes access?
Comments
You can create features that users can use without seeing the source code, it just requires wrapping the feature.
https://www.smartbenchsoftware.com/post/protecting-featurescript-code
I've written about this concept a few times. Basically, you make a public facing feature that directly calls the protected source code. They only get the wrapper, and none of the source code.
Experts in Onshape Automation - Custom Features and Integrated Applications
As an example of @Caden_Armstrong 's comment, here is a public feature I created a couple of days ago. Just for purposes of this thread I have wrapped it up… and you're welcome to look at the source ;)
https://cad.onshape.com/documents/f821326903b5d7dc9cce4ec3/w/891da7c3412609c17a264b20/e/1431adfc3aa58c880146a39e
By the way, all the original code behind this example was created using an Onshape MCP server. Now to be clear, I have no plan to keep this hidden, and when I tidy it up a bit more will publish it like any other. The point being you can protect things, you can choose to not share at all. it's up to you.
I'll also stand on the other side of this argument here and challenge the claim that the stronger and more powerful your tools become the greater incentive there is to lock it away. I've got a pretty healthy catalog of features built up, some of them are uniquely powerful and enable entire workflows and products that aren't possible without their existence. Most of those features are only as useful as they are because they've borrowed techniques and implementations learned from other users on this forum.
I personally will never paywall or close source any of my features because I believe that doing so would be removing value from everyone else's use of them, and inversely prevent people from stepping in and improving upon the works I've made and prevent me from getting that extended value out of them. But that's just my personal leaning.
Derek Van Allen | Engineering Consultant | Meddler