Skip to main content
Glama

patch_artifact

Cambia PEDAZOS de un artefacto ya guardado, sin volver a mandarlo entero. Es la forma normal de editarlo: save_artifact cobra el archivo completo en cada guardado (un artefacto de 100 KB son ~50.000 tokens de salida), un parche cobra lo que cambia.

Cada edit es un reemplazo LITERAL (no es una regex) sobre el HTML guardado:

  edits: [{ buscar: "<td>42</td>", reemplazar: "<td>57</td>" }]

Las reglas, que son lo que lo hace seguro:
  · Cada `buscar` tiene que aparecer EXACTAMENTE UNA VEZ. Con 0 o con varias no se guarda nada y se te dice cuántas hay: ampliá el fragmento —sumale la línea de arriba o la de abajo— hasta que sea único. Si querés cambiar todas a propósito, mandá todas:true en ese edit.
  · Es atómico: si un solo edit no encaja, no se aplica ninguno y no se crea versión.
  · Se aplican EN ORDEN sobre el texto en memoria, así que el edit 3 ve lo que hicieron el 1 y el 2.
  · Queda como una versión nueva, igual que save_artifact: la anterior sigue en el historial y se puede restaurar.

El texto exacto para `buscar` sale de **get_artifact con buscar="…"**, que devuelve sólo los fragmentos que coinciden con su contexto alrededor: ~800 caracteres en vez de los 107.000 del archivo.

Se parchea el HTML GUARDADO —para un artefacto react, markdown o mermaid, el ya envuelto—, que es exactamente lo que devuelve get_artifact.

Con base_version se exige que la versión viva sea esa: si alguien guardó en el medio no se pisa nada y se te dice cuál es la actual.

Input Schema

NameRequiredDescriptionDefault
notaNoQué cambió, en una línea. Es lo que se lee en el historial de versiones.
editsYesLos reemplazos, en orden. Hasta 50.
artifact_idYesID del artefacto a editar
base_versionNoLa versión sobre la que calculaste los edits. Si ya no es la viva, se rechaza el parche.
workspace_idNoUUID del workspace, o su nombre tal como lo dice el usuario ('Acme', 'el personal'). Omitir si el token ya tiene workspace fijo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

With annotations already covering readOnly/destructive/openWorld, the description adds rich behavior: uniqueness requirement per edit, atomic all-or-nothing application, sequential in-memory ordering, creation of a new restorable version, and conflict rejection via base_version. Crucially it clarifies this patches the STORED HTML (post-wrapping), which is not derivable from the schema.

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-loads the core idea in the first sentence, then uses tight bullets for the rules. It is longer than average, but nearly every sentence carries actionable information; a little trimming of prose around get_artifact would be possible.

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 5-param mutation tool with no output schema, the description is complete: it covers error behavior, atomicity, versioning, restore-ability and concurrency conflicts, leaving nothing an agent needs to call it correctly unspecified.

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?

Schema coverage is already 100%, but the description adds meaning well beyond it: it explains the literal (non-regex) replacement semantics, the unique-match rule for `buscar` and its error message, the role of `todas`, and the optimistic-concurrency semantics of `base_version`.

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?

Specific verb (patching pieces) plus resource (an already-saved artifact), with a concrete example edit. It explicitly contrasts itself with save_artifact ('save_artifact cobra el archivo completo...'), so an agent can distinguish it from the sibling 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?

States this is the normal way to edit ('Es la forma normal de editarlo'), names the alternative save_artifact and why it is costlier, and directs the agent to get_artifact to obtain the exact `buscar` text. It also flags when to use todas:true and when base_version is required.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources