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

With no annotations, the description carries the full burden. It does add real behavioral context: the default sort ('ordena por fecha DESC'), 10 rows per page, and a 1..6 limit on consecutive pages. It says nothing about permissions, rate limits, or failure behavior, which an unannotated mutation-adjacent fetch tool should ideally cover.

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-loads the purpose before the Args/Devuelve blocks, and each documented argument and the return dict earn their place given the 0% schema coverage. It is dense but not 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?

No output schema exists, so the description supplies the return shape ({'ok','ses','modo','total','paginas','pagina','tamano_pagina','filas'}) and notes that sumilla is COMPLETA relative to buscar_resoluciones. Combined with full parameter documentation, an agent has enough to invoke and read results 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 description coverage is 0%, so the description must compensate entirely, and it does: every one of the 9 parameters is documented, including the anio catalog ('2026'..'1998' or '1982'), the exact-word requirement with a cross-reference to buscar_palabras_clave, and the full set of 'orden' values with their default.

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 ('Busca resoluciones de ANULACION y EJECUCION DE LAUDOS ARBITRALES') and ties it to the 'Comerciales' searcher, which is more precise than the bare name. It hints at differentiation via 'la sesion es del buscador de laudos' but never explicitly tells the agent why to pick this over the sibling buscar_resoluciones.

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 implied through mechanism rather than stated: 'ses' is described as the session for the next page, and palabra_clave points to buscar_palabras_clave for obtaining the exact keyword. There is no explicit when-to-use/when-not guidance or named alternative against which this tool competes.

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 the return shape ({'ok','q','sugerencias','nota'}) and the cap of up to 50 suggestions. It doesn't discuss failure modes or rate limits, but for a read-only suggestion endpoint there is little behavioral surface to disclose.

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 definition is front-loaded with purpose and integration, then Args and Returns blocks. Every element is relevant, and since no output schema exists, documenting the return dict earns its place rather than being redundant.

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, no-annotation, no-output-schema tool, the description covers purpose, usage in the broader search workflow, the parameter contract, and the return shape. It is nearly self-sufficient; only edge behaviors (empty results, error note semantics) are left unstated.

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 for the single parameter, and it does: it defines q as initial text, specifies the 1+ character minimum, and gives concrete examples ('indemnizacion', 'reivindicacion'). This adds real meaning beyond the bare 'Q: string' in the 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 the specific resource (keyword autocomplete suggestions) and states the scope of what it returns. It distinguishes itself by naming the sibling tools (buscar_resoluciones, buscar_laudos) whose keyword values it feeds, though the operating verb is implicit rather than a clean verb+resource phrasing.

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 clearly explains the workflow context: the exact returned values are used as 'palabra_clave' in buscar_resoluciones and buscar_laudos, which tells the agent to call this before those searches. It lacks an explicit when-not-to-use clause, but the integration guidance is unambiguous.

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 reasonably well: it discloses the result cap (hasta 50 sugerencias), the return object shape, and the scope limitation (solo Corte Suprema). It does not document the 'nota' field or error behavior, but for a read-only lookup this is solid disclosure.

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 description is organized into a purpose line followed by explicit Args/Devuelve sections, with the key constraint front-loaded. It is dense but every sentence carries information; no filler.

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 autocomplete with no output schema and no annotations, the definition covers input constraints, output shape, result limits, and the downstream use case. The only minor gap is the undocumented 'nota' return field, which is not critical to correct invocation.

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: it defines q as an initial text with a minimum of 1 character and gives three concrete examples ('prescripcion', 'indemnizacion', 'pension'). This adds real semantics beyond the bare 'string' type, though it does not specify normalization or partial-match rules.

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 states a specific resource and function: autocomplete suggestions over the systematized inventory of 'Pretension/Delito' values. It also names the sibling it feeds (buscar_resoluciones), so an agent can distinguish its role from other buscar_* tools. Slightly indirect phrasing ('Sugerencias del AUTOCOMPLETE') keeps it from 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?

It conveys the core usage pattern: the EXACT returned values are used as the 'pretension' filter in buscar_resoluciones. This effectively tells the agent when this tool is useful (to obtain valid filter values) and which sibling consumes them. It stops short of an explicit when-not statement or an alternative for non-Corte-Suprema searches.

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 delivers: implicit AND intersection for multi-word text, text-only reproduces the home search while filters refine it, index is global and continuous across pages, 10 rows per page, paginas 1..6 costing ~8-12s each with a 'nota' when truncated, and detailed ses reuse semantics including new-id declaration when an unknown ses is passed with filters.

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 purpose is front-loaded in the first line and the Args block is a disciplined one-item-per-parameter list with no filler. It is necessarily long for 19 parameters plus session/pagination behavior, though a few parentheticals (default, note) are repeated more than needed.

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?

