Skip to main content
Glama

ClevSec EU compliance tools

GDPR DPIA report and action plan (ClevSec Pro)

gdpr_dpia_report
Read-onlyIdempotent

Use after gdpr_dpia_screening when the user needs the DPIA worked out: a risk register linking each high or medium risk to its measures with coverage and indicative residual risk, and every gap (legal basis, special category data, necessity, missing measures, transfers, prior consultation under Art. 36) with an action, priority, article and a 30/60/90-day roadmap. Requires ClevSec Pro.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "gdpr_dpia_report"
  }
}

Input Schema

NameRequiredDescriptionDefault
c1NoDoes the processing evaluate or score people (profiling or predicting their performance, finances, health, preferences, reliability, behaviour or location)?
c2NoDoes it involve automated decisions with legal or similarly significant effects (for example access to credit, a job or a service)?
c3NoDoes it involve systematic monitoring of people (for example online tracking, employee monitoring or CCTV)?
c4NoDoes it involve sensitive or highly personal data (special category or criminal data, financial data, location data or private communications)?
c5NoIs the processing large-scale (many people, a large volume or range of data, a long duration or a wide geographic area)?
c6NoDoes it combine or match datasets from different sources in ways people would not expect?
c7NoDoes it concern vulnerable people (children, employees, patients, the elderly, or others in an unequal relationship with you)?
c8NoDoes it use innovative technology or a new way of using existing technology (for example AI, biometrics or IoT)?
c9NoCould the processing itself prevent people from exercising a right or using a service or contract (for example credit screening that decides whether to offer a loan)?
m1NoEncryption of personal data at rest and in transit
m2NoPseudonymization or anonymization where possible
m3NoAccess controls limiting who can view/modify the data
m4NoRegular security testing (vulnerability scans, penetration tests)
m5NoStaff training on data protection for those handling the data
m6NoData minimization — collecting only what is strictly necessary
m7NoAutomated deletion at end of retention period
m8NoIncident response plan covering this processing activity
m9NoRegular audits or reviews of the processing activity
r1NoRisk of unauthorized access to personal data (data breach)
r2NoRisk of data being used for purposes beyond what was communicated
r3NoRisk of inaccurate data leading to wrong decisions about individuals
r4NoRisk of excessive data collection beyond what is needed
r5NoRisk of insufficient transparency — individuals unaware of processing
r6NoRisk of discrimination or unfair treatment based on the processing
r7NoRisk of financial loss or economic disadvantage to individuals
r8NoRisk of reputational damage or social disadvantage to individuals
r9NoRisk of physical harm or safety concerns
t1NoWill you systematically and extensively evaluate people by automated means (including profiling), and base decisions on it that have legal or similarly significant effects on them?
t2NoWill you process special category data (health, biometric, genetic, racial or ethnic origin, political opinions, religion, trade union membership, sex life or sexual orientation) or criminal conviction data on a large scale?
t3NoWill you systematically monitor a publicly accessible area on a large scale (for example CCTV in shops, stations or streets)?
t4NoIs this type of processing on your supervisory authority's published list of operations that require a DPIA?
x1NoWill personal data be transferred outside the EU/EEA (including remote access from outside the EEA)?
m10NoData Processing Agreements with all third-party processors
m11NoPrivacy by design principles applied in system architecture
m12NoMechanism for data subjects to exercise their rights easily
r10NoRisk of loss of confidentiality (e.g. medical or legal privilege)
nec1NoIs the processing necessary to achieve the stated purpose, or could the purpose be achieved with less data?
nec2NoIs the amount of data collected proportionate to the purpose?
nec3NoIs the retention period limited to what is necessary?
nec4NoAre data subjects adequately informed about the processing (transparency)?
nec5NoCan data subjects exercise their rights (access, rectification, erasure, portability)?
nec6NoIf relying on consent, is it freely given, specific, informed, and withdrawable?
nec7NoIf relying on legitimate interest, has a balancing test been conducted?
proj_dataNoCategories of personal data
proj_legalNoLegal basis for processing
proj_subjectsNoCategories of data subjects

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety profile is covered. The description adds genuinely useful behavior beyond that: the entitlement requirement ('Requires ClevSec Pro') and the shape of the output (risk register, gap list, roadmap). It does not describe return format details or response structure, keeping it short of 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?

Single dense sentence but front-loaded with the usage trigger, followed by what it produces and the entitlement caveat. Every clause carries information; the enumeration is long but each item earns its place. Slightly heavy for one sentence, keeping it from a 5.

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?

No output schema exists, yet the description specifies the return content (risk register with residual risk, gap list with action/priority/article, 30/60/90 roadmap), so an agent knows what to expect. Combined with the prerequisite and sibling routing, nothing material is missing for a 46-param read-only tool.

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% across all 46 parameters, including enum labels and per-field questions, so the schema fully carries parameter meaning. The description adds no parameter-level detail (e.g. what c1-c9 versus t1-t4 drive), which is acceptable given full coverage but yields the baseline 3.

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?

States a specific resource (DPIA report/action plan) and enumerates its contents: a risk register linking risks to measures with coverage and residual risk, plus gaps with actions, priorities, articles and a 30/60/90 roadmap. It explicitly names the sibling gdpr_dpia_screening and positions itself as the follow-up, so an agent can distinguish it without opening the schema.

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?

Gives an explicit trigger ('Use after gdpr_dpia_screening when the user needs the DPIA worked out') and names the preceding tool, so the sequencing vs the alternative is unambiguous. It also surfaces the 'Requires ClevSec Pro' prerequisite, which is the key gating condition for invocation.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources