Regulatory search engine for EU textile sustainability law: ESPR, DPP, CSRD, CBAM, CWA 18291.
Scored across 8 tools
Most tools have clear, distinct roles: search vs. exact-text lookup, outline vs. fetch, and listing documents are well separated. The main ambiguity is between search and search_eu_textile_regulations, though the latter's regulatory scope is clearly stated; about_reecopedia also lacks a description but its name is self-explanatory.
All names are snake_caseión, but the style is mixed: bare verbs like fetch and search sit alongside verb_noun names like find_exact_text and list_corpus_documents, while document_outline and about_reecopedia don't follow the same verb pattern. The naming is readable but not predictable enough for a higher score.
Eight tools is well within the ideal range and each tool earns its place for a retrieval-focused corpus server: semantic search, exact-text search, document listing, outline navigation, fetching source text, and a feedback/reporting tool. No obvious bloat or unnecessary duplication.
The retrieval workflow is well covered: search discovers cited ids, fetch retrieves source text, find_exact_text handles literal lookup, and document_outline supports navigation; report_answer_issue closes the loop for quality feedback. Minor gaps exist such as no explicit document metadata tool or broader search scoping options, but agents can work around these.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a compact navigation-v1 tree of indexed source text. Source metadata is shared in documents; depth/path encode hierarchy. Pass opaque ids unchanged to fetch. Warnings expose uncertain structure; citable=false marks navigation containers or unverified fragments.
| Name | Required | Description | Default |
|---|---|---|---|
| document | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds meaningful behavioral details beyond annotations: the tree is 'navigation-v1', warnings indicate uncertain structure, and citable=false marks navigation containers or unverified fragments. This informs the agent about output nuances without contradicting 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?
The description is compact—three sentences with no fluff. It front-loads the core purpose and then adds supporting details about hierarchy encoding, warnings, and the citable flag. However, the jargon 'navigation-v1' is somewhat opaque and could be simplified or defined, slightly reducing clarity.
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?
The tool has an output schema (not shown) which relieves the description of explaining return values. Yet the description omits guidance on the document parameter, potential error conditions, or how to obtain the initial document id. For a read-only tool with one parameter, this is a notable gap that affects completeness.
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 description fails to explain the 'document' parameter beyond its type. It does not clarify what format the document identifier takes, what a valid input looks like, or how it relates to the returned tree. With zero schema coverage, the description was expected to compensate but does not, leaving the agent to guess the parameter's meaning.
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 the tool returns a 'compact navigation-v1 tree of indexed source text' and elaborates on depth/path encoding and metadata sharing. This distinguishes it from sibling tools like search or fetch, which have different purposes. The verb 'Return' plus the resource and key characteristics make the purpose unambiguous.
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 implies this tool is for obtaining an outline/tree of a document but does not explicitly state when to use it versus siblings such as find_exact_text or search. It mentions 'Pass opaque ids unchanged to fetch' which hints at integration with fetch but offers no explicit exclusions or conditions. The context is present but not framed as guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch original text by an opaque id from search or document_outline. Pass ids unchanged. Navigation containers have citable=false and child ids, not source evidence. Historical page identifiers return migration guidance.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds behavioral context beyond that: ids are opaque, must be passed unchanged, navigation containers have citable=false and child ids rather than source evidence, and historical page identifiers yield migration guidance. This meaningfully informs the agent about edge-case behavior without contradicting any annotation.
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, each earning its place: the first states the core action and source, the second gives the critical pass-through instruction, and the third covers two edge cases. It is front-loaded and free of 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 only one parameter, an existing output schema, and annotations covering safety/idempotency, the description covers all essential operational details: id origin, pass-through requirement, container distinction, and historical-id behavior. Nothing needed 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% and the schema only says 'id' is a string. The description fully compensates by specifying the id is opaque, originates from search or document_outline, must be passed unchanged, and clarifying which id types do not correspond to source evidence. This gives the agent a complete mental model of the single parameter.
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 precise verb-resource pair: 'Fetch original text by an opaque id from search or document_outline.' It clearly defines the input source (ids from two named tools) and contrasts with navigation containers, making it distinguishable from siblings like search and document_outline.
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 guidance on what ids to pass: ids from search or document_outline, unchanged, and warns that navigation containers are not source evidence. It also notes that historical page identifiers yield migration guidance, which implicitly tells the agent not to expect source text for those. It lacks an explicit 'when not to use' statement naming alternatives, but the constraints are concrete and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Locate a literal string in the current corpus, optionally restricted to a document.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| document | No | ||
| max_results | No | ||
| case_sensitive | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful scoping context ('current corpus' and 'optionally restricted to a document') but does not disclose any other behavioral traits such as result ordering, limits, or error conditions. This is adequate given the strong annotation coverage.
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, tightly phrased sentence that front-loads the core action and scope. Every word adds value, with no redundant or filler content. It is an example of concise, efficient writing.
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?
The tool is simple with an output schema and strong annotations, so the description does not need to explain return values or safety. It covers the core behavior and scoping. The only missing element is explicit differentiation from the sibling 'search' tool, which is a minor gap and partly covered by the literal string phrase. Overall, the description is complete enough for 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 for undocumented parameters. It adds meaning to 'text' (literal string) and 'document' (restriction scope), but it does not explain 'max_results' or 'case_sensitive' beyond their self-explanatory names and schema defaults. The description provides partial value but not full compensation for the low schema coverage.
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 ('Locate'), a clear resource ('a literal string'), and scope ('in the current corpus, optionally restricted to a document'). The term 'literal string' effectively differentiates it from the sibling 'search' tool, which likely uses fuzzy or semantic matching. This makes the purpose unambiguous and distinct.
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 guidance is only implied: the word 'literal' suggests using this tool for exact substring matching rather than a semantic search, but the description does not explicitly mention when to prefer it over the sibling 'search' tool or any other alternative. There is no mention of when not to use it. The agent must infer the selection criteria from the wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List indexed document names matching a substring.
| Name | Required | Description | Default |
|---|---|---|---|
| contains | No | ||
| max_results | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to restate safety. The description adds some context by noting the operation works on 'indexed document names' with substring matching, but it does not disclose other behavioral details like pagination or result limits, which is acceptable given 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?
The description is a single concise sentence that front-loads the main action and scope. There is no filler or redundant wording, so every word earns its place.
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 an output schema and strong annotations, the description covers the core operation adequately. It is incomplete in that it does not address usage relative to sibling search tools or clarify the max_results parameter, but given the tool's low complexity this is a moderate gap rather than a severe one.
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 undocumented parameters. It indirectly explains the 'contains' parameter through 'matching a substring', but it gives no semantic guidance for 'max_results', leaving one of two parameters effectively 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 states a specific verb ('List'), resource ('indexed document names'), and filter ('matching a substring'), which clearly conveys the tool's purpose. It does not explicitly distinguish itself from sibling tools like search or find_exact_text, but the emphasis on document names makes the scope reasonably clear.
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 implies when to use the tool: when you want document names containing a particular substring. However, it provides no explicit guidance about when not to use it or how it compares to sibling tools such as search or find_exact_text, so the guidance is minimally adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
File a report that an answer built from Reecopedia search results was wrong, misleading or incomplete. The report (the query and the reason, nothing else — no personal data) enters Reecopedia's human curation queue and is reviewed weekly to correct the corpus and retrieval quality.
THIS TOOL WRITES. Use it only when the user has asked for the problem to be reported, and send only the original query and the reason the user gave. Do not call it on your own initiative and do not add anything the user did not say.
ANNOTATIONS — why each hint is set the way it is, based on this tool's actual behaviour. readOnlyHint=false: this is the only tool that writes; it appends one record (the query and the reason, nothing else) to Reecopedia's internal human curation queue. destructiveHint=false: the write is append-only; it modifies and deletes nothing that already exists. idempotentHint=false: two calls can append two records — de-duplication covers only an identical query+reason pair within the same hour. openWorldHint=false: the record stays in the internal queue; it is not sent anywhere outside Reecopedia.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The original search query the reported answer was built from. | |
| reason | Yes | The user's reason why the answer was wrong (min 10 chars — e.g. which fact was incorrect, which source was misread, what was missing). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by explaining the append-only nature, that no personal data is sent, that the report enters a human curation queue, and that de-duplication applies only to identical query+reason pairs within the same hour. It aligns with all annotations and adds meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently organized into purpose, usage rule, and annotation explanation. Every sentence carries operational or safety guidance, and there is no padding or redundant restatement of the tool name.
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?
Together with the schema and annotations, the description fully covers when to call, what data gets sent, what side effects occur, and privacy constraints. Nothing an agent needs in order to invoke this tool 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?
The input schema already documents both parameters clearly and with 100% coverage, including that query is the original search query and reason has a 10-character minimum. The description reinforces the 'query and reason, nothing else' constraint, but it does not add much new per-parameter meaning beyond what the schema provides.
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 and resource: 'File a report' for answers built from Reecopedia search results that are wrong, misleading, or incomplete. It also differentiates this tool from the sibling search/read tools by explicitly stating it is the only tool that writes, making its purpose unambiguous.
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 explicitly states when to use the tool: only after the user has asked for the problem to be reported, and never on the agent's own initiative. It also gives clear exclusions: send only the original query and reason, and do not add anything the user did not say.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return cited corpus results by id; use fetch for full source text. The client verifies the evidence. Query embeddings use Alibaba; candidate passages go to Jina for reranking.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful behavioral context: it returns cited corpus results rather than full text, the client verifies evidence, and the pipeline uses Alibaba embeddings with Jina reranking. No contradiction with annotations exists.
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 three sentences and front-loads the primary behavior in the first sentence. The technical pipeline detail is relevant but could be considered optional; overall, it is concise and well-structured without redundancy.
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 an output schema present, return value details are already covered. The annotations handle safety and idempotency. The description adds the key distinction from `fetch` and gives enough context for a simple one-parameter search tool, though it could briefly mention the sibling EU-specific search 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 0%, so the description must compensate for explaining the `query` parameter. It only indirectly references 'Query embeddings' and never clarifies what the query should contain, its expected format, or any constraints. The parameter name is self-evident, but the description fails to add meaningful semantics beyond 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 states a specific action ('Return cited corpus results') and distinguishes this tool from `fetch` by noting that full source text should be retrieved via `fetch`. The title 'Search regulatory documents' reinforces the purpose. It does not explicitly differentiate from the sibling `search_eu_textile_regulations`, but the core resource and behavior are clear.
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 explicitly says 'use fetch for full source text', providing a clear alternative when full text is needed. This gives the agent a concrete routing cue. However, it does not address when to prefer this tool over `search_eu_textile_regulations` or `find_exact_text`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search regulatory evidence in English legal register. Cite original document and unit; verify each claim. Optional scope narrows corpus partitions. No model assesses the answer in this MCP tool; the client must verify each claim against the returned text. Query embeddings use Alibaba; candidate passages are sent to Jina for reranking.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| scope | No | ||
| top_k | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond the readOnly/idempotent annotations: 'No model assesses the answer in this MCP tool; the client must verify each claim against the returned text.' It also discloses the underlying processing pipeline ('Query embeddings use Alibaba; candidate passages are sent to Jina for reranking'). This is exactly the kind of grounding an agent needs for a search tool.
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 five sentences, front-loaded with purpose ('Search regulatory evidence in English legal register') and each sentence contributes distinct value. Slight redundancy exists with 'verify each claim' appearing twice, but overall it is efficient and structured.
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?
The description covers the core function, the scope parameter, the client-verification requirement, and the reranking pipeline. An output schema exists, so return-value details are not required. Minor ambiguity remains about whether the corpus is specifically EU textile regulations, but the title and tool name resolve that; top_k is also not explained in prose, but the schema provides a default.
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 input schema has 0% description coverage, so the description must compensate for parameter meaning. It explains only one of three parameters: 'Optional scope narrows corpus partitions.' The 'query' parameter is left to obvious inference, and 'top_k' receives no explanation at all, leaving its semantics (e.g., number of results) to the agent. This is insufficient given the low schema coverage.
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: 'Search regulatory evidence in English legal register.' It also adds operational detail by instructing to 'Cite original document and unit; verify each claim.' This distinguishes the tool from generic siblings like 'search' through the legal-register scope, though it does not explicitly mention 'EU textile' in the description (the title and name do).
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 implies usage context by defining the search domain and noting 'Optional scope narrows corpus partitions,' which is a usage hint. However, it does not explicitly state when to prefer this tool over alternatives like the sibling 'search' or 'find_exact_text,' nor does it provide exclusions or when-not conditions.
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.
about_reecopedia1 field changedOutput schema / additionalPropertiesPrevious value: -{
- "type": "string"
-}New value: +truedocument_outline1 field changedInput schema / properties / document / descriptionRemoved value: -"Exact source file name as returned by `search` /\n`search_eu_textile_regulations` (e.g. \"CELEX-02024R1781-20240628.pdf\")."fetch1 field changedInput schema / properties / id / descriptionRemoved value: -"A result id from `search`, format \"<source-file>#p<page>\"\n(e.g. \"REG_2024_1781_ESPR_EN.pdf#p39\")."find_exact_text4 fields changedInput schema / properties / case_sensitive / descriptionRemoved value: -"Exact-case match (default False)."Input schema / properties / document / descriptionRemoved value: -"Optional exact source file name to restrict the search."Input schema / properties / max_results / descriptionRemoved value: -"Max (file, page) matches to return (1-50, default 20)."Input schema / properties / text / descriptionRemoved value: -"The exact string to find (min 3 characters)."list_corpus_documents2 fields changedInput schema / properties / contains / descriptionRemoved value: -"Optional case-insensitive substring to filter file names\n(e.g. \"cbam\", \"cwa\", \"CELEX\")."Input schema / properties / max_results / descriptionRemoved value: -"Max file names to return (1-1000, default 100)."search1 field changedInput schema / properties / query / descriptionRemoved value: -"English, in the legal register of the act. A non-English query is accepted but retrieves poorly, and the result then carries a `notice` saying so.\nAct identifiers stay verbatim (\"ESPR\", \"2024/1781\"): they are\nmatched as metadata. Article and annex numbers are matched in\ntheir English form: \"第9条\" and \"Artikel 9\" do not match,\n\"Article 9\" does.\nMeasured 2026-08-27 on the live index, one question three ways:\n\"must a marketplace show the product passport before purchase,\nwhere is it written?\" returned NOTHING; \"marketplace must make the\ndigital product passport accessible before purchase\" returned the\nCWA guidance (0.96) with the ESPR at 0.001; \"make the digital\nproduct passport accessible to customers before they are bound by a\ncontract of sale\" returned the ESPR itself first (0.94, p.21)."search_eu_textile_regulations4 fields changedInput schema / properties / query / descriptionRemoved value: -"English, in the legal register of the act. A non-English query is accepted but retrieves poorly, and the result then carries a `notice` saying so.\nAct identifiers stay verbatim (\"ESPR\", \"2024/1781\"): they are\nmatched as metadata. Article and annex numbers are matched in\ntheir English form: \"第9条\" and \"Artikel 9\" do not match,\n\"Article 9\" does.\nMeasured 2026-08-27 on the live index, one question three ways:\n\"must a marketplace show the product passport before purchase,\nwhere is it written?\" returned NOTHING; \"marketplace must make the\ndigital product passport accessible before purchase\" returned the\nCWA guidance (0.96) with the ESPR at 0.001; \"make the digital\nproduct passport accessible to customers before they are bound by a\ncontract of sale\" returned the ESPR itself first (0.94, p.21)."Input schema / properties / scopeAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}Input schema / properties / top_k / defaultPrevious value: -10New value: +20Input schema / properties / top_k / descriptionRemoved value: -"Number of passages to return (1-10, default 10)."list_corpus_documentsreport_answer_issue2 fields changedInput schema / properties / query / descriptionPrevious value: -"The original search query the bad answer was built from."New value: +"The original search query the reported answer was built from."Input schema / properties / reason / descriptionPrevious value: -"Why the answer was wrong (min 10 chars — e.g. which fact was\nincorrect, which source was misread, what was missing)."New value: +"The user's reason why the answer was wrong (min 10 chars —\ne.g. which fact was incorrect, which source was misread, what was\nmissing)."search1 field changedInput schema / properties / query / descriptionPrevious value: -"ENGLISH ONLY, in the legal register of the act. A non-English `query` violates this tool's contract and its passages must be discarded, not answered from.\nAct identifiers stay verbatim (\"ESPR\", \"2024/1781\"): they are\nmatched as metadata. Article and annex numbers must be rewritten\ninto their English form, because that is how they are matched:\n\"第9条\" and \"Artikel 9\" do not match, \"Article 9\" does.\nMeasured 2026-08-27 on the live index, one question three ways:\n\"must a marketplace show the product passport before purchase,\nwhere is it written?\" returned NOTHING; \"marketplace must make the\ndigital product passport accessible before purchase\" returned the\nCWA guidance (0.96) with the ESPR at 0.001; \"make the digital\nproduct passport accessible to customers before they are bound by a\ncontract of sale\" returned the ESPR itself first (0.94, p.21)."New value: +"English, in the legal register of the act. A non-English query is accepted but retrieves poorly, and the result then carries a `notice` saying so.\nAct identifiers stay verbatim (\"ESPR\", \"2024/1781\"): they are\nmatched as metadata. Article and annex numbers are matched in\ntheir English form: \"第9条\" and \"Artikel 9\" do not match,\n\"Article 9\" does.\nMeasured 2026-08-27 on the live index, one question three ways:\n\"must a marketplace show the product passport before purchase,\nwhere is it written?\" returned NOTHING; \"marketplace must make the\ndigital product passport accessible before purchase\" returned the\nCWA guidance (0.96) with the ESPR at 0.001; \"make the digital\nproduct passport accessible to customers before they are bound by a\ncontract of sale\" returned the ESPR itself first (0.94, p.21)."search_eu_textile_regulations1 field changedInput schema / properties / query / descriptionPrevious value: -"ENGLISH ONLY, in the legal register of the act. A non-English `query` violates this tool's contract and its passages must be discarded, not answered from.\nAct identifiers stay verbatim (\"ESPR\", \"2024/1781\"): they are\nmatched as metadata. Article and annex numbers must be rewritten\ninto their English form, because that is how they are matched:\n\"第9条\" and \"Artikel 9\" do not match, \"Article 9\" does.\nMeasured 2026-08-27 on the live index, one question three ways:\n\"must a marketplace show the product passport before purchase,\nwhere is it written?\" returned NOTHING; \"marketplace must make the\ndigital product passport accessible before purchase\" returned the\nCWA guidance (0.96) with the ESPR at 0.001; \"make the digital\nproduct passport accessible to customers before they are bound by a\ncontract of sale\" returned the ESPR itself first (0.94, p.21)."New value: +"English, in the legal register of the act. A non-English query is accepted but retrieves poorly, and the result then carries a `notice` saying so.\nAct identifiers stay verbatim (\"ESPR\", \"2024/1781\"): they are\nmatched as metadata. Article and annex numbers are matched in\ntheir English form: \"第9条\" and \"Artikel 9\" do not match,\n\"Article 9\" does.\nMeasured 2026-08-27 on the live index, one question three ways:\n\"must a marketplace show the product passport before purchase,\nwhere is it written?\" returned NOTHING; \"marketplace must make the\ndigital product passport accessible before purchase\" returned the\nCWA guidance (0.96) with the ESPR at 0.001; \"make the digital\nproduct passport accessible to customers before they are bound by a\ncontract of sale\" returned the ESPR itself first (0.94, p.21)."search1 field changedInput schema / properties / query / descriptionPrevious value: -"The regulatory question — SEND IT IN ENGLISH even if the user\nasked in another language, whatever that language is (the corpus is\nEnglish; a non-English query can miss the official text entirely),\nthen answer the user in their own language. Do NOT translate\nword-for-word: phrase it in the LEGAL REGISTER of the act, because\nretrieval matches the wording of the law, not the phrasing of the\nquestion. Measured 2026-08-27 on the live index, same question three\nways: \"must a marketplace show the product passport before purchase,\nwhere is it written?\" returned NOTHING; \"marketplace must make the\ndigital product passport accessible before purchase\" returned the\nCWA guidance (0.96) with the ESPR at 0.001; \"make the digital\nproduct passport accessible to customers before they are bound by a\ncontract of sale\" returned the ESPR itself first (0.94, p.21). Keep\narticle/annex numbers and act identifiers verbatim (\"Article 9\",\n\"ESPR\", \"2024/1781\"): those are matched as metadata, not translated."New value: +"ENGLISH ONLY, in the legal register of the act. A non-English `query` violates this tool's contract and its passages must be discarded, not answered from.\nAct identifiers stay verbatim (\"ESPR\", \"2024/1781\"): they are\nmatched as metadata. Article and annex numbers must be rewritten\ninto their English form, because that is how they are matched:\n\"第9条\" and \"Artikel 9\" do not match, \"Article 9\" does.\nMeasured 2026-08-27 on the live index, one question three ways:\n\"must a marketplace show the product passport before purchase,\nwhere is it written?\" returned NOTHING; \"marketplace must make the\ndigital product passport accessible before purchase\" returned the\nCWA guidance (0.96) with the ESPR at 0.001; \"make the digital\nproduct passport accessible to customers before they are bound by a\ncontract of sale\" returned the ESPR itself first (0.94, p.21)."search_eu_textile_regulations1 field changedInput schema / properties / query / descriptionPrevious value: -"The regulatory question — SEND IT IN ENGLISH even if the user\nasked in another language, whatever that language is (the corpus is\nEnglish; a non-English query can miss the official text entirely),\nthen answer the user in their own language. Do NOT translate\nword-for-word: phrase it in the LEGAL REGISTER of the act, because\nretrieval matches the wording of the law, not the phrasing of the\nquestion. Measured 2026-08-27 on the live index, same question three\nways: \"must a marketplace show the product passport before purchase,\nwhere is it written?\" returned NOTHING; \"marketplace must make the\ndigital product passport accessible before purchase\" returned the\nCWA guidance (0.96) with the ESPR at 0.001; \"make the digital\nproduct passport accessible to customers before they are bound by a\ncontract of sale\" returned the ESPR itself first (0.94, p.21). Keep\narticle/annex numbers and act identifiers verbatim (\"Article 9\",\n\"ESPR\", \"2024/1781\"): those are matched as metadata, not translated."New value: +"ENGLISH ONLY, in the legal register of the act. A non-English `query` violates this tool's contract and its passages must be discarded, not answered from.\nAct identifiers stay verbatim (\"ESPR\", \"2024/1781\"): they are\nmatched as metadata. Article and annex numbers must be rewritten\ninto their English form, because that is how they are matched:\n\"第9条\" and \"Artikel 9\" do not match, \"Article 9\" does.\nMeasured 2026-08-27 on the live index, one question three ways:\n\"must a marketplace show the product passport before purchase,\nwhere is it written?\" returned NOTHING; \"marketplace must make the\ndigital product passport accessible before purchase\" returned the\nCWA guidance (0.96) with the ESPR at 0.001; \"make the digital\nproduct passport accessible to customers before they are bound by a\ncontract of sale\" returned the ESPR itself first (0.94, p.21)."search1 field changedInput schema / properties / query / descriptionPrevious value: -"The regulatory question — SEND IT IN ENGLISH even if the user\nasked in another language (the corpus is English; a non-English\nquery can miss the official text entirely), then answer the user in\ntheir own language. Keep article/annex numbers and act identifiers\nverbatim (\"Article 9\", \"ESPR\", \"2024/1781\"): those are matched as\nmetadata, not translated."New value: +"The regulatory question — SEND IT IN ENGLISH even if the user\nasked in another language, whatever that language is (the corpus is\nEnglish; a non-English query can miss the official text entirely),\nthen answer the user in their own language. Do NOT translate\nword-for-word: phrase it in the LEGAL REGISTER of the act, because\nretrieval matches the wording of the law, not the phrasing of the\nquestion. Measured 2026-08-27 on the live index, same question three\nways: \"must a marketplace show the product passport before purchase,\nwhere is it written?\" returned NOTHING; \"marketplace must make the\ndigital product passport accessible before purchase\" returned the\nCWA guidance (0.96) with the ESPR at 0.001; \"make the digital\nproduct passport accessible to customers before they are bound by a\ncontract of sale\" returned the ESPR itself first (0.94, p.21). Keep\narticle/annex numbers and act identifiers verbatim (\"Article 9\",\n\"ESPR\", \"2024/1781\"): those are matched as metadata, not translated."search_eu_textile_regulations1 field changedInput schema / properties / query / descriptionPrevious value: -"The regulatory question — SEND IT IN ENGLISH even if the user\nasked in another language (the corpus is English; a non-English\nquery can miss the official text entirely), then answer the user in\ntheir own language. Keep article/annex numbers and act identifiers\nverbatim (\"Article 9\", \"ESPR\", \"2024/1781\"): those are matched as\nmetadata, not translated."New value: +"The regulatory question — SEND IT IN ENGLISH even if the user\nasked in another language, whatever that language is (the corpus is\nEnglish; a non-English query can miss the official text entirely),\nthen answer the user in their own language. Do NOT translate\nword-for-word: phrase it in the LEGAL REGISTER of the act, because\nretrieval matches the wording of the law, not the phrasing of the\nquestion. Measured 2026-08-27 on the live index, same question three\nways: \"must a marketplace show the product passport before purchase,\nwhere is it written?\" returned NOTHING; \"marketplace must make the\ndigital product passport accessible before purchase\" returned the\nCWA guidance (0.96) with the ESPR at 0.001; \"make the digital\nproduct passport accessible to customers before they are bound by a\ncontract of sale\" returned the ESPR itself first (0.94, p.21). Keep\narticle/annex numbers and act identifiers verbatim (\"Article 9\",\n\"ESPR\", \"2024/1781\"): those are matched as metadata, not translated."search1 field changedInput schema / properties / query / descriptionPrevious value: -"The regulatory question, in any language (English works best)."New value: +"The regulatory question — SEND IT IN ENGLISH even if the user\nasked in another language (the corpus is English; a non-English\nquery can miss the official text entirely), then answer the user in\ntheir own language. Keep article/annex numbers and act identifiers\nverbatim (\"Article 9\", \"ESPR\", \"2024/1781\"): those are matched as\nmetadata, not translated."search_eu_textile_regulations1 field changedInput schema / properties / query / descriptionPrevious value: -"The regulatory question, in any language (English works best)."New value: +"The regulatory question — SEND IT IN ENGLISH even if the user\nasked in another language (the corpus is English; a non-English\nquery can miss the official text entirely), then answer the user in\ntheir own language. Keep article/annex numbers and act identifiers\nverbatim (\"Article 9\", \"ESPR\", \"2024/1781\"): those are matched as\nmetadata, not translated."report_answer_issueEU Digital Product Passport (DPP/ESPR) requirements, product readiness scoring and GS1 validation.
EU regulations (GDPR, DORA, NIS2, AI Act, etc.) via Ansvar Gateway. Cited, OAuth + paid.
Temporal search and comparison for official Luxembourg and reviewed EU law, with provenance.
Create & manage EU Digital Product Passports with PassportCraft: textiles, batteries, general goods.
Add one secure layer between your agents and this server.
