EasyLPD: Swiss data protection (FADP) and GDPR

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

Annotations already establish read-only, idempotent, non-destructive behaviour, so the description's extra value is the output shape (six stages, each with article citations, weight, rationale, template link) and the filtering rule that answered steps are omitted. That is meaningful context beyond the annotations, though response format details like ordering guarantees or volume are left implicit.

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 usage trigger, then describes the output in one compact sentence. The second sentence is dense and run-on but every clause conveys real information about what the plan contains.

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 seven parameters including a nested answers object, the description does the heavy lifting by explaining the staged output and the filtering of completed steps, which is enough for correct invocation. Minor gaps around result size or ordering keep it from 5.

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 every parameter is already documented, and the description largely restates that answered yes/na steps are excluded — information the 'answers' property already carries. It adds marginal value over the schema, so 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 outcome — a stage-ordered action plan of applicable FADP/GDPR/AI Act steps with articles, weight, rationale and templates — and implicitly distinguishes itself from which_laws_apply and assessment_questions by producing a tailored plan rather than a law list or question set. It never names a sibling explicitly, so it stops short of a clean 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?

Opens with an explicit trigger ('Use when someone asks what their organisation must do about data protection, or how to start') and tells the agent to feed in answers from assessment_questions so completed steps are dropped. No explicit exclusions or 'when not to use' guidance, which keeps it at 4.

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 the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely non-obvious behavior: that 'unknown' counts as not in place until verified, that questions should be presented incrementally rather than dumped, and that scoring is a separate follow-up call. That is exactly the extra context the annotations cannot 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?

Two sentences, front-loaded with the trigger and then the payload specification. The field enumeration ('id, area, why it matters, its weight and the legal references') is dense but earns its place since no output schema exists. Slightly long, but no 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?

For a 7-parameter tool with no output schema, the description fully compensates: it specifies the shape of each returned question, the conversational protocol for collecting answers, the meaning of the ambiguous 'unknown' value, and the handoff to score_assessment. An agent could execute the whole flow from this text alone.

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 every parameter including the enum and defaults is already documented in structured form. The description contributes a light framing — that the jurisdiction/AI booleans determine 'an organisation's profile' which filters the question set — but does not clarify defaults such as freeOnly (free vs. full assessment) or the lang parameter beyond what the schema says. 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 states a concrete resource — the EasyLPD self-assessment questions that apply to an organisation's profile — and enumerates the fields each question carries (id, area, why it matters, weight, legal references). It implicitly separates itself from fadp_questions by naming the EasyLPD assessment, but never explicitly tells the agent how the two question sets differ.

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 an explicit trigger ('Use when someone wants to check where their organisation stands with data protection'), an operational procedure ('Ask them in the conversation, a few at a time'), the accepted answer vocabulary, and a named next step ('then call score_assessment'). No inference is required to know when and how 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, idempotentHint and non-destructive behaviour, so safety is covered. The description adds real context beyond them: it discloses exactly what comes back in each mode (purpose per template, page link, section headings, opening text, and the FADP/GDPR divergence notes), which is valuable given there is no output schema.

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 'Use when...' trigger and then the two return modes; little waste. The middle sentence is slightly convoluted ('The 39 templates of EasyLPD with what each is for and the link to its page'), which mildly slows parsing but is not padded.

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 all-optional parameters, the description carries the return-value burden and does so for both modes, and the lang enum default is handled by the schema. Only minor gaps remain, such as whether the result is paginated or truncated to 39 rows and how search results are ranked.

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 goes further: it explains that supplying an id switches to single-template detail mode and that search is an optional word-based narrowing. The lang parameter is left to the schema, which documents it adequately with an enum and default.

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 the resource precisely (the 39 EasyLPD data-protection templates) and describes both output modes: a catalogue with purpose and page link, or a single template's section headings, text start and FADP-vs-GDPR differences. It never states the verb explicitly ('returns/lists'), but the second sentence makes the operation unambiguous and clearly separates it from obligation-question siblings.

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 opening 'Use when someone needs a privacy notice, a processor agreement (DPA), a breach procedure, a DPIA...' gives concrete trigger scenarios tied to named document types. It does not explicitly say when not to use it or name a sibling alternative (e.g. fadp_obligations for obligation lookups), so it stops short of full routing 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?

The annotations already declare a safe, read-only, idempotent, closed-world operation. The description adds useful scope context beyond that: the law has been in force since 1 September 2023, the output is a summary, and it is explicitly not legal advice.

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 four short sentences, front-loads the use case, then names the alternative and adds the legal-advice caveat. Every sentence contributes without repetition.

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, annotation-rich, zero-required-parameter overview tool with no output schema, the description gives enough content scope and routing guidance. A little more detail on the output shape would make it fully complete, but nothing critical is missing.

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 is one optional lang parameter, and schema description coverage is 100%. The description does not add anything about the parameter, so the schema fully carries that burden and 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 states precisely what the tool provides: an overview of Swiss FADP duties for SMEs, including applicability, risk, eight duties, and article references. It explicitly distinguishes itself from action_plan, so an agent can tell the two apart without opening schemas.

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 says to use this for an overview and explicitly routes organisation-specific obligations to action_plan. That is clear positive and alternative guidance, though it does not address other siblings such as assessment_questions, fadp_questions, or which_laws_apply.

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, closed-world behavior, so the description's contribution is the two-mode contract and the answer payload (articles, detail, FADP/GDPR comparison table, templates, page link). It does not say whether answers are curated static content or why an unknown id fails, but it adds real context 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?

