Skip to main content
Glama
Sign In
MCP 3DVista

MCP 3DVista

by juanchacon98
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

generar_codigo

Generates JavaScript for 3DVista buttons, hotspots, or tour start, covering actions like scene navigation, component visibility, links, WhatsApp, language switching, and analytics events.

Instructions

Genera JavaScript para 3DVista (Acciones > "Ejecutar JavaScript" de botones, hotspots o al iniciar). Acciones: ir_a_escena, siguiente_escena, anterior_escena, mostrar_componente, ocultar_componente, alternar_componente, mostrar_varios, mostrar_temporal, click_componente, abrir_url, whatsapp, llamar, correo, pantalla_completa, silenciar, auto_recorrido, cambiar_idioma, compartir, evento_analytics, al_cambiar_escena, personalizado. Use listar_acciones para ver parametros.

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": {
      "accion": "<accion>"
    },
    "name": "generar_codigo"
  }
}

Input Schema

NameRequiredDescriptionDefault
modoNoaccion (defecto): autonomo para 3DVista. helper: usa window.TDVH (requiere instalar_ayudante o skin HTML). externo: desde un Web Frame/pagina.
accionYes
parametrosNoParametros de la accion (ver listar_acciones)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.4.0

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations at all, the description carries the full behavioral burden, yet it never says whether the tool only returns a code string or touches the tour/project, whether the code is validated, or what the response looks like. The one behavioral hint is the schema's 'modo' note about needing instalar_ayudante, which the description itself never surfaces.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and placement are front-loaded in one sentence, which is good structure, but the long enum dump duplicates the schema verbatim and consumes most of the description without adding information. The single genuinely value-adding line is the pointer to listar_acciones.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a generator with a nested parameters object, no output schema, and no annotations, the definition covers purpose and action enumeration but omits return shape, side effects, and any per-action parameter detail. It is adequate to select the tool, but not complete enough to invoke it confidently without a follow-up call to listar_acciones.

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 67%, and the description merely re-lists the 21 'accion' enum values already present in the schema rather than explaining what each one needs. The key semantic contribution is delegation — "Use listar_acciones para ver parametros" — which tells the agent the nested 'parametros' object is undocumented here, but adds no concrete meaning for 'modo' or individual actions.

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 concrete verb and resource ("Genera JavaScript para 3DVista") plus the exact placement (Acciones > Ejecutar JavaScript de botones, hotspots o al iniciar), so the agent knows what is produced and where it goes. It does not contrast itself with plausible siblings such as validar_javascript or inyectar_en_export, which keeps it from a 5.

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?

The placement context (buttons, hotspots, on-start) implies when the output is usable, and "Use listar_acciones para ver parametros" routes the agent elsewhere for parameter discovery. However, there is no explicit when-to-use vs when-not guidance and no statement of prerequisites or of what to do after generating.

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