Hermetics RGPD

Save a record of processing activity

save_processing_record

Saves one entry of the record of processing activities (GDPR art. 30(1)) in the Hermetics account linked to the connection: new records get a code and every change is kept as a new version, in the account's own register on the Hermetics platform (the free account has no DPO: the user checks the records). When the account belongs to a Hermetics client organization, records go to that organization's register on the Hermetics platform (codes AT-001...), pending its DPO's review; a change to a record the DPO has validated is sent to the DPO as a proposal. Returns the code, the version and the points a DPO would review in the entry; when an existing record is updated, also what changed from the previous version and what the change requires (information notice, proof of consent, processor contract, transfer safeguard, DPIA review). The free account stores 3 records; the paid plans have no record limit.

Input Schema

Name	Required	Description
`name`	Yes	Short name of the processing activity (e.g. "Payroll", "Newsletter").
`purpose`	Yes	Purpose of the processing (art. 30(1)(b)).
`record_id`	No	Code of an existing record (e.g. RT-001, or AT-001 in an organization register) to save a new version of it; omit to create a new record.
`retention`	Yes	Retention period or the criteria used to determine it (art. 30(1)(f)).
`department`	No	Department or business unit in charge of the processing (e.g. "HR", "Marketing").
`processors`	No	Processors acting on behalf of the company (art. 28).
`recipients`	Yes	Categories of recipients, internal and external (art. 30(1)(d)).
`legal_basis`	Yes	Legal basis under art. 6(1).
`data_subjects`	Yes	Categories of data subjects (art. 30(1)(c)), e.g. "employees", "customers".
`art9_exception`	No	The art. 9(2) exception relied on, if special category data are processed.
`data_categories`	Yes	Categories of personal data (art. 30(1)(c)), e.g. "identity", "bank details".
`security_measures`	No	General description of technical and organisational security measures (art. 30(1)(g)).
`internal_recipients`	No	Internal recipients: who, inside the company, can see the data (art. 30(1)(d)), e.g. "payroll team".
`legal_basis_details`	No	Details of the legal basis: the legal obligation, the contract, or the legitimate interest pursued.
`special_category_data`	No	True if special category data (art. 9) are processed.
`transfers_outside_eea`	No	Transfers to third countries (art. 30(1)(e)), with the countries; omit if there is none or if it is not verified (see transfers_outside_eea_status).
`transfers_outside_eea_status`	No	Whether personal data are transferred outside the EEA: "yes" (give the countries in transfers_outside_eea when known), "no" (checked with the user, including the hosting and the processors: none) or "unknown" (not verified yet). Omitted: "yes" when transfers_outside_eea is given, otherwise "unknown".

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 25, 2026

addedInput schema / properties / department

Added value: +{
+  "description": "Department or business unit in charge of the processing (e.g. \"HR\", \"Marketing\").",
+  "maxLength": 200,
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / internal_recipients

Added value: +{
+  "description": "Internal recipients: who, inside the company, can see the data (art. 30(1)(d)), e.g. \"payroll team\".",
+  "items": {
+    "maxLength": 200,
+    "minLength": 1,
+    "type": "string"
+  },
+  "maxItems": 30,
+  "type": "array"
+}

changedInput schema / properties / transfers_outside_eea / description

Previous value: -"Transfers to third countries (art. 30(1)(e)); omit if none."New value: +"Transfers to third countries (art. 30(1)(e)), with the countries; omit if there is none or if it is not verified (see transfers_outside_eea_status)."

addedInput schema / properties / transfers_outside_eea_status

Added value: +{
+  "description": "Whether personal data are transferred outside the EEA: \"yes\" (give the countries in transfers_outside_eea when known), \"no\" (checked with the user, including the hosting and the processors: none) or \"unknown\" (not verified yet). Omitted: \"yes\" when transfers_outside_eea is given, otherwise \"unknown\".",
+  "enum": [
+    "yes",
+    "no",
+    "unknown"
+  ],
+  "type": "string"
+}

Changed1 schema field changedOct 13, 2026

changedInput schema / properties / record_id / description

Previous value: -"Code of an existing record (e.g. RT-001) to save a new version of it; omit to create a new record."New value: +"Code of an existing record (e.g. RT-001, or AT-001 in an organization register) to save a new version of it; omit to create a new record."

AddedOct 12, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Beyond the annotations (readOnly=false, destructive=false, idempotent=false), the description discloses the versioning model that justifies non-idempotence, where the data lands (account register vs organization register), the DPO review/proposal workflow for validated records, and a hard quota (3 records on the free plan, unlimited on paid). It also states what the call returns and what a change triggers (information notice, consent proof, processor contract, transfer safeguard, DPIA review).

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?

The core action is front-loaded and every sentence carries substantive information (storage target, DPO flow, return values, quota) with no filler. However, the first sentence is a long chain of clauses with nested parentheses that is harder to parse than necessary.

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 17-parameter mutation tool with a nested object and no output schema, the description covers the gaps structured data cannot: return contents, side effects and version creation, cross-organization routing, DPO approval consequences, and storage limits. An agent has enough to call it correctly and anticipate the result.

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%, so the schema already documents all 17 parameters including record_id's omit-to-create semantics and the transfers_outside_eea_status defaulting rule. The description adds only an implicit reminder of the record_id create-vs-version switch and does not enrich parameter meaning beyond what the schema states, so the baseline 3 applies.

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 names a specific verb and resource: it saves one entry of the GDPR art. 30(1) record of processing activities, and it explicitly covers both create (new records get a code) and update (every change is kept as a new version) modes. It is clearly distinguishable from the read-only sibling list_processing_records by its write semantics, but it never names or contrasts sibling tools directly.

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 concrete context for when the behavior differs: free accounts (no DPO, self-checked, 3-record cap) versus client organizations (register codes AT-001..., pending DPO review, validated-record changes become proposals). What is missing is explicit routing guidance versus alternatives such as list_processing_records (to find a record_id first) or pending_reviews.

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

All Hermetics RGPD 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?