Skip to main content
Glama
dossincargas

Dossin MCP Server

Official
by dossincargas

get_database_schema

Retrieve the complete MySQL database schema (tables, columns, data types, foreign keys, indexes, constraints) to understand data relationships and build accurate queries.

Instructions

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:

    1. Remover datos hardcodeados del artefacto

    2. Agregar: const [data, setData] = useState([]);

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

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

    5. 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior2/5

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.

Conciseness1/5

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.

Completeness2/5

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.

Parameters4/5

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.

Purpose3/5

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.

Usage Guidelines4/5

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.

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