Skip to main content
Glama

REP27 — EU & UK legal representative

Check which EU/UK representative obligations apply

check_obligations
Read-only

Checks, from a few facts about the company, whether it legally needs an EU GDPR Art. 27 representative, a UK GDPR Art. 27 representative and/or a GPSR Art. 16 EU responsible person, explains why with the legal basis and lists exemptions. Recommends the cheapest REP27 combination. Returns result_url, a personal page with the result.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
langNoLanguage code for the answer (ISO 639-1, e.g. en, it, es, fr, de, pt, nl, pl, ja, zh)en
currencyNoCurrency to also show prices in: EUR, USD, GBP, CAD, AUD, NZD, CHF, CZK, JPY or NOK (ECB rate)EUR
offers_to_euYesTrue if the company offers goods or services to people in the EU/EEA or monitors their behaviour (tracking, ad profiling)
offers_to_ukNoTrue if the company offers goods or services to people in the UK or monitors their behaviour
has_eu_branchNoTrue if the company has an establishment (branch or subsidiary) in the EU
has_uk_branchNoTrue if the company has an establishment in the UK
established_inYesCountry where the company is established, name or ISO code (e.g. United States, US, China)
public_authorityNoTrue if the organisation is a public authority or body
data_requests_per_yearNoExpected data-subject requests per year (access, erasure…), 0 if unknown
sells_consumer_products_euNoTrue if it places physical consumer products on the EU market (own shop or marketplaces like Amazon, Etsy, eBay)
sells_consumer_products_ukNoTrue if it places physical consumer products on the UK market
health_or_special_category_dataNoTrue if it processes health or other special-category data (Art. 9) or criminal-offence data at scale
occasional_low_risk_processing_onlyNoTrue if personal data of EU/UK people is processed only occasionally, at low risk and without special categories (Art. 27(2) exemption)
has_eu_importer_or_manufacturer_in_euNoTrue if an EU-based manufacturer, importer or authorised representative already covers the products

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description adds real value beyond them: it explains why the answer is given (legal basis), that exemptions are listed, that a cheapest-combination recommendation is produced, and that a personal result_url page is returned. It does not mention auth or rate limits, but for a read-only assessment tool this is solid added context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tightly packed sentences, each earning its place: what is determined, what the output explains, what is recommended, and what is returned. Front-loaded with the core action and no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 14-parameter legal-assessment tool with a full output schema, the description covers purpose, reasoning output, exemptions, recommendation, and the result_url artifact. It omits any hint about how many/which facts are minimally required beyond the two required params, a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% across all 14 parameters, so the schema already carries the full semantics (including defaults and enum-like value lists for lang and currency). The description only says 'a few facts about the company' and adds no field-level guidance, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (checks) plus the exact determinations it makes: EU GDPR Art. 27 representative, UK GDPR Art. 27 representative, GPSR Art. 16 responsible person. An agent can distinguish this from informational siblings like about_rep27 purely from the description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It signals the trigger condition ('from a few facts about the company') and that it is a determination tool rather than an informational one, but never states when not to use it or routes the agent between this and the sibling about_rep27. Usage is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources