Regulatory search engine for EU textile sustainability law: ESPR, DPP, CSRD, CBAM, CWA 18291.
What Reecopedia is, who runs it, and its privacy policy.
| 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe behavior is covered. The description adds useful content scope but does not disclose anything beyond that, such as whether the data is static, how current the privacy policy is, or the response structure.
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 compact phrase that captures the three informational facets without any filler. It front-loads the core subject and avoids repetition of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, an output schema, and annotations conveying safety, the description provides everything needed to select and invoke the tool. An agent can confidently call this tool for meta-questions about Reecopedia.
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 tool has no parameters, so parameter-semantic confusion is impossible. The description need not document parameter meanings; the schema is fully trivially complete.
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 identifies what the tool does: it explains Reecopedia, its operators, and privacy policy. While it lacks an explicit verb like 'returns' or 'displays', the content scoping is unmistakable and differentiates it from search/fetch and other sibling tools.
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 usage context is implied: use this tool when someone asks what Reecopedia is, who runs it, or its privacy policy. However, there is no explicit guidance about when not to use it or how it compares to sibling tools such as search, fetch, or document_outline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the heading tree (table of sections) of an indexed document,
so you can explore its structure before fetching pages. Each entry has
the heading text, its full path, depth and first page: pass the page to
fetch as "#p" to read it.
| Name | Required | Description | Default |
|---|---|---|---|
| document | Yes | Exact source file name as returned by `search` / `search_eu_textile_regulations` (e.g. "CELEX-02024R1781-20240628.pdf"). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is read-only and non-destructive; the description adds useful behavioral context by stating the output is the heading tree, not page content, and that each entry includes text, path, depth, and first page. No contradiction with 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?
Two focused sentences, with the main purpose front-loaded. The fetch composition note is dense but earns its place because it tells the agent exactly how to use the result.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only tool with an output schema, the description covers purpose, output structure, prerequisite (indexed document), and integration with fetch. Nothing essential 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 schema already documents the document parameter fully (exact source file name from search, with an example), so the description adds little beyond that. A baseline of 3 is appropriate because schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Return the heading tree (table of sections) of an indexed document'. It clearly frames the tool's role as structure exploration, distinguishing it from sibling fetch and search tools.
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?
Provides clear usage context: explore the heading tree before fetching pages, and passes returned page references to fetch with explicit syntax. It does not spell out when-not-to-use or name alternative tools as exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full text of a regulatory document page returned by search.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | A result id from `search`, format "<source-file>#p<page>" (e.g. "REG_2024_1781_ESPR_EN.pdf#p39"). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that it retrieves full text, but does not disclose error handling, pagination, or other behavioral details. With annotation coverage, a 3 is appropriate.
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 sentence that is front-loaded with the verb and object. It contains no fluff or redundant phrasing, making it highly concise and effective.
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 one-parameter tool with an output schema and annotations, the description is complete. It specifies the action, resource, and id source, giving the agent everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the id parameter is thoroughly documented with format examples. The main description's mention of 'returned by search' adds little beyond what the schema already states, so baseline 3 is warranted.
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 fetches the full text of a regulatory document page, with a specific verb and resource. It also indicates the page comes from a search result, distinguishing it from sibling tools like document_outline that serve a different purpose.
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 the tool should be used after `search` to retrieve full text for a page identified by a result id. It provides clear context but does not explicitly list when-not-to-use or alternatives, which would warrant a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find literal occurrences of an exact string in the corpus — article
numbers, regulation ids, precise wording (e.g. "Article 8(3)",
"2024/1781"). Complements semantic search: use this when you need the
exact string, not the concept. Returns one match per (file, page) with an
occurrence count and a text snippet; read the full page with fetch.
Scans the literal chunk text of both indexes the semantic search serves
(the two chunkings differ, so some passages exist in only one); the
synthetic contextual enrichment is NOT scanned — it is not document text.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The exact string to find (min 3 characters). | |
| document | No | Optional exact source file name to restrict the search. | |
| max_results | No | Max (file, page) matches to return (1-50, default 20). | |
| case_sensitive | No | Exact-case match (default False). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and non-destructive hints, but the description adds substantial behavioral detail: returns one match per (file, page) with occurrence count and snippet, scans both chunk indexes, notes the two chunkings differ, and explicitly excludes the synthetic contextual enrichment from scanning. This goes well beyond the annotations and is fully consistent with 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?
The description is multi-sentence but front-loads the core purpose and then layers usage guidance, return behavior, and scanning scope. Every sentence contributes value; however, it is slightly verbose compared to the minimal requirement. Efficient but not ultra-tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (sibling tools, two chunk indexes, synthetic exclusion) and that an output schema exists, the description is complete. It covers purpose, when to use, return format, scanning scope, and how to follow up with `fetch`. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already well-documented in the input schema. The description does not add parameter-specific semantics beyond the schema; it mentions examples of what to search for, but those are illustrative of purpose, not parameter meaning. Baseline 3 is appropriate.
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?
Description states a specific verb ('Find literal occurrences') with a clear resource ('exact string in the corpus') and provides concrete examples. It explicitly differentiates from semantic `search` by stating 'use this when you need the exact string, not the concept.' This fully distinguishes the tool from siblings.
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 names the alternative `search` explicitly and gives the selection condition ('when you need the exact string, not the concept'). It also directs the agent to `fetch` for full-page reads, providing clear context and an alternative action. No gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report that an answer built from Reecopedia search results was wrong, misleading or incomplete. The report (query + reason, nothing else — no personal data) enters Reecopedia's human curation queue and is reviewed weekly to correct the corpus and retrieval quality.
Call this when the user flags an answer as wrong, or when you notice the retrieved passages contradict the answer you gave.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The original search query the bad answer was built from. | |
| reason | Yes | 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?
Annotations provide minimal behavioral signals (readOnlyHint=false, destructiveHint=false), so the description adds meaningful context: the report enters a human curation queue, is reviewed weekly, and contains no personal data. It does not contradict annotations and adds transparency about side effects and data handling.
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 two concise paragraphs. The first sentence states the purpose directly, the second explains the workflow, and the final sentence gives usage triggers. Every sentence adds value with no redundant or vague content.
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 tool with two well-documented params, the description covers purpose, usage triggers, and behavioral outcome. It also clarifies privacy details (no personal data) and the review cycle. An output schema exists, so return-value details are not needed. The description is fully complete for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both 'query' and 'reason'. The description reinforces that only these two fields are sent, but does not add deeper semantic meaning beyond the schema. Therefore the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Report') and identifies the exact resource ('an answer built from Reecopedia search results') and the scope (wrong, misleading, or incomplete). It clearly distinguishes this from sibling tools like search and fetch by focusing on reporting issues rather than retrieving content.
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: 'Call this when the user flags an answer as wrong, or when you notice the retrieved passages contradict the answer you gave.' It provides concrete, actionable triggers and implies it is not for general feedback or other purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
LANGUAGE CONTRACT — READ BEFORE CALLING. Corpus is English. Call this
tool ONLY with an English query in the legal register of the act (the
wording of the Official Journal), not a tourist translation. Keep act
identifiers and rewrite article/annex numbers into English (Article 9, Annex I; 第9条 / Artikel 9 / articolo 9 → Article 9). After you
receive passages, answer the user in the user's language; quote the law
in English with (file, page, article). If the user spoke another
language, YOU translate before this call. Do not send non-English text
in query.
Deep-research listing interface over the same corpus as
search_eu_textile_regulations (ESPR, DPP, CSRD, CBAM, EU ETS, CWA 18291,
JRC studies).
Use this when you need a browsable result list rather than an answer:
returns {results: [{id, title, text, url}]}. Pass a result id to the
fetch tool to read the full document page. For a direct regulatory
answer use search_eu_textile_regulations instead.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 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. Act identifiers stay verbatim ("ESPR", "2024/1781"): they are matched as metadata. Article and annex numbers must be rewritten into their English form, because that is how they are matched: "第9条" and "Artikel 9" do not match, "Article 9" does. Measured 2026-08-27 on the live index, one question three ways: "must a marketplace show the product passport before purchase, where is it written?" returned NOTHING; "marketplace must make the digital product passport accessible before purchase" returned the CWA guidance (0.96) with the ESPR at 0.001; "make the digital product passport accessible to customers before they are bound by a contract of sale" returned the ESPR itself first (0.94, p.21). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and non-destructive, and the description adds meaningful behavioral context: non-English queries violate the contract and their passages 'must be discarded, not answered from', article/annex numbers must be in English to match, and results are structured for browsing rather than answering. It also clarifies that after receiving passages, the assistant should answer in the user's language while quoting the law in English.
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 all-caps language contract and clearly organized, but it is verbose for a single-parameter tool and repeats content already present in the input schema. It is readable and purposeful, yet not as concise as it could be.
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?
All necessary context is present: language constraints, valid query form, result structure, the handoff to `fetch`, and the explicit alternative tool for direct answers. Given the schema richness and annotations, nothing essential is missing for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, and the schema's `query` parameter already details the English-only requirement, legal register, act identifier handling, article/annex rewriting, and measured retrieval examples. The tool-level description largely repeats this guidance rather than adding new parameter-level semantics.
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 identifies the tool as a 'deep-research listing interface' over the same corpus as `search_eu_textile_regulations`, and specifies that it returns a browsable result list with `{results: [{id, title, text, url}]}`. It distinguishes itself from siblings by saying it is for listing results rather than producing a direct regulatory answer.
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 explicitly states when to use the tool — when a browsable result list is needed — and when not to: for a direct regulatory answer, use `search_eu_textile_regulations` instead. It also gives concrete handoff guidance, telling the agent to pass a result `id` to the `fetch` tool to read the full document.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
LANGUAGE CONTRACT — READ BEFORE CALLING. Corpus is English. Call this
tool ONLY with an English query in the legal register of the act (the
wording of the Official Journal), not a tourist translation. Keep act
identifiers and rewrite article/annex numbers into English (Article 9, Annex I; 第9条 / Artikel 9 / articolo 9 → Article 9). After you
receive passages, answer the user in the user's language; quote the law
in English with (file, page, article). If the user spoke another
language, YOU translate before this call. Do not send non-English text
in query.
Primary question-answering search over the Reecopedia corpus of EU textile sustainability regulations. Use this for natural-language regulatory questions.
Returns the most relevant passages with citations (source file, page, section); answer ONLY from these passages and cite them. Corpus: ESPR 2024/1781, Digital Product Passport, CSRD, CBAM, EU ETS, CWA 18291, JRC BREF and textile preparatory studies, EP studies.
For a browsable result list instead of an answer, use search.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 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. Act identifiers stay verbatim ("ESPR", "2024/1781"): they are matched as metadata. Article and annex numbers must be rewritten into their English form, because that is how they are matched: "第9条" and "Artikel 9" do not match, "Article 9" does. Measured 2026-08-27 on the live index, one question three ways: "must a marketplace show the product passport before purchase, where is it written?" returned NOTHING; "marketplace must make the digital product passport accessible before purchase" returned the CWA guidance (0.96) with the ESPR at 0.001; "make the digital product passport accessible to customers before they are bound by a contract of sale" returned the ESPR itself first (0.94, p.21). | |
| top_k | No | Number of passages to return (1-10, default 10). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only and non-destructive, but the description adds important behavioral detail: English-only querying, citations in a specific format, answering only from retrieved passages, and discarding non-English query results. No contradiction with the annotations was found.
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 critical language contract, then gives the tool's purpose, return behavior, corpus scope, and sibling alternative. Every block adds necessary invocation guidance, and even the longer language-contract section 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?
Given the output schema, read-only annotations, and tool complexity, the description covers everything needed: query language constraints, translation behavior, citation format, answer grounding, corpus coverage, and when to use a sibling tool. No critical gap is apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the input schema's `query` description already covers English-only input, legal-register wording, and Article/Annex number rewriting. The description reinforces these points and adds the translate-before-call instruction, but the schema carries most of the parameter-semantics burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise question-answering search over the Reecopedia EU textile corpus, not just 'search EU textile regulations'. It explicitly differentiates itself from `search` by describing its answer-oriented behavior and by naming the browsable-list alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use this tool for natural-language regulatory questions and routes browsable-result needs to `search`. It also sets clear preconditions: the query must be in English and in the legal register of the act, and the agent must translate before calling when the user speaks another language.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
EU 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.
Most tools have clearly distinct purposes: semantic answering, browsable search, exact-string lookup, outline navigation, full-page fetch, about, and feedback. The main ambiguity is between `search` and `search_eu_textile_regulations`, but their descriptions do separate result-list browsing from cited passage answers.
All names use lowercase snake_case, but the pattern is mixed: `fetch` and `search` are one-word verbs, `document_outline` is a noun compound, `about_reecopedia` begins with a preposition, and the rest use verb_object naming. The inconsistency is readable but not predictable enough to infer tool behavior from names alone.
Seven tools is a well-scoped size for a specialized regulatory-corpus reader: Q&A, browse, exact search, outline, fetch, about, and feedback each earn their place. There is no redundancy or bloated surface.
The toolset covers the full retrieval lifecycle: ask a regulatory question, browse results, find exact strings, inspect document structure, fetch full pages, and report bad answers for curation. No obvious dead ends or missing operations are apparent for the stated domain.
