Server Quality Checklist

Tool Scores

• analizar_conflictoA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses important behavioral traits: it only identifies POTENTIAL conflicts, does not detect semantic contradictions, and returns links for verification. This goes beyond a simple action description, though it omits details like failure behavior or data format.

  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 a single, information-dense sentence with clear components and a separate warning. It is concise and front-loaded with 'EVIDENCIA', though the heavy use of capitalization and semicolons makes it slightly less readable than ideal, but every part earns its place.

  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 tool's complexity (two norms, multiple evidence types) and lack of output schema, the description sufficiently indicates what is gathered and how to treat the result (verify links). It does not detail the exact return structure, but sets expectations for a potential-conflict evidence report.

  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% for all three parameters, so baseline is 3. The description adds minimal parameter-specific insight; it mentions 'pasajes que mencionan un tema' which aligns with 'sobre', but the schema already explains that parameter. No significant added semantics.

  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 clearly states the tool's function: 'Reúne para dos normas la EVIDENCIA de un posible conflicto' and lists specific evidence components (identificación, vigencia, jerarquía, reformas, pasajes). It distinguishes itself from siblings by explicitly noting it does NOT detect semantic contradictions, making it unique among conflict-related tools.

  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 gives context for use: it gathers potential conflict evidence, not legal conclusions, and instructs to 'verifica en los enlaces antes de actuar'. It excludes semantic contradiction detection, but does not name alternative tools explicitly, so slightly short of full when/when-not guidance.

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

• buscar_por_temaA
  4.1/5.0
  Behavior5/5

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

  With no annotations, the description carries full burden. It discloses key behavioral traits: the query resolves against a packaged index making it instantaneous and offline-capable; each result includes specific fields (temsubid, normid); the prefix 'ts-' is part of the ID and must be preserved; and it warns that IDs from different taxonomies can collide, potentially returning the wrong topic. This is rich behavioral context.

  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 concise and front-loaded with the main function. Each sentence adds value, though the last sentence about taxonomies and prefixes is somewhat dense. Overall, it's well-structured with no wasted words.

  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 explains the main return values (tema, subtema, associated norms/sentences/concepts, temsubid, normid). It also explains follow-up usage and an important caveat about catalog collisions. It doesn't explicitly mention pagination or the 'limite' parameter, but overall it gives enough context to use the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 50% (texto described, limite not). The description does not mention parameters at all, so it adds no meaning beyond the schema. The tool description neither explains 'limite' nor reinforces its usage. For a low-to-mid coverage, the description should have stepped in, but it didn't.

  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 clearly states the tool's purpose: 'devuelve tema, subtema y las normas, sentencias y conceptos asociados.' It also differentiates it from siblings by mentioning the 'índice empaquetado' (instantaneous, works offline) and the specific ID handling with 'ts-' prefix, which is unique to this tool.

  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 gives clear context for when to use this tool: for a 'Consulta temática oficial' (official thematic query). It implies a use case when the portal is down ('funciona aunque el portal esté caído') and provides guidance on using the returned IDs with 'explicar_relacion_tema'. It doesn't exclude alternatives explicitly, but the context is clear enough.

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

• cambios_desdeA
  4.2/5.0
  Behavior4/5

  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 reveals two critical traits: the date input is filtered by the YEAR of the modifying norm (not exact date), and the tool does not discover or track new norms automatically. This goes beyond the schema and helps avoid misuse, though it doesn't describe the return format.

  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?

  The description is two sentences with no redundant wording. The first sentence front-loads the core purpose, and the second adds a crucial limitation. Every word earns its place, making it highly concise and well-structured.

  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?

  The description covers purpose, parameters, and key behavioral limitations. Since there is no output schema, the description could benefit from a brief note about the return format, but for a tool with only two simple parameters and clear schema descriptions, it is largely complete. The explicit inclusion of change types (modification, repeal, addition) adds useful 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%, with both parameters fully documented in the input schema (e.g., 'desde' states 'se filtra por el AÑO de la norma modificadora'). The description adds no additional param semantics beyond reinforcing that only listed norms are considered, so baseline 3 is appropriate.

  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 clearly states the tool's function: 'Resume los cambios' (summarizes changes: modification, repeal, addition) on explicitly listed norms. It also distinguishes its scope by stating it does NOT automatically track novelties or discover new norms, differentiating it from sibling tools that search or retrieve norms.

  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 implies when to use the tool: when you have a specific list of norms and want changes since a date. The negative statement 'NO rastrea novedades automáticamente ni descubre normas nuevas' provides a clear exclusion, though it does not name alternative tools. This gives better guidance than no context, but lacks explicit references to siblings.

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

• buscar_jurisprudencia_consejo_estadoA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries full behavioral disclosure. It reveals that terms are joined with OR, that results include the legal problem and answer, that full text is not returned, and that a SAMAI link is provided. This is substantive behavioral detail beyond the minimum, though it omits potential error scenarios or rate limits.

  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 five sentences, each adding useful content: purpose, court distinction, result content, link, and search behavior. It is front-loaded with purpose and avoids redundancy, though slightly longer than strictly necessary, making it concise but not maximally compact.

  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 absence of an output schema, the description adequately explains returns (legal problem/answer, no full text, SAMAI link) and search behavior (OR, pagination). It gives enough context for an agent to use the tool effectively, though it could mention potential empty results or how to interpret the response format more explicitly.

  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?

  All three parameters have schema descriptions, so the baseline is 3. The description adds valuable semantics by explaining the OR-join behavior for 'texto' and the pagination strategy with 'pagina'. This enriches the schema and helps the agent use parameters correctly.

  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 opens with a specific verb and resource: 'Busca providencias tituladas del Consejo de Estado', identifying the exact court and scope. It also explicitly distinguishes this tool from the Corte Constitucional and Corte Suprema, aligning with sibling tools like buscar_jurisprudencia_suprema. This is a clear, specific purpose with sibling differentiation.

  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 provides clear context by stating the tool is for the Consejo de Estado and 'DISTINTO' from other courts, implying when to use this tool versus alternatives. It also gives search strategy advice ('Usa términos distintivos y avanza con pagina'). However, it does not explicitly name alternative tools or provide a formal when/when-not list, so it falls short of a 5.

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

• comparar_articulosA
  4.3/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden and excels. It discloses the algorithm (Dice bigrams ≥0.92), classification categories (plazo, sanción, excepción, sujeto obligado), the fallback 'revisar manualmente', and the limitation 'Sin modelo semántico'. This gives the agent a realistic expectation of behavior.

  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 information-dense but front-loaded: it opens with the main action and then details outputs and method. It is a single long sentence with semicolons, which is a bit heavy but not wasteful. Every clause adds value, earning a 4.

  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 tool's moderate complexity and lack of output schema, the description covers the essential behavior (what is compared, what is produced, edge-case handling). It does not explicitly describe the return format or a concrete example, but the agent can infer the structure. A 4 reflects this solid coverage with minor gaps.

  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?

  The schema covers 100% of the parameters with clear examples, so no additional parameter meaning is needed. The description does not add extra detail about the parameters, but the baseline of 3 is appropriate because the schema already handles them.

  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 clearly states the verb 'compara' (compares) with a specific resource (text of an article between two norms) and enumerates what it produces (marks additions/removals, classifies differences, detects editorial changes). This leaves no doubt about the tool's function and distinguishes it from sibling search and retrieval tools.

  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 gives clear context: it is for comparing articles from two different norms, which differentiates it from siblings like 'cambios_desde' (likely a chronological comparison). However, it does not explicitly state when not to use it or mention alternatives, so a small deduction applies.

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

• listar_normativa_ambiental_anlaA
  4.3/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses that the tool provides classification, not new documents, and implies it lacks full-text and validity data by stating resolver_cita handles those. It does not detail output format or pagination behavior, but it does a good job of setting expectations for a curated list tool.

  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 three focused sentences with no filler. It front-loads the source and classification purpose, states what the tool does not provide, and gives a clear usage directive. The heavy use of caps is slightly noisy but does not detract from clarity.

  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 lack of annotations and output schema, the description provides sufficient context for a list/discovery tool: it explains the curation source, the limitation (no new documents), and the relationship to resolver_cita. It does not describe the response structure, but the purpose is simple enough that the description, together with the schema, sets adequate 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?

  The schema already describes 'desde' and 'texto' (67% coverage), so the description need not repeat them. However, the description adds no parameter-specific meaning and does not compensate for the undocumented 'seccion' property beyond the title's theme focus. Baseline 3 is appropriate.

  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 clear, specific purpose: it lists environmental regulations classified by ANLA/Eureka. It explicitly says 'Lo que aporta es la CLASIFICACIÓN, no documentos nuevos' and instructs the agent to use it 'para descubrir QUÉ normas aplican a un tema ambiental,' clearly distinguishing it from siblings like resolver_cita.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives explicit guidance: use this tool to discover which regulations apply to an environmental topic, and then use resolver_cita to resolve each one. It names the alternative tool and explains why resolver_cita is better for full text and validity, making the when-to-use decision unambiguous.

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

