Skip to main content
Glama
Angelthebestone

Normativa Colombia MCP

by Angelthebestone
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Resolver una cita normativa

resolver_cita

Resolve exact Colombian legal citations—laws, decrees, rulings, or articles—in batches and validate them against official sources, avoiding imprecise keyword searches.

Instructions

Ruta rápida y exacta para citas como "Ley 909 de 2004", "Decreto 1083", "C-337/11" o "artículo 6 de la Ley 1221 de 2008". Úsala SIEMPRE que la pregunta mencione una norma concreta: el buscador por palabras es impreciso. Los CÓDIGOS se citan por su nombre ("art. 191 del Código de Comercio", "art. 164 del CPACA") y la respuesta dice contra qué norma se resolvió. Acepta un LOTE con citas (["Ley 909 de 2004", "C-337/11"]), que resuelve cada una en una sola llamada, y varios ARTÍCULOS de la MISMA norma con articulos (["705", "710"]) y cita apuntando a la norma: se descarga una vez y la ficha no se repite.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoEnlace a comprobar (solo con validar=true)
citaNoEj.: "Ley 909 de 2004", "C-337/11", "art. 6 de la Ley 1221 de 2008", "art. 191 del Código de Comercio"
citasNoVarias citas a la vez, ej. ["Ley 909 de 2004", "C-337/11"]: cada una se resuelve y se devuelve con su enlace
formatoNoSolo con validar=true: "json" devuelve el resultado como objeto (fecha_consulta, y por cita: resultado, comprobaciones, titulo, url, nota), sin cabecera ni pie, para encadenarlo sin releer texto.
validarNoEn vez de la resolución, comprueba que la cita (y el enlace, si se da con url) coincide con lo que devuelve el Gestor: número/año, dominio y artículo. Clasifica en "cita validada", "parcialmente validada" o "no fue posible validar". NUNCA afirma vigencia.
contextoNoPor defecto true. Con false se omite el extracto de tema asociado y queda solo la identificación, la vigencia y el texto pedido.
articulosNoVarios artículos de la MISMA norma en una sola llamada, ej. ["705", "707", "710"]. Se usa con cita apuntando a la norma ("Decreto Ley 624 de 1989"); la norma se descarga una vez y se extrae cada artículo.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.15.1
    • addedInput schema / properties / formato
      Added value: +{
+  "description": "Solo con validar=true: \"json\" devuelve el resultado como objeto (fecha_consulta, y por cita: resultado, comprobaciones, titulo, url, nota), sin cabecera ni pie, para encadenarlo sin releer texto.",
+  "enum": [
+    "markdown",
+    "json"
+  ],
+  "type": "string"
+}
  2. Changed1 schema field changedv1.14.0
    • changedInput schema / properties / contexto / description
      Previous value: -"Por defecto true. Con false se omite el extracto de tema asociado y se devuelve solo la identificación, la vigencia y el texto pedido. Útil cuando ya se conoce la norma y solo se quiere el articulado."New value: +"Por defecto true. Con false se omite el extracto de tema asociado y queda solo la identificación, la vigencia y el texto pedido."
  3. Changed3 schema fields changedv1.13.0
    • addedInput schema / properties / articulos
      Added value: +{
+  "description": "Varios artículos de la MISMA norma en una sola llamada, ej. [\"705\", \"707\", \"710\"]. Se usa con cita apuntando a la norma (\"Decreto Ley 624 de 1989\"); la norma se descarga una vez y se extrae cada artículo.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • changedInput schema / properties / cita / description
      Previous value: -"Ej.: \"Ley 909 de 2004\", \"C-337/11\", \"art. 6 de la Ley 1221 de 2008\""New value: +"Ej.: \"Ley 909 de 2004\", \"C-337/11\", \"art. 6 de la Ley 1221 de 2008\", \"art. 191 del Código de Comercio\""
    • addedInput schema / properties / contexto
      Added value: +{
+  "description": "Por defecto true. Con false se omite el extracto de tema asociado y se devuelve solo la identificación, la vigencia y el texto pedido. Útil cuando ya se conoce la norma y solo se quiere el articulado.",
+  "type": "boolean"
+}
  4. Changed4 schema fields changedv1.11.2
    • addedInput schema / properties / citas
      Added value: +{
+  "description": "Varias citas a la vez, ej. [\"Ley 909 de 2004\", \"C-337/11\"]: cada una se resuelve y se devuelve con su enlace",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / url
      Added value: +{
+  "description": "Enlace a comprobar (solo con validar=true)",
+  "type": "string"
+}
    • addedInput schema / properties / validar
      Added value: +{
+  "description": "En vez de la resolución, comprueba que la cita (y el enlace, si se da con url) coincide con lo que devuelve el Gestor: número/año, dominio y artículo. Clasifica en \"cita validada\", \"parcialmente validada\" o \"no fue posible validar\". NUNCA afirma vigencia.",
+  "type": "boolean"
+}
    • removedInput schema / required
      Removed value: -[
-  "cita"
-]
  5. First observedv1.6.0

TDQS

A3.9/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden. It adds useful context about batch resolution and avoiding repeated downloads for multiple articles, but it does not describe permissions, read-only nature, error behavior, or the validation mode, which is only covered in the schema.

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 front-loaded with the core purpose and usage rule, and every sentence has a practical function. It is dense but not bloated, though the multiple examples and batching explanation make it slightly longer than strictly necessary.

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?

Given the rich schema descriptions, the description is complete enough for an agent to select and invoke the tool correctly. It covers purpose, usage routing, batch behavior, and article extraction, but omits the validation mode and does not compensate for the absence of annotations with broader behavioral context.

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 the schema already documents all seven parameters, including examples, defaults, and the validar/formato/contexto behavior. The description reinforces the batch citas and articulos patterns, but adds little parameter meaning beyond what the schema already provides.

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 states a specific verb and resource: resolving legal citations such as laws, decrees, and rulings. It distinguishes this from imprecise word-based search and gives concrete citation examples, so an agent can identify the tool's purpose without opening the schema.

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?

It gives an explicit usage condition: use it whenever the question mentions a concrete norm, because word search is imprecise. It also explains batch citations and multiple articles from the same norm. However, it does not name a specific sibling tool as the alternative and gives no explicit when-not condition.

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