Regulatory search engine for EU textile sustainability law: ESPR, DPP, CSRD, CBAM, CWA 18291.
Scored across 8 tools
Each tool targets a distinct retrieval operation (search, outline, fetch, exact match, list), and the two search tools are separated by the clearly-labeled EU textile specialization. However, search and search_eu_textile_regulations could still be confused when the query is about EU textile regulations, and about_reecopedia has no description to clarify its role.
Most names follow a consistent lowercase snake_case verb-first pattern (fetch, find_exact_text, list_corpus_documents, report_answer_issue, search). Minor deviations are about_reecopedia (preposition-led) and document_outline (noun-led), which are still readable and not disruptive.
Eight tools is a well-scoped count for a corpus search and retrieval server. Each tool serves a clear function and none feel redundant or excessive for the apparent purpose.
The set covers the core research workflow well: search with evidence, exact text lookup, document listing, outline navigation, source fetching, and a feedback/report channel. Minor gaps exist around document-level metadata or an explicit way to discover the corpus scope, but no essential retrieval operation is missing.
| 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 and per-part evidence assessment; use fetch for full source text. Query embeddings use Alibaba; candidate passages go to Jina and query plus selected passages to Anthropic.
| 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 declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds valuable behavioral context by revealing the processing pipeline: Alibaba embeddings, Jina candidate passages, and Anthropic for the query and selected passages. This goes beyond the annotations without contradicting them.
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?
Two sentences with no filler: the first front-loads the core return value and directs to fetch for full text; the second compactly summarizes the model pipeline. Every clause 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?
The description covers the core purpose and mentions the output is per-part evidence assessment, and an output schema exists to detail return values. However, it omits any comparison with the highly related sibling search_eu_textile_regulations, which is a significant contextual gap for correct tool selection in a sibling-rich environment.
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 schema description coverage at 0%, the description must compensate for the undocumented 'query' parameter. It partially does by explaining that the query is embedded with Alibaba and later sent to Anthropic, but it doesn't specify query format, length, supported languages, or example forms. The semantic addition is real but thin.
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 cited corpus results by id with per-part evidence assessment, and explicitly contrasts itself with fetch for full source text. It doesn't disambiguate from the sibling search_eu_textile_regulations, so it misses full sibling 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 provides an explicit alternative ('use fetch for full source text') and clearly implies search should be used when cited results or evidence assessments are needed. However, it gives no guidance on when to choose this tool over search_eu_textile_regulations, leaving a gap in the sibling context.
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. Each question part has a model assessment and validated quotations. Query embeddings use Alibaba; candidate passages are sent to Jina and query plus selected passages to Anthropic.
| 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 annotations already establish that the tool is read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond that: it promises citations to the original document and unit, per-part model assessments, validated quotations, and even discloses the model pipeline. This meaningfully shapes agent expectations.
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 front-loaded with the core purpose and each sentence adds useful information about scope, output verification, or internal behavior. It is compact enough for an agent to parse quickly, though the model-pipeline sentence is somewhat detail-heavy.
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, combined with the output schema and annotations, covers the search domain, verification behavior, scope option, and evidence structure. It is missing guidance on how top_k affects retrieval or assessment, and it does not clarify when to prefer this tool over the sibling 'search'. Solid but not fully complete.
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 0% schema description coverage, the description must compensate. It explains that 'scope' is optional and 'narrows corpus partitions', and it implies the query can contain multiple question parts. However, it does not explain what kind of query text is expected or what 'top_k' controls, leaving a partial gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource: 'Search regulatory evidence in English legal register.' This is specific enough to distinguish it from generic browsing or fetching, but it does not explicitly differentiate it from the sibling 'search' tool or mention corpus boundaries.
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 a legal-research use case, but it gives no explicit guidance on when to use this tool instead of 'search', 'fetch', or 'find_exact_text'. It also does not mention prerequisites, limitations, or when results might be insufficient.
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_issuesearch_eu_textile_regulations2 fields changedInput schema / properties / top_k / defaultPrevious value: -6New value: +10Input schema / properties / top_k / descriptionPrevious value: -"Number of passages to return (1-10, default 6)."New value: +"Number of passages to return (1-10, default 10)."about_reecopediadocument_outlinefetchfind_exact_textsearchsearch_eu_textile_regulationsEU 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.
