Skip to main content
Glama
onshape-mcp

onshape-mcp

by gpambrozio

Add a mate

onshape_assembly_mate

Join two mate connectors with a mate: FASTENED, REVOLUTE, SLIDER, CYLINDRICAL, PLANAR, and so on. Each connector is an assembly-level mate connector's feature id, or a Part Studio mate connector given as {path: [instance id], connector…

Instructions

Join two mate connectors with a mate: FASTENED, REVOLUTE, SLIDER, CYLINDRICAL, PLANAR, and so on. Each connector is an assembly-level mate connector's feature id, or a Part Studio mate connector given as {path: [instance id], connector: feature id} from onshape_get_assembly. The mate's value measures the first connector against the second, so list the moving part first.

Input Schema

NameRequiredDescriptionDefault
wsYesWorkspace id — the <ws> segment of the document URL.
docYesDocument id — the <doc> in cad.onshape.com/documents/<doc>/w/<ws>/e/<elem>.
elemYesElement id (tab) — the <elem> segment of the document URL.
nameNoFeature name (default "Mate").
typeNoMate type (default FASTENED).
validateNoRe-read the feature list afterwards and fail if the feature regenerated with an error (default true).
connectorsYesThe mate connectors to join, moving part first.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.3.0
    • changedInput schema / properties / connectors / description
      Previous value: -"Feature ids of the mate connectors to join."New value: +"The mate connectors to join, moving part first."
    • addedInput schema / properties / connectors / items / anyOf
      Added value: +[
      +  {
      +    "description": "Feature id of an assembly-level mate connector.",
      +    "minLength": 1,
      +    "type": "string"
      +  },
      +  {
      +    "description": "A mate connector defined in the Part Studio, as onshape_get_assembly lists it.",
      +    "properties": {
      +      "connector": {
      +        "description": "Part Studio mate connector id, e.g. \"FabC_0.mcPinion\" (parts[].mateConnectors[].featureId).",
      +        "minLength": 1,
      +        "type": "string"
      +      },
      +      "path": {
      +        "description": "Occurrence path of the instance that owns the connector, e.g. [instance id].",
      +        "items": {
      +          "minLength": 1,
      +          "type": "string"
      +        },
      +        "minItems": 1,
      +        "type": "array"
      +      }
      +    },
      +    "required": [
      +      "path",
      +      "connector"
      +    ],
      +    "type": "object"
      +  }
      +]
    • removedInput schema / properties / connectors / items / type
      Removed value: -"string"
    • addedInput schema / properties / validate
      Added value: +{
      +  "description": "Re-read the feature list afterwards and fail if the feature regenerated with an error (default true).",
      +  "type": "boolean"
      +}
  2. First observedv0.1.0

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden. It discloses useful semantics like mate-type options and connector-ordering effects, but it never explicitly states that this creates a persistent assembly mate feature, what permissions are required, or what the validate parameter does on failure — schema covers validate but the description does not surface the mutation profile.

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

Conciseness5/5

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

Three sentences, zero waste. The operation is front-loaded, followed by connector-format details and then the ordering caveat, which is exactly the order an agent needs.

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

Completeness3/5

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

For a mutation tool with no annotations, no output schema, and seven parameters, the description leaves key operational facts unsaid: that it creates a feature, error/failure behavior, and what validate actually gates. The connector semantics are complete, but the mutation and validation story is only inferable.

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

Parameters4/5

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

Schema coverage is 100%, establishing a baseline of 3, and the description genuinely adds meaning: it enumerates concrete mate types beyond the schema's bare 'Mate type (default FASTENED)', explains the two connector representation shapes, and clarifies that the first connector is the moving part. It does not document name or validate behavior, but it improves on the schema's semantics.

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

Purpose4/5

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

The description states a specific verb and resource — joining two mate connectors with a mate — and enumerates mate types, so the agent knows exactly what operation it performs. It does not explicitly distinguish itself from sibling tools such as onshape_assembly_mate_connector or onshape_assembly_relation, which keeps it short of a 5.

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?

It gives concrete procedural guidance: where to obtain connectors (onshape_get_assembly), the two accepted connector formats, and the ordering rule (moving part first). It stops short of stating when not to use it or naming the alternative sibling for other join operations.

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