Skip to main content
Glama
Sign In
MCP 3DVista

MCP 3DVista

by juanchacon98
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

inyectar_en_export

Injects custom CSS, JS, or HTML as a named block into a 3DVista HTML5 export's index.htm, with automatic backup, idempotent replacement, and optional file creation.

Instructions

Inserta CSS, JS o HTML propio en el index.htm del export (bloque con nombre, idempotente, con respaldo index.htm.original). Opcionalmente escribe archivos en el export.

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": {
      "ruta_export": "<ruta_export>",
      "nombre_bloque": "<nombre_bloque>"
    },
    "name": "inyectar_en_export"
  }
}

Input Schema

NameRequiredDescriptionDefault
jsNoJS en linea (va antes de </body>)
cssNoCSS en linea (va en <head>)
htmlNoHTML extra antes de </body>
archivosNoMapa ruta_relativa → contenido para crear en el export
ruta_exportYesCarpeta del export HTML5 de 3DVista (donde esta index.htm)
esperar_tourNoEnvuelve el JS para ejecutarse cuando el recorrido este listo (incluye el ayudante TDVH)
nombre_bloqueYesIdentificador (letras, numeros, -, _). Reutilizarlo reemplaza el bloque.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.4.0

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses idempotency ('bloque con nombre, idempotente'), that reusing a block name replaces the previous block, and that a backup index.htm.original is created. It doesn't state what happens to pre-existing files listed in 'archivos' or what is returned on failure, leaving a small gap.

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?

One dense sentence plus a short qualifier, front-loaded with the primary action and the key safety fact (backup). No filler, though the parenthetical packs several distinct facts together rather than structuring them.

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 7-parameter mutation tool with a nested object and no output schema, the description covers the essential behavior: what gets modified, where content is injected, idempotency, backup creation, and optional file writes. Return-value expectations are the only unstated element, a minor omission for a file-injection utility.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already explains every parameter including insertion points and the block identifier. The description restates idempotency and the optional file writing but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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?

States a specific verb and resource: inserting custom CSS/JS/HTML into the export's index.htm, plus the optional ability to write files. It's precise enough to separate from a generic file-writer, though it never names the inverse sibling (quitar_inyeccion) that an agent would need to distinguish it from.

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

Usage Guidelines3/5

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

Usage is implied by the domain ('index.htm del export' of a 3DVista tour) and by the note that files can optionally be written, but there's no explicit when-to-use/when-not or pointer to alternatives like crear_skin_html or quitar_inyeccion. The agent must infer the choice from sibling names alone.

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

Deploy Server

Other Tools