• buscar_normativa_upmeA
  4.4/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden and excels: it warns that the tool returns PDFs, not full text, and highlights the critical date discrepancy between web publication and the actual norm date. These are non-obvious, high-impact behavioral traits that an agent must know.

  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?

  Three sentences, each purposeful: first defines scope, second warns about PDF-only output, third warns about date semantics. There is zero fluff, and the most critical caveats are front-loaded.

  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?

  For a 4-parameter search tool without an output schema, the description covers what is searched, the PDF-only limitation, and the crucial date quirk. It omits details about result format or pagination, but the essential operational context is present and sufficient for correct invocation.

  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 covers only 50% of parameters (texto and incluir_administrativos have descriptions). The description adds semantic context by giving example search topics (transmission, expansion plans) and mentioning administrative acts, but it does not clarify the behavior of limite or pagina. This partial compensation warrants a middle score.

  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 clearly specifies the tool's resource (UPME circulars and resolutions) and enumerates content types (transmission/gas calls, expansion plans, administrative acts). The explicit UPME name distinguishes it from sibling sector-specific tools like buscar_resoluciones_creg and buscar_normativa_anh, and the verb is implied by the tool name and title.

  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 gives a clear context of when to use the tool by listing its coverage areas and the issuing entity. It does not explicitly name alternatives or state when not to use it, but the specificity strongly implies the intended use case.

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

• buscar_unificadoA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It reveals that search is parallel, results declare their source, and SUIN validity is not the official record but labeled 'SEGÚN EL BUSCADOR'. This goes beyond the basic name and adds meaningful context for result interpretation.

  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?

  The description is three sentences, front-loaded with the core purpose, then usage guidance, then a behavioral caveat. Every sentence earns its place, with no redundancy or filler.

  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?

  The description covers the search behavior, result content (source and link), and a specific data-quality caveat about SUIN. Given that there is no output schema, this is reasonably complete for a search tool, though it does not detail the full response structure or error cases, which are typical for such tools.

  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?

  The input schema covers all four parameters with descriptive comments, achieving 100% coverage. The description itself does not add parameter-specific semantics beyond the schema; it only contextualizes the overall behavior. Thus, the baseline score of 3 is appropriate.

  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 clearly states the tool's specific function: it searches in parallel across multiple named sources (Gestor Normativo, Corte Constitucional, SUIN-Juriscol, DIAN) and aggregates results with source and link. It distinguishes itself from sibling tools by scoping it to open or subject-based queries, not exact citations or specific courts.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit usage guidance: use when the query is open or by subject and no obvious tool exists; for exact citations, prefer resolver_cita; for specific courts, use their dedicated search tools. This clearly frames when to choose this tool over the many siblings.

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

• consultar_perfilA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It transparently explains that the tool runs preconfigured sources/filters, returns profile results with sector, warning, date, and disclaimer, and that each profile declares its own scope/limits. This goes beyond surface-level description, though it omits details like error handling or authentication, preventing a 5.

  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?

  The description is three sentences and front-loaded with the core purpose. Every sentence earns its place: the first states what it does, the second explains the output and profile limitations, and the third provides explicit negative guidance. There is no redundancy or fluff, making it concise and well-structured.

  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 moderate complexity (3 params, no output schema, no annotations), the description covers the main operational context: preconfigured sources, profiles, output contents, and usage boundaries. However, it lacks a detailed breakdown of the return structure or behavior on invalid inputs, which would be needed for a perfect 5. The presence of sibling-tool references adds contextual completeness.

  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?

  The input schema covers 100% of parameters with descriptions, including valid profile IDs, the 'texto' example, and the 'limite' range. The description adds little beyond the schema—mainly repeating profile names and giving usage context. Since schema coverage is high, a baseline of 3 is appropriate, and the description does not meaningfully enhance parameter understanding.

  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 begins with a specific verb and resource: 'Ejecuta una consulta con las fuentes y los filtros preconfigurados de un perfil', clearly identifying the tool's function. It distinguishes itself from siblings by listing profile types and explicitly referencing alternative tools like buscar_normas and resolver_cita, making the purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/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 by naming the profiles and instructing to use describir_fuentes for the list of profiles. It also contains a clear negative directive: 'NO uses un perfil para lo que no cubre' and points to buscar_normas or resolver_cita for other matters, leaving no ambiguity about when to use this tool versus alternatives.

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

