Skip to main content
Glama
DweskZ

EcuDataMCP

by DweskZ
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Consultar datos de un indicador del SUT o la Judicatura

query_sut_indicador
Read-only

Query live SUT or Consejo de la Judicatura dashboard indicator rows from Ecuador, selecting fields, equality filters, and a row limit.

Instructions

Live query of one SUT or Consejo de la Judicatura dashboard's data model (fuente): choose campos, optional equality filtros (plain columns only) and a row limite. Take the indicador from list_catalogo(fuente) and its valid campos from get_sut_indicador_schema.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
camposYesField labels exactly as returned by get_sut_indicador_schema.
formatNotext summary (default) or json structured result.text
fuenteNosut (default) | judicaturasut
limiteNoRow cap applied server-side by the query itself (clamped to 20000; the result carries truncado=true when the cap was reached).
filtrosNoOptional {campo: valor} equality filters, plain columns only.
indicadorYesA key from list_catalogo(fuente=<fuente>).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.13.0
    • changedInput schema / properties / limite / description
      Previous value: -"Row cap applied server-side by the query itself."New value: +"Row cap applied server-side by the query itself (clamped to 20000; the result carries truncado=true when the cap was reached)."
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "type": "object"
-}New value: +null
  2. Changed2 schema fields changedv0.12.0
    • addedInput schema / properties / fuente
      Added value: +{
+  "default": "sut",
+  "description": "sut (default) | judicatura",
+  "enum": [
+    "sut",
+    "judicatura"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / indicador / description
      Previous value: -"A key from list_catalogo(fuente='sut')."New value: +"A key from list_catalogo(fuente=<fuente>)."
  3. Changed1 schema field changedv0.11.0
    • changedInput schema / properties / indicador / description
      Previous value: -"A key from list_sut_indicadores."New value: +"A key from list_catalogo(fuente='sut')."
  4. Changed5 schema fields changedv0.10.0
    • addedInput schema / properties / campos / description
      Added value: +"Field labels exactly as returned by get_sut_indicador_schema."
    • addedInput schema / properties / filtros / description
      Added value: +"Optional {campo: valor} equality filters, plain columns only."
    • addedInput schema / properties / format / description
      Added value: +"text summary (default) or json structured result."
    • addedInput schema / properties / indicador / description
      Added value: +"A key from list_sut_indicadores."
    • addedInput schema / properties / limite / description
      Added value: +"Row cap applied server-side by the query itself."
  5. Changed7 schema fields changedv0.8.14
    • removedInput schema / properties / campos / title
      Removed value: -"Campos"
    • removedInput schema / properties / filtros / title
      Removed value: -"Filtros"
    • removedInput schema / properties / format / title
      Removed value: -"Format"
    • removedInput schema / properties / indicador / title
      Removed value: -"Indicador"
    • removedInput schema / properties / limite / title
      Removed value: -"Limite"
    • removedInput schema / title
      Removed value: -"query_sut_indicadorArguments"
    • removedOutput schema / title
      Removed value: -"query_sut_indicadorDictOutput"
  6. First observedv0.8.12

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds meaningful context with 'Live query' (freshness) and the plain-columns filter restriction, but defers the row cap and truncado=true flag entirely to the schema, so it does not go far beyond the structured fields.

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

Conciseness5/5

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

Two sentences, front-loaded with the core action and then the input-sourcing recipe. No filler, and the most decision-relevant information (what it queries, where inputs come from) leads.

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

Completeness4/5

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

With no output schema, the description should hint at returns; it notes the row limite cap indirectly and the format param (text vs json) is documented, but it does not describe the result shape or the truncado flag. The input workflow is complete, so only the return-side detail is thin.

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 100%, so every parameter is already documented, including the value sourcing for indicador and campos. The description restates this workflow guidance rather than adding syntax or format detail the schema lacks; the 100%-coverage baseline of 3 applies.

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 (live query) and resource (one SUT or Consejo de la Judicatura dashboard's data model), scoped to a single indicador. It distinguishes itself from siblings by naming list_catalogo and get_sut_indicador_schema as the sources for its inputs, so an agent can place it in the toolchain.

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?

Gives a clear workflow: pull the indicador from list_catalogo(fuente) and valid campos from get_sut_indicador_schema, plus the constraint that filtros work on plain columns only. It stops short of explicit when-not-to-use or an alternative tool for cases outside this data model.

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