Read-only EU energy-label preflight over MCP: supplier-declared EPREL records, evidence-first
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.5/5 across 5 of 5 tools scored.
The tools are mostly distinct: search finds candidates, two getters retrieve different aspects (full record vs energy label data), compare analyzes metrics, and prepare bundles receipts. The two getters could be confused, but their descriptions clearly differentiate the full record from the energy-label-specific structure.
All tool names follow a verb_noun pattern with a domain prefix (eprel or energy_label), e.g., compare_eprel_product_metrics, get_eprel_product_record. The consistency is high, though 'prepare_energy_label_preflight_receipt' uses 'energy_label' instead of 'eprel', a minor deviation.
Five tools is a well-scoped set for a preflight workflow: search, retrieve record, retrieve label data, compare metrics, and create a signed receipt. Each tool fills a distinct role with no redundancy or bloat.
The toolset covers the core preflight lifecycle: discovery, retrieval, comparison, and evidence bundling. Minor gaps exist, such as no explicit tool for listing supported product groups or metric catalogs, but agents can work around these using search and get.
compare_eprel_product_metricsCompare declared metricsACompare two or more COMPATIBLE records on their COMMON supplier-declared metrics — a value table only. Cross-product-group comparison fails safely as 'incompatible_comparison'; no 'best product', no ranking, no buying advice. Answers come from the queried source at the stated retrieval time: the official EPREL Public API in live mode, or a clearly-labelled synthetic fixture in dev/test — provenance.sourceAuthority names which. Supplier-declared data only; Jithox verifies nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| metricKeys | No | Optional metric keys to restrict the comparison to. | |
| publicRecordIds | No | Public record identifiers to compare; a comparison needs at least 2 (fewer returns 'insufficient_identifiers'), up to 5. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| billing | Yes | |
| product | Yes | |
| receipt | Yes | |
| decision | Yes | |
| retryable | Yes | |
| capability | Yes | |
| provenance | Yes | |
| generatedAt | Yes | |
| limitations | Yes | |
| schemaVersion | Yes | |
| receiptEnvelope | No | |
| decisionCategory | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world, but the description adds valuable behavioral disclosure: provenance.sourceAuthority identifies the live EPREL API vs synthetic fixtures, 'supplier-declared data only' and 'Jithox verifies nothing' warn about data trust, and the failure mode 'incompatible_comparison' is documented. No contradictions 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?
The description is front-loaded with the core purpose in the first sentence. Every subsequent sentence adds a distinct caveat (compatibility, failures, provenance, data trust), making it dense but not redundant. It earns each sentence without being verbose.
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 that an output schema exists, the description need not explain return values. It covers constraints (compatible records, common metrics), failure modes, data source provenance, and limitations (no verification). This is complete for a read-only comparison tool with rich annotations and schema.
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?
Both parameters are fully described in the schema (100% coverage), so the baseline is 3. The description references compatibility and common metrics, which relate to parameter usage, but does not add syntax or format details beyond the schema. It does not meaningfully enhance parameter understanding.
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-resource pair ('Compare two or more COMPATIBLE records on their COMMON supplier-declared metrics') and clearly limits the tool to a value table only, distinguishing it from ranking or advice tools. It also explicitly scopes to common metrics and excludes cross-group comparisons, making 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?
Clear context is provided: the tool is for comparing compatible records on common metrics, and cross-group comparisons fail safely with 'incompatible_comparison'. It explicitly excludes ranking and buying advice, giving when-not-to-use guidance. However, it does not name alternative sibling tools directly, so it stops short of explicit alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_eprel_energy_label_dataGet declared label dataAStructure the supplier-DECLARED energy-label / product-sheet data for one public record. The result states supplierDeclared=true and independentlyVerifiedByJithox=false explicitly — nothing is independently verified. Answers come from the queried source at the stated retrieval time: the official EPREL Public API in live mode, or a clearly-labelled synthetic fixture in dev/test — provenance.sourceAuthority names which. Preflight evidence only — never a conformity, CE, GPSR, safety or market-access determination.
| Name | Required | Description | Default |
|---|---|---|---|
| publicRecordId | No | The public record identifier whose declared label data to return. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| billing | Yes | |
| product | Yes | |
| receipt | Yes | |
| decision | Yes | |
| retryable | Yes | |
| capability | Yes | |
| provenance | Yes | |
| generatedAt | Yes | |
| limitations | Yes | |
| schemaVersion | Yes | |
| receiptEnvelope | No | |
| decisionCategory | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and non-destructive, but the description adds significant behavioral context: it states the result explicitly sets supplierDeclared=true and independentlyVerifiedByJithox=false, clarifies that nothing is independently verified, and explains that answers come from either the live EPREL API or a synthetic fixture with provenance.sourceAuthority identifying the source. It also warns that this is preflight evidence only, not a conformity determination. 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?
The description is composed of three dense but purposeful sentences. It front-loads the core purpose and then adds essential caveats about verification, source, and legal limitations. No redundant or filler content exists.
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 only one parameter with full schema coverage, an output schema, and rich annotations, the description covers the essential context: purpose, source mode (live vs. synthetic), verification status, and preflight-only limitations. It does not explain error handling, but that is not necessary given the output schema and annotations.
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 provides a complete description of publicRecordId ('The public record identifier whose declared label data to return') with 100% coverage. The description adds no additional parameter-level meaning, so a baseline of 3 is appropriate since the schema already handles parameter 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 uses a specific verb 'Structure' and names the resource as 'supplier-DECLARED energy-label / product-sheet data for one public record', which clearly differentiates from sibling tools like search_eprel_products or compare_eprel_product_metrics. It also explicitly contrasts declared vs. independently verified data, further defining the tool's 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 states this is for one public record and explicitly excludes conformity, CE, GPSR, safety, or market-access determinations, giving clear when-not-to-use context. However, it does not name alternative sibling tools (e.g., get_eprel_product_record) for different needs, so it lacks explicit alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_eprel_product_recordGet one public recordAStructure ONE public record by its public record identifier: declared supplier/brand, product group, declared public fields, documents, missing fields, provenance and freshness. 'exact_public_record' / 'no_match_in_queried_source' / 'unavailable'. Answers come from the queried source at the stated retrieval time: the official EPREL Public API in live mode, or a clearly-labelled synthetic fixture in dev/test — provenance.sourceAuthority names which. Supplier-declared data only; Jithox verifies nothing. Preflight evidence only — never a conformity, CE, GPSR, safety or market-access determination.
| Name | Required | Description | Default |
|---|---|---|---|
| publicRecordId | No | The public record identifier (from a prior search candidate). |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| billing | Yes | |
| product | Yes | |
| receipt | Yes | |
| decision | Yes | |
| retryable | Yes | |
| capability | Yes | |
| provenance | Yes | |
| generatedAt | Yes | |
| limitations | Yes | |
| schemaVersion | Yes | |
| receiptEnvelope | No | |
| decisionCategory | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond annotations: it explains data provenance (official EPREL API vs synthetic fixture), freshness (retrieval time), trust level (supplier-declared, unverified), and explicitly excludes conformity/CE/GPSR/safety determinations. It aligns with readOnlyHint and openWorldHint without contradiction.
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 concise and front-loaded with purpose. Four sentences cover the outcome, possible return states, source, trust boundary, and limitations, with no filler or redundant repetition of schema/annotations.
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?
Despite having an output schema and annotations, the description independently supplies critical context: what the tool returns, the three possible outcomes, data source and provenance, verification status, and explicit non-suitability for regulatory determinations. This is complete for a single-parameter retrieval 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 coverage is 100% for the single parameter, so the description does not need to add much. It only restates 'public record identifier' without adding format, examples, or additional semantics, earning the baseline score.
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's function: 'Structure ONE public record by its public record identifier', listing the specific content (declared supplier/brand, product group, public fields, documents, missing fields, provenance, freshness). It distinguishes from sibling tools by focusing on retrieval of a single record, whereas siblings handle search, comparison, or energy label data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a specific public record identifier is available and contrasts with search ('ONE public record'), but it does not explicitly name alternatives or state when not to use this tool. It provides contextual boundaries ('Preflight evidence only') and source information, but lacks an explicit 'use instead of X' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
prepare_energy_label_preflight_receiptPrepare a preflight receiptABundle the preflight lookups into one idempotent Ed25519-signed receipt committing to the FINGERPRINTED inputs, record references, sources, freshness and decision states — provable evidence of WHAT was looked up and WHEN. Attests the lookups, never a registration, conformity or market-access outcome. Preflight evidence only — never a conformity, CE, GPSR, safety or market-access determination.
| Name | Required | Description | Default |
|---|---|---|---|
| bundle | Yes | The preflight results to attest (fingerprinted inputs, sources, decision states — no raw query values). | |
| createdAt | Yes | ISO timestamp the bundle was assembled. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| billing | Yes | |
| product | Yes | |
| receipt | Yes | |
| decision | Yes | |
| retryable | Yes | |
| capability | Yes | |
| provenance | Yes | |
| generatedAt | Yes | |
| limitations | Yes | |
| schemaVersion | Yes | |
| receiptEnvelope | No | |
| decisionCategory | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly), the description reveals idempotency, Ed25519 signing, commitment to fingerprinted inputs and decision states, and explicitly negates any conformity/registration use. This adds critical 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 sentences, front-loaded with the primary action and key attributes (idempotent, signed), followed by a clarifying exclusions sentence. 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 complex tool with nested bundle and output schema, the description covers purpose, exclusions, and behavioral traits (idempotency, signing). The output schema handles return values, so no further explanation needed.
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?
Both parameters have detailed schema descriptions (100% coverage). The description references 'fingerprinted inputs' and 'no raw query values,' consistent with the schema, but adds no new parameter-level meaning beyond what the schema already provides. Baseline 3.
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 ('bundle') and resource ('preflight lookups into one Ed25519-signed receipt'), clearly distinguishing it from the sibling lookup tools. It also states the core output: provable evidence of WHAT and WHEN.
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 states that this tool attests lookups only and 'never a registration, conformity or market-access outcome,' and explicitly excludes CE, GPSR, safety, or market-access determinations. This gives the agent clear when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_eprel_productsSearch public energy-label recordsASearch the queried source by model identifier, registration number, or supplier/brand + product group. Returns CANDIDATE public records with deterministic match kinds and visible ambiguity: 'exact_public_record' / 'possible_match' / 'multiple_matches' / 'no_match_in_queried_source' — a no-match is never 'not registered'. Outage → 'unavailable'; unverified schema → 'source_schema_unverified'; stale → 'stale'. Answers come from the queried source at the stated retrieval time: the official EPREL Public API in live mode, or a clearly-labelled synthetic fixture in dev/test — provenance.sourceAuthority names which. Supplier-declared data only; Jithox verifies nothing. Preflight evidence only — never a conformity, CE, GPSR, safety or market-access determination.
| Name | Required | Description | Default |
|---|---|---|---|
| productGroup | No | Product group to narrow the search (must be covered by the queried source). The official live source searches ONE group at a time: text searches (model/brand) REQUIRE it; registration-number lookups do not. | |
| modelIdentifier | No | The supplier's model identifier to search for. | |
| supplierOrBrand | No | Supplier or trade brand to narrow the search. | |
| registrationNumber | No | A public registration number, when known. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| billing | Yes | |
| product | Yes | |
| receipt | Yes | |
| decision | Yes | |
| retryable | Yes | |
| capability | Yes | |
| provenance | Yes | |
| generatedAt | Yes | |
| limitations | Yes | |
| schemaVersion | Yes | |
| receiptEnvelope | No | |
| decisionCategory | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnly/openWorld annotations, disclosing match kinds (exact_public_record, possible_match, etc.), error states (unavailable, stale, unverified schema), source provenance (live API vs synthetic fixture), and emphasizing that it is preflight evidence only with no verification by Jithox.
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 dense and front-loaded with the core purpose, then efficiently explains match kinds and caveats. It is slightly longer than typical but every sentence contributes meaningful information without fluff.
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, and the description richly covers match semantics, error conditions, data source provenance, and usage constraints. Given the tool's complexity, this is complete and leaves no critical gaps.
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 descriptions cover all four parameters at 100% coverage, including the requirement for productGroup in text searches. The tool description only summarizes the search modes without adding new parameter-level detail, so it stays at the baseline of 3.
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 searches by model identifier, registration number, or supplier/brand, returning candidate records with deterministic match kinds. It is specific about the resource (EPREL public records) and distinguishes it from sibling tools that compare, get, or prepare data.
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 (searching by identifiers) and explains the query patterns, but it does not explicitly reference alternative sibling tools for different needs. The guidance is clear context without explicit exclusions, earning a 4.
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!