• consultar_por_jerarquiaA
  4.4/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full transparency burden. It discloses the output composition (documents with title and link, plus the character of the level), explains that levels are classified as vinculante/orientador/informativo, and adds a caveat that it is not legal advice and to verify on the link. It omits edge behaviors like pagination or no-result handling, but it gives substantial behavioral context beyond 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.

  Conciseness5/5

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

  The description is concise and well structured: three sentences lead with the core action, then describe the output, then give usage direction and a caveat. Every sentence adds value with no filler or repetition.

  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 there is no output schema, the description properly explains what is returned (documents with title, link, and level character) and covers legal caveats. It also provides usage alternatives. Minor gaps remain about result ordering and no-result behavior, but the description is largely complete for a search tool of this complexity.

  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?

  The schema already covers 100% of the parameters, so the baseline is 3. The description restates the 'nivel' options and explains the character of each level, but it does not add new meaning to 'texto' or 'limite' beyond what their schema descriptions already provide.

  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 opens with a specific verb and resource: 'Busca normativa colombiana por nivel de autoridad', lists the exact levels allowed, and states the returned data (documents with title, link, and level character). It also explicitly contrasts with sibling tools by saying 'para buscar sin nivel usa buscar_normas o buscar_por_tema', so it clearly distinguishes itself from siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description contains explicit when-to-use guidance: 'ÚSALA cuando la pregunta pida un nivel concreto' and gives the alternative: 'para buscar sin nivel usa buscar_normas o buscar_por_tema'. This is direct, actionable, and names specific sibling tools as alternatives.

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

• expedienteA
  4.5/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden and excels: it discloses the activation flag (EXPEDIENTES=1, disabled by default), memory vs. disk persistence via EXPEDIENTES_TTL_MS and EXPEDIENTES_DIR, and the exact behavior of each action (e.g., 'crear' returns the id, 'agregar' requires an already created expediente). This goes well beyond 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.

  Conciseness5/5

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

  The description is a concise, information-dense paragraph that front-loads the primary purpose, then covers configuration and action semantics in order. Every sentence contributes new behavioral information without redundancy, making it highly efficient.

  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 tool with 5 parameters, no output schema, and no annotations, the description fully covers the lifecycle (create, add, read, export), persistence behavior, activation requirements, and parameter constraints. It provides enough detail for an agent to select and invoke the tool correctly in most scenarios.

  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 baseline is 3. The description adds minor clarifications such as 'agregar' requiring an already created expediente and the markdown output for 'exportar', but it mostly reiterates schema details. Overall it adds marginal value beyond the schema.

  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 opens with 'Crea, agrega, lee o exporta un expediente para agrupar consultas, citas y observaciones de una investigación', explicitly naming the verbs and resource. This clearly distinguishes it from sibling search/retrieval tools, making the tool's purpose unambiguous.

  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?

  Clear context is provided: it is for grouping investigation-related items, requires the EXPEDIENTES=1 flag to be enabled, and supports four specific actions. No explicit alternatives are mentioned, but the tool's role as a container versus the siblings' search functions is implied, so there is clear context without exclusions.

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

• buscar_normasA
  4.6/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the burden of behavioral disclosure. It reveals a key limitation: the index covers only thematic summaries, not the full text ('indexa solo los resúmenes temáticos, NO el articulado completo'), and that terms are OR-joined. However, it does not describe the response format or pagination behavior, which could be useful.

  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?

  The description is appropriately sized, with each sentence earning its place: main purpose, critical indexing caveat, search strategy, and alternative tool references. It is front-loaded with the core function and maintains relevance throughout.

  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 tool's complexity (8 parameters, no output schema, no annotations), the description provides essential context: scope, limitations, and alternative routes. It does not explain result ordering or default behavior with zero parameters, but the schema already documents parameter constraints and defaults, so the description covers the most important non-obvious aspects.

  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?

  Schema coverage is 88%, so the baseline is 3. The description adds value beyond the schema by explaining that the search engine uses OR logic and that users should use few, distinctive words, directly guiding the 'palabras' parameter. It also points to specific alternatives for other search needs, clarifying when this tool's parameters are appropriate.

  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 clearly states the tool's purpose: 'Busca leyes, decretos, resoluciones, conceptos y sentencias del sector público colombiano.' It specifies the verb (buscar), the resource type, and the target sector, which distinguishes it from more specialized search siblings. The list of document types adds specificity beyond a generic 'search'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly provides usage guidance and alternatives: 'Para buscar dentro del texto de una norma concreta, usa obtener_documento con fuente="gestor" y buscar_en_texto. Para una cita exacta, usa resolver_cita.' It also advises how to use the tool effectively ('Usa pocas palabras y muy distintivas') based on the OR behavior.

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

