juris-sedetc-mcp

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

With no annotations, the description carries the full behavioral burden and delivers: accent/tilde stripping so unmatched accents are explained, cross-inventory dedup of repeated documents surfaced in 'nota', block ordering (current index first, then historical), a 1000-page cap, and variable page size of up to 20 rows. These are non-obvious traits an agent could not infer from schema or annotations.

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

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

It is long and dense, but front-loaded with purpose and then cleanly partitioned into Args and Devuelve sections, so every part earns its place. Slight verbosity in the return-value paragraph keeps it from a 5.

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

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

For a tool merging two heterogeneous sources with an output schema present, the definition covers query syntax, pagination limits, dedup semantics, row ordering, and how to chain into detalle_sentencia. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: 'search' explains multi-word behavior and the '*' wildcard, 'page' explains 1-based indexing and the 1000-page cap, and 'modo' supplies the effective enum ('todas'|'algunas'|'frase') that the schema's untyped anyOf string omits. This fully compensates for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb (Busca) and a precisely scoped resource: full text of ALL Tribunal Constitucional resolutions, explicitly clarifying that it merges the current systematization index and the historical inventory. It routes the agent away from the sibling busqueda_avanzada, so it is distinguishable without opening any schema.

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

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

It gives concrete fallback conditions: 'Con total 0 prueba otra palabra clave o pasa a busqueda_avanzada' and points to detalle_sentencia for full records when a 'slug' is present. Alternatives are named with conditions, though the other siblings (resultados_sistematizacion, resultados_tesauro, listar_*) are not contrasted.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses that the server strips accents, that the historic inventory can only be queried by text when 'search' is present (its engine rejects other text combinations), that an EXACT fecha_publicacion is silently degraded to the whole year (with the range workaround), that the historic inventory caps at 1000 pages, and that duplicate rows are dropped with a 'nota'. These are exactly the non-obvious traits an agent needs.

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

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

Front-loaded with a two-sentence summary of scope and inventory-merging before the parameter list, and the Args section is dense but well organized. The main cost is the lengthy 'Devuelve' block spelling out the return payload, which duplicates information already carried by the output schema and could be trimmed.

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

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

For a 13-parameter merge tool with zero annotation and zero schema-description coverage, the description supplies everything an agent needs: filter applicability per inventory, format rules, catalog references, pagination limits, dedup behavior, and response shape. Nothing material for correct invocation is missing.

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

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

Schema description coverage is 0%, so the description must compensate for all 13 parameters, and it does: every argument gets format, example, catalog source, and applicability scope (e.g. '00148-2026-HC' for expediente, comma ranges for fecha_publicacion, exact names for demandante/demandado, 'todas'|'algunas'|'frase' for modo, 1-based page). This meaning is entirely absent from the schema and is fully supplied here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: an AVANZADA search of the TC that merges the two inventories into a single unified view, with filters applying to both when equivalents exist. The scope is concrete and an agent can picture the operation. It does not distinguish itself from near-siblings such as buscar_sentencias, so it stops short of a 5.

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

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

The description explains in detail which filters apply to which inventory (both when equivalent, sistematizacion-only when advanced) and notes that 'proceso' is ignored when 'search' is present, which is genuine conditional guidance. However, it never states when to choose this tool over the sibling tools (buscar_sentencias, resultados_sistematizacion, etc.); it only routes to the catalog helpers listar_filtros and listar_palabras for id values. Tool-selection guidance is implied rather than explicit.

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

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

No annotations are provided, so the description carries the burden. It usefully discloses that 'fundamentos' are returned complete and never truncated and that a PDF URL is included, which is genuine behavioral context for a read tool. However it says nothing about auth requirements, rate limits, error cases, or what happens on an invalid slug.

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

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

Front-loaded with the core purpose, then an Args/Devuelve block that mirrors the actual interface. It is reasonably tight, with minor redundancy from the repeated uppercase 'COMPLETOS'/'COMPLETA' emphasis, but nothing is wasted enough to hurt the score.

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

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

For a single-parameter read tool the definition covers what it does, what the one argument means, and the shape of the response (including that an output schema also exists). Missing only auth/error context and sibling routing, so it is nearly complete for its complexity.

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

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

Schema description coverage is 0%, so the description must compensate and largely does: it explains that 'slug' comes from the row entries of 'los buses' and gives a concrete example ('00148-2026-hc-1440-2026') that makes the expected format inferable. The origin phrase 'filas de los buses' remains vague, keeping it short of a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: retrieving the 'FICHA COMPLETA' of a TC sentencia/auto/interlocutoria by slug, and enumerates the fields it returns. It is clearly a detail-fetch tool, distinguishable in nature from the sibling search/list tools, though it never names them explicitly.

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

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

Usage is only implied: the emphasis on 'COMPLETA ... NUNCA truncada' hints this is the full-detail counterpart to the search results, but there is no explicit 'use after buscar_sentencias' statement, no prerequisites, and no named alternative. Adequate but leaves the agent to infer the workflow.

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

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

