Skip to main content
Glama

Prepare a compliance analysis

prepare_analysis

Prepares, in the Hermetics space of the organization, the analysis of a record of the register with the same engines as the Hermetics platform: legal basis, DPIA, legitimate interests assessment, transfer impact assessment, information notice (art. 13 and 14), the privacy policy of the whole register, or the art. 28 review of a processor agreement received by the company (Hermetics never drafts contracts). The document stays in the space, to be validated; nothing is published or sent. Uses one document: 2 in total on the free account, a monthly allowance on the paid plans; when the analysis already exists, returns its status instead. Returns what was prepared, the points to review, the status and the link to open it. Prepared from the facts given; the decision is the user's, or the designated DPO validates it when the organization has one.

Input Schema

NameRequiredDescriptionDefault
typeYeslegal_basis (art. 6), dpia (art. 35), lia (legitimate interests assessment), tia (transfer impact assessment, art. 44 to 49), information_notice (art. 13 and 14), privacy_policy (the whole register), processor_agreement_review (art. 28 review of a processor agreement received by the company).
notesNoFacts or context from the user for the preparation; no personal data needed.
record_idNoCode of the record in the register (e.g. AT-001); required for every type except privacy_policy.
agreement_textNoFull text of the processor agreement received by the company (processor_agreement_review only).
processor_nameNoName of the processor whose agreement is reviewed (processor_agreement_review only).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior4/5

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

Annotations only declare generic hints (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description goes well beyond them: nothing is published or sent, the document is left for validation, quota consumption is spelled out (one document, 2 on free account, monthly allowance on paid plans), and the existing-analysis fallback is disclosed. Solid added context for a mutation-style tool.

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?

Purpose and scope are front-loaded, but the paragraph is dense and mixes contract-heavy language ('Hermetics never drafts contracts') with operational facts. Most sentences carry information, yet the run-on construction and parenthetical asides make it heavier than needed for a tool-router to scan.

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?

With no output schema, the description compensates by stating what is returned (what was prepared, points to review, status, link) and clarifying the human-validation boundary. Combined with the quota and existing-analysis behavior, an agent has enough to invoke it correctly; only the record_id/privacy_policy parameter split is left to the schema.

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 enum already documents each type with its article reference, so the baseline is 3. The description adds only the quota/record framing and does not clarify agreement_text, processor_name, or notes beyond what the schema states.

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 names a specific verb (prepares) and a concrete resource (the analysis of a register record), then enumerates the exact analysis types it covers, matching the schema enum. No sibling tool (gdpr_obligations, list_processing_records, etc.) performs this action, so the agent can route unambiguously.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives useful operating context (analysis stays in the space and is not published; if the analysis already exists, its status is returned instead), but never states when to prefer this over a sibling or what prerequisites apply beyond the implied record_id requirement. Usage is implied rather than explicit, and no alternatives are named.

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