Regulatory search engine for EU textile sustainability law: ESPR, DPP, CSRD, CBAM, CWA 18291.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.3/5 across 6 of 6 tools scored.
The two search tools (search and search_eu_textile_regulations) have nearly identical descriptions, making it ambiguous which to use. Other tools are distinct.
Naming is mostly snake_case but mixes verb-only (fetch, search) with verb_phrase (find_exact_text, search_eu_textile_regulations) and a prepositional tool (about_reecopedia).
Six tools is a reasonable count for a specialized search system, though the redundant search tools could be consolidated.
Covers core functionality: search, exact lookup, document structure, and page retrieval. Missing listing of available documents or corpus updates, but sufficient for querying.
about_reecopediaAbout Reecopedia & privacyAWhat 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 openWorldHint=false. The description adds the content scope (subject, operator, privacy) but no deeper behavioral context such as return format or whether it accesses external data. It does not contradict 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 one short, front-loaded sentence that succinctly conveys the tool's purpose without any redundant wording.
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, parameterless informational tool with an output schema and clear annotations, the description fully covers the essential scope. No additional details about return values or behavior are necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema already covers everything. The description adds context about the informational nature, but parameter-specific semantics are not applicable. Baseline 4 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 clearly states what information the tool provides (what Reecopedia is, who runs it, privacy policy), which distinguishes it from sibling tools focused on searching or fetching content. However, it lacks an explicit action verb, so it is clear but not a perfect verb-driven specification.
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 tool's usage is implied by its name and purpose; users would naturally select it when seeking about/platform information. But the description does not explicitly state when to use it versus alternatives or provide any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
document_outlineDocument outline (headings index)AReturn 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 readOnlyHint=true, so the safety profile is established. The description adds that each entry includes heading text, full path, depth, and first page, and how to construct the fetch page reference, which is useful 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?
Two front-loaded sentences with no waste; every sentence contributes purpose and usage context.
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 simple one-parameter tool with annotations and output schema, the description covers purpose, entry contents, and integration with fetch. It is sufficiently 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?
The input schema fully describes the only parameter with 100% coverage, so baseline 3 applies. The tool description does not add additional parameter-level detail, though it clarifies the output's page field usage.
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 a specific verb ('Return') and resource ('heading tree of an indexed document'), and differentiates from siblings by focusing on structure exploration before fetching pages.
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 instructs the agent to use this tool to explore structure before fetching pages, and explains how to pass the resulting page reference to `fetch`. It does not explicitly exclude alternative tools, but provides clear situational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fetchFetch document page (deep research interface)AFetch 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, covering the safety profile. The description adds that the tool returns full text, but provides no further behavioral details such as error handling, performance, or size limits. It meets the baseline with annotations but doesn't go beyond.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence conveys the essential action and source of input. No redundancy, front-loaded with the verb and object, and 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 tool with one well-documented parameter, presence of output schema, and readOnlyHint annotation, the description is complete. It explains what the tool does and where the input comes from, without over-explaining.
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 a detailed description of the `id` parameter, including format and example. The tool description merely echoes 'returned by search' without adding new semantic meaning, so it remains at the baseline for high 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 clearly states the action ('Fetch'), the resource ('full text of a regulatory document page'), and the provenance ('returned by `search`'). It distinguishes itself from sibling tools like `document_outline` and `find_exact_text` by focusing on page-level retrieval.
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 phrase 'returned by `search`' provides clear context on when to use this tool (after a search yields an id). While it doesn't explicitly list alternatives or exclusions, the prerequisite is unmistakable and sufficient for a single-purpose fetch tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_exact_textFind exact text (literal search)AFind 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 declare readOnlyHint=true and openWorldHint=false, but the description adds substantial behavioral detail: returns one match per (file, page) with an occurrence count and snippet, scans both chunkings used by semantic search, and explicitly excludes synthetic contextual enrichment. This goes well beyond the annotations and is 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?
Three sentences cover purpose, usage guidance, return format, and scanning scope without redundancy. The description is front-loaded with the core function and every sentence earns its place, with no fluff or repetition of schema or annotation details.
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?
An output schema exists, so return value details are not strictly required, but the description still mentions occurrence counts and snippets. It also explains the two-chunking nuance and the exclusion of synthetic enrichment, which is critical for trusting results. Given the tool's moderate complexity, the description is 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?
Schema coverage is 100% with clear parameter descriptions, so baseline is 3. The description adds practical examples of valid `text` inputs ('Article 8(3)', '2024/1781') and clarifies the matching scope (literal chunk text, not synthetic enrichment), which enriches parameter meaning and lifts it to 4.
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 ('Find literal occurrences') and identifies the resource ('the corpus'), then gives concrete examples ('Article 8(3)', '2024/1781') and explicitly distinguishes from sibling `search` by saying it complements semantic search. This makes the tool's unique purpose unmistakable.
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 provides explicit when-to-use guidance: 'use this when you need the exact string, not the concept,' directly contrasting with semantic `search`. It also directs users to read full pages via `fetch`, indicating the complementary workflow and naming sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
report_answer_issueReport a wrong or misleading answerAInspectReport 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.
searchSearch (deep research interface)ASearch EU textile sustainability regulations (ESPR, DPP, CSRD, CBAM,
EU ETS, CWA 18291, JRC studies). Deep-research interface: returns a list
of matching regulatory passages as {results: [{id, title, text, url}]}.
Pass a result id to the fetch tool to get the full document page.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The regulatory question, in any language (English works best). |
| 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 the description adds useful behavioral detail: it returns only matching passages as structured results, not full documents, and requires a follow-up fetch by id. The listed domain scope and result shape go 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?
The description is two tight sentences, front-loading the domain and scope, then stating the output shape and the fetch workflow. Every sentence adds necessary information with no 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?
For a one-parameter search tool with output schema and read-only annotations, the description is complete: it covers the subject domain, result format, and next-step workflow. The output schema already documents return values, so the description need not elaborate further.
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 fully describes the single query parameter (100% schema coverage), including language guidance. The tool description does not add parameter-specific semantics beyond framing the query as a regulatory question, so the schema carries the 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?
The description states a specific verb and resource: 'Search EU textile sustainability regulations' with a defined scope (ESPR, DPP, CSRD, CBAM, EU ETS, CWA 18291, JRC studies). It clearly communicates a deep-research interface returning passages, but it does not explicitly distinguish from the similarly named sibling 'search_eu_textile_regulations'.
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 clear usage context: formulate a regulatory question, receive matching passages, then pass an id to fetch for the full page. However, it does not explicitly say when to use this tool instead of siblings like find_exact_text or search_eu_textile_regulations, so no exclusions are documented.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_eu_textile_regulationsSearch EU textile regulationsASearch the Reecopedia corpus of EU textile sustainability regulations.
Returns the most relevant regulatory passages with citations (source file, page, section). Answer the user's question 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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The regulatory question, in any language (English works best). | |
| 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?
Beyond the readOnlyHint annotation, the description discloses the return structure (source file, page, section), the constraint to answer only from retrieved passages, and the list of covered regulations, adding meaningful behavioral context without contradicting 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 two sentences, front-loaded with purpose, and every clause adds value—including the corpus list and the 'ONLY from passages' instruction—without any redundancy or 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?
Given the presence of an output schema, the description appropriately avoids detailing return values. It sufficiently covers corpus scope, citation behavior, and usage rules, making it fully adequate for tool selection and 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 coverage is 100%, so the parameters are already documented. The description adds minimal semantic value, only reinforcing that the query represents the user's question; it does not elaborate on top_k beyond 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 clearly identifies the action ('Search the Reecopedia corpus of EU textile sustainability regulations') and specifies the output format ('passages with citations'), effectively distinguishing it from the generic sibling 'search' tool by domain and scope.
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 establishes clear context for use (EU textile regulations in the Reecopedia corpus) and a firm rule ('Answer the user's question ONLY from these passages and cite them'), but it does not explicitly discuss alternatives or exclusions relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!