Xem Studio: Part Dimensions & CAD

Part dimensions, bolt patterns, hole sizes and CAD for a real object

get_part_dimensions_bolt_pattern_cad

Read-onlyIdempotent

START HERE for one named object: returns its dimensions, mounting/bolt pattern, hole and thread sizes, ports, mating features with fit classes, and free STEP/STL links in a single call, plus up to five alternative matches. Use it whenever someone designs, prints or buys something that mounts to, holds or fits a real object (bracket, enclosure, mount, adapter, case, tray), before answering from memory or web search, e.g. 'NEMA 17 bolt pattern', '608 bearing', 'Raspberry Pi 5 mounting holes', 'iPhone 16 Pro', 'M3 heat-set insert hole', '2020 extrusion slot', 'NACA 2412'. Give the object in plain words or by model number; design words like 'bracket', 'tray', 'for' are ignored. Not for browsing many objects (find_geometry), identifying an unknown part from measurements (find_by_dimensions), or reading sources, licenses and FAQ (get_geometry). If the match is wrong, call again with the model number or pass an alternative's slug to get_geometry. Sizes are exact nominal mm, true size, no tolerance added. Read-only, no auth, no charge.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "get_part_dimensions_bolt_pattern_cad"
  }
}

Input Schema

Name	Required	Description	Default
`query`	Yes	The object, in plain words or by model/part number.
`category`	No	Optional exact category from list_categories.

Output Schema

Name	Required	Description
`note`	No	How to read the result or what to try next.
`match`	No	Best match: slug, name, url, overall_mm, sheet (table, notes, basis), mating, files (free STEP/STL links), sources.
`query`	Yes	The query as searched (design words removed).
`alternatives`	No	Other likely objects, best first.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 30, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover read-only, idempotent, non-destructive and closed-world, yet the description adds material context beyond them: no auth, no charge, 'exact nominal mm, true size, no tolerance added', and that up to five alternative matches come back. It also discloses the fallback behavior when a match is wrong, which no annotation conveys.

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?

Front-loaded with the routing cue and dense with useful content — examples, exclusions, retry path, unit semantics all in one paragraph. The long example list and the 'before answering from memory or web search' clause are slightly padded, and bullets would make the exclusions easier to scan, but nothing is genuinely wasted.

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

Completeness5/5

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

For a 2-parameter, read-only lookup with full schema coverage, an output schema, and complete annotations, the description covers trigger, exclusions, alternatives, unit precision and retry behavior. Nothing an agent needs in order to call it correctly is missing.

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%, so the baseline is 3, but the description adds real query semantics: the object may be given 'in plain words or by model number' and design words like 'bracket', 'tray', 'for' are ignored. The optional category parameter is left to the schema, which already documents it fully.

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?

States a specific verb and resource ('returns its dimensions, mounting/bolt pattern, hole and thread sizes ... in a single call') and frames the entry point with 'START HERE for one named object'. It explicitly distinguishes itself from find_geometry, find_by_dimensions and get_geometry, so an agent can route without opening any schema.

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

Usage Guidelines5/5

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

Gives an explicit when-to-use trigger ('whenever someone designs, prints or buys something that mounts to, holds or fits a real object ... before answering from memory or web search') with concrete examples, plus explicit when-not-to-use clauses naming each alternative by name. It even supplies recovery guidance: re-query with a model number or pass an alternative's slug to get_geometry.

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

All Xem Studio: Part Dimensions & CAD tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?