The trigger is front-loaded, but the single run-on sentence then recites ~40 topics that largely restate the enum values in prose, making it a wall of text rather than a structured list. The information is not wrong, but much of it duplicates structured data and would scan better as categories.

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 two-parameter, read-only lookup tool with no output schema, the description covers trigger, mode switching, and the shape of the returned answer, which is what an agent needs to call it correctly. Only sibling routing and failure behavior on an unrecognized id are left 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?

Schema coverage is 100% and both enums are self-documenting, so the baseline is met; the description goes further by spelling out what omitting the optional id does versus supplying one, which the schema does not state. The lang parameter is left to the schema, which is acceptable given its enum and default.

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?

Names the exact resource (common questions on the Swiss FADP/nLPD/revDSG) and states both operating modes: a list when no id is given, a full answer when an id is given. The curated topic list makes the boundary versus siblings like fadp_obligations or which_laws_apply recognizable 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.

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

"Use when someone asks a common question on the Swiss FADP" is an explicit trigger, and the enumerated topics tell the agent which question types this tool covers. It never names an alternative tool or says when NOT to use it (e.g. versus fadp_obligations or assessment_questions), so routing is only partially resolved.

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 readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds meaningful context beyond that: results vary by applicable law, the output includes a risk level and three prioritized gaps, and a disclaimer that this is guidance rather than legal advice or certification — a real behavioral expectation an agent should relay to the user.

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, no filler, with the prerequisite stated first and the disclaimer trailing appropriately. The first sentence is overstuffed with distinct claims (scoring basis, risk level, gaps, link) that would read better separated, but nothing 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?

There is no output schema, and the description compensates by naming the key return elements: risk level, three gaps, and the openInEasyLPD link. For a seven-parameter, nested-schema tool this is largely sufficient, though it stops short of explaining how the score is derived or what happens with 'unknown'/'na' answers.

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 100% schema description coverage, every parameter including the nested answers object and the four-language enum is documented in the schema. The description adds no parameter-level detail, so baseline 3 applies; the mention of 'applicable law' gestures at the jurisdiction flags but does not explain how they interact.

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 (scores) and resource (the answers from assessment_questions) and states what the tool produces: risk level, three gaps, and an openInEasyLPD link. It is clearly distinguishable from siblings like assessment_questions and action_plan, though the phrasing is embedded in a run-on sentence rather than front-loaded.

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 opening clause 'Use after the questions of assessment_questions have been answered' gives an explicit prerequisite and names the sibling that must run first. There are no stated exclusions or alternative paths (e.g., what to do if answers are incomplete), but the sequencing is unambiguous.

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 this as a safe, idempotent, read-only, closed-world lookup, so the description doesn't need to restate that. It adds genuinely useful behavior beyond the annotations: the answer covers two separate legal regimes (FADP and GDPR adequacy lists) and the lists are volatile, so results should be re-checked before being relied upon.

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 an explicit usage trigger, followed by what is evaluated and a freshness caveat. No filler; the example list adds disambiguation value rather than noise.

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 convey the shape of the answer (a per-regime determination on whether safeguards are needed). It does not say how the two jurisdictions are reported separately or what happens for non-adequate countries, leaving a small gap for a lookup tool with only two inputs.

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 both parameters (country code and lang) are already documented in the schema. The description restates the ISO 3166-1 alpha-2 format, duplicating schema content, and says nothing about the lang parameter — the 3 baseline is appropriate when the schema carries the 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?

States a specific check — whether transferring personal data to a given country is permitted without further safeguards under both the Swiss FADP and EU GDPR adequacy lists. The verb+resource combination and the dual-jurisdiction framing distinguish it from siblings like which_laws_apply or fadp_obligations.

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?

'Use when someone asks whether they may use a provider or send personal data to another country' gives a clear triggering condition, reinforced by concrete examples (cloud, hosting, CRM, US services). It stops short of naming an alternative sibling or stating exclusion conditions, so it is clear context rather than full routing 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?

Beyond the read-only/idempotent annotations, it discloses the derivation logic (five yes/no questions with GDPR art. 3 and AI Act art. 2 scope), the shape of the answer (core obligations plus single-law obligations, each with articles and the implementing template), the AI Act establishment/output caveat, and an explicit 'guidance, not legal advice' disclaimer.

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 trigger and scope are front-loaded, but the description is longer than needed: the three law names and their acronyms are repeated across sentences, and "Tells whether the Swiss FADP..., the EU GDPR and the EU AI Act apply" largely restates the opening 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 carries the return-value burden and does so by describing obligations, articles and templates returned per profile. The AI Act nuance is covered; minor gaps remain on whether the response is exhaustive or configurable by lang.

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 each of the six parameters is already documented in the schema; the description adds only the framing that inputs are treated as scope questions for GDPR art. 3 / AI Act art. 2. It gives no extra interpretation of the individual booleans or the lang enum, 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 opening sentence names the exact trigger question, the specific laws covered (FADP/LPD/DSG, GDPR, AI Act), and the decision it returns, which clearly separates it from siblings like fadp_obligations or fadp_questions. An agent can route to 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.

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

"Use first when someone asks which data protection laws their organisation must follow" is an explicit entry-point condition, reinforced by a concrete example (Swiss company selling online to the EU). It does not name when to prefer fadp_obligations or transfer_check instead, so ordering is implied but alternatives are not spelled out.

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