Skip to main content
Glama

execute_batch

Execute a batch of ordered low-level operations in a single pass. Suppresses redraw and rebuild until completion, with all-or-nothing rollback on failure.

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?

With no annotations provided, the description fully discloses behavioral traits: it suppresses redraw, feature tree, and rebuild during processing, performs one rebuild at the end, and enforces all-or-nothing semantics with rollback on failure. It also details the verify parameter options and advises against per-feature rendering. The return structure for both success and failure is described, providing 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?

The description is structured with a main explanation, an English summary, an Args section, and additional notes on semantics and return values. It is comprehensive but not overly verbose, though it could be slightly more concise. The key concept is front-loaded, and the organization aids readability.

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 no output schema, the description thoroughly covers return values, error handling, and behavioral aspects. It provides all necessary information for correct usage, including restrictions on operations and the all-or-nothing rollback mechanism. The sibling tools list includes many individual low-level operations and composite builders, and this tool's description clearly positions it as the batch primitive complementing those.

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?

The input schema has 0% description coverage, so the description carries full burden. It adds crucial semantics: ops must be an array of objects with 'tool' (protocol operation name) and 'args' (matching exact parameter names), and clarifies which operations are allowed. verify is explained with its 'summary' vs 'none' options, and rebuild is described regarding rebuild suppression. This far exceeds the schema's minimal information.

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 a single pass, following a 'compile once, build once' approach like build123d. It distinguishes from separate calls by emphasizing efficiency gains, and explicitly states that it cannot invoke arbitrary API or composite build_* operations, making its purpose very specific and distinct from sibling tools.

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 provides explicit guidance: use this tool instead of N separate calls for efficiency, ensure each operation is a protocol operation (not composite or perception/IO), and avoid nesting batch calls. It explains the parameters rebuild and verify with appropriate defaults and recommendations. However, it does not explicitly state when not to use it beyond the restrictions, which is sufficient for an advanced tool.

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/MCP_CAD'

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