• buscar_resoluciones_cregA
  4.6/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses the unique full-text access capability, the separate compilations (vigentes/derogadas), and the critical literal-signal rule ('Esa señal se traslada literal; no la conviertas en un sí o un no'). While it doesn't detail return structure or pagination, it provides substantial behavioral context beyond the baseline.

  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 three dense sentences with no filler, containing only high-value information. The use of caps for key directives (ÚSALA, NO, ÚNICA) aids scanning, though it is slightly emphatic. Every sentence earns its place, but the length is near the upper bound of conciseness.

  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?

  With no output schema, the description fully compensates by covering what the tool searches, sector scope, how to access full text (via obtener_documento), the vigencia literalness nuance, when not to use it, and alternative tools. This provides everything an agent needs to select and invoke the tool correctly.

  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?

  Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the default behavior of anio ('SIN ÉL solo se mira el año en curso, que trae muy pocas') and contextualizing compilacion with the explanation of separate compilations and literal signal transfer, exceeding the schema's basic property descriptions.

  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 clearly states 'Busca las resoluciones de la Comisión de Regulación de Energía y Gas' with a specific verb+resource, lists the sector topics (tarifas, conexión, comercialización, plantas solares, gas natural), and explicitly distinguishes from siblings by noting it is the only sectorial source and excluding laws/decrees with resolver_cita/buscar_normas.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides explicit positive guidance ('ÚSALA para la regulación energética y de gas'), explicit negative guidance ('NO sirve para leyes o decretos nacionales de otros sectores'), names alternative tools (resolver_cita, buscar_normas), and directs to obtener_documento with fuente='creg' for full text, leaving no ambiguity about when to use this tool.

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

• explicar_relacion_temaA
  4.6/5.0
  Behavior4/5

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

  Despite no annotations, the description discloses key behavioral constraints: the requirement that both IDs come from the same busqueda row, the format of temsubid with prefix, and rejection of other catalog IDs. It does not detail error handling or response format beyond mentioning the return as an extract, but the constraints add meaningful context beyond 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.

  Conciseness5/5

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

  The description is three sentences, front-loaded with the tool's purpose, followed by usage constraints and an alternative. Every sentence adds value with no redundancy or filler.

  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?

  For a simple 2-parameter tool with no output schema, the description adequately explains return value (restrictor excerpt), input requirements, and an alternative for related queries. It doesn't specify error cases, but this is not a significant gap given the focused nature of the tool.

  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?

  Schema coverage is 100%, but the description adds crucial semantics: the 'same row' relationship between normid and temsubid, and the explicit rejection of IDs from other catalogs. This goes beyond the schema's property descriptions, which only state the source and prefix.

  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 clearly states the tool's purpose: 'Devuelve el "restrictor": el extracto que explica por qué esa norma es pertinente para ESE subtema en concreto.' It uses a specific verb ('devuelve') and resource (el restrictor), and distinguishes itself from siblings by emphasizing the specific subtopic relationship and referencing buscar_por_tema for identifiers.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicit usage guidance is provided: both identifiers must come from the same row of buscar_por_tema, and ids from listar_catalogos or other catalogs are rejected. It also offers an alternative tool (obtener_documento with fuente='gestor') for seeing all restrictors, clarifying when not to use this tool.

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

• resolver_citaA
  4.6/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden and goes beyond basics: it discloses the validation mode's classification behavior and explicitly warns that it never affirms validity ('NUNCA afirma vigencia'). It also states that each citation is resolved with a link, giving a clear expectation of output; however, it doesn't address potential side effects or error behavior, but for a lookup tool this is adequate.

  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?

  The description is tight and front-loaded, using three sentences to cover purpose, usage, batch mode, and validation. Every sentence adds functional information without redundancy.

  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?

  The description covers both main modes (resolution and validation), provides examples, and includes the critical caveat about not affirming vigencia. With no output schema, it could have specified the exact return structure for the normal mode, but the phrase 'cada una con su enlace' gives a sufficient expectation for an agent.

  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?

  All four parameters are fully described in the schema (100% coverage), giving a solid baseline. The description adds extra value by explaining the batch parameter 'citas' with examples and clarifying the 'validar' mode's nuances, though it could have elaborated further on return formats.

  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 clearly identifies the tool as a fast and exact route for resolving normative citations (e.g., 'Ley 909 de 2004', 'C-337/11') and explicitly distinguishes it from the imprecise word-based search. The title 'Resolver una cita normativa' reinforces the verb-resource structure.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly instructs to use it whenever the question mentions a concrete norm ('Úsala SIEMPRE que la pregunta mencione una norma concreta') and warns against the word search, providing clear when-to-use guidance. It also explains the batch use case, covering the main alternative.

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

