Praxikon

The legal path behind one obligation, not only the outcome

explain_applicability

Read-only

Use this whenever you have to justify why an obligation does or does not bear on a case, and an outcome on its own is not enough. It returns the legal path: the conditions under which the rule is about a situation, the exceptions under which it is not despite those conditions, and the statements of the obligation split by kind, each with the primary source, the locator inside that source and the source record behind it. Supply a profile as well and the deterministic rule trace is added: which rule was met, not met or unknown for this case, plus the assumptions and the questions the engine could not settle. Use this rather than paraphrasing an obligation yourself: the conditions, the exceptions and the citations are published data and are not to be reconstructed from prose. Take the identifier from earlier tool output; a short form such as art. 26 resolves when it points at one obligation, else error_code and suggestions come back. A question without an identifier belongs with the short question tool or the case check.

Input Schema

Name	Required	Description	Default
`lang`	No	Language of the labels and explanations. Dutch is the default.	nl
`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
`profile`	No	The same coded profile that classify_system takes, with the same fields and codes: see the profile schema of classify_system. Send a version 2 profile to have the wider set assessed, including Article 26 for a deployer. The server validates the profile against that full schema.
`known_at`	No	Knowledge time pin, a date or an ISO instant. Defaults to the release default.
`effective_at`	No	Legal time pin, a date or an ISO instant. Defaults to the release default.
`obligation_id`	Yes	The stable identifier, for example praxikon:eu:ai-act:obligation:article-50-transparency.
`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
`pin`	No	The release and the two time axes this answer resolved against. Store it next to anything you keep: an unpinned query is not reproducible, because the defaults move with each release.
`view`	No
`caveats`	No
`message`	No
`sources`	Yes
`assessment`	Yes	Present only when a profile was supplied and the decision engine assessed this obligation for it. Null otherwise, with the reason in assessment_absent_reason and, when the engine said why, the detail in not_assessed.
`error_code`	No
`legal_path`	Yes
`obligation`	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.
`suggestions`	No
`not_assessed`	No	Why the engine did not assess this obligation for this profile, as the engine reported it, with the facts that would have it assessed. For example profile_version_below_2: send a version 2 profile.
`requested_id`	No
`identifier_resolution`	No
`assessment_absent_reason`	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"
+}

Changed5 schema fields changedOct 12, 2026

addedOutput schema / properties / error_code

Added value: +{
+  "enum": [
+    "unknown_identifier",
+    "ambiguous_identifier"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / identifier_resolution
```
Added value: +{
+  "type": "object"
+}
```
addedOutput schema / properties / message
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / requested_id
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / suggestions
```
Added value: +{
+  "type": "array"
+}
```

First observedOct 11, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnly, non-destructive, closed-world, so the bar is lower, but the description still adds real behavior: ambiguous short-form identifiers return error_code plus suggestions, and the profile path adds assumptions and unsettled questions from the engine. It also asserts the returned citations are published data rather than prose. It stops short of describing pagination or latency, hence not a 5.

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?

Dense but every sentence carries distinct information — when to use, what is returned, profile effects, identifier sourcing, and fallback routing. The opening sentence leads with usage rather than the operation itself, which slightly delays the core statement, 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?

Given an output schema, annotated safety profile, and fully described parameters, the description covers the remaining agent-critical gaps: eligibility, identifier provenance, ambiguity/error handling, privacy-relevant retention, and which sibling to use instead. Nothing needed to invoke it correctly is missing.

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; the description still adds meaning by explaining what supplying 'profile' actually changes (deterministic rule trace of met/not-met/unknown with assumptions) and that obligation_id accepts a short form like 'art. 26' with a defined resolution/error path. That is effect-level semantics the schema does not convey.

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?

The description names a specific resource and output: the legal path behind one obligation — its conditions, exceptions, and source-split statements — plus an optional deterministic rule trace when a profile is supplied. It is clearly separable from siblings like get_applicable_obligations or answer_question, and the title reinforces the 'path, not just outcome' framing.

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

Usage Guidelines5/5

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

It states the trigger explicitly ('whenever you have to justify why an obligation does or does not bear on a case'), names an exclusion ('use this rather than paraphrasing an obligation yourself'), gives the prerequisite (take the identifier from earlier tool output), and routes identifier-less questions to 'the short question tool or the case check'.

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?