Praxikon

Classify one AI system against the routes of the Regulation

classify_system

Read-only

Use this as the first step when you hold a concrete AI system and need to know which routes of the EU AI Act come into view: prohibited practice screening, Annex III high risk, transparency, FRIA and the general purpose model route, and with a version 2 profile the wider set of duties, such as Article 26 for a deployer. It runs the deterministic decision engine over coded answers and returns one applicability status per assessed obligation, with the timing and what is still open. It is not meant for a general question about the law. An obligation the engine did not assess is listed in assessment_scope.not_assessed with the reason; it was not found inapplicable. It does not return a single coded classification label.

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`	Yes	The coded answers about one system. The fifteen version 1 fields are required. A field that does not bear on this case takes not_relevant, and unsure is a real answer that leads to insufficient_context rather than to a guess. A version 1 profile has five obligations assessed. To have the wider set assessed, including Article 26 for a deployer of a high risk system, also send profile_version 2.0.0, chain_roles (consistent with actor_role) and the twelve other version 2 scope facts: ai_system_scope, jurisdiction_established_in_eu, jurisdiction_market_in_eu, jurisdiction_output_in_eu, scope_exclusion, annex_i_product, annex_i_third_party_conformity, article_25_role_change, provider_outside_eu, sandbox_participation, real_world_testing and adverse_significant_decision. The remaining version 2 facts are optional: an unanswered fact is unknown and leads to insufficient_context, never to a silent no. The backend rejects a profile whose answers contradict each other.
`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
`notes`	No
`dataset`	Yes
`privacy`	No
`profile`	No
`sources`	No
`summary`	Yes
`disclaimer`	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.
`obligations`	Yes
`snapshot_id`	No
`blocking_flags`	No
`deadline_notes`	No
`open_questions`	No
`assessment_scope`	No	What this assessment did and did not assess, from the engine itself. not_assessed groups the obligations that were not assessed by reason (for example profile_version_below_2), with the facts that would have them assessed. Not assessed is not the same as not applying.
`evaluation_scope`	No
`payload_hash_sha256`	No
`decision_engine_version`	No
`snapshot_schema_version`	No
`evaluated_obligation_ids`	No
`not_indicated_obligation_ids`	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.5/5.0

Behavior5/5

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

Beyond the readOnly and non-destructive annotations, the description explains that a deterministic decision engine runs over coded answers, returns one applicability status per assessed obligation with timing and open points, and does not return a single classification label. It also clarifies that obligations missing from assessment_scope.not_assessed were not found inapplicable, which is important behavioral context.

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?

The description is front-loaded with the primary use case and then adds only necessary scope, return behavior, and caveats. Despite covering a complex classification tool, every sentence contributes to correct selection or interpretation.

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 the complex nested input schema, the output schema, and the read-only annotations, the description is complete enough for an agent to decide when and how to call it. It covers scope, versioned behavior, return shape at a high level, and the meaning of unassessed obligations.

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 100%, and the nested profile schema fully documents the coded facts, enums, version 1 versus version 2 requirements, and not_relevant handling. The description adds little parameter-level detail beyond the schema, so the baseline 3 is appropriate.

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 states a specific verb and resource: classify a concrete AI system against the routes of the EU AI Act. It lists the routes it covers and explicitly distinguishes its purpose from a general legal question, which also routes the agent away from a sibling like answer_question.

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 clear usage guidance: use it as the first step when holding a concrete AI system, and it is not meant for a general question about the law. The when-not is explicit, though it does not name sibling tools as alternatives.

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?