• buscar_jurisprudenciaA
  4.7/5.0
  Behavior5/5

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

  With no annotations provided, the description bears the full burden and does so admirably. It discloses that the relatoría is updated daily, explains the retry mechanism for long phrases (and that the response announces the nucleus), and describes the return structure including the route for obtener_documento. This goes well beyond basic safety traits.

  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?

  Every sentence earns its place: purpose, usage context, return values, a behavioral quirk, and disambiguation from siblings. The description is front-loaded with the core action and maintains a logical flow without redundancy or fluff.

  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?

  Despite having no output schema and no annotations, the description covers all necessary context: what it searches, when to use it (and when not), what it returns, how it handles long phrases, and which alternatives to use. Parameter details are fully covered by the schema, leaving no significant gaps for an agent to select and invoke the tool.

  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 baseline is 3. The main description does not add parameter-level detail beyond the schema; the note about long phrases relates to the 'termino' parameter but is more about behavioral quirk than parameter semantics. The schema already thoroughly documents all five parameters.

  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 clearly states the tool's verb and resource: 'Busca sentencias y autos en la relatoría de la Corte Constitucional'. It also differentiates from sibling tools by explicitly naming alternatives for other courts (Suprema, Consejo de Estado) and providing specific output fields, making 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.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says when to use it ('la herramienta indicada para jurisprudencia constitucional reciente'), notes that the Gestor Normativo has very little, and names exact alternative tools for other courts. It also advises on handling long search phrases, providing clear guidance on both usage and alternatives.

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

• buscar_jurisprudencia_supremaA
  4.7/5.0
  Behavior5/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 so richly. It discloses full-text search, no stop-word removal, exact-phrase default, example result counts, and that results include cited norms plus a route for full-text retrieval.

  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?

  The description is dense but every sentence earns its place: it front-loads purpose and differentiation, then adds workflow integration and search behavior. It is long but not wasteful, with clear structure and no redundancy.

  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?

  Despite lacking annotations and an output schema, the description covers output contents (cited norms, route), integration with sibling tools, and search quirks. This is sufficient for an agent to invoke the tool correctly and handle results across a multi-step workflow.

  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?

  The schema already provides 100% coverage with detailed descriptions for all 7 parameters, including exacto's OR behavior and sala's requirement. The description adds search-behavior context but does not materially improve parameter-level meaning beyond the schema.

  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 clearly states the tool searches Supreme Court rulings by chamber (Tutelas, Civil, Laboral, Penal) since 1991. It uses a specific verb ('Busca') and resource, and explicitly distinguishes it from buscar_jurisprudencia, which targets the Constitutional Court.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly contrasts with a sibling tool by naming it and clarifying that the two courts are different. It also provides chaining guidance: cited norms can be resolved with resolver_cita and full text via obtener_documento with fuente="suprema". It advises using distinctive terms and notes the exact-phrase default.

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

• listar_catalogosA
  4.7/5.0
  Behavior5/5

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

  Since no annotations are provided, the description carries the full behavioral disclosure burden. It discloses the volume constraint on 'temas', the id prefix convention ('tema-24457') due to taxonomy reuse, and the subtle trap that DIAN's absence from the entity catalog does not mean DIAN regulations do not exist. These are non-obvious behaviors beyond what the schema reveals.

  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 a single dense paragraph, but every sentence contributes value—from listing catalog types and counts to explaining special cases and scope limitations. It is appropriately sized for the complexity, though it could benefit from bullet points to improve skimmability. It is front-loaded with the main purpose before diving into cautions.

  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 absence of an output schema, the description covers essential context such as scope limitations, required 'filtro' for 'temas', and the prefix convention. It does not explicitly describe the return format or pagination behavior, but the schema already defines 'limite' and 'desde' with defaults. The description is complete enough for a catalog-listing tool.

  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 description adds significant meaning to the 'catalogo' parameter by explaining all seven enum values and their specific purposes. It also clarifies that 'tema_id' is used with 'subtemas' and 'numero'/'anio' with 'conceptos_fp'. However, it does not elaborate on 'desde' and 'limite' (pagination parameters), which are already documented in the schema with defaults, so the description compensates well for the 57% schema coverage.

  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 clearly states that the tool lists valid catalog values for buscar_normas filters (document types, years, entities, themes) and also supports special catalogs for subtopics, concepts, and DAFP norms. It goes beyond the title by naming the specific resource and filter context, and differentiates from siblings by explicitly limiting its scope to the Gestor Normativo de Función Pública.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit usage guidance: it says these catalogs are ONLY for buscar_normas and do NOT cover DIAN (suggesting buscar_normativa_tributaria as an alternative), SUIN-Juriscol, or the high courts. It also explains that the 'temas' filter is obligatory due to volume and instructs how to use subtemas and conceptos_fp with specific parameters. This is clear when-to-use and when-not-to-use guidance.

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

