searchReturn 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 | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Input 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 / 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)."Input 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)."Input 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."Input 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."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.
Add one secure layer between your agents and this server.