No output schema exists, so the description must describe the return payload, and it does in detail: ok/ses/modo/total/paginas/pagina/tamano_pagina/siguiente_pagina plus the per-row fields, including the site quirk that especialidad/organo and sala_suprema/norma_derecho_interno are mutually exclusive representations of the same concept. Nothing an agent needs to call and consume this tool 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%, so the description must document all 19 parameters, and it does: it gives meaning, format and examples for texto, nivel, distrito, especialidad, sala, pretension, palabra_clave, expediente, tipo_recurso, tipo_resolucion, anio, ncpp, nlpt, autos, orden, forma, pagina, paginas and ses, including which helper tool supplies valid values.

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 (buscar RESOLUCIONES en la Jurisprudencia Nacional Sistematizada del PJ) and further scopes it to the content of casaciones, apelaciones, ejecutorias, autos, etc. It names related helpers (ficha_resolucion, listar_filtros, listar_salas) so an agent can position this tool among its siblings 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 rich conditional guidance: filters only make sense with a level, distrito only applies with nivel='Corte Superior', sala requires distrito, pretension is Corte Suprema-only, ncpp/nlpt require specific especialidades, and it points to listar_filtros/buscar_pretensiones/buscar_palabras_clave for valid values. It never explicitly contrasts the tool against top-level alternatives like buscar_laudos or fichas_resoluciones, so a 4 rather than 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 and does well: it discloses the return payload keys, that output is base64 to be decoded and saved as .xls, and importantly the cap behavior (ok:false with size and a reduction hint, NEVER truncating the file). It omits auth/permission needs and rate limits, but error and output semantics are unusually 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-loads the purpose, then cleanly separates Args and Devuelve. The return-value block is dense but earns its place given no output schema exists; no filler sentences.

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 one-parameter tool with no output schema and no annotations, the description supplies purpose, parameter provenance, return shape, and error/cap behavior. Nothing essential to calling 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 by defining 'ses' as the session returned by buscar_resoluciones or buscar_laudos. That tells the agent where the required value comes from, which is the key semantic gap the bare string schema leaves open.

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 ('Exporta la BUSQUEDA ACTUAL de la sesion a EXCEL (XLS) en base64') and anchors it to the site's 'Exportar' button. This clearly distinguishes it from the search/list siblings (buscar_resoluciones, listar_salas, etc.), which are all read/query tools rather than exporters.

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 establishes usage context by noting it exports the CURRENT session search and that 'ses' comes from buscar_resoluciones or buscar_laudos, which routes the agent to run a search first. It stops short of explicit when-not-to-use guidance or naming alternatives, but for a single export tool the context is clear.

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 it does disclose meaningful behavior: the return dict shape, the 'ok'/'nota' fields, the edge case where a row exposes no PDF, and that some fields are site-dependent alternatives (especialidad?/organo_jurisdiccional? or sala_suprema?). It stops short of stating read-only semantics or error behavior explicitly.

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-loads the purpose and then uses clearly labeled Args and Devuelve (returns) sections. It is dense and the return enumeration is long, but the structure is organized and every element carries information.

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?

With no output schema, the description thoroughly explains the returned dict, including the 'nota' case and alternative field sets, and documents both parameters. For a simple 2-param read tool, an agent has enough to invoke it and interpret the result 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 description coverage is 0%, so the description must compensate, and it does: 'ses' is defined as the session returned by the search tools, and 'index' is defined as the global 0-based row index from the search results. This adds real meaning beyond the bare schema types.

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: it returns the complete FICHA/RESUMEN of a resolution looked up by 'index', and enumerates the fields that come back. It distinguishes itself from the search siblings by naming buscar_resoluciones/buscar_laudos as the source of 'ses', though it does not explicitly differentiate itself from fichas_resoluciones (plural).

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 implied rather than stated: by describing 'ses' as coming from buscar_resoluciones or buscar_laudos and 'index' as the row index from those searches, it outlines the intended two-step workflow. However, it gives no explicit when-to-use vs the sibling fichas_resoluciones and no exclusions or preconditions.

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. It usefully discloses the cap of 50, duplicate handling, and that failed indices are returned in 'faltas' with reasons, but it omits safety traits such as read-only nature or session prerequisites.

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 description is compact and well-structured with Args and Devuelve sections, front-loading the batch purpose and return shape. It is appropriately sized for a two-parameter tool with no wasted sentences.

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?

Given no output schema and no annotations, the description supplies the return structure, failure handling, cap, and parameter meanings. It could be more complete by explicitly stating that 'ses' and valid indices come from a prior search call, but the essentials are present.

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. It defines both parameters: 'ses' as the search session and 'indices' as a list of global indices with an example and a note that duplicates are processed once, adding meaningful semantics 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 clearly states it retrieves a batch of records/summaries from the same search in one call, with a cap and deduplication note. It is specific about the resource and scope, though it does not explicitly name sibling tools like ficha_resolucion to sharpen differentiation.

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 context that all indices must come from the same search and that this is a batch operation with a 50-item cap. However, it does not state when to prefer this over ficha_resolucion for a single record or buscar_resoluciones for searching, leaving alternatives implicit.

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 real behavior: exact-match semantics with the 'Penal' vs 'Familia Penal' example, the district-dependency of certain catalogs, and the 'Todos'/'0' no-filter equivalence. It also sketches the return shape, but omits auth/permission needs or rate-limit behavior.

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 cleanly sectioned into Args and Devuelve. The only waste is that the category list appears twice (first sentence and Args block), a minor redundancy rather than a structural flaw.

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-only catalog tool with no output schema, the description supplies the return shape, the consumer tools, and the key caveats. It stops short of documenting the full output fields (indicated only by '...'), but an agent can invoke it correctly from what is given.

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 the single parameter has no enum in the schema, so the description must compensate. The Args block enumerates the valid categoria values ('todos', 'nivel', 'distritos', 'especialidades', 'tipos_recurso', 'tipos_resolucion', 'anios', 'orden') and explains 'todos' as the summary mode, which is exactly the missing information.

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 states a concrete resource (the exact catalog values behind the search filters: nivel, distritos, especialidades, tipos_recurso, tipos_resolucion, anios, orden) and its role as supplier of inputs to buscar_resoluciones and buscar_laudos. That explicitly separates it from the sibling search tools, which consume rather than produce these values.

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 tells the agent the values 'alimentan los filtros de buscar_resoluciones y buscar_laudos', and adds a conditional caveat that in Corte Superior specialties/salas depend on the district (pointing to listar_salas) and that 'Todos'/'0' means no filter. Clear context for when to call it, though it never states a when-not-to-use case.

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 burden and does well: it discloses caching behavior (~15s first call, 30 min cache) and the return shape. It omits auth/permission requirements and error behavior, but the cache disclosure is meaningful 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.

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

Front-loads the main purpose, then uses Args/Devuelve sections for scannability. Content is dense but organized; a few phrases repeat the 'nombre EXACTO' filter guidance, slightly redundant but not wasteful.

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 two-param, no-output-schema tool, the description supplies the return structure, catalog sources, downstream filter usage, and caching latency. 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: both distrito and especialidad get example values and pointers to the enumerating tool (listar_filtros categoria='distritos'/'especialidades'). This fully disambiguates the two required params.

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 (Lista) and resource (órganos jurisdiccionales/salas) scoped by distrito and especialidad (corte superior). It clearly distinguishes itself from siblings like listar_filtros by explaining that this returns the sala catalog rather than the filter catalog it consumes.

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 context for use: pass the returned EXACT 'nombre' (or 'codigo') as the 'sala' filter in downstream tools, and points to listar_filtros for valid distrito/especialidad values. It does not, however, state explicit when-not-to-use conditions versus alternatives.

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 access is public/unauthenticated via the PJ ServletDescarga, that the MCP server only returns the URL rather than fetching the PDF, and that a bad uuid yields a 500 from the site. This is meaningful error and side-effect context.

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 purpose is front-loaded and capitalized, and the Args/Devuelve structure is easy to scan. It is slightly longer than strictly necessary with the docstring-style headers, but no sentence is pure waste.

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 tool with no output schema and no annotations, the description covers the essentials: what is produced (a URL), the return dict keys {ok, url, archivo}, auth expectations, and error behavior. Only the choice relative to sibling data tools is unaddressed.

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% (schema only declares a generic string), so the description must compensate. It does by specifying the uuid identifies a row/record and giving the concrete format (8-4-4-4-12 hexadecimal), which is genuinely useful validation guidance.

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 action (generate a public download URL) and resource (PDF of a resolution), which clearly separates it from data-fetching siblings like ficha_resolucion or buscar_resoluciones. It does not name an alternative sibling explicitly, 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?

It states the URL is public and needs no session/token, implying usage, and notes the MCP server does not download the file. However, it never says when to prefer this over ficha_resolucion or the buscar_* siblings, leaving the routing decision to inference.

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