Hermetics RGPD

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds real behavioral context beyond them: deterministic rules, the fact that each obligation includes a legal basis and a suggested query, and the default-handling rule for omitted facts. It does not describe output volume or edge-case failure modes, keeping it at 4.

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

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

Three tight sentences: purpose first, then the deterministic/output behavior, then the default-handling rule. No filler and each sentence carries decision-relevant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 16 parameters, no output schema, and a non-trivial domain, the description supplies what the schema cannot: the return content (legal basis + suggested search_law query) and the omission-handling default. An agent has everything needed to call and interpret this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds the general default semantics ('a fact left out is treated as unknown, except processors, which are assumed') that the schema only states for the processors parameter. That generalization helps the agent decide how much to supply, though it does not add per-parameter detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Lists') and resource (GDPR obligations) with clear scope (company established in EU/EEA) and the inputs it reasons from. It is easily distinguished from siblings like search_law, which it explicitly hands off to for official text.

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

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

It gives clear context for use (deriving obligations from a few facts) and routes the agent to search_law for the official legal text, which is an explicit alternative. It stops short of stating when NOT to use it or prerequisites, but the routing guidance is genuinely useful.

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

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false): it says nothing is actioned from this call, that proposals must be approved by the user in the space, that the conversation must be enabled, and that a model-written answer consumes one question of the plan. That is real operational context an agent cannot infer from structured fields.

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

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

Front-loads the core action and return value in the first sentence, then layers boundaries and prerequisites. Slightly dense in a single paragraph, with some redundancy (e.g. re-explaining thread_id already in the schema), but no sentence is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly explains what comes back (answer, sources, action links, thread link). Prerequisites and plan consumption are covered. Minor gap: nothing about failure behavior when the conversation is off or the plan quota is exhausted beyond the bare prerequisite statement.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% — both parameters already document language freedom, the personal-data/marker behavior, and that thread_id comes from hermetics_status. The description largely restates the same points rather than adding new syntax or constraints, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (writes a message in a thread of the Hermetics Assistant) and what comes back (the answer, its cited official sources, and links to act in the space). It also distinguishes itself from hermetics_status, which is named as the source of thread_id.

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

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

Explicitly frames the message as information, never an instruction, and clarifies that nothing is started, approved, sent or validated from here — a clear usage boundary. It also states the prerequisite (conversation switched on in the space) and where approval actually happens, though it does not contrast this tool against non-Hermetics siblings like prepare_analysis.

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

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

Goes beyond the annotations meaningfully: it discloses that the result is deterministic and uses no AI model, that it consumes no plan allowance, and that waiting points carry only kind and link, never their content. The 'nothing is decided or changed' line reinforces the readOnly hint rather than contradicting it.

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

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

Two sentences, front-loaded with what is returned before the guarantees (determinism, no plan allowance, no changes). The first sentence is dense with nested appositives, which costs a little readability but every clause carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description carries the return-shape burden itself, and it does: a status sentence, waiting points (kind + link, no content), and open threads as references. For a zero-parameter read tool with full annotation coverage, an agent has everything needed to call it and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Zero parameters with 100% schema coverage, so the baseline of 4 applies; there is nothing for the description to disambiguate and it does not waste words on parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (returns the space's status summary) and enumerates the three things included: a one-sentence standing, waiting points with kind and link, and open threads as references. The sibling hermetics_message is never named, so the agent gets no explicit differentiation from the write/message tool.

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

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

Usage is only implied: an agent can infer this is the 'what's the current state of my space' read. There is no explicit when-to-use statement, no exclusion, and no routing to a sibling such as hermetics_message for follow-up actions.

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

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

Annotations already establish the safety profile (read-only, idempotent, non-destructive, closed-world), so the description isn't carrying that burden. It adds real behavioral value instead: records come back as latest version with full content, include a status, and absent facts are null and listed in `missing` — with an explicit instruction not to fabricate them.

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

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

Three sentences, front-loaded with the core action and scope, then the highest-value warning last. Dense but every sentence carries distinct information; the two account/organization cases are necessarily separated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no params, the description proactively characterizes the returned content (full content, latest version, status, null `missing` fields), which is exactly what an agent needs. Complete for this simple read tool, though it leaves the shape of the `missing` indication implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Zero input parameters, so the baseline is 4. The description references `missing` and `record_id`, clarifying the identity/data semantics an agent must understand when following up, which is useful even though these aren't input parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Lists') and resource ('records of processing activities (GDPR art. 30(1))'), and clarifies scope for both individual accounts and client organizations (whole register with status). It does not explicitly contrast itself with the write counterpart save_processing_record, but the read/write distinction is self-evident from the verb.

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

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

Usage is implied rather than stated: the tool is for reading the register, and the closing instruction to 'save the record with its record_id' hints at the save_processing_record path. There is no explicit when-to-use/when-not or named alternative, so it stays at implied guidance.

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

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

Annotations already cover read-only, idempotent, non-open-world, non-destructive behavior. The description adds valuable domain context beyond that: the causal trigger (a new rule), what fields are returned (rule, source, reason), and the lifecycle rule that saving a new version closes reviews. It also discloses the paywall constraint (paid plans), which is not in annotations and could affect invocation. It does not describe pagination or ordering.

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

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

One compact sentence that front-loads the action and scope, followed by two short clauses adding only the lifecycle and plan constraints. No wasted words or repetition of the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no parameters, no output schema, and annotations covering safety hints, the description is close to complete. It adds the domain trigger, returned fields, closure behavior, and login/plan implications. It could mention ordering or whether results are paginated, but those are minor omissions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, so there is no parameter semantics to explain; the baseline for zero params is 4. The description does not claim to accept filters, which correctly matches the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it lists records of processing activities, and further specifies the triggering condition (a new rule that may affect them) and what is shown for each (the rule, its source, the reason). This clearly distinguishes it from siblings like list_processing_records and save_processing_record.

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

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

The description makes the 'when' clear: after a change in the law, to see which records need review. It also implies the lifecycle boundary (saving a new version closes reviews), which tells the agent when reviews stop appearing. It does not explicitly name an alternative tool or state when NOT to use this one.

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

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.

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.

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.

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.

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.

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.

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

Beyond the annotations (write, non-destructive, non-idempotent), it discloses what the tool generates (a code, a legal deadline from art. 12(3), and a list of remaining tasks), that it applies a monthly quota after which recording continues but agent processing stops, and that no message is sent externally. Those side-effects and limits go well past what readOnlyHint/destructiveHint convey.

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

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

The purpose is front-loaded, but the text meanders into quota mechanics, agent roles, and DPO validation in one dense block, with some awkward phrasing ('beyond it, the request is still recorded... only our agents stop'). Several clauses could be tightened without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a write tool with no output schema, the description covers the important context: the returned deadline and pending steps, the quota behavior, and who validates. Missing is any explicit note on permissions or what happens on repeated submissions for the same request, but overall it is sufficient to call correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all five parameters are already documented in the schema, including the right enum and the received_on format. The description restates the deadline logic tied to received_on but adds no new syntax or format detail, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Records a data subject request') and enumerates the six GDPR rights it covers, so an agent knows exactly what gets created. It does not explicitly differentiate itself from siblings like save_processing_record or report_breach, so it stops short of a 5.

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

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

Usage context is implied rather than stated: the description clarifies that identity checks and system searches remain the company's responsibility and that nothing is sent to the requester. But it never says when to prefer this tool over prepare_analysis or save_processing_record, and there is no explicit when-not guidance.

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

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

Well beyond the annotations, it discloses that the DPO is alerted, that no external notification occurs, and that a monthly per-plan quota governs agent handling — with the specific fallback that beyond the quota the breach is still recorded with its deadline and only agent involvement stops. That is exactly the kind of side-effect and limit information an agent needs before a mutation.

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

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

The main action and the deadline are front-loaded, and most sentences carry real information (DPO alert, no external notice, quota behavior). It is somewhat long and the closing clause about the user's decision versus DPO validation partially restates the earlier DPO alert sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description does its job by explaining what is returned (the deadline and next steps). It covers side effects, quota limits, and the human decision point, leaving nothing material an agent would need before invoking this mutation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all five parameters are already documented in the schema, including the discovered_at semantics that drive the 72-hour clock. The description reinforces the deadline concept but adds no syntax or format detail beyond the structured fields, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Opens a personal data breach'), names the space it is created in, and describes the artifact produced (code plus 72-hour deadline under art. 33(1)). This is clearly distinguishable from siblings like record_request or prepare_analysis, which handle different request types.

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

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

The description establishes clear context: opening a breach record starts the 72-hour clock from awareness and explicitly says nothing is notified to the authority or data subjects, which scopes it away from any notification tool. It does not, however, name an alternative sibling or state an explicit when-not condition.

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

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.

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.

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.

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.

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.

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.

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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuine value by disclosing the return shape: verbatim passages, each carrying current legal status (in force, applicable from a date, amended) and an official link — context an agent cannot get from annotations.

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

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

A single front-loaded sentence with no filler, verb first and return contract second. The long parenthetical corpus list is dense but every element is substantive rather than padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-value burden and does so reasonably (passages, status, links). It omits result limits, ranking/pagination behavior, and how multiple statuses are surfaced, which are minor gaps for a retrieval tool with a fully documented schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description goes slightly beyond the schema by spelling out that national-law coverage for the country parameter includes authority guidance and decisions, clarifying what including a country actually adds to the result set.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb (searches) and resource (official EU/national data protection texts) and enumerates the corpora covered (GDPR, ePrivacy, AI Act, EDPB guidance, CJEU case law, national law). This clearly separates it from record-oriented siblings such as list_processing_records or report_breach, though it never names an alternative explicitly.

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

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

Usage is only implied: the 'question' parameter signals a research/retrieval task and the country note hints at scoping, but there is no statement of when to reach for search_law versus gdpr_obligations or prepare_analysis, and no exclusions. The agent must infer the routing.

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