Skip to main content
Glama
danielproxd2

MCP_CAD

by danielproxd2

execute_batch

Run an ordered list of low-level CAD operations in one pass, with automatic rollback if any operation fails to ensure model integrity.

Instructions

Ejecuta una lista ORDENADA de operaciones de bajo nivel en UNA sola pasada.

Es el primitivo "compila una vez, construye una vez" estilo build123d: en vez de N llamadas sueltas (cada una = un viaje al add-in + un rebuild/redibujo de SolidWorks), envía TODO el lote en una sola llamada. El add-in lo ejecuta in-process con redibujo, árbol de operaciones y reconstrucción SUPRIMIDOS, y hace UNA sola reconstrucción al final. La superficie sigue acotada: cada tool del lote se despacha por el mismo switch de operaciones permitidas — NO puede invocar API arbitraria ni geometría inventada.

[en: Run an ORDERED list of low-level ops in ONE pass — the build123d-style "compile once, build once" primitive. The add-in runs them in-process with redraw/feature-tree/rebuild suppressed and ONE rebuild at the end.]

Args: ops: lista de {"tool": <nombre-de-operación>, "args": {: valor}}. tool debe ser una operación de PROTOCOLO (p.ej. "create_sketch", "create_line", "create_circle", "extrude_sketch", "fillet") — NO un compuesto build_* ni una herramienta de percepción/IO. Los nombres de args deben coincidir EXACTAMENTE con los parámetros de esa operación (p.ej. create_line: x1_mm, y1_mm, x2_mm, y2_mm). No se permiten begin_batch / end_batch / execute_batch dentro del lote. rebuild: si True (default), una reconstrucción al cerrar el lote. verify: "summary" (default) adjunta un chequeo BARATO post-build (feature_count + bbox, SIN render) para verificar sin gastar un capture_views; "none" lo omite. Renderiza tú al final, no por feature.

Semántica TODO-O-NADA: si una operación falla, se revierte el modelo a su conteo de operaciones previo al lote (deshacer) y se reporta el índice/paso que falló — nunca se deja una pieza a medio construir que "parece" correcta.

Devuelve {ok, count, results:[{index,tool,result}], rebuilt, summary?} en éxito, o {ok:false, failed_index, failed_tool, error, rolled_back, applied_before_failure} en fallo. Aprobación humana: esta llamada (aprobada por el diseñador en el cliente MCP) ES la aprobación del lote completo.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
opsYes
verifyNosummary
rebuildNo
Behavior5/5

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

Describes the all-or-nothing semantics with rollback on failure, suppressed redraw/rebuild, and verification options. Without annotations, this fully discloses behavioral traits.

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 somewhat verbose due to bilingual text (Spanish and English), but it is well-structured with sections. Information is valuable and front-loaded with the core concept.

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 tool's complexity, no annotations, and no output schema, the description covers all essential aspects: purpose, usage, parameters, return values for success and failure, and behavioral guarantees. It is fully informative for an agent.

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?

With 0% schema coverage, the description extensively documents all parameters: ops format (tool and args with examples), rebuild default, and verify options. This compensates fully for the schema's lack of parameter descriptions.

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 that the tool executes an ordered list of low-level operations in one pass, using a 'compile once, build once' approach. It distinguishes from making separate calls and explicitly notes it is not for composite or perception/IO tools.

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?

Provides explicit guidance on when to use (batch instead of individual calls) and what not to include (no nested batch calls, no composite tools). Also clarifies that human approval on this call is approval for the entire batch.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/danielproxd2/solidworks-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server