With no annotations, the description carries the full burden and largely meets it: it discloses local pagination (100 values/page), the 1..3 'paginas' cap with a 'nota' truncation flag, and that the full 'sentidos' response is ~86 KB and may be client-truncated. It stops short of stating read-only/auth expectations, but the behavioral surface is well covered.

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

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

Front-loaded with the catalog list and counts, then Args, then returns; every sentence carries operational detail. It is dense and somewhat long, but no clear filler remains.

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

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

Despite an output schema existing, the description adds the exact return shape (id/nombre/slug/search_elastic), the pagination cursor fields, and the truncation 'nota'. Combined with the parameter constraints, nothing an agent needs to call and chain this into busqueda_avanzada is missing.

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

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

Schema coverage is 0% and no enums exist, so the description must compensate fully — and it does, defining 'categoria' values, 'page' as 1-based at 100 values/page with detail-only applicability, and 'paginas' bounded at 1..3 with its overflow behavior. Every parameter is semantically documented beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb+resource ('Catálogo EXACTO para busqueda_avanzada') and enumerates exactly which catalogs it returns, with record counts for each. An agent can immediately distinguish it from sibling busqueda_avanzada, which consumes these ids rather than producing them.

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

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

It states the downstream consumer explicitly ('los id alimentan busqueda_avanzada') and distinguishes 'todos' (counts only) from detail categories. It does not, however, contrast usage against other sibling listar_* tools such as listar_tesauro or listar_palabras, so routing among those is left to inference.

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

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

