DSGVO.pro — German Digital-Law Compliance

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

Beyond annotations, the description adds important behavioral context: API key requirement, free-tier limit of 3 scans/month, async execution taking 60–120 seconds, and the fact that the tool returns only a scanId. It thoroughly explains the operation's side effects and constraints without contradicting the 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?

The description is long and dense, but most content earns its place: authentication, quotas, module coverage, async behavior, and post-call steps are all present. It is structured with emoji markers and clear sections, though the lengthy tier/module list slightly reduces readability and front-loading.

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 complex scanner tool, the description is exceptionally complete: auth requirements, provider endpoint, quota limits, module coverage, activation dates, asynchronous result handling, and the exact follow-up tools are all covered. The integration with sibling tools makes the full workflow actionable.

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?

The input schema already documents the single url parameter with an example. The description adds little about the parameter itself, but that is acceptable because schema coverage is 100% and there is only one parameter, so the schema carries the semantic load.

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 action: 'Start a compliance scan against up to 33 German digital law modules.' It clearly distinguishes itself from sibling tools by explicitly noting that it returns only a scanId, not actual results, which separates it from get-scan-result and get-scan-status.

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 gives explicit workflow guidance: after calling this tool, wait 60–90 seconds, then call get-scan-result with the scanId, and use get-scan-status to check progress. It also names the alternative tools for retrieving outcomes, making when-to-use clear.

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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds useful behavioral context by noting that the content is German text and that the result includes both full text and metadata, going slightly beyond the 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?

Two short sentences front-load the purpose and result, with no filler or unnecessary repetition of schema details. Every word earns its place.

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 simple 2-param read-only getter with full schema coverage, output schema, and safety annotations, the description is complete enough. It identifies the resource, the language, and the result type, while the sibling list provides surrounding discovery context.

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%, with both parameters fully described in the input schema, including a law enum and article number/suffix guidance. The description adds no additional parameter semantics, so the baseline score 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?

The description uses a specific verb ('Get') and a specific resource ('full German text of a specific article or paragraph from a law'). It clearly distinguishes itself from sibling tools like list-laws and search-law by targeting a single known norm rather than discovery or enumeration.

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 phrase 'specific article or paragraph' implies the agent should already know which law and article to request, but there is no explicit guidance about when to use this tool versus search-law or list-laws. Usage context is implied rather than clearly stated.

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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds unique behavioral context not in annotations: the tool returns current progress if scan is still running instead of error, and it specifies the exact data elements returned. This adds value beyond the 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?

The description is two sentences plus a caution, front-loaded with the core action and result summary. Every sentence earns its place, with no redundancy. The warning is clearly marked with an emoji, and the fallback behavior is concisely explained.

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?

The tool is relatively simple (one parameter, no nested objects) and has an output schema, so the description's summary of return contents suffices. It covers the full lifecycle context (when to call, what to expect) and even notes the non-error fallback. Given the output schema exists, the description does not need to detail every field. This is complete for its complexity.

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% for the single parameter scanId, which is described as 'The scan ID returned by check-compliance'. The description does not add any extra detail about the parameter itself, but it does provide context (completed scan) that indirectly relates to usage. Per rubric, with high schema coverage, baseline is 3, and the description does not exceed that.

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 the exact purpose: to retrieve a full compliance report for a completed scan, and lists specific return contents (score, financial risk, per-module results, violations with law references and fixes). It clearly distinguishes this from sibling tools like get-scan-status (which checks status) and check-compliance (which initiates scans). No ambiguity.

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 states when to use it: only after the scan is complete, and instructs to check with get-scan-status first. Also explains the behavior if called early (returns current progress rather than error), effectively telling when not to use it and offering an alternative. This is exemplary 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by listing possible statuses and explaining that the tool returns module progress, which goes beyond annotation-only info. It also implies lightweight/poll-friendly behavior, though it does not discuss rate limits or edge cases.

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 first sentence is concise and the guidance is front-loaded, but the description includes a long parenthetical list of 13+ module names and legal references that adds no value for tool selection or invocation. This bloat makes the description significantly less concise than it should be.

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 simple polling tool with one parameter, an output schema, and strong annotations, the description covers the key operational context: what statuses to expect, when to poll, and what to do next. It could mention failure behavior (e.g., scan not found) but that is not essential given the output 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% and the schema already describes scanId as returned by check-compliance. The description does not add further parameter-level detail (e.g., format, required conditions), so it relies on the schema. Baseline of 3 is appropriate given high schema coverage.

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 the specific verb ('check') and resource ('progress') of an in-progress compliance scan, clearly distinguishing it from get-scan-result (full report) and check-compliance (initiation). Mentions the returned status values and module count, making it unambiguous.

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 says 'Use this to poll progress' and instructs to call get-scan-result when status is 'completed'. This provides clear when-to-use guidance and names the alternative for follow-up, effectively differentiating it from sibling tools.

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 declare readOnlyHint, idempotentHint, and destructiveHint false, so the description does not need to restate safety. It adds the specific output detail of article/paragraph counts, which is useful behavioral context beyond the annotations and name.

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 description is a single, front-loaded sentence with no filler. It conveys the essential action and scope without redundancy.

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 simple, parameterless list tool, the description is adequate: it states what is returned (all statutes with counts). However, it does not mention potential ordering, pagination, or whether the list is exhaustive, though these may be covered by the output schema. Overall, it is complete enough for typical use.

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?

With zero parameters, schema coverage is trivially 100%, but the baseline is 4 because there is nothing to explain about parameters. The description adds meaning by specifying what the list contains (counts), which helps the agent understand the response scope.

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 clearly states the tool lists all available German/EU digital-law statutes with article/paragraph counts. The verb 'List' and the resource scope distinguish it from siblings like search-law (searches) and get-article (fetches a specific article).

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 as a listing operation for an overview of statutes, but there is no explicit guidance on when to use it versus siblings (e.g., search-law or get-article). The description does not mention alternatives or when not to use it.

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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that it returns matching articles/paragraphs with excerpts, which is useful context beyond the safety profile. It doesn't mention rate limits or pagination, but for a search tool with idempotent read behavior, this is adequate. No contradiction with 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?

The description is a single paragraph of moderate length. It front-loads the core functionality (search across all statutes) and then elaborates. Every sentence adds value: the list of statutes, accepted inputs, and return type. Slightly dense but not verbose. Could be broken into bullets for readability, but still efficient.

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?

Given the complexity (26 statutes, two search modes) and that there's an output schema (which likely explains return structure), the description covers the key aspects: scope, input types, and outputs. It also lists the legal areas covered. It doesn't explain edge cases like ambiguous queries or ranking, but the output schema presumably covers return format. Adequate completeness for a search 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 description coverage is 100%: both 'query' and optional 'law' parameters are described in the schema. The description adds examples of query formats ("356a", "§312k", "Art. 42", "Cookie") and clarifies the scope of values for 'law', which adds some value beyond the schema. However, it doesn't provide detailed syntax or format rules beyond the schema, so a 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?

The description clearly states the tool searches across 26 German/EU statutes and lists them explicitly, distinguishing it from siblings like list-laws (which likely only lists laws) and get-article (which likely fetches a specific article). It specifies both direct paragraph reference lookup and free-text keyword search, making the purpose unambiguous.

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 implicitly tells when to use this tool: for searching legal texts across statutes, with either paragraph references or keywords. However, it doesn't explicitly contrast with siblings or state when not to use it (e.g., when you know the specific law and article, get-article might be more appropriate). Clear context but no explicit exclusions.

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