REP27 — EU & UK legal representative

Check which EU/UK representative obligations apply

check_obligations

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

Name	Required	Description	Default
`lang`	No	Language code for the answer (ISO 639-1, e.g. en, it, es, fr, de, pt, nl, pl, ja, zh)	en
`currency`	No	Currency to also show prices in: EUR, USD, GBP, CAD, AUD, NZD, CHF, CZK, JPY or NOK (ECB rate)	EUR
`offers_to_eu`	Yes	True if the company offers goods or services to people in the EU/EEA or monitors their behaviour (tracking, ad profiling)
`offers_to_uk`	No	True if the company offers goods or services to people in the UK or monitors their behaviour
`has_eu_branch`	No	True if the company has an establishment (branch or subsidiary) in the EU
`has_uk_branch`	No	True if the company has an establishment in the UK
`established_in`	Yes	Country where the company is established, name or ISO code (e.g. United States, US, China)
`public_authority`	No	True if the organisation is a public authority or body
`data_requests_per_year`	No	Expected data-subject requests per year (access, erasure…), 0 if unknown
`sells_consumer_products_eu`	No	True if it places physical consumer products on the EU market (own shop or marketplaces like Amazon, Etsy, eBay)
`sells_consumer_products_uk`	No	True if it places physical consumer products on the UK market
`health_or_special_category_data`	No	True if it processes health or other special-category data (Art. 9) or criminal-offence data at scale
`occasional_low_risk_processing_only`	No	True 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_eu`	No	True if an EU-based manufacturer, importer or authorised representative already covers the products

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 15, 2026

TDQS

A4/5.0

Behavior4/5

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

Adds real behavior beyond the annotations: it explains the legal basis, enumerates exemptions, recommends a cheapest REP27 combination, and — importantly — discloses that it persists a 'personal page' returned as result_url, which is consistent with readOnlyHint=false. It does not cover cost, rate limits, or that results are advisory rather than legal advice, but the key side effect is disclosed.

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: what is checked, what is produced alongside the verdict (legal basis, exemptions, cheapest combination), and what is returned. Front-loaded with the core action and no wasted words.

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?

With 14 parameters and an output schema in place, the description correctly focuses on outcome shape (verdict + reasoning + exemptions + recommendation + result_url) rather than enumerating inputs. Minor gaps: no note that the result page is persisted/shareable or that output is advisory, which would matter for a legal-adjacent tool.

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 semantics; the description only gestures at 'a few facts about the company' without adding meaning to individual inputs. Baseline 3 applies when the schema does the heavy lifting.

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?

Specific verb plus resource: it determines whether an EU GDPR Art. 27 representative, UK GDPR Art. 27 representative and/or GPSR Art. 16 responsible person is legally required. The three named obligations and the 'explains why / lists exemptions / recommends cheapest REP27 combination' framing make it clearly distinct from the informational sibling about_rep27.

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?

The phrase 'from a few facts about the company' implies this is the assessment step a user runs when they have company details, but it never states when to use this versus about_rep27 or get_plans, and gives no prerequisites or exclusions. Usage is inferable rather than stated.

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

All REP27 — EU & UK legal representative tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?