With no annotations, the description carries the full behavioral burden and does well: it discloses that filtering is LOCAL (backend doesn't filter), that comparison is case-insensitive and accent-insensitive, the 100-per-page size, and the 1..3 consecutive-pages cap with a 'nota' on truncation. It omits any permission/auth context, but for a read-only catalog this is minor.

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

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

Front-loaded with the purpose, then cleanly separated into Args and Devuelve sections, so an agent can scan to the parameter it needs. It is information-dense rather than padded, though 'filtrado LOCAL' is repeated and the return-block detail is somewhat redundant given an output schema exists.

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

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

Covers the essentials for a 4-param, 0%-coverage tool: filtering semantics, pagination limits, truncation behavior, and the id-based chaining into busqueda_avanzada. Because an output schema exists, the Devuelve block is a bonus rather than a necessity; the definition is complete enough to invoke correctly.

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

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

Schema coverage is 0%, so the description must compensate, and it fully does: all four parameters are documented with meaning beyond the schema — letra as initial letter with example, contiene as a substring with accent/case rules, page as the page of the FILTERED result, and paginas as consecutive pages in one call with a 1..3 bound. This is exactly what a 0%-coverage schema needs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource ('Catalogo de PALABRAS CLAVES del TC') with a concrete scale (29 603 exactas) and the operations (local filtering by initial letter or content). An agent immediately knows this returns a keyword catalog. It doesn't explicitly contrast itself with sibling listers like listar_tesauro or listar_filtros, though the downstream reference to busqueda_avanzada clarifies its role.

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

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

Gives clear downstream context: 'Usa los id en busqueda_avanzada(palabras=1,3)', which tells the agent exactly why and how to consume the output. It also warns that filtering is LOCAL and the backend does not filter, which shapes invocation. It lacks explicit when-not-to-use or sibling-alternative guidance.

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

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

No annotations are provided, so the description carries the full disclosure burden. It does convey that the tree is COMPLETE (no pagination or filtering implied) and sketches the return shape, which is useful, but it says nothing about auth, rate limits, or why the tree is static/cacheable. An output schema already exists, so the return-value sketch earns only partial credit.

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

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

Purpose and the cross-tool routing are front-loaded in the first sentence, with the return block last. The 'Devuelve:' block is largely redundant given an output schema exists, costing a little efficiency but not enough to break the structure.

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

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

For a zero-parameter, read-only listing whose output schema already documents the response, the description supplies what is missing: how many branches exist, how children are organized, and how the ids feed the sibling tool. Nothing essential for correct invocation is absent.

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

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

The tool takes zero parameters, which is the baseline-4 case. The description introduces id concepts ('1', '268') but these belong to resultados_sistematizacion, not to this tool's inputs, so no additional parameter meaning is needed or expected.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: returns the COMPLETE taxonomy tree of the TC's systematization, with 6 thematic branches and type/node children. This clearly separates it from siblings like resultados_sistematizacion (which returns results) and listar_tesauro/listar_filtros (other taxonomies).

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

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

Explicitly routes the agent to a sibling workflow: 'Usa los "id" en resultados_sistematizacion', telling the agent the ids produced here are consumed there, and with concrete examples ('1' = Precedentes vinculantes, '268' = Habeas corpus). No exclusions versus listar_tesauro/listar_filtros are given, so it stops short of a full 5.

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

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 richly: it warns about context-limit navigation, explains that count_subarbol is an accumulated subtree total distinct from resultados_tesauro's direct count, and flags upstream 'code' inconsistency with an explicit instruction to navigate by 'id'. It also mentions the 'nota' field emitted when a node has no children.

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

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

Front-loaded with the core navigable-tree concept, then Args and Devuelve sections. Every sentence earns its place given the complexity, but the formatting is chatty and somewhat verbose for an agent-facing definition.

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

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

Although an output schema exists, the description still clarifies the return shape and the non-obvious count semantics and code-vs-id trap. For a navigation tool with subtle footguns, nothing an agent needs in order to call it correctly is missing.

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

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

Schema description coverage is 0%, so the description must compensate, and it fully does: it documents each of the three params (tipo values 'sentencias'/'autos'/'interlocutorias', parent_id as prior-node id or null for roots, depth range 1..4 with default 1 and a local cap). This adds authoritative syntax and defaults beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: it navigates/lists the concept tree ('Arbol de conceptos del TESAURO del TC NAVEGABLE'), and clarifies the two modes (roots without parent_id vs subtree with it). It even distinguishes itself from the sibling resultados_tesauro by contrasting their count semantics, so an agent can tell the two apart without opening schemas.

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

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

Gives clear usage context: must be navigated rather than fetched whole ('NUNCA se entrega de un bote'), omit parent_id for roots, pass a parent_id from a prior response for subtrees, and use depth for levels. It does not enumerate explicit when-not-to-use conditions or name the alternative tools by name, which keeps it 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.

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

With no annotations, the description carries the full burden. It does disclose useful behavior: the server strips accents from 'search', and the response carries a global 'index' plus 'slug' for detalle_sentencia. It never states that this is a read-only query, nor does it describe pagination mechanics beyond the field names.

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

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

Front-loaded summary followed by an explicit Args/Devuelve split, which makes it easy to scan. The Devuelve section overlaps with the output schema, so a little of it is redundant, but nothing is padded.

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

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

Four parameters are all documented, the id source is named, and return fields are pointed at even though an output schema already exists. An agent has enough to call the tool correctly; the remaining gap is the absence of any statement about read-only safety and how the two text filters combine.

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

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

Schema description coverage is 0%, so the description has to compensate and largely does: it explains comma-separated id syntax with concrete examples ('268' = Habeas corpus, '1' = Precedentes vinculantes, '268,269'), clarifies that 'search' filters within the sistematizacion, gives an expediente example, and notes page is 1-based. Only the interaction between 'search' and 'numero_expediente' is left unstated.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific resource and view ('la vista sistematizacion del portal del TC') and enumerates what the results contain (precedentes vinculantes, tipos de proceso, sub-categorias del arbol). It also points at the sibling that supplies the ids, so an agent can distinguish it from listar_sistematizaciones, though it never contrasts itself against the parallel sibling resultados_tesauro.

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

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

States the prerequisite that exact ids come from listar_sistematizaciones, which is genuine routing guidance, but gives no when-to-use vs resultados_tesauro/busqueda_avanzada and no exclusions or fallback behavior. Usage is implied rather than stated.

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

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

With no annotations, the description carries the full burden and does disclose a genuine behavioral subtlety: 'total' counts only documents assigned directly to the node, whereas listar_tesauro's 'count_subarbol' is the accumulated subtree count (with a concrete example, raiz 63493 vs 7). Auth, rate limits, and empty-result behavior are not covered, but the most misleading counterintuitive trait is surfaced.

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

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

The Args/Devuelve blocks are structured and front-loaded, but the 'Devuelve' line largely restates an output schema that already exists, and the note about total vs count_subarbol is buried after the field list. It is longer than it needs to be, with some duplication of structured data.

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

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

For a 3-parameter query tool with an existing output schema and no annotations, the description covers purpose, id sourcing, exact parameter values, and the count-discrepancy caveat. The return-shape restatement is redundant given the output schema, but no decision-relevant information is missing.

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

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

Schema description coverage is 0% and the schema has no enums or defaults documented beyond raw values, so the description must compensate — and it does: 'tesaurios' is comma-separated ids from the chosen tree with examples ('4', '1,2'), 'tipo' enumerates the exact accepted strings and its default, and 'page' is 1-based. Nothing needed to call the tool is left implicit.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: returns documents/results by TESAURO concept node of the TC, accumulated by 'count' per node. It also anchors its identity by stating the ids come from the tree returned by sibling listar_tesauro, so an agent can distinguish it from buscar_sentencias or resultados_sistematizacion without opening any schema.

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

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

It names the prerequisite source of the 'tesaurios' ids (el arbol de listar_tesauro) and pins the exact accepted values for 'tipo'. It doesn't state when-not to use it versus busqueda_avanzada or buscar_sentencias, but the routing 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.