Praxikon

Where a published statement comes from

get_source_provenance

Read-only

Use this before you quote, cite or hand on anything from this graph, and whenever a reader asks on what authority a statement rests. It returns, for one object, every statement with its kind, its primary source, the locator inside that source and the review metadata, plus the source records behind those citations and a ready made citation block with the identifier, the object version, the payload hash and the release. Works for any object type, not only obligations, and for a GDPR object under praxikon:eu:gdpr as well, which is read from the GDPR obligations graph. 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.

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
`known_at`	No	Knowledge time pin.
`entity_id`	Yes	The stable identifier of any object, for example praxikon:eu:ai-act:guidance:..., praxikon:eu:ai-act:obligation:... or praxikon:eu:gdpr:obligation:... . An identifier in the flat raip:<type>:<slug> form published up to dataset 1.1.0 resolves to the same object.
`effective_at`	No	Legal time pin.
`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
`found`	Yes
`entity`	No
`review`	No
`caveats`	No
`message`	No
`sources`	Yes
`citation`	No
`error_code`	No
`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.
`statements`	Yes
`suggestions`	No
`requested_id`	No
`source_review`	No
`statement_counts`	No
`identifier_resolution`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 27, 2026

changedInput schema / properties / entity_id / description

Previous value: -"The stable identifier of any object, for example praxikon:eu:ai-act:guidance:... or praxikon:eu:ai-act:obligation:... . An identifier in the flat raip:<type>:<slug> form published up to dataset 1.1.0 resolves to the same object."New value: +"The stable identifier of any object, for example praxikon:eu:ai-act:guidance:..., praxikon:eu:ai-act:obligation:... or praxikon:eu:gdpr:obligation:... . An identifier in the flat raip:<type>:<slug> form published up to dataset 1.1.0 resolves to the same object."

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.4/5.0

Behavior5/5

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

Annotations already declare readOnly, non-destructive, closed-world behavior, and the description adds substantial context: the exact response components, the brief/full distinction, the identifier-resolution behavior, and the error_code/suggestions fallback. No contradictions.

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?

Four sentences lead with the use case, then explain outputs and scope, then the identifier rule. Despite its length, each sentence carries actionable information and nothing is repeated from schema or annotations.

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?

For a provenance tool with six parameters and an output schema, the description covers when to call it, what it returns, scope across object types, and identifier resolution. The safety profile is already in annotations, so no required context 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 the schema already documents lang, detail, known_at, effective_at, and store_for_improvement. The description adds meaningful guidance for entity_id (take it from earlier output; short forms resolve only when unambiguous), which goes beyond the schema, but it does not discuss the remaining parameters.

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 specifies a provenance lookup for one object: it returns statements, sources, locators, review metadata, source records, and a citation block. It also states the scope (any object type and GDPR objects), but it does not explicitly name sibling tools or contrast itself with them, so it is clear but not fully sibling-differentiated.

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?

It gives a clear trigger ('before you quote, cite or hand on anything' and 'whenever a reader asks on what authority') and notes the object-type and GDPR scope. It does not state when not to use it or name an alternative sibling, so it stops short of a 5.

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?