• obtener_documentoA
  4.8/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden. It discloses that the text is never returned whole ('nunca entero'), respects a character limit with a specific range (200–40.000, default 8000), and reports 'total/mostrado/omitido'. It also explains disk-writing behaviors for entero and ruta_destino, including that ruta_destino downloads without returning the text—highly transparent for a tool with 17 parameters.

  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 a single dense paragraph, but each sentence carries essential information about sources, modes, limits, or alternatives. It is not overly verbose given the complexity of the tool, though breaking it into bullets would improve scanability. No filler words are present.

  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?

  Given the tool's complexity (17 parameters, no annotations, no output schema), the description covers all critical aspects: source enumeration, parameter requirements, chunking behavior, character limits, summary reporting, disk-writing options, and sibling alternatives. It even clarifies subtle behaviors like ruta_destino not returning text, filling the gaps left by the missing annotations and output schema.

  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?

  Schema coverage is high (94%), so the baseline is 3. The description adds value by mapping each source to its required parameters (e.g., 'suprema' requires ruta + sala, 'consejo' uses token) and explaining the relationship between entero/ruta_destino and the returned text. While some parameter details are repeated, the cross-parameter context is genuinely helpful, justifying a 4.

  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 opens with a specific action: 'Devuelve el texto (troceado, nunca entero) de un documento' and then enumerates the seven sources with their exact parameters (e.g., 'gestor' by id, 'corte' by ruta o cita). It also names alternatives like buscar_en_texto, articulo/seccion, and historial, which distinguishes this tool from siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly provides usage guidance: 'Usa buscar_en_texto para encontrar un término dentro del documento, articulo/seccion para una parte puntual, o historial (solo gestor) para los cambios anotados.' It also clarifies when to use entero=true and ruta_destino, giving clear context for when each option is appropriate.

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

• buscar_en_suinA
  4.9/5.0
  Behavior5/5

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

  Without annotations, the description discloses critical behavioral traits: it does not search article text, its vigencia field is unreliable and contradicts the document's own record, its index has gaps (Teletrabajo example), and long phrases match loosely. This far exceeds baseline.

  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?

  Every sentence provides essential either what the tool does or its limitations and alternatives. The use of caps for critical warnings aids parsing, and it remains focused despite its length.

  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?

  Given the tool's complexity and the absence of an output schema, the description covers scope, exclusions, reliability caveats, index gaps, and fallback tools, making it sufficient for an agent to select and invoke it correctly.

  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 description clarifies that 'texto' covers title, epigraph, subject, or issuing entity, and warns that the 'vigencia' filter/field is based on the buscador and unreliable. Since the schema already describes most parameters (80% coverage), the description adds meaningful context but doesn't need to explain every parameter.

  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 clearly specifies the tool searches SUIN-Juriscol documents by title, epigraph, subject, or issuing entity, and distinguishes it from resolver_cita by stating it is not for exact citations. It also notes its coverage of documents not in Gestor Normativo, differentiating from sibling search tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly states when not to use: for exact citations ('LEY 909 DE 2004' returns nothing) and points to resolver_cita. Also advises trying buscar_por_tema or resolver_cita when a subject search doesn't yield expected results, providing clear alternatives.

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

• buscar_normativa_anhA
  4.9/5.0
  Behavior5/5

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

  No annotations are provided, so the description carries full burden for behavioral disclosure. It clearly discloses that the tool does not return full text (only epígrafe and links to PDF/detail page), that personal acts are hidden by default (two out of three documents), and that there are 785 documents, setting clear expectations about output and scope.

  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?

  The description is dense and information-rich with every sentence earning its place: purpose, scope, output limitation, exclusions, sibling alternatives, and a critical default-behavior warning. The use of SHOUTED keywords ('ÚSALA', 'NO', 'OCULTA') makes key guidance scannable without adding unnecessary bulk.

  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?

  Despite having no output schema and no annotations, the description covers all essential context: document type scope, topical scope, document count, return format (epígrafe + links, not text), navigation to alternatives for out-of-scope queries, and the critical default filter behavior. The 7-parameter schema is well-complemented by the description's behavioral context, making the tool safely invocable by an agent.

  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 schema already covers 86% of parameters with descriptions, but the description adds crucial semantic context beyond the schema: it explains the meaning of incluir_administrativos (nombramientos y encargos) and why it matters statistically, and clarifies that pagination means 20 items per page with 40 total pages. This supplements the schema meaningfully without redundancy.

  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 clearly identifies the tool as searching ANH resolutions, agreements, and circulars related to hydrocarbons, listing specific topics and document count. It distinguishes itself from siblings by explicitly stating it is for hydrocarbon and royalty regulation, not for national laws/decrees of any sector, and names alternatives (resolver_cita, buscar_normas).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit when-to-use (hydrocarbon regulation and royalties) and when-not-to-use (not for national laws/decrees, not for other sectors) guidance, naming specific alternative tools. Also gives critical usage detail about personal acts being hidden by default and how to include them, which is essential for correct tool selection and invocation.

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

