Praxikon

Who supervises, per member state

get_national_enforcement

Read-only

Use this for the national layer: which authority is designated in a member state, how far the implementing law has come, and which dated enforcement signals are recorded, each with a primary source. The authority is recorded as free text per member state and is deliberately not a graph identifier, because which national body fills the market surveillance role differs per member state. The same call returns the ruling register: judgments and supervisory decisions with the relation they bear to a provision (interprets, narrows, broadens, confirms, contradicts, or illustrates for context). An event says what happened, a ruling says what we know a provision means. Never present a related_gdpr ruling as AI Act case law: it rests on the GDPR and carries the illustrates relation only. This tool takes no lang: the tracker carries both languages on every record, in the fields that end in _nl and _en.

Input Schema

Name	Required	Description	Default
`type`	No	Narrow to one event type, for example implementing_law.
`detail`	No	Amount of data to return. brief keeps the outcome, the dates, the reasons, the open questions and the source with its locator; full adds the complete objects, every statement text and every hash, for re-computation or archiving.	brief
`country`	No	ISO 3166-1 alpha-2 country code, for example NL. Omit for all member states.
`known_at`	No	Knowledge axis of the ruling register, as YYYY-MM-DD: returns the rulings we had recorded on that date and nothing that arrived afterwards. A provision keeps its own effective_at; only the reading moves.
`obligation`	No	Slug of an obligation, for example article-50-transparency. Returns the rulings that bear on it. An empty result on an existing obligation means no ruling is recorded, not that the slug is wrong.
`store_for_improvement`	No	Optional. Set to false when the user asks that Praxikon does not keep this request to improve its answers; nothing of this call is then kept beyond the anonymous daily count. See https://www.praxikon.com/nl/legal/privacy, section 2.7.

Output Schema

Name	Required	Description
`view`	No
`stats`	No
`events`	Yes
`filters`	No
`rulings`	Yes
`version`	No
`countries`	Yes
`provenance`	Yes	Which published endpoints produced this result. Every call is listed with its full URL, so a reader can re-issue it and check the answer rather than trust it.
`verified_at`	No
`events_total`	No
`ruling_register`	No
`empty_result_note`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 23, 2026

addedInput schema / properties / store_for_improvement

Added value: +{
+  "default": true,
+  "description": "Optional. Set to false when the user asks that Praxikon does not keep this request to improve its answers; nothing of this call is then kept beyond the anonymous daily count. See https://www.praxikon.com/nl/legal/privacy, section 2.7.",
+  "type": "boolean"
+}

First observedOct 11, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already declare a safe read, but the description adds substantial behavior: the authority is free text deliberately not a graph identifier, the call also returns the ruling register, and the lang parameter is absent because both _nl and _en fields ship on every record. It also warns that related_gdpr rulings rest on the GDPR and carry only the illustrates relation, which prevents a real misinterpretation of results.

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

Conciseness4/5

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

Front-loaded with a usage directive and no wasted preamble; every sentence carries content. It is dense overall, and the event-versus-ruling aphorism could be trimmed given an output schema exists, but nothing is filler.

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

Completeness5/5

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

With annotations covering the safety profile, full schema coverage and an output schema, the remaining burden is domain framing, which the description supplies: what the national layer contains, how rulings relate to provisions, source citation, and the bilingual field convention. An agent could call this correctly and interpret the results.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description earns credit above it by explaining why no lang parameter exists and how records carry both languages, and by framing the ruling register that known_at and obligation filter against. It does not add syntax detail for type, country or detail, but the schema already does that.

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

Purpose4/5

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

The description states the resource concretely: designated national authority, implementing-law progress and dated enforcement signals, plus a ruling register, each with a primary source. That is specific enough to separate it from answer_question or check_case, though it never names a sibling and the purpose is buried in a long first sentence rather than stated as a crisp verb+resource.

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

Usage Guidelines4/5

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

'Use this for the national layer' clearly sets the selection context and the register semantics tell the agent what it is getting back. There are no explicit exclusions or named alternatives among the siblings, so an agent must infer when to prefer this over check_case or get_applicable_obligations.

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

All Praxikon 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?