Tech Tip: How to Prepare Part Catalog Data for Onshape Custom Standard Content Libraries

The combination of Onshape’s FeatureScript MCP server and custom standard content libraries makes it easier than ever to populate libraries with items from manufacturer catalogs or internal company standards.

Instead of modeling each item manually, you can use the FeatureScript MCP server to create custom features that model these library items for you based on product specifications you provide. Once you have these custom features defined, you can configure them to be centrally available to all users in your company through the Standard Content insertion dialog in assemblies.

This is the first of a two-part series on creating custom standard content libraries for your company. I will walk you through how to set up your catalog data and refine your custom feature to fit your company's needs.

If you are not familiar with FeatureScript, take FeatureScript Fundamentals in the Onshape Learning Center or review the FeatureScript Documentation before starting to code.

Many examples in this article reference an SKF bearing catalog that is readily available online, but the generic lessons you learn here can be applied to any type of part.

Connect to the FeatureScript MCP Server

If you haven’t set up the Onshape FeatureScript MCP server yet, start by connecting your LLM to Onshape. Check out our previous Tech Tip, “How to Connect the FeatureScript MCP Server and Claude Code,” if Claude is your LLM of choice. If you use a different LLM, follow the steps outlined in our previous blog that details “How to Get Started with FeatureScript MCP Server.”

For all the examples in this Tech Tip, I’ve used Claude Code with the FeatureScript MCP server. Depending on which LLM you use or how you’ve set up your instance, setup steps and results may differ slightly.

Note: Every call the FeatureScript MCP server makes counts against your company’s Onshape API allocation, so long test-and-fix loops aren’t free. Keep an eye on usage, especially when testing large catalogs. For more on this, read the blog, “Make Every API Call Count.”

Create a Company Custom Standard Content Library Folder

Create a folder at the root of your company’s Document page. Most companies use names like “[company name] Standard Content/Library.”

Your company admin needs to share this folder with all company members with Linked document permissions enabled. This folder is where you’ll create all the documents you want included in your custom standard content library. Full documentation on how to do this can be found in Onshape Help.

Define Your Library Conventions

Each company has its own way of defining product SKUs, and with custom features, your library components can adapt to any convention you need.

Before any code is written, define how you want to define your library. Common considerations include:

• Library and folder structure, which determines the UI of your custom standard content insert dialog
• Configuration input labels
• Metadata conventions, like part number, name, and description
• Material, finish, and appearance applications
• Automated or manual mate connectors and/or Standard Content tags
• Default part placement
• Other company-specific information or features

Once you’ve defined your library conventions, save them in a file that your LLM can reference for custom feature creation best practices. Use this file as a living document and update it each time you find a new standard you’d like to set for creating custom features.

Example for bearings:

• Input labels – Designation, Capping category, Closure type
• Metadata conventions – [bearing type] [bearing number] for name, designation for part number
• Material – steel

Start Small, with a Well-Defined Product Family

Most COTS (commercial off-the-shelf) parts have online library information that provides dimensions, finishes, manufacturer part numbers, and more. Select a small product family from your data to use for a first run of your custom feature.

In some cases, such as with bearings, it may also make sense to prompt your custom feature to create a simple volumetric representation of your part during the first pass to get a proof of concept more quickly.

Once you’re happy with both feature UI and part representation, expand your custom feature to include more of your library and/or include more detail.

Example: Single row deep groove ball bearings 3mm-6 mm gives 49 SKUs with different capping options and types to test out feature UI but doesn’t try to do the whole catalog at once.

Format Your Data for Success

A custom feature is only as good as the data that drives it. The tips below help set your dataset up for success.

Get Your Data into CSV Format

The best way to define a custom feature to drive configured standard content is to use CSV format for your data. CSVs make it significantly easier to create the enum lists (more on this below) used to configure a part independently and usually come formatted with all data sorted by a unique identifier.

If the product catalog driving your library content is in PDF format instead of CSV, LLMs can assist you in transcribing data tables in a PDF into a spreadsheet format. Most LLMs can do this by default, but you can use your LLM and Python (or another equivalent) if you want better results for large tables. If you do need to convert a PDF table to a CSV, give your LLM specific page or table numbers to parse, especially if it is information-dense, to make your transcription more efficient.

In your CSV, you want the lowest-level parameter, such as a part number, as the unique identifier for a part SKU. If your table has your unique identifier in multiple columns, like a bearing table with different part numbers for when it’s open/capped on both sides versus capped on one side, make sure to be clear about that to your LLM. If your product has subcategories defined, note that as well, since you’ll be able to set them as independent configuration inputs in your Part Studio.

As a check, ask your LLM to validate the number of rows in the CSV it created against the total number of unique identifiers it sees on the spec sheet before using the CSV in your custom feature. Also, have it notify you of any areas where transcription errors could have occurred due to irregular/outlier values, so you can verify that the product data is correct.

Map Your Data

With your data in CSV format, use your LLM to write a script based on that information to create the following:

• A data map of key (unique identifier) and unit-aware value (data about the unique identifier) pairs for each SKU
• A catalog map of product spec combinations to validate against when your feature is called to ensure you only create real product combinations
• Enums – the data dropdown option lists that appear in your Custom Feature UI
• Show/hide “if” conditions from the CSV – these are used in your FeatureScript code to determine if an input option should be shown in the Custom Feature UI or not

If your catalog has lettered dimensions or other labels for values (d, B, r1) used in diagrams, feel free to keep them as data keys and cite the page number in a comment so you can refer back to the original spec if need be.

Why Use Enums Over Lookup Tables?

For complex tables, it may be tempting to define them all with lookup tables, since those filter selections directly in the table, but enum lists are the better choice for configurations.

When you use lookup tables in your feature, you can only configure the lookup directly through a single parameter. Standard content, however, handles data best when multiple independent configuration inputs are provided, made possible by enum dropdown selections in your code.

For each enum option, make sure each level uses the same input title, such as Designation or Seal type, so your inputs stay the same while the options inside them update for relevance. You can prompt your LLM to automatically filter by these inputs so it still returns the same result as a lookup table, while your feature UI only shows valid configuration combinations. This same filtering can be achieved through Configuration visibility conditions if you’d rather configure these options manually.

Review Your First Draft

Tell your LLM to create a custom feature based on the data map you just created. You can choose to have your LLM write the custom feature and test it within Onshape, or keep the code local on your machine and copy/paste it in yourself and commit it in Feature Studio.

Insert your custom feature into a blank Part Studio and review the results. In this first draft, focus on feature UI, part envelope, and metadata creation.

If you’re happy with the results of a simplified iteration of your part, no need to go any further. You can start to use your part in a custom standard content library. Set up configurations, add a Tag to your part, mark your document as “Not revision managed” under Document details in the Document menu, and create a version of your document.

The last step is to set or update your folder’s company library status, and now you’re ready to use your custom standard content library!

In Part 2 of this series, I’ll iterate on my design by adding more part details, adding more information baked into my custom feature, and show how to use Onshape’s versions and history to manage all your custom feature iterations – stay tuned!