This MCP server connects AI assistants to the Polish Data Protection Authority (UODO) decisions portal, enabling natural language search and retrieval of administrative decisions, GDPR enforcement details, fines, and legal reasoning.
Capabilities:
Search decisions (uodo_search_decisions): Full-text search with Polish stemming, comma-separated OR support, filtering by case number signature and date range, pagination, and newest-first sorting.
Get full decision (uodo_get_decision): Retrieve complete decision by ID, including metadata (categories, legal bases, issuing President), verbatim ruling, and full justification; automatically saves a Markdown copy in local stdio mode.
List search fields (uodo_list_search_fields): Discover all searchable fields and their data types for building advanced queries.
Additional features: No API key required, in-memory cache (15-minute TTL), 15-second request timeout, offline archive of downloaded decisions, and dual operation modes (stdio for local Claude Desktop integration, HTTP for remote deployments).
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@UODO MCP Wyszukaj 5 decyzji o karach za naruszenie RODO"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
# UODO MCP — decyzje Prezesa UODO w Claude
Serwer MCP, którym podłączysz Claude Desktop (oraz inne rozwiązania wspierające MCP) do orzeczenia.uodo.gov.pl — oficjalnego portalu decyzji Prezesa Urzędu Ochrony Danych Osobowych. Zamiast ręcznie przeszukiwać portal i kopiować fragmenty decyzji, pytasz Claude'a w języku naturalnym w Claude Desktop, a on przeszukuje bazę, pobiera pełne treści do plików markdown i cytuje sentencję i uzasadnienie.
To narzędzie do wyszukiwania i pracy na treści decyzji. Nie interpretuje prawa za Ciebie i nie zastępuje analizy prawnika — patrz Zastrzeżenie.
Dla każdego, kto na co dzień szuka precedensów, argumentacji albo wysokości kar w orzecznictwie UODO:
prawnicy i kancelarie przygotowujące opinie, pisma czy analizy ryzyka opartych na praktyce decyzyjnej UODO,
inspektorzy ochrony danych (IOD), którzy sprawdzają, jak Prezes UODO oceniał podobne naruszenia w innych podmiotach,
działy compliance, które potrzebują szybkiego przeglądu kar w danym sektorze albo za dany typ naruszenia,
badacze i studenci prawa analizujący linię orzeczniczą UODO.
Nie musisz znać składni zapytań ani struktury API — piszesz do Claude w języku naturalnym, on tłumaczy to na wywołania narzędzi.
Related MCP server: io.github.mister-franklin/gdpr-decisions
Sekcja dla prawników, radców prawnych, adwokatów i IOD oceniających ryzyko wdrożenia tego serwera MCP w kancelarii lub dziale prawnym.
Zweryfikuj kod samodzielnie, zanim go podłączysz. Nie musisz mieć zaplecza programistycznego — audyt możesz zlecić narzędziu AI (np. Claude Code, Codex, Cursor):
Pobierz repozytorium na dysk (plik .zip lub git clone).
Otwórz je w wybranym narzędziu AI do analizy kodu.
Poproś o audyt, np.: "Przeanalizuj ten kod pod kątem bezpieczeństwa i prywatności danych. Sprawdź, dokąd wysyłane są dane, czy są ślady złośliwego kodu oraz podatności typu prompt injection."
To kilka minut pracy, a dają pełną kontrolę nad tym, co serwer faktycznie robi, zanim zaufasz mu instalując go na swoim urządzeniu.
Jeśli chcesz lepiej zrozumieć serwery MCP i dowiedzieć się, jak działają oraz jakie zagrożenia za sobą niosą, polecamy szkolenie r.pr. Michała Pietrzyka (AI Lead, Kancelaria JDP) "Claude AI w pracy prawnika" — mec. Pietrzyk ma tam spory blok poświęcony właśnie tej kwestii: Claude AI w pracy prawnika – warsztaty online.
Pełnotekstowe wyszukiwanie w decyzjach UODO — kary administracyjne, upomnienia, nakazy dostosowania przetwarzania do RODO
Filtrowanie po sygnaturze (DKN, DS, DKE, …) i zakresie dat
Pobieranie pełnej treści decyzji — metadane, sentencja/decyzja i pełne uzasadnienie
Bogate metadane — kategorie tematyczne, podstawy prawne (artykuły RODO, ustawy krajowe, orzecznictwo), Prezes wydający decyzję, status publikacji
Lokalne archiwum — w trybie stdio każda pobrana decyzja zapisuje się jako plik .md do ~/Documents/uodo-orzeczenia (zmienisz przez zmienną środowiskową UODO_OUTPUT_DIR) do dalszej pracy offline
Cache w pamięci (15 minut) ograniczający liczbę zapytań do API
Ochrona przed zawieszeniem — 15-sekundowy limit czasu na każde zapytanie do API
Dwa tryby pracy — stdio do lokalnego użytku w Claude Desktop, HTTP do wdrożenia zdalnego/hostowanego (patrz Dla programistów)
Krok 1. Zainstaluj Node.js w wersji 20 lub nowszej.
Krok 2. Otwórz plik konfiguracyjny Claude Desktop:
Windows: Win + R → wpisz %APPDATA%\Claude → otwórz claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Krok 3. Dodaj poniższy wpis do sekcji mcpServers (jeśli plik jest pusty, wklej całość):
{
"mcpServers": {
"UODO": {
"command": "npx",
"args": ["-y", "@thescalablelegalmarketer/uodo-mcp"]
}
}
}Krok 4. Zapisz plik i zrestartuj Claude Desktop. Przy pierwszym uruchomieniu Claude sam pobierze serwer — nie trzeba nic dodatkowo instalować.
Klucz API nie jest potrzebny — API portalu UODO jest publicznie dostępne.
Wyszukaj w bazie UODO 5 decyzji dotyczących niezgłoszenia naruszenia
ochrony danych w terminie 72 godzin. Dla każdej podaj:
- sygnaturę i datę decyzji
- sentencję (dosłowny cytat)
- wysokość nałożonej kary
- główny argument Prezesa UODOZnajdź decyzje UODO dotyczące sektora mieszkaniowego (wspólnoty
mieszkaniowe, spółdzielnie). Jakie naruszenia RODO były najczęstsze
i jakie kary były nakładane?Pobierz decyzję DKN.5131.16.2025 i przeanalizuj, jakie kryteria
Prezes UODO zastosował przy ustalaniu wysokości kary pieniężnej.uodo_search_decisionsWyszukuje decyzje UODO. Wyniki sortowane od najnowszych. Wszystkie parametry opcjonalne.
Parametr | Typ | Opis |
| string | Wyszukiwanie pełnotekstowe w treści decyzji, np. |
| string | Fragment sygnatury, np. |
| string | Format |
| string | Format |
| number | Maks. 100, domyślnie 20 |
| number | Przesunięcie stronicowania, licząc od 0 |
Wskazówka: sygnatury mają postać DKN.5131.X.RRRR (postępowania w sprawie kar), DS.523.X.RRRR (postępowania skargowe), DKE.561.X.RRRR (postępowania kontrolne). Prefiks typu DKN.5131 zwróci wszystkie decyzje danego rodzaju postępowania.
uodo_get_decisionPobiera pełną decyzję po ID. Zwraca metadane, dosłowną sentencję/decyzję i pełne uzasadnienie. W trybie stdio dodatkowo zapisuje plik .md do UODO_OUTPUT_DIR.
Parametr | Typ | Opis |
| string | Wymagany. ID decyzji z wyników |
uodo_list_search_fieldsZwraca listę dostępnych pól wyszukiwania wraz z ich typami danych. Przydaje się przy budowaniu bardziej złożonych zapytań.
Limit terminów w wyszukiwaniu OR — przy wyszukiwaniu wielu terminów rozdzielonych przecinkiem bardzo szerokie zapytania mogą przekroczyć limit długości URL; w razie problemu podziel zapytanie na kilka osobnych wywołań
Puste pola title_pl/keywords w wynikach wyszukiwania — indeks portalu UODO obecnie ich nie uzupełnia; pełne metadane (w tym kategorie tematyczne) są dostępne dopiero po pobraniu konkretnej decyzji przez uodo_get_decision
Cache w pamięci — 15 minut TTL, czyści się przy restarcie procesu
Tryb HTTP nie zapisuje plików .md (brak dostępu do systemu plików użytkownika)
Urząd Ochrony Danych Osobowych to polski organ nadzorczy w rozumieniu art. 51 RODO. Prezes UODO wydaje wiążące decyzje w postępowaniach dotyczących naruszeń ochrony danych osobowych — w tym kary administracyjne (art. 83 RODO), upomnienia (art. 58 ust. 2 lit. a), nagany (art. 58 ust. 2 lit. b) oraz nakazy dostosowania przetwarzania do przepisów.
Portal orzeczenia.uodo.gov.pl publikuje pełne treści tych decyzji. API portalu jest publicznie dostępne, bez uwierzytelniania.
To narzędzie służy wyłącznie do wyszukiwania i analizy orzecznictwa — nie stanowi porady prawnej i jej nie zastępuje. Zawsze weryfikuj cytaty względem źródła pierwotnego (portalu UODO) przed użyciem ich w piśmie procesowym, opinii prawnej czy dokumentacji compliance.
npm run dev # serwer stdio (TypeScript, bez builda)
npm run dev:http # serwer HTTP na porcie 3000
npm run build # type-check + bundlowanie esbuild → dist/
npm run start # uruchomienie skompilowanego bundla stdio
npm run start:http # uruchomienie skompilowanego serwera HTTPBuild i uruchomienie przez Docker:
docker build -t uodo-mcp .
docker run -p 3000:3000 uodo-mcpEndpoint MCP: http://localhost:3000/mcp
Health check: http://localhost:3000/health
Do wdrożenia nadaje się dołączony Dockerfile — np. na Railway, Render lub Fly.io.
uodo-mcp/
├── src/
│ ├── types.ts ← interfejsy TypeScript dla API UODO
│ ├── api.ts ← klient API UODO + cache w pamięci
│ ├── format.ts ← parsowanie HTML, formatowanie tekstu, zapis plików
│ ├── server.ts ← fabryka createMcpServer() — rejestracja narzędzi
│ ├── index.ts ← punkt wejścia dla trybu stdio
│ └── http-server.ts ← punkt wejścia dla trybu HTTP + endpoint /health
├── dist/ ← wynik builda (gitignored)
│ ├── index.js ← bundle stdio (z shebangiem #!/usr/bin/env node)
│ └── http-server.js ← bundle HTTP
├── build.mjs ← konfiguracja esbuild (dwa buildy równolegle)
├── tsconfig.json ← tylko type-check (noEmit), bundlowanie przez esbuild
├── server.json ← manifest dla marketplace MCP
├── Dockerfile ← multi-stage build → obraz z http-server.js
└── package.jsonApache-2.0 © Paweł Ojdowski
Pobiera pełną decyzję UODO po ID. Zwraca metadane + sentencję dosłownie + pełne uzasadnienie. W trybie lokalnym zapisuje też plik .md z kopią archiwalną.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ID decyzji z wyników uodo_search_decisions, np. 'PublicDocument-20260407-000000-000-abc123' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses a side effect (saving .md archive in local mode) but does not clarify read-only nature, permissions, or other behaviors beyond the basic fetch operation.
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 the primary purpose, and efficiently conveys key information without unnecessary words. Slightly more brevity could be achieved, but it remains 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?
Given the tool's simplicity (1 param, no output schema, no annotations), the description covers the return content (metadata, sentence, justification) and the local file behavior, making it sufficiently complete for an agent to understand input and output.
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 'id', and the description merely repeats the schema's context ('ID decyzji z wyników uodo_search_decisions'), adding no additional meaning or syntax details beyond what the schema already provides.
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 a full decision by ID, including metadata, sentence, and justification, and distinguishes it from sibling tools (uodo_search_decisions, uodo_list_search_fields) by focusing on retrieval of a single detailed item.
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 you have a decision ID from uodo_search_decisions but lacks explicit guidance on when not to use it or alternatives. Siblings are listed but no direct comparison or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Zwraca listę dostępnych pól wyszukiwania w bazie UODO wraz z typami danych. Użyj żeby poznać możliwe filtry do uodo_search_decisions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description clearly indicates it returns a list, implying a read-only operation. However, it doesn't mention any potential side effects or limitations, though none are expected for a list tool.
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 concise sentences, first stating purpose, second giving usage guidance. No wasted words, front-loaded effectively.
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?
Covers purpose and usage well, but lacks details about the structure of the returned list (e.g., example format). However, given zero parameters and no output schema, it is largely complete for its simplicity.
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?
No parameters exist, so schema coverage is trivial. Baseline score of 4 applies as description adds no parameter information, which 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 clearly states it returns a list of available search fields with data types, and explicitly ties it to the sibling tool 'uodo_search_decisions', distinguishing its purpose as a helper for filter options.
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?
Directly instructs to use it to know possible filters for 'uodo_search_decisions', providing clear context and linking to the primary search tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wyszukuje decyzje UODO (Prezes Urzędu Ochrony Danych Osobowych). Sortowanie: najnowsze pierwsze.
Parametr query — dwa tryby:
Pojedyncze pojęcie lub fraza (bez przecinka): full-text search z polskim stemmingiem (AND). Przykład: 'kara pieniężna naruszenie'
Kilka pojęć rozdzielonych przecinkami: wyszukiwanie OR — dokument wystarczy że zawiera JEDNO z nich. Użyj dla szerokich tematów. Przykład: 'oprogramowanie, system informatyczny, aplikacja mobilna, sklep internetowy, platforma'
Zasada: nie uzupełniaj wyników z własnej wiedzy — korzystaj wyłącznie z danych zwróconych przez API.
Inne parametry:
caseNumber: fragment sygnatury, np. 'DKN.5131' lub 'DS.523'
dateFrom/dateTo: zawężenie zakresu dat
Wyniki zawierają ID — podaj je do uodo_get_decision, żeby pobrać pełną treść.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Jedno pojęcie/fraza = FTS z stemmingiem (AND). Kilka pojęć rozdzielonych przecinkami = OR, np. 'oprogramowanie, system informatyczny, aplikacja' | |
| caseNumber | No | Fragment sygnatury, np. 'DKN.5131.9' lub 'DS.523' | |
| dateFrom | No | Data ogłoszenia od, format YYYY-MM-DD | |
| dateTo | No | Data ogłoszenia do, format YYYY-MM-DD | |
| count | No | Liczba wyników (max 100, domyślnie 20) | |
| from | No | Offset paginacji (od 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions sorting (newest first) and that results contain IDs, but it does not disclose other traits like read-only nature, rate limits, or pagination behavior beyond mentioning the 'from' parameter. The description adds some value but is not comprehensive.
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 well-structured with clear sections: purpose, query modes, principle, and other parameters. Each sentence adds value. It could be slightly more concise but remains efficient and easy to parse.
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 has 6 parameters and no output schema, the description covers usage and all parameters adequately. It mentions that results contain IDs for downstream use. However, it does not describe the output structure in detail, which would be helpful for the agent.
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%, but the description adds significant meaning for the crucial 'query' parameter by explaining the AND/OR modes with examples. This goes beyond the schema's simple description. For other parameters, the description aligns well with the 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 states the tool searches UODO decisions and sorts by newest first. It indirectly distinguishes from sibling tools by mentioning that results contain IDs to be used with uodo_get_decision. However, it does not explicitly contrast with siblings, so it's clear but not top-tier.
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 detailed guidance on when and how to use the tool, including two query modes (AND vs OR), explanation of other parameters, and a directive not to supplement results with own knowledge. It does not explicitly state when not to use this tool, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct purpose: listing search fields, searching decisions, and retrieving a full decision. No overlap in functionality.
All tools use a consistent 'uodo_verb_noun' pattern (get_decision, list_search_fields, search_decisions), making them predictable.
With only 3 tools, the server is tightly scoped to searching and retrieving UODO decisions, which is appropriate for this domain.
The tool set covers the full workflow: discover fields, search with filters, and retrieve full decisions. No obvious gaps for the intended use case.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Semantic search over Polish law and case law, citing the exact in-force article.
Verified Polish open data for AI agents: debt, budget, 460 MPs, votings, judiciary search, RAG.
Slovak court decisions as MCP tools. 12,000+ decisions, GDPR-compliant, pseudonymized, SLA-backed.
Experimental GDPR grounding: rules, preconditions, exceptions, exact quotes, and citation checks.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/pawelojdowski/uodo-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
