Praxikon

DPIA intake as a Word file

export_dpia_intake

Read-only

Use this when the user wants the DPIA intake of a concrete, intended use of AI or of personal data as a Word file to work on, and, where the FRIA comes into play, the FRIA draft too. It takes the same fixed fact answers as the case check of Praxikon, as coded choices, and gives the same documents as the download on the site: the four parts of Article 35(7) GDPR with the seventeen points of the Dutch government model DPIA, each point filled from the facts given, partly filled, or left as an open question, with articles and source links. Leave out what is not known: it counts as unknown and becomes an open question, never a no. Send only the coded answers and never the case text, names or other personal data; there is no field for them. The answer gives a download_url: the case check on the site with the answers in the part after #, which the browser never sends to the server; opening it shows the outcome and builds the Word file in the user's browser. Give the user that link, the explanation and the summary, and show the notice. Praxikon keeps no copy of the file.

Input Schema

Name	Required	Description	Default
`org`	No
`lang`	No	Language of the document. Dutch is the default.	nl
`role`	No
`scale`	No
`domain`	No
`effect`	No
`special`	No
`aiSystem`	No
`criminal`	No
`transfer`	No
`automated`	No
`frequency`	No
`inService`	No
`profiling`	No
`interaction`	No
`apCategories`	No
`personalData`	No
`interactionKnown`	No
`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
`date`	No
`dpia`	Yes
`fria`	Yes
`lang`	No
`view`	Yes
`title`	Yes
`notice`	Yes
`stored`	Yes
`summary`	Yes	What the intake holds, point by point, as plain text to show in the chat.
`documents`	Yes
`provenance`	Yes
`explanation`	Yes
`fria_reason`	No
`download_url`	Yes	The case check with the answers in the URL fragment; the browser builds the Word file.
`fria_included`	Yes
`rules_version`	No
`full_check_url`	Yes

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

Behavior5/5

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

Beyond the readOnlyHint/openWorldHint/destructiveHint annotations, the description discloses that no copy of the file is kept, that the download_url carries answers in the fragment which the browser never sends to the server, and that the Word file is built client-side. It also states an important semantic behavior: unknown facts are treated as unknown and become open questions, "never a no."

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

Conciseness3/5

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

The usage trigger is front-loaded, which is good, but the middle section is a dense run-on chain of clauses and the closing "Praxikon keeps no copy of the file" partly restates the earlier browser-side explanation. It is informative yet longer and less scannable than needed for a 19-parameter tool.

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?

For a complex, privacy-sensitive export tool with an output schema, the description covers the essential operational facts: what is produced, the download_url handoff, how the agent should present the link/explanation/summary/notice, and the personal-data prohibition. Remaining gaps are the individual code meanings and the language/store_for_improvement options, the latter partly covered by the schema itself.

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 only 11% across 19 parameters, so the description must carry the load. It adds real semantic rules — send only coded answers, omit unknowns, no field exists for case text or personal data, and codes/meanings match check_case's input — but it never explains what individual codes such as scale, effect, special, domain, or interactionKnown mean, deferring that to the sibling tool's schema.

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 a concrete outcome: producing the DPIA intake of a specific intended AI/data use as a Word file, plus the FRIA draft where applicable, with the four Article 35(7) parts and seventeen model-DPIA points. It relates itself to the sibling check_case ("the same fixed fact answers as the case check"), so an agent can tell the two apart by output. It stops short of a crisp one-line distinction ("check_case gives the outcome, this gives the downloadable document").

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 when the user wants ... as a Word file to work on" is an explicit selection trigger, and the FRIA condition is spelled out. However, no explicit when-not or "use check_case instead if the user only needs the assessment" routing is given, leaving the agent to infer the boundary with the sibling that shares the same inputs.

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?