Skip to main content
Glama
dossincargas

Dossin MCP Server

Official
by dossincargas

compile_and_save_component

Compile dynamic Dossin components into standalone HTML via backend. Returns a public URL for embedding or sharing. Requires user authentication token.

Instructions

Envía un COMPONENTE DOSSIN al backend para compilación remota a HTML standalone.

🔐 AUTENTICACIÓN OBLIGATORIA: ⚠️ ANTES de llamar a esta tool, DEBES preguntar al usuario por su token de autenticación. ❗ El token es REQUERIDO para la compilación en el backend.

FLUJO OBLIGATORIO:

  1. Pregunta al usuario: "Por favor, proporciona tu token de autenticación"

  2. El usuario puede obtenerlo desde:

    • DevTools del frontend: document.cookie.split('; ').find(r => r.startsWith('accessToken='))?.split('=')[1]

    • O copiar directamente desde la aplicación

  3. Una vez obtenido el token, procede con la compilación


⚠️ CRÍTICO - DIFERENCIA ENTRE ARTEFACTO Y COMPONENTE DOSSIN:

📱 ARTEFACTO DE CLAUDE (NO compilar):

  • Componente con datos hardcodeados

  • Se muestra en el chat de Claude

  • const turnos = [{id: 1, ...}, {id: 2, ...}]; // Datos fijos

  • NO tiene fetch(), NO tiene useEffect

  • ❌ NO usar con compile_and_save_component

🔧 COMPONENTE DOSSIN (SÍ compilar):

  • Componente con fetch dinámico

  • const [data, setData] = useState([]);

  • useEffect(() => { fetch('http://localhost:3000/api/database/query', ...) }, []);

  • Incluye estados: loading, error, data

  • ✅ USAR con compile_and_save_component

TRANSFORMACIÓN REQUERIDA (Artefacto → Componente Dossin):

  1. Remover: const turnos = [datos_hardcodeados];

  2. Agregar: const [turnos, setTurnos] = useState([]);

  3. Agregar: const [loading, setLoading] = useState(true);

  4. Agregar: const [error, setError] = useState(null);

  5. Agregar: useEffect con fetch al endpoint

  6. Agregar: manejo de if(loading) e if(error)

COMPILACIÓN EN BACKEND:

  • El backend compila el componente con todas las dependencias

  • Genera HTML standalone listo para producción

  • Retorna URL pública del componente compilado

  • Compatible con iframes, S3, CDN

RESULTADO:

  • URL pública del componente compilado

  • HTML standalone con datos en tiempo real

  • Listo para embeber o compartir

  • Registrado con trazabilidad del usuario que lo creó

CUÁNDO USAR:

  • Solo después de transformar ARTEFACTO → COMPONENTE DOSSIN

  • Para generar archivos HTML de producción

  • Para obtener URL pública del componente

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
reactCodeYesEl código JSX completo del COMPONENTE DOSSIN. DEBE incluir: imports (React, useState, useEffect), fetch dinámico a la API, estados (loading, error, data), y manejo de errores. NO enviar artefactos con datos hardcodeados.
userTokenYesToken JWT del usuario para autenticación (OBLIGATORIO). Debe ser solicitado al usuario ANTES de llamar a esta función. El token se envía como Authorization Bearer al backend y permite trazabilidad de quién creó el componente.
componentNameYesNombre descriptivo del componente (ej: 'VolumenCargaProvincias', 'TurnosDelDia'). Se usa para el título del HTML y nombre del archivo.
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the authentication requirement: '⚠️ ANTES de llamar a esta tool, DEBES preguntar al usuario por su token de autenticación.' It explains the backend compilation process, the generation of a public URL, and the traceability of the user. It also warns about not sending hardcoded artifacts. These are valuable behavioral traits beyond what the schema alone would reveal.

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 lengthy but well-structured with section headers, bullet points, and bold text. The core purpose is front-loaded in the first sentence. While some content is redundant (e.g., repeated emphasis on authentication token), the detailed transformation instructions and usage rules justify the length for a tool with such specific requirements. It could be tightened slightly, but the structure makes it scannable and useful.

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?

The description is highly complete for a tool with 3 required parameters, no output schema, and no annotations. It covers the tool's purpose, authentication prerequisites, step-by-step user interaction, the distinction between artifacts and Dossin components, the transformation procedure, backend compilation behavior, and the expected result (public URL). There are no critical gaps in context or usage requirements.

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?

Though the input schema has 100% coverage with each parameter described, the description significantly enriches the meaning of the parameters. For reactCode, it specifies what a valid Dossin component must include (imports, fetch, states) and explicitly says not to send hardcoded artifacts. For userToken, it details the exact flow for obtaining it from the user and explains it is used for Authorization Bearer and traceability. For componentName, it notes it is used for the HTML title and file name. This goes well beyond the one-line schema 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 opens with a clear, specific statement: 'Envía un COMPONENTE DOSSIN al backend para compilación remota a HTML standalone.' It identifies the verb (send), the resource (COMPONENTE DOSSIN), and the purpose (compilation to standalone HTML). It also distinguishes itself from sibling tools (get_database_schema and execute_query) through the 'CUÁNDO USAR' section, explicitly stating when this tool should be used and when it should not. This makes its purpose unmistakable.

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?

The description provides explicit usage guidance with a dedicated 'CUÁNDO USAR' section: 'Solo después de transformar ARTEFACTO → COMPONENTE DOSSIN', 'Para generar archivos HTML de producción', and 'Para obtener URL pública del componente'. It also clearly contrasts artifacts (NOT to compile) with Dossin components (to compile), giving detailed transformation steps. This fully addresses when to use the tool and when to avoid it.

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/dossincargas/dossin__mcp'

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