cnmc-logistica

Overview Schema Source Related Servers Discussions Admin

consulta_sql

Runs a single read-only SELECT or WITH…SELECT query against the CNMC logistics SQLite database to retrieve installations, operators, prices, routes, capacities, and related records.

Instructions

Ejecuta una única sentencia SELECT (o WITH … SELECT) sobre la base, en solo lectura.

Tablas principales: instalaciones, detalles, detalle_productos, operadores, operadores_nombres, precios, condiciones, servicios_incluidos, precios_origen_destino, notas_origen_destino, capacidades, documentos, filas_documento, enlaces_documento, precios_pdf, matrices_pdf, bonificaciones, notas_pdf, condiciones_pdf, cobertura_pdf, ejecuciones, incidencias. Vistas útiles: precios_pdf_por_detalle, reconsignaciones, lineas_pdf_sin_resolver. Cada tabla con historial tiene una vista _vigentes con lo visto en la última foto. La función plano(texto) quita tildes y mayúsculas. Usa estado para ver las columnas.

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": {
      "sql": "<sql>"
    },
    "name": "consulta_sql"
  }
}

Input Schema

Name	Required	Description	Default
`sql`	Yes
`limite`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Nov 11, 2026

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose two critical guardrails: read-only and exactly one statement. It says nothing about truncation, timeouts, row caps, permissions, or what happens on a malformed query — the silent row-limit behavior is especially important and left unmentioned.

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?

Front-loaded with the operation and its read-only/single-statement constraint, then the reference material. The long comma-separated table and view lists are information-dense but mostly earn their place as schema discovery aid; grouping them by purpose would improve scanability.

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 free-form SQL tool the essentials are covered: what is permitted, what the data model looks like, how to find current vs. historical rows, and where to look up columns via `estado`. An output schema exists, so return shape need not be described, and the remaining gap (limite semantics) is narrow.

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 coverage is 0%, so the description must compensate, and it does well for `sql`: syntax constraints, the table inventory, and the plano() function give an agent real query-writing support. It never mentions the `limite` parameter or its 200 default, so the truncation control an agent may need is completely undocumented.

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?

States a specific verb and resource (execute a single SELECT or WITH…SELECT against the database) and binds it to a read-only scope. An agent immediately understands this is the raw query escape hatch, distinct from the domain-specific siblings like listar_instalaciones or buscar_precios.

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?

Provides strong in-task guidance: which tables exist, which views are useful, that <tabla>_vigentes holds the latest snapshot, the plano() helper, and that `estado` should be consulted for columns. It never addresses tool selection, though — nothing says when to prefer this over the curated sibling tools or when it is unnecessary, so there are no explicit exclusions.

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

Deploy Server