kernelcad

Open in Studio

open_in_studio

Use this when the user wants to SEE or share the model — it persists the current kernelCAD model and returns a one-click link that opens it in the kernelCAD Studio web app, where the user can view and share it. Pass the full .kcad source you have been building as code. code is OPTIONAL: if you just called evaluate_script you can omit it and this reuses that last evaluated source automatically (no need to re-send the whole script). Pass code explicitly to override, or whenever you have not evaluated this exact source yet. The result includes a slug — pass that slug on every subsequent call to UPDATE the same project in place: the user's open Studio tab re-renders live, so they can watch the model evolve as you iterate. Omit slug only for a new, separate model (each omission creates a new project and link). Trigger phrases: "open it in Studio", "let me see it", "show me the model"; also call it after you finish a build, and after each meaningful revision while iterating.

Input Schema

TableJSON Schema

Name	Required	Description
`code`	No	The full .kcad source of the model to open in Studio (the script you have been editing). Optional: omit to reuse the source from your most recent evaluate_script call.
`slug`	No	Slug returned by a previous open_in_studio call. When given, updates that existing project in place (live-updating the user's open Studio tab) instead of creating a new one.
`title`	No	Optional human-readable title for the model (shown in Studio). Defaults to "Model from Claude".
`parameters`	No	Optional list of the model's editable parameters, so Studio can render parameter controls. Each item is one control derived from the .kcad params.
`attachments`	No	Complementary project files referenced by relative path from the .kcad source.

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	No	Whether the model was persisted.
`url`	No	The /p/<slug> Studio link for the model.
`slug`	No	The project slug; pass it back to update this project in place.
`updated`	No	True when an existing project was updated; false when a new one was created.
`version`	No	Immutable Studio revision persisted by this call. Read it with get_project_revision using this slug and version.
`embedUrl`	No	Read-only, chrome-free /embed/<slug> viewer URL — drop into an <iframe> to embed the live model in any site or widget (no login).
`assetHashes`	No
`attachmentCount`	No

TDQS

A4.3/5.0

Behavior5/5

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

Discloses key behaviors: persists the model, returns a slug for live updates, optional code reuse from evaluate_script. Annotations indicate a write operation (readOnlyHint false) and non-destructive (destructiveHint false); description adds the reuse and live-update details without contradiction. Complete transparency.

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?

Thorough but well-structured. The most important usage guidance is front-loaded, followed by parameter details. Slightly longer than necessary but every sentence contributes to correct usage. Could be trimmed by merging redundant phrases.

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?

Given the complexity of conditional slug usage and code reuse, the description covers all operational scenarios. The existence of an output schema likely provides return value details. The live-update behavior with slug is fully explained, making the tool self-contained for an agent.

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% with descriptions for each parameter. Description adds crucial context: code is optional and reuses last evaluated source, slug determines update vs. new project. This exceeds schema-only information, though for trivial parameters like title the description adds little.

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 clearly states the tool persists a kernelCAD model and returns a link for viewing/sharing. It specifies the context ('when the user wants to SEE or share the model') and distinguishes it implicitly from siblings by focusing on a unique outcome. Could be improved by explicitly contrasting with similar tools like evaluate_script that don't persist.

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?

Provides explicit trigger phrases and specific situations to use (after finishing a build, after each meaningful revision). Offers conditional guidance on passing slug for updates vs. omitting for new projects. Does not explicitly state when not to use or list alternatives, but the guidance is substantial and actionable.

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

All kernelcad tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation4/5

Tools are mostly distinct, with clear descriptions for each. However, there is some potential overlap between inspection tools like 'inspect' and 'mesh_summary', and between rendering tools 'render_preview' and 'get_latest_render', which could cause minor confusion.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern, making it predictable for an agent to infer functionality.

Tool Count2/5

44 tools is significantly higher than the typical well-scoped range of 3-15. While the domain is complex, the count feels excessive and could overwhelm an agent.

Completeness4/5

The tool set covers an extensive range of CAD operations including creation, inspection, rendering, export, and verification. Minor gaps exist, such as direct sketch editing tools, but overall it is comprehensive.

Open in Studio

Input Schema

Output Schema

TDQS

Glama MCP Gateway

TDQS

Resources