Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Dossin MCP Server ¿Qué camiones están disponibles?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Este paquete es un servidor MCP (Model Context Protocol) diseñado para interactuar con la base de datos de Dossin a través de su backend.
Este servidor MCP se descarga directamente desde GitHub, no requiere instalación previa ni configuración de tokens.
Related MCP server: MCP-Driven Data Management System
Para usar este servidor MCP en Claude Desktop, configura el archivo claude_desktop_config.json de la siguiente manera:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"dossin": {
"command": "npx",
"args": ["-y", "github:moradelboca/dossin__mcp"],
"env": {
"BACKEND_URL": "http://localhost:3000/api"
}
}
}
}Importante:
Asegúrate de que el backend de Dossin esté corriendo en http://localhost:3000
Reinicia completamente Claude Desktop después de agregar la configuración
No necesitas configurar tokens ni .npmrc, funciona directamente desde GitHub
Este servidor MCP se descarga directamente desde GitHub usando npx. Actúa como puente entre Claude y el backend de Dossin, exponiendo tres herramientas principales:
get_database_schema: Obtiene el schema completo de la base de datos con metadatos (vía GET /api/database/schema)
execute_query: Ejecuta consultas SQL y retorna resultados (vía POST /api/database/query)
compile_and_save_component: Envía componentes React al backend para compilación remota (vía POST /api/archivos/compilar)
El backend de Dossin debe estar corriendo en http://localhost:3000 (o la URL que configures en Claude Desktop)
Los endpoints /api/database/schema, /api/database/query y /api/archivos/compilar deben estar disponibles
Node.js instalado (v18 o superior recomendado)
Obtiene el schema completo de la base de datos.
Uso en Claude:
Obtén el schema de la base de datosRespuesta: JSON con todas las tablas, columnas, tipos, relaciones y metadatos.
Ejecuta consultas SQL SELECT.
Uso en Claude:
Ejecuta la siguiente query: SELECT * FROM camiones LIMIT 10Respuesta: JSON con columnas, filas y conteo.
Envía componentes React al backend para compilación remota y obtiene una URL pública del componente compilado.
Uso en Claude:
Usuario: "Compila este componente React"
Usuario: "Sube el componente VolumenCargaProvincias al backend"
Usuario: "Exporta este componente a HTML"Autenticación (Producción):
En producción, este endpoint requiere autenticación. Puedes proporcionar tu token de dos formas:
Opción 1 - Pasar el token en el chat:
Usuario: "Compila este componente. Mi token es: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."Claude automáticamente extraerá y usará el token para autenticarse con el backend.
Opción 2 - Obtener tu token:
Desde la consola del navegador en el frontend de Dossin:
// Copia este resultado y pégalo en Claude
document.cookie
.split('; ')
.find(row => row.startsWith('accessToken='))
?.split('=')[1]Funcionalidad:
Envía el código JSX al backend vía POST /api/archivos/compilar
Autenticación automática con el token del usuario
El backend compila y bundlea el componente
Retorna URL pública del componente compilado
El componente queda registrado con el email del usuario que lo creó
Disponible para usar en iframes, compartir, etc.
Ventajas:
✅ Compilación centralizada en el backend
✅ URL pública inmediata
✅ Trazabilidad completa (quién creó qué)
✅ Sin dependencias pesadas en el MCP
✅ Archivos listos para producción
✅ Fácil de embeber y compartir
Ejemplo de respuesta:
{
"success": true,
"url": "https://dev.dossin.com.ar/components/VolumenCargaProvincias-2025-12-10.html",
"htmlPath": "/components/VolumenCargaProvincias-2025-12-10.html",
"message": "Componente compilado exitosamente en el backend. URL: https://..."
}Turnos:
Usuario: ¿Hay turnos mañana?
Usuario: ¿Cuántos turnos tengo hoy?
Usuario: Muéstrame los turnos pendientes de esta semana
Usuario: ¿Qué turnos tiene el camión ABC123?Camiones:
Usuario: ¿Qué camiones están disponibles?
Usuario: Muestra los datos del camión con matrícula XYZ789
Usuario: ¿Cuántos camiones tenemos registrados?Cargas:
Usuario: ¿Qué cargas están en proceso?
Usuario: Muestra las cargas de maíz del último mes
Usuario: ¿Cuántas toneladas se cargaron hoy?Choferes:
Usuario: Lista todos los choferes activos
Usuario: ¿Qué chofer maneja el camión ABC123?Primero, obtener el schema (si no lo tiene):
Claude: [Usa get_database_schema internamente]Interpretar la pregunta y construir query:
Usuario: ¿Hay turnos mañana?
Claude: [Construye: SELECT * FROM turnos WHERE fecha = '2025-10-22']
Claude: [Usa execute_query]Presentar resultados de forma natural:
Claude: "Sí, hay 5 turnos programados para mañana:
| Hora | Camión | Producto | Destino |
|-------|---------|----------|---------|
| 08:00 | ABC123 | Maíz | Puerto |
| ..."El servidor MCP de Dossin permite un flujo completo desde la generación hasta la compilación remota de componentes React:
Generación: Claude genera el componente React basado en tu solicitud
Envío al Backend: Claude envía el código al backend para compilación
Compilación Remota: El backend compila y bundlea el componente
URL Pública: Recibes una URL pública del componente compilado
Usuario: "Crea un componente con el volumen de carga por provincia de los últimos 6 meses"
Claude:
1. [Genera componente React completo]
2. [Muestra el código al usuario]
3. "¿Quieres que lo compile en el backend?"
Usuario: "Sí, compílalo"
Claude:
[Usa compile_and_save_component]
"✅ Componente compilado en el backend.
URL: https://dev.dossin.com.ar/components/VolumenCargaProvincias-2025-12-10.html
Puedes:
- Abrirlo directamente en el navegador
- Embederlo en un iframe
- Compartir la URL"Los componentes generados tienen las siguientes características:
Componentes Atómicos y Relevantes:
Solo muestran las estadísticas explícitamente solicitadas
No incluyen información adicional no solicitada
Pueden mostrar múltiples estadísticas si se solicitan juntas
Carga de Datos en Tiempo Real:
Los datos se cargan automáticamente al montar el componente
Usa fetch para consultar el backend de Dossin
Incluye manejo de estados de carga y errores
Editor Visual Integrado:
Controles para modificar estilos en tiempo real:
Colores (fondo, texto, bordes)
Tamaños (padding, margin, fuente)
Bordes (radio, grosor)
Sombras
Los cambios se reflejan inmediatamente
Opcional: guardar configuración visual en el backend
Usuario: "Muéstrame los turnos de hoy en un componente React interactivo"
Claude: [Genera componente React con fetch, editor de estilos, y datos de turnos]
Usuario: "Necesito un dashboard con total de camiones y cargas activas"
Claude: [Genera componente con ambas estadísticas y editor visual]
Usuario: "Crea un widget para visualizar productos más cargados"
Claude: [Genera componente con query específico y estilos editables]Los componentes generados por Claude siguen esta estructura:
import React, { useState, useEffect } from 'react';
function ComponenteDossin() {
// Estados para datos y estilos
const [data, setData] = useState(null);
const [loading, setLoading] = useState(true);
const [error, setError] = useState(null);
const [styles, setStyles] = useState({
backgroundColor: '#ffffff',
color: '#000000',
padding: '20px',
fontSize: '16px',
borderRadius: '8px'
});
// Carga de datos al montar
useEffect(() => {
fetch('http://localhost:3000/api/database/query', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
sql: 'SELECT ... FROM ...',
params: []
})
})
.then(res => res.json())
.then(result => {
setData(result.rows);
setLoading(false);
})
.catch(err => {
setError(err.message);
setLoading(false);
});
}, []);
// Función para actualizar estilos
const updateStyle = (property, value) => {
setStyles(prev => ({ ...prev, [property]: value }));
};
// Renderizado con estados de carga/error
if (loading) return <div>Cargando...</div>;
if (error) return <div>Error: {error}</div>;
return (
<div>
{/* Visualización de datos con estilos dinámicos */}
<div style={styles}>
{/* Contenido específico de la estadística */}
</div>
{/* Editor de estilos */}
<div className="style-editor">
<h3>Editor de Estilos</h3>
{/* Controles de color, tamaño, etc. */}
</div>
</div>
);
}
export default ComponenteDossin;React: Los componentes usan Hooks (useState, useEffect)
Fetch API: No requiere librerías adicionales
Backend activo: El backend de Dossin debe estar corriendo
CORS configurado: El backend debe permitir peticiones desde el frontend
Para que Claude entienda mejor el contexto de Dossin y responda de manera más natural, agrega estas instrucciones personalizadas en la configuración de Claude Desktop:
Estás conectado al sistema Dossin, un sistema de gestión de cargas y agro.
Contexto del negocio:
- Dossin gestiona turnos de carga/descarga de productos agrícolas
- Administra camiones, choferes, cargas, clientes y destinos
- La base de datos contiene información operativa del día a día
Cuando el usuario hable de:
- "turnos" o "turnos de mañana/hoy" → Consulta la tabla de turnos con fechas
- "camiones" → Busca en vehículos/camiones registrados
- "cargas" → Operaciones de carga activas o históricas
- "choferes/conductores" → Personal de conducción
- "productos" → Productos agrícolas (cereales, oleaginosas)
- "clientes" → Empresas o productores que usan el servicio
Comportamiento esperado:
1. Usa get_database_schema PRIMERO para entender la estructura
2. Construye queries SQL apropiadas basadas en el schema
3. NO expliques los pasos técnicos en detalle, solo responde directamente
4. Presenta datos en tablas cuando sea apropiado
5. Interpreta preguntas naturales y tradúcelas a consultas SQL relevantes
6. CUANDO SE SOLICITEN COMPONENTES REACT: Genera código completo, funcional, con fetch y editor de estilos
Ejemplo de consulta simple:
Usuario: "¿Hay turnos mañana?"
→ Obtén schema si no lo tienes
→ Ejecuta: SELECT * FROM turnos WHERE fecha = '2025-10-22'
→ Responde: "Sí, hay X turnos programados para mañana: [lista]"
Ejemplo de componente React:
Usuario: "Muéstrame los turnos de hoy en un componente React"
→ Genera componente completo con:
- useEffect para fetch de datos
- Editor de estilos (colores, tamaños, etc.)
- Manejo de estados de carga/error
- Solo información solicitada (turnos de hoy)Para ejecutar el servidor en modo desarrollo con auto-reload:
npm run devPara probar el servidor manualmente:
node index.jsEl servidor se comunicará a través de stdio (stdin/stdout) usando el protocolo MCP.
mcp/
├── index.js # Servidor MCP principal
├── package.json # Dependencias (solo MCP SDK y dotenv)
├── src/
│ ├── config.js # Configuración del servidor
│ ├── database.js # Funciones para interactuar con la BD
│ ├── handlers.js # Handlers de las herramientas MCP
│ └── tools.js # Definición de herramientas MCP
├── .env # Variables de entorno (no incluido en git)
├── .env.example # Ejemplo de variables de entorno
├── .gitignore # Archivos a ignorar
└── README.md # Esta documentaciónEl servidor se comunica con el backend vía HTTP, no se conecta directamente a la base de datos
El servidor NO tiene autenticación. La autenticación (si la hay) la maneja el backend
Las consultas SQL no están restringidas por ahora (depende de la lógica del backend)
La compilación de componentes React se realiza en el backend, no localmente
El MCP solo envía el código JSX al backend y recibe la URL del componente compilado
Asegúrate de que el backend esté corriendo antes de usar este MCP server
Verifica que:
El backend de Dossin esté corriendo (npm start en la carpeta backend)
La URL en BACKEND_URL sea correcta (por defecto http://localhost:3000/api)
Los endpoints /api/database/schema y /api/database/query estén disponibles
Verifica que la ruta en claude_desktop_config.json sea absoluta y correcta
Reinicia completamente Claude Desktop
Revisa los logs de Claude Desktop para ver errores
Asegúrate de que todas las dependencias estén instaladas (npm install)
Verifica que Node.js esté en la versión correcta (v18 o superior recomendado)
Solicitud del usuario:
"Crea un componente React que muestre el total de turnos de hoy"Claude generará:
Componente que hace fetch a /api/database/query con SQL: SELECT COUNT(*) as total FROM turnos WHERE fecha = CURDATE()
Editor con controles para: backgroundColor, color, fontSize, padding, borderRadius
Visualización del número con estilos aplicables en tiempo real
Solicitud del usuario:
"Dame un dashboard con total de camiones, cargas activas y turnos pendientes"Claude generará:
Componente con 3 fetch diferentes (o un fetch con JOIN)
Una card para cada estadística solicitada
Editor de estilos que afecta a todo el dashboard o cards individuales
Solo muestra esas 3 estadísticas (nada más)
Solicitud del usuario:
"Muéstrame los 5 productos más cargados este mes en un componente visual"Claude generará:
Query con GROUP BY y ORDER BY LIMIT 5
Lista/tabla ordenada con los productos
Editor para personalizar colores, tamaños de fuente, espaciado
Gráfico o visualización si es apropiado
Solicitud del usuario:
"Necesito ver turnos por fecha con selector de fecha"Claude generará:
Input de fecha que actualiza el estado
useEffect que re-fetch cuando cambia la fecha
Editor de estilos visual
Lista de turnos filtrados por fecha seleccionada
Para usar los componentes generados en tu proyecto React:
Copia el código generado por Claude
Instala dependencias (si no las tienes):
npm install reactAjusta la URL del backend si es necesario (variable de entorno recomendada)
Configura CORS en el backend de Dossin para aceptar peticiones desde tu frontend
Importa y usa el componente en tu app
Ejemplo de uso:
import EstadisticaTurnos from './components/EstadisticaTurnos';
function App() {
return (
<div className="App">
<h1>Dashboard Dossin</h1>
<EstadisticaTurnos />
</div>
);
}Los componentes generados son puntos de partida. Puedes extenderlos:
Agregar más controles de estilo: shadows, transforms, animations
Guardar configuración: Persistir estilos en localStorage o backend
Añadir gráficos: Integrar Chart.js, Recharts, etc.
Exportar estilos: Generar CSS/Tailwind classes desde la configuración
Temas: Crear presets de estilos (oscuro, claro, corporativo)
⚠️ Importante: Los componentes generados hacen peticiones al backend sin autenticación por defecto. Para producción:
Implementa autenticación (JWT, OAuth, etc.)
Valida permisos en el backend
Sanitiza queries SQL (el backend ya debe hacer esto)
Usa HTTPS en producción
Configura CORS apropiadamente (no usar wildcard * en producción)
El servidor MCP envía el código del componente al backend de Dossin, que se encarga de:
Compilación: El backend usa esbuild para compilar JSX a JavaScript
Bundling: Incluye todas las dependencias necesarias (React, librerías, etc.)
Optimización: Minifica y optimiza el código
Hosting: Sirve el HTML compilado desde una URL pública
✅ MCP ligero: Sin dependencias pesadas (esbuild, babel, react)
✅ Centralizado: Todas las compilaciones en un solo lugar
✅ URL pública: Acceso inmediato desde cualquier lugar
✅ Gestión: El backend puede versionar y administrar los componentes
✅ Escalable: Fácil agregar caché, CDN, etc.
┌─────────┐ ┌──────────┐ ┌─────────┐
│ Claude │ ─── código ───▶ │ MCP │ ── POST req ──▶ │ Backend │
└─────────┘ └──────────┘ └─────────┘
│ │
│ ┌───────────────────┘
│ │ Compila con esbuild
│ │ Bundlea dependencias
│ │ Guarda HTML
│ ▼
│ ┌─────────┐
└───│ URL │
└─────────┘MIGRATION_TO_ESM.md: Guía completa de migración de UMD a ESM
CLAUDE_INSTRUCTIONS.md: Instrucciones detalladas para Claude sobre cómo usar el sistema ESM
IMPLEMENTATION_SUMMARY.md: Resumen técnico de la implementación
CHANGELOG.md: Historial de cambios del proyecto
MIT
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:
Pregunta al usuario: "Por favor, proporciona tu token de autenticación"
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
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):
Remover: const turnos = [datos_hardcodeados];
Agregar: const [turnos, setTurnos] = useState([]);
Agregar: const [loading, setLoading] = useState(true);
Agregar: const [error, setError] = useState(null);
Agregar: useEffect con fetch al endpoint
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
| Name | Required | Description | Default |
|---|---|---|---|
| reactCode | Yes | El 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. | |
| userToken | Yes | Token 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. | |
| componentName | Yes | Nombre descriptivo del componente (ej: 'VolumenCargaProvincias', 'TurnosDelDia'). Se usa para el título del HTML y nombre del archivo. |
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.
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.
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.
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.
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.
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.
Ejecuta consultas SQL SELECT en la base de datos de Dossin.
DATOS DISPONIBLES:
Turnos: Programación de carga/descarga
Camiones: Vehículos y sus matrículas
Cargas: Operaciones activas/históricas
Choferes: Conductores registrados
Clientes: Empresas y productores
Productos: Catálogo agrícola
Destinos: Puertos, acopios, plantas
MEJORES PRÁCTICAS: ✅ Usa parámetros (?) para valores dinámicos ✅ Obtén el schema primero si no conoces la estructura ✅ Limita resultados con LIMIT cuando sea apropiado ✅ Usa CURDATE() para fecha actual ⛔ Solo consultas SELECT permitidas
EJEMPLO: query: "SELECT * FROM turnos WHERE fecha >= CURDATE() LIMIT 10" params: []
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Consulta SQL SELECT. Usa placeholders (?) para valores dinámicos. Ejemplo: SELECT * FROM turnos WHERE fecha = ? AND estado = ? | |
| params | No | Array de parámetros para reemplazar placeholders (?). Ejemplo: ['2025-12-02', 'pendiente'] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It successfully communicates the read-only nature via 'Solo consultas SELECT permitidas' and gives a clear list of available data. It also warns about best practices like limiting results. It could additionally describe return format or error behavior, but the essence of the tool's behavior is well-covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized into clear sections (DATOS DISPONIBLES, MEJORES PRÁCTICAS, EJEMPLO). Every sentence provides actionable information: the data list prevents guesswork, the best practices are concise and directly useful, and the example demonstrates usage. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a SQL query tool with two parameters and no output schema, the description provides substantial context: available tables, best practices, and an example. The main gap is that it does not describe what the query result object looks like (e.g., array of row objects), but given the simplicity and the example, an agent can likely infer this. It also appropriately points to schema discovery as a prerequisite.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both query and params are described). The description adds value by reinforcing the parameter usage with an example ('SELECT * FROM turnos WHERE fecha >= CURDATE() LIMIT 10') and by explaining the placeholder mechanism (?) for dynamic values. This goes beyond the schema, which only shows type and example, by giving contextual guidance on their combined use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Ejecuta consultas SQL SELECT en la base de datos de Dossin.' It lists the specific data entities available, which helps an agent understand the scope. The sibling tools (get_database_schema, compile_and_save_component) are clearly different in purpose, so this tool is well-distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit best practices: use parameters (?), fetch schema first, use LIMIT, and use CURDATE(). The 'Solo consultas SELECT permitidas' restriction clarifies when not to use this tool (i.e., for non-SELECT operations). However, it does not explicitly name the alternative tool for schema retrieval, though 'Obtén el schema primero' strongly implies get_database_schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DOSSIN - Sistema de Gestión de Cargas Agrícolas
Sistema integral para el sector agropecuario que administra:
Turnos: Programación de carga/descarga de productos agrícolas
Camiones: Vehículos de transporte (matrículas, choferes, capacidad)
Cargas: Operaciones de mercaderías y productos agrícolas
Choferes: Conductores registrados
Clientes: Empresas y productores
Productos: Catálogo agrícola (cereales, oleaginosas)
Destinos: Puertos, acopios, plantas
Base de datos MySQL con operaciones del sistema.
GENERACIÓN DE COMPONENTES REACT - REGLAS OBLIGATORIAS:
⚠️ SIEMPRE genera componentes React para consultas/visualizaciones de datos.
1. PRINCIPIO ATÓMICO:
Mostrar SOLO información solicitada explícitamente
NO agregar datos extra o sugerencias no pedidas
Un propósito único y claro por componente
2. DOS TIPOS DE COMPONENTES - ARTEFACTO vs COMPONENTE DOSSIN:
📱 ARTEFACTO DE CLAUDE (Para mostrar en el chat):
Este es el componente que se muestra como artefacto en la interfaz de Claude
Ejecutar execute_query PRIMERO para obtener datos reales de la BD
Hardcodear los datos obtenidos directamente en el código del componente
NO usar fetch(), NO useEffect, NO estados de loading/error
Los datos están embebidos en el código para visualización inmediata
Ejemplo: const turnos = [{id: 1, hora: '08:00', camion: 'ABC123'}, ...];
🔧 COMPONENTE DOSSIN (Para compile_and_save_component):
Este es el componente que se compila y guarda como HTML standalone
ANTES de llamar compile_and_save_component, TRANSFORMAR el artefacto:
Remover datos hardcodeados del artefacto
Agregar: const [data, setData] = useState([]);
Agregar: const [loading, setLoading] = useState(true);
Agregar: const [error, setError] = useState(null);
Agregar useEffect con fetch() dinámico
Endpoint: POST http://localhost:3000/api/database/query
Body: { sql: "query_original", params: [] }
Parsear: result.data contiene los datos
Incluir manejo de estados (if loading, if error)
El HTML final carga datos en tiempo real del backend
3. CÓDIGO COMPLETO Y FUNCIONAL:
Incluir TODOS los imports necesarios
Diseño responsive con Tailwind
Código ejecutable sin modificaciones
Manejo de errores apropiado
4. LIBRERÍAS SIN RESTRICCIONES:
Imports normales: import X from 'libreria'
esbuild bundlea automáticamente
Si falta alguna, la compilación FALLARÁ con error claro
El error dirá qué librería instalar - DETENER y avisar al usuario
Librerías instaladas: react, react-dom, lucide-react, recharts
RECORDATORIOS CRÍTICOS:
ARTEFACTO: datos hardcodeados (muestra inmediata en Claude)
COMPONENTE DOSSIN: fetch dinámico (HTML compilado para producción)
Siempre transformar antes de compilar
Componentes atómicos y específicos
Backend: http://localhost:3000/api
Obtiene el schema completo de la base de datos MySQL incluyendo tablas, columnas, tipos de datos, relaciones (foreign keys), índices y constraints.
CUÁNDO USAR:
Primera interacción con la base de datos
Antes de construir consultas complejas
Para entender relaciones entre tablas
Cuando necesites saber nombres exactos de columnas
RETORNA: JSON con estructura completa de la base de datos.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the tool returns a JSON with the complete database structure, which is useful. However, without annotations, the description carries the full burden, and the massive irrelevant sections about React component rules and system details actively misdirect the agent about the tool's behavior. It fails to disclose anything beyond the basic return type, such as read-only nature or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
This description is egregiously overlong, with hundreds of words of unrelated DOSSIN system details and React component instructions preceding the actual tool purpose. It is not front-loaded and violates conciseness by forcing the agent to wade through irrelevant material to find the one relevant sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core information about the schema (tables, columns, data types, relations, indexes, constraints) is present, and it explains return format. However, the description is dominated by irrelevant content, and with no output schema or annotations, the agent cannot easily distinguish which parts apply. The context is muddled, making the description incomplete as a guide for proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics to explain. The baseline of 4 applies because the description cannot add value beyond the schema, and it correctly does not attempt to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The core statement 'Obtiene el schema completo de la base de datos MySQL incluyendo tablas, columnas, tipos de datos, relaciones (foreign keys), índices y constraints' clearly specifies the tool's verb, resource, and scope, and the usage section differentiates it from execute_query. However, this essential purpose is buried under a lengthy unrelated preamble about the DOSSIN system and React component generation, which significantly obscures and dilutes the tool's actual function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Primera interacción con la base de datos', 'Antes de construir consultas complejas', 'Para entender relaciones entre tablas', and 'Cuando necesites saber nombres exactos de columnas'. It implicitly separates it from execute_query by framing schema retrieval as a prerequisite to building queries, but it does not explicitly state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: schema retrieval, SQL query execution, and component compilation/saving. The verbose instructions don't blur the boundaries between these operations.
All tool names use snake_case with a verb-first structure (get_, execute_, compile_and_save_). The compound verb in compile_and_save_component is a minor deviation but the pattern remains predictable.
Three tools is on the low end for a server handling database access and component generation, but it covers the core read-and-compile workflow. It feels slightly thin given the number of domain entities mentioned.
The schema, query, and compile tools form a coherent pipeline for generating data-driven components. Minor gaps exist (e.g., no list/manage compiled components, no explicit auth tool), but the primary purpose is well covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Ask data questions in natural language. Get SQL, insights, and charts from your databases.
Ask business questions in plain English. Get instant answers from your database, no SQL needed.
GibsonAI MCP server: manage your databases with natural language
Your Databricks Lakehouse in natural language: run SQL on your SQL warehouses, track long-running qu
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