• buscar_normativa_tributariaA
  4.9/5.0
  Behavior5/5

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

  Without annotations, the description carries the full burden, and it does well. It discloses the return format ("Devuelve el extracto... y el enlace al texto completo"), the performance behavior ("la primera búsqueda de cada término tarda ~20 s"), and the pagination quirk ("las páginas siguientes del MISMO término son instantáneas"). These are critical behavioral details not otherwise available.

  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?

  The description is well-structured and front-loaded. It starts with the core purpose, then differentiation, return value, follow-up tool, and a performance warning. Every sentence earns its place, and the AVISO is long but necessary.

  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?

  Given the lack of output schema and the tool's complexity (search with pagination and performance quirks), the description covers the essential information: what it searches, what it returns, how to read the document, and how to paginate efficiently. It also explains the unusual 20-second first-query delay, which is crucial for agent planning.

  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 schema already covers 67% of parameters with descriptions (texto and desde), and the description adds meaningful context for "desde" by explaining its role in pagination: "pagina con desde en vez de lanzar búsquedas nuevas." The description does not elaborate on "limite," but the schema provides default, minimum, and maximum values, so the marginal gap is small.

  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 clearly states what the tool does: "Busca en el normograma de la DIAN: decretos, resoluciones, conceptos y circulares en materia tributaria, aduanera y cambiaria." It uses a specific verb (Busca) and a specific resource (normograma DIAN), and explicitly differentiates it from siblings with "Es lo que ninguna otra herramienta de este MCP cubre."

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description tells the agent when to use this tool: when searching for DIAN tax/customs/exchange regulations, and it explicitly names the alternative for reading full documents: "Para leer el documento usa obtener_documento con fuente=\"dian\"." It also provides usage guidance for pagination, advising to use "desde" instead of launching new searches.

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

• buscar_normativa_sectorialA
  5/5.0
  Behavior5/5

  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 thoroughly documents limitations: PDFs may lack extractable text, validity status is often not published, and filters behave differently per source (e.g., Invima rejects empty queries, ANM doesn't apply year to circulars). This is far beyond typical descriptions.

  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?

  Though lengthy, the description is well-structured with clear sections: core purpose, when-not-to-use, PDF/validity caveats, and filter behavior. Every sentence provides actionable information, and the use of bold headers ('CUÁNDO NO USARLA') aids scannability. No filler or repetition exists.

  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?

  Given the complexity of 13 sources with varying behaviors and no output schema, the description is exceptionally complete. It explains what each response will declare (which filter behavior occurred), warns about PDF text extraction, and clarifies that validity status is not independently verified. This equips the agent to handle edge cases effectively.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers 67% of parameters, but the description adds substantial meaning: it explains that filter behavior is inconsistent across entities, gives concrete examples (Superfinanciera stays in current year, etc.), and advises to explicitly specify year when expected. This compensates for any schema gaps and enriches parameter understanding.

  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 clearly states that the tool searches administrative acts (resoluciones, circulares, acuerdos) from sectoral regulators and ministries that the normative manager does NOT catalog. It explicitly distinguishes from sibling tools like resolver_cita and buscar_por_tema, making the unique scope unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The 'CUÁNDO NO USARLA' section explicitly tells when not to use this tool and names alternatives (resolver_cita, buscar_por_tema), including the specific case of Decretos Únicos Reglamentarios. It also provides per-portal filter behavior guidance, giving clear context for when and how to use parameter combinations.

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

• describir_fuentesA
  5/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden and does so well: it discloses no network access, that indices are packaged, that the full table is long, and that the parameter returns only one source's scope. This gives the agent a clear mental model of the tool's behavior.

  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?

  The description is compact and front-loaded: first sentence gives the core purpose, second adds usage timing, third clarifies parameter behavior. Every clause earns its place; no redundancy.

  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 simple single-parameter tool with no output schema and no annotations, this description is complete. It covers purpose, when to use, network behavior, parameter effects, and output size expectations, making it self-sufficient for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Although the schema already documents the 'fuente' parameter at 100% coverage, the description adds meaning: with the parameter it returns ONLY that source's scope (which 'usually is what's needed'), without it the full table is long. This advises on parameter choice and output size beyond the schema.

  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 the tool declares the real scope: which source answers each question, what is not covered, and the generation date of packaged indices. This specific verb-resource pair (declara alcance) clearly distinguishes it from sibling search tools by being a metadata/inventory tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicit usage instructions: use it BEFORE concluding something doesn't exist from an empty search and to check if the index freshness is current. It also states 'No consulta la red' as an exclusion, clarifying it is not for live lookups among the sibling search tools.

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