Skip to main content
Glama
dsh18235538266-crypto

onshape-mcp-codex

by dsh18235538266-crypto
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

write_featurescript_feature

Author and apply custom Onshape FeatureScript features in one step, creating a Feature Studio element and instantiating it in the target Part Studio.

Instructions

Paradigm escape hatch. Author an arbitrary FeatureScript custom feature (threads, helices, shells, drafts, sweeps along a path, patterns along a curve -- anything our primitives can't express) and apply it to a Part Studio in one call. The system creates a Feature Studio element in the same workspace, uploads your source, confirms it compiles, fetches the sourceMicroversionId, and instantiates a BTMFeature-134 with the correct e{fs_eid}::m{microversion} namespace.

featureScript is a COMPLETE FS source file. Prelude: FeatureScript 2909;\nimport(path:"onshape/std/geometry.fs",version:"2909.0");. Export exactly one defineFeature(...) whose binding name matches the featureType arg. Minimal worked example (offset plane):

FeatureScript 2909;
import(path:"onshape/std/geometry.fs",version:"2909.0");
annotation { "Feature Type Name" : "My feat" }
export const myFeat = defineFeature(function(context is Context, id is Id, definition is map)
    precondition { annotation{"Name":"Offset"} isLength(definition.offset, LENGTH_BOUNDS); }
    {
        opPlane(context, id + "p", {"plane": plane(vector(0,0,definition.offset), vector(0,0,1), vector(1,0,0))});
    });

parameters is a list of {id, type, value} dicts to bind precondition variables. type ∈ {quantity, string, boolean, real}. For quantity, value is a unit-tagged string like "25 mm" or "0.5 in".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
elementIdYesTarget Part Studio element ID
documentIdYes
parametersNoBind precondition variables. Omit if the custom feature takes no inputs.
featureNameYesHuman-readable name that shows up in the Onshape feature tree.
featureTypeYesThe exported defineFeature binding name. MUST match the `export const <name> = ...` in featureScript.
workspaceIdYes
featureScriptYesComplete FS source. Must start with `FeatureScript <N>;` where N is the current std library version (currently 2909).
fsElementNameNoOptional name for the Feature Studio element that carries the source. Defaults to ClaudeFS_<featureType>.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral disclosure burden. It does this well by revealing the multi-step side effects: creating a Feature Studio element, uploading source, confirming compilation, fetching sourceMicroversionId, and instantiating a BTMFeature. It does not discuss failure modes or whether existing elements are overwritten, but it is substantially transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but dense and well-structured, front-loading the core purpose before moving into requirements and an example. The worked example is valuable but somewhat repetitive with the prose explanation of the prelude. Overall, nearly every sentence earns its place for such a complex tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, no output schema, and no annotations, the description is quite complete: it covers source formatting, naming constraints, parameter binding, and the internal application pipeline. Minor gaps include no explicit explanation of documentId/workspaceId semantics and no description of the returned result or error behavior, but the required calling contract is well covered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is high (75%), and the description adds significant meaning beyond the schema. It explains that featureScript must be a complete FS source file with a specific prelude and exactly one exported defineFeature whose name matches featureType. It also clarifies the parameters structure, value types, and unit-tagged quantity format with a worked example.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action: author an arbitrary FeatureScript custom feature and apply it to a Part Studio in one call. It distinguishes itself from primitive-based tools by framing itself as an 'escape hatch' for anything primitives can't express, with concrete examples like threads, shells, and sweeps.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives strong when-to-use guidance: use this when primitives cannot express the desired feature. It provides examples of such cases. However, it does not explicitly name or contrast with the sibling eval_featurescript tool or other alternatives, leaving some implicit routing to the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools