Busca jurisprudencia española desde Claude, ChatGPT y otros clientes MCP. Localiza resoluciones, consulta sus fundamentos y el fallo cuando estén disponibles y comprueba los pasajes con enlaces a las fuentes oficiales para preparar tu investigación jurídica. Conecta tu cuenta mediante OAuth o utiliza una clave API. Los resúmenes se distinguen del texto íntegro; la cobertura es progresiva y no exhaustiva.
Scored across 10 tools
The search surface is crowded and self-overlapping: search_evidence, search_decisions, and answer_with_sources all retrieve judicial passages, and the search_evidence description itself tells agents to 'prefer search_decisions and read_decision for judgments'. The lookup/read split for both decisions and administrative documents is clear, but the retrieval trio has blurry boundaries that require reading long caveats to choose correctly.
Names follow a predictable verb_noun snake_case pattern (list_*, lookup_*, read_*, search_*, answer_with_sources) and pair symmetrically across the judicial and administrative domains. Minor deviations exist (answer_with_sources vs. the search_* family, singular lookup_decision/read_decision vs. plural search_decisions/search_administrative_documents), but nothing that impedes reading.
Ten tools is a well-scoped size for a jurisprudence search server, with a clean symmetry of two domains (judicial and tax administrative) each getting search/lookup/read. Slightly over-staffed because search_evidence largely duplicates the search_decisions + read_decision path, so not every tool clearly earns its place.
The core lifecycle is covered: enumerate sources/courts, search broadly and strictly, resolve exact references, read version-pinned literal passages, and assemble cited answers, across both judgments and DGT/TEA doctrine. Gaps are minor but real — no tool to browse or paginate a court's decisions, and no cross-reference/related-citation tool despite emphasis on version provenance.
Retrieve and organize verifiable judicial passages with sources and version provenance. When allowed_modes is omitted, retrieval defaults to natural hybrid thematic search. Use allowed_modes=['judicial_text'] for explicit textual retrieval; require_semantic is preserved when supplied. For DGT or TEA tax administrative doctrine use the administrative tools. Does not provide legal advice or determine the outcome of the user's case.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | ||
| countries | No | ||
| allowed_modes | No | ||
| max_citations | No | ||
| source_groups | No | ||
| require_semantic | No | ||
| response_language | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the default retrieval mode, the preservation of require_semantic when supplied, and an explicit scope disclaimer that it does not provide legal advice or determine case outcomes. It still says little about the shape or volume of what comes back.
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 text is dense and front-loaded: purpose first, then mode defaults, then the administrative alternative, then the scope disclaimer. Every sentence carries information, though the mode/flag sentence is syntactically crowded and could be split for faster scanning.
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 7-parameter retrieval tool with no output schema, the description covers routing and mode semantics but omits the meaning of countries, source_groups, max_citations and response_language, and gives no sense of the citation/provenance structure returned. An agent could invoke it, but not confidently tune it.
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% across 7 parameters, so the description must carry the load. It explains allowed_modes in useful depth (default behavior plus the 'judicial_text' value) and mentions require_semantic, but question, countries, max_citations, source_groups, and response_language receive no explanation at all, leaving the majority of parameters undocumented in both places.
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 opens with a specific verb and resource ('Retrieve and organize verifiable judicial passages with sources and version provenance'), which is far more informative than the tool name. It distinguishes the tool from the administrative siblings (DGT/TEA) but never explains how it differs from close siblings like search_evidence or search_decisions, leaving an agent to guess between 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?
Strong conditional guidance: it states that omitting allowed_modes defaults to hybrid thematic search, that allowed_modes=['judicial_text'] forces textual retrieval, and that administrative doctrine belongs to the administrative tools. It lacks an explicit exclusion against the nearest judicial siblings (search_evidence, search_decisions), so the routing picture is incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List visible Spanish judicial bodies and their counts within the available corpus.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety and determinism profile is fully covered. The description adds the non-trivial fact that only 'visible' bodies in the 'available corpus' are returned, which explains why the output may be partial — useful context beyond the annotations, though nothing about ordering or result size.
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?
A single front-loaded sentence with no filler. The scoping qualifier ('within the available corpus') is placed where it is most useful rather than buried.
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 no-argument, no-output-schema tool the description is minimally sufficient, but with no output schema it should say more about the return shape — what a 'count' is measured over and whether the returned labels are the values accepted by the search tools. That linkage is the main missing piece for correct downstream use.
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?
With zero parameters there is no parameter meaning to convey, so the baseline of 4 applies. The description neither adds nor omits anything relevant on this dimension.
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 verb and resource — listing Spanish judicial bodies together with their counts. It is unambiguous and clearly distinct from sibling tools such as search_decisions or lookup_decision, though it does not explicitly name a contrast with any sibling.
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?
There is no when-to-use or when-not-to-use guidance, and no mention of how this enumeration relates to the search/lookup siblings that take court filters. The phrase 'within the available corpus' hints at a discovery role, but the agent must infer that it is meant as a facet-exploration step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List configured legal sources and their availability status; availability does not imply complete coverage.
| Name | Required | Description | Default |
|---|---|---|---|
| include_planned | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, closed-world, non-destructive behavior. The description adds a useful caveat that availability does not imply complete coverage, but it does not explain status values, ordering, or the effect of include_planned.
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 a single front-loaded sentence with no filler. The caveat about availability is compact and directly relevant.
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 simple read-only listing tool with one optional parameter and no output schema, the description is adequate but incomplete. It omits the include_planned parameter semantics and gives no indication of result shape or source status values.
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?
There is one optional parameter, include_planned, with 0% schema description coverage, but the description does not mention or clarify it. An agent cannot infer what 'planned' sources are or how toggling the default changes results.
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 uses a clear verb-resource pair: 'List configured legal sources' and adds that availability status is returned. It is distinguishable from siblings like list_courts and search_decisions, though it does not explicitly say how it relates to 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?
There is no explicit guidance on when to use this tool versus alternatives such as list_courts or answer_with_sources. Usage is only implied by the object being listed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a specific tax administrative document by DGT:consultation-number or DYCTEA:registry. Use this first for an exact reference. Before answering, always call read_administrative_document even if this lookup returns a criterion or excerpt; lookup does not replace the required reading step. Ambiguous references require refinement; not found does not establish absence from the official source.
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the lookup may return only a criterion or excerpt rather than the full document, and a miss is not evidence of absence from the official source. It does not discuss auth or limits, but none seem relevant for a read-only local lookup.
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?
Four short sentences, front-loaded with the verb and identifier formats, followed by the required follow-up workflow and the ambiguity/not-found caveats. Every sentence adds a distinct constraint; nothing is 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?
With one required parameter, no output schema and no nested objects, the description covers what an agent needs: what it returns (criterion or excerpt), the mandatory read step, and how to interpret a miss. Only the exact identifier string format remains underspecified, which is a minor gap for a tool this simple.
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 'identifier' parameter has no schema description, so the description carries the burden. It does add meaning by naming the two accepted identifier schemes (DGT:consultation-number and DYCTEA:registry), but gives no concrete example, prefix syntax, or validation rules, leaving the agent to guess the exact string format.
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 ('Retrieve a specific tax administrative document') and narrows it to an exact-reference lookup by DGT:consultation-number or DYCTEA:registry. This cleanly separates it from the sibling search_administrative_documents (broad search) and read_administrative_document (full reading), so an agent can pick it 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?
Explicitly says 'Use this first for an exact reference', mandates a follow-up read_administrative_document call even when the lookup returns content, and warns that ambiguous references need refinement and that not-found does not prove absence. Both the when-to-use and the when-not-to-conclude conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a judgment by stable id, ECLI, ROJ, decision or case number. Never invent an ECLI from another reference. Use court codes from list_courts: TC or TS; exact unambiguous catalog names are also accepted. Not found does not prove absence from the official source. Use lookup_administrative_document for DGT or DYCTEA references.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | ||
| court | No | ||
| identifier | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and a closed-world hint, so safety is covered. The description adds one genuinely non-obvious behavioral fact, that a not-found result does not prove absence from the official source, which is valuable for negative-result handling. It says nothing about what a hit returns (full text vs. metadata) or about ambiguity handling when several identifiers are supplied.
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?
Five short sentences with the primary action front-loaded and no redundant restatement of the schema or title. Each sentence adds a distinct rule (identifier forms, ECLI caution, court codes, negative-result caveat, administrative routing).
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 three undocumented optional parameters and no output schema, the definition should carry more of the load. The negative-result caveat and sibling routing help, but the lack of any statement about which parameter accepts which identifier form, or what a successful result contains, leaves real ambiguity.
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 carries the full burden for id, court, and identifier, and it partially does: court is pinned to catalog codes TC/TS or exact catalog names. However, it lists many accepted identifier forms (ECLI, ROJ, case number, decision) without saying which of the two string parameters, id or identifier, takes which form, and it never says whether parameters must be combined or are independently optional.
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 first sentence gives a specific verb (Retrieve) and resource (a judgment) plus the full set of accepted identifier types (stable id, ECLI, ROJ, decision or case number). It also routes the agent away from lookup_administrative_document for DGT/DYCTEA references, so it is distinguishable from 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?
It names two explicit dependencies: use list_courts for court codes (TC or TS) and use lookup_administrative_document for administrative references. It also warns never to invent an ECLI from another reference. The gap is that the relationship to the closer siblings read_decision and search_decisions is never stated, so the agent must infer when lookup beats search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read version-pinned literal administrative passages. Select tax_answer for the DGT answer, administrative_criterion for a TEA criterion, or legal_grounds for resolution grounds when available. limit must be 1 to 5 paragraphs per call; use pagination for more. Check available_sections. Facts and questions do not establish the answer. Preserve classification and conditions; do not presume binding effect, validity or applicability.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| id | Yes | ||
| limit | No | ||
| offset | No | ||
| section | No | tax_answer | |
| start_char | No | ||
| version_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive behavior, so safety is covered; the description adds genuinely new context about how the returned text must be treated (facts and questions do not establish the answer, preserve classification and conditions, do not presume binding effect, validity or applicability). This is meaningful interpretive behavior disclosure for a legal-source reader, though it says nothing about version resolution behavior or what happens when a section is unavailable.
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 passage is dense but front-loaded, with the core read action first and constraints after, and no redundant restatement of the title. A few phrases are compressed to the point of ambiguity ("Facts and questions do not establish the answer", "Check available_sections") and would benefit from one clarifying clause each.
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 7-parameter reader with no output schema and zero schema description coverage, the description covers the primary selection and paging mechanics adequately but leaves the q search parameter and start_char unexplained, and it references an available_sections field that the agent has no schema to interpret. It is workable but not fully self-sufficient.
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% across 7 parameters, so the description must carry the load. It explains section (three of ten enum values), limit (1-5) and pagination via offset, plus the version-pinned notion behind version_id, but leaves q, start_char, id and the remaining enum values (ruling, antecedents, tax_facts, normative_references, etc.) entirely unexplained.
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 concrete verb and resource ("Read version-pinned literal administrative passages") and specifies which section kinds can be requested (tax_answer, administrative_criterion, legal_grounds), which separates it from the pure lookup/search siblings. It stops short of explicitly contrasting itself with lookup_administrative_document or search_administrative_documents, so the differentiation is inferable rather than stated.
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 operative guidance for choosing a section value and states the limit constraint (1 to 5 paragraphs) with an instruction to paginate for more, which are real usage rules. However, it never says when to prefer this tool over the sibling lookup/search tools, and the instruction "Check available_sections" points at a field that is not documented anywhere in the definition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read literal paragraphs from a specific judgment version and section. Optional q anchors the initial read near the topic; inspect prefix_omitted and continue with the returned offsets. Check available_sections and warnings; summaries are not full judgments.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| id | Yes | ||
| limit | No | ||
| offset | No | ||
| section | No | legal_grounds | |
| start_char | No | ||
| version_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/non-destructive, and the description adds genuine behavioral context beyond them: truncation semantics via prefix_omitted, continuation via returned offsets, and the presence of available_sections and warnings in the response. It also warns that summaries are not full judgments, which prevents a misuse of the source_summary section.
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?
Three tight sentences with the core read action front-loaded, followed by parameter hints and then response-field guidance. No filler, though the compressed phrasing ('Check available_sections and warnings') reads as terse shorthand an agent must decode.
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 7-parameter tool with no output schema, the description usefully names key return fields and continuation mechanics, which is more than most. Still missing: how id and version_id relate, what limit controls, and any guidance on choosing a section — gaps an agent must guess at.
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% across 7 parameters, so the description must compensate and does so only partially: it explains q as a topic anchor, offsets as continuation handles, and references version and section concepts. It says nothing about limit (default 3, max 5), id vs version_id relationship, or the meaning of the five section enum 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: reading 'literal paragraphs' from a 'specific judgment version and section'. This differentiates it from metadata-style siblings like lookup_decision or search_decisions by emphasizing literal text retrieval, though no sibling is named 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?
Implies usage through 'Optional q anchors the initial read near the topic' and 'continue with the returned offsets', which tells the agent how to page through content. However, it never states prerequisites such as needing an id from search_decisions/lookup_decision, nor when to prefer read_administrative_document or answer_with_sources instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Spanish tax administrative doctrine. Use source_groups=['petete'] for DGT interpretations and binding consultations; ['dyctea'] for TEAC/TEAR/TEAL criteria and economic-administrative appeals; omit the filter to search both. For comparisons with judgments also call search_decisions. Then verify the actual answer or criterion using read_administrative_document. Coverage is progressive.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| query | Yes | ||
| per_page | No | ||
| search_mode | No | Free-text query defaults to natural hybrid exploratory retrieval, requiring vectors and using up to 50 documents. Select strict explicitly for textual operators and phrases. The original query is preserved; retrieval does not establish legal interpretation or exhaustive coverage. | natural |
| source_groups | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the low bar is met by structure alone. The description adds genuinely useful behavior context beyond that: 'Coverage is progressive' warns results may be incomplete/incremental, and it mandates a verification step via read_administrative_document. It does not discuss result ordering or pagination depth, which keeps it from 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences, front-loaded with purpose, then filter semantics, then alternatives, then verification. No filler or restatement of the title; each clause carries actionable 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?
There is no output schema, and the description compensates by telling the agent to verify results with read_administrative_document and warning that coverage is progressive. Given 5 parameters with weak schema documentation, it could say more about result ordering and page/per_page behavior, but the critical decision inputs 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 coverage is only 20% (only search_mode is documented in the schema), so the description must carry the load. It does explain the least obvious parameter well — the meaning of each source_groups enum value and the null/omit case — but query, page and per_page receive no semantic elaboration, and pagination limits go unmentioned.
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 ('Search Spanish tax administrative doctrine') and immediately distinguishes scope from siblings by naming search_decisions for judgments and read_administrative_document for verification. An agent can tell this is a doctrine search tool, not an ID lookup or judgment search, without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit routing rules: petete for DGT interpretations and binding consultations, dyctea for TEAC/TEAR/TEAL criteria and economic-administrative appeals, omit the filter to search both. It also names two follow-up/alternative tools and the conditions that select them (comparison with judgments, verifying the actual criterion).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Spanish and EU court judgments by legal issue, terms, body, date or source. Filter countries with ES, EU or both. Optional source_groups accepts only boe_tc, cendoj, tc_hj, curia; omit it to search all judicial sources. This judicial search does not include DYCTEA or PETETE; use search_administrative_documents for tax administrative doctrine. Returns matching decisions with identifiers, metadata, official links, and indexed excerpts. Free-text query defaults to natural hybrid thematic retrieval, requiring vectors and limited to a window of up to 50 decisions. Select search_mode=strict explicitly for textual operators and phrases. query_intent implies strict when search_mode is omitted; do not combine query_intent with explicit natural. The original free-text query is preserved; retrieval does not establish legal interpretation or exhaustive coverage. Use query_intent for required, alternative, phrase, or excluded terms, then use read_decision to verify literal passages.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| court | No | ||
| query | No | ||
| date_to | No | ||
| per_page | No | ||
| countries | No | ||
| date_from | No | ||
| search_mode | No | Free-text query defaults to natural hybrid exploratory retrieval, requiring vectors and using up to 50 decisions. Select strict explicitly for textual operators and phrases. If query_intent is supplied without search_mode, strict is implied; explicit natural with query_intent is invalid. The original query is preserved; retrieval does not establish legal interpretation or exhaustive coverage. | natural |
| query_intent | No | ||
| source_groups | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and idempotency, but the description adds non-obvious behavior: natural mode is hybrid retrieval requiring vectors and limited to a 50-decision window, the original query is preserved, and retrieval does not establish legal interpretation or exhaustive coverage. Those operational caveats are exactly what an agent needs and are not derivable from the 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 front-loaded with scope, then routing, then return values, then mode semantics, so an agent can stop reading early. It is fairly long and repeats some search_mode guidance already present in the schema's own description, but no sentence is pure 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?
With no output schema, the description supplies the return shape (identifiers, metadata, official links, indexed excerpts), and it covers the highest-risk parameters and the 50-decision retrieval window. Pagination limits and court-name format are not addressed, which keeps it short of fully complete for a 10-parameter tool.
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 only 10%, so the description must compensate, and it does for the tricky parameters: source_groups enum values and omission semantics, countries ES/EU filtering, search_mode default and interaction with query_intent, and the shape of query_intent usage. It leaves court, page, and per_page unexplained, which is a residual gap but a minor one for a search tool.
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 opening sentence names a specific verb and resource ('Search Spanish and EU court judgments') and even lists the dimensions it can search by. It explicitly states what it does not cover (DYCTEA, PETETE) and names the sibling tool that handles that space, so an agent can separate it from search_administrative_documents without reading 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?
The description gives explicit routing: use search_administrative_documents for tax administrative doctrine, use query_intent for required/alternative/phrase/excluded terms, use read_decision to verify literal passages. It also explains when search_mode=strict is required and that query_intent with explicit natural is invalid, so the agent knows both when to use this tool and how to configure alternatives within it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search judicial passages with official links, versions and content_scope. When the user restricts a court, send body_code='TS' for Tribunal Supremo (court is an alias); writing the court in query does not filter results. For several requested courts make separate filtered calls. A court mention without a filter requires clarification; use court_scope='all' only when the user permits all courts and the mention is contextual. Check applied_filters. Prefer search_decisions and read_decision for judgments; CENDOJ summaries are not full judgments. Omitted allowed_modes defaults to natural hybrid retrieval; use allowed_modes=['judicial_text'] for explicit textual retrieval. allowed_modes accepts judicial_text, semantic_vector and judicial_hybrid. For DGT/TEA administrative doctrine use search_administrative_documents.
| Name | Required | Description | Default |
|---|---|---|---|
| court | No | Court code from list_courts. Required for a user court restriction: TS=Tribunal Supremo, TC=Tribunal Constitucional, TSJM=TSJ Madrid. Query text is not a court filter. | |
| limit | No | ||
| query | Yes | ||
| body_code | No | Court code from list_courts. Required for a user court restriction: TS=Tribunal Supremo, TC=Tribunal Constitucional, TSJM=TSJ Madrid. Query text is not a court filter. | |
| countries | No | ||
| body_family | No | ||
| court_scope | No | Use restricted with an explicit court code. Use all only if the user permits all courts; this explicitly treats court mentions in query as context, not a restriction. | |
| allowed_modes | No | ||
| source_groups | No | ||
| decision_date_to | No | ||
| require_semantic | No | ||
| content_languages | No | ||
| response_language | No | ||
| decision_date_from | No | ||
| court_category_code | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds non-obvious behavior: query text is not a court filter, omitted allowed_modes falls back to natural hybrid retrieval, and CENDOJ results are summaries rather than full judgments. It also points to checking applied_filters, though it does not say what that field contains.
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 purpose then a sequence of concrete rules, and nearly every sentence carries an instruction an agent would otherwise get wrong. It is a dense run-on block with telegraphic fragments ('Check applied_filters.') that would read better as a short list, but there is little pure 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 15-parameter tool with no output schema, the description covers the court-filtering and retrieval-mode logic well and hints at return fields (official links, versions, content_scope, applied_filters). However, most filter parameters have no explanation anywhere, so an agent cannot confidently use date ranges, source groups, or language filters from the definition alone.
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 only 20% across 15 parameters, so the description has to carry meaning. It explains the court/body_code alias and filtering semantics, court_scope's two modes, and the accepted allowed_modes values with their default, but leaves limit, countries, body_family, source_groups, decision_date_from/to, require_semantic, content_languages, response_language and court_category_code undocumented in both places.
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 ('Search judicial passages') plus what comes back ('official links, versions and content_scope'). It explicitly separates itself from siblings by naming search_decisions and read_decision for judgments and search_administrative_documents for DGT/TEA doctrine, so an agent can pick it without opening a 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?
Gives operational routing rules: use body_code='TS' for a Tribunal Supremo restriction, make separate filtered calls for multiple courts, ask for clarification on an unfiltered court mention, and only use court_scope='all' when the user permits all courts. It also names the alternative tools for judgments and administrative doctrine.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
answer_with_sourceslist_courtslist_source_groupslookup_administrative_documentlookup_decisionread_administrative_documentread_decisionsearch_administrative_documentssearch_decisionssearch_evidenceJusPronto is case-management software for Brazilian law firms. Its remote MCP server (OAuth 2.1 with PKCE, per-permission scopes, audit log) lets Claude and ChatGPT read the firm's own cases, deadlines, agenda, recent court movements and case files with the page cited. Write actions require the lawyer's approval. Requires a JusPronto account.
Connect AI to millions of laws and court cases with the Lawstronaut MCP.
MCP for CourtListener: US federal and state opinions, dockets, judges, plus eCFR regulations.
Busca e verifica jurisprudência brasileira real (+400 mil julgados) — anti-alucinação para IA.
Add one secure layer between your agents and this server.
