TracePass DPP Compliance Assistant

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

Annotations only declare the safety profile (not read-only, not destructive, not idempotent, closed-world); the description adds substantial behavioral context beyond that: it never publishes, it may return a request for an identifier, it can return a not_covered outcome, and results carry citations, a disclaimer, and status labels. The heavy response-handling rules (add no facts, keep citations, phrase as product type not personal duties) go well past what the annotations 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 and the draft-only constraint are correctly front-loaded, but the body is a long run of imperative house-style rules ('never call this advice or yourself a consultant', 'never rank or recommend vendors') that read like system-prompt policy rather than tool selection guidance. Useful in aggregate, but several sentences do not earn a place in a tool description.

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, yet the description covers the important return expectations: possible identifier requests, citations and disclaimer that must be preserved, status labels, and the not_covered case. Missing only smaller operational details such as what happens on repeated calls (the tool is non-idempotent) or validation failure behavior, so it is close to but not fully complete.

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 per-parameter guidance including the category enum mapping rules and the battery subType caveat, so the schema already carries the semantics. The description only adds a generic anti-fabrication constraint for identifiers ('ask the user; never invent one'), which reinforces gtin/serialNumber handling but provides no syntax or format detail beyond the schema. 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+resource+scope: creates a *draft* passport in the user's own TracePass account, sourced from facts the user stated. The draft-only/never-publishes boundary is stated immediately, which cleanly separates it from the profile/registry siblings and prevents an agent from expecting a publish-capable 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?

Explicit triggering condition ('use it whenever the user asks to create a passport'), an explicit handling of the ambiguous case ('create and publish' → create draft, tell the user publishing happens in TracePass, it never publishes), and a fallback path for when no template exists ('if the result is not_covered, say so and point to the article'). Very little is left to inference.

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 destructiveHint=true, readOnlyHint=false and idempotentHint=true, so the safety profile is covered. The description adds value beyond them by disclosing the confirmation-before-running requirement and the total scope of destruction.

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 and usage rules are front-loaded and efficient, but the majority of the text is a long block of output-phrasing rules (citations, labels, vendor rankings, tone) that reads as shared boilerplate rather than tool-specific instruction. That bloat dilutes the signal an agent needs to pick this destructive tool.

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 zero-parameter destructive tool with no output schema, the description covers the essential facts: what it destroys, when to invoke it, and that confirmation is required. Handling of a 'not_covered' result is mentioned, which compensates for the absent 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?

The tool takes zero parameters and the schema is an empty object with 100% coverage, so there is nothing for the description to disambiguate. Baseline 4 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 ('Deletes every stored company fact') and clearly distinguishes it from the sibling read/update tools get_profile and update_profile. The scope of the deletion ('every stored company fact') is 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?

Gives an explicit trigger ('only when the user explicitly asks to delete their profile') and notes it is separated out so the assistant confirms first, which is real routing guidance. It does not name an explicit alternative or state what to do if the user asks indirectly, but the condition is 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 cover the safety profile (readOnlyHint, idempotentHint, non-destructive, closed-world), so the description is free to add genuinely useful behavior: the shape of the returned facts, the existence of a not_covered result state and what to do with it, and the obligation to preserve citation and 'Planned, not law yet' labels verbatim. That is 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?

Front-loads the purpose before the constraint list, and each rule is short. The block of answer-formatting rules is long for a tool definition, but for a guardrail-heavy compliance read each rule carries its own weight, so it is dense rather than 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, the description carries the return-value burden and does so adequately, naming the returned fields, the last-updated metadata, and the not_covered branch. Combined with annotations covering the read-only/idempotent profile, an agent has enough to call and interpret it.

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 tool takes zero parameters, so there is no parameter semantics to explain and the baseline for a no-param tool is 4. The description correctly spends no words on inputs.

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 ('Shows the company facts the assistant has stored') and enumerates the returned fields (categories, markets, role, own-brand flag) plus their last-updated timestamps, so the agent knows exactly what this read returns. It does not, however, distinguish itself from near-siblings like what_changed or scope_check.

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 extensive rules for how to phrase the ANSWER (citations, disclaimers, no personal duties, no vendor ranking), but nothing about when to choose get_profile over siblings such as scope_check, required_fields, or what_changed. Tool-selection guidance is absent.

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, but the description adds substantial behavioral context beyond them: grounding constraints ('add no facts, dates or articles of your own'), citation/disclaimer/label preservation, phrasing rules, vendor-neutrality, and the not_covered response path. This is unusually rich disclosure for a read-only 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?

The purpose and topic scope are front-loaded, and every sentence carries a distinct operational rule. It is nonetheless a dense block of stacked prohibitions; a short grouped sentence on grounding/citation rules would read more cleanly without losing content.

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 fully earns its keep: it describes the return shape (points each with a source date), the label states ('Planned, not law yet', 'being re-checked'), and the not_covered case. An agent has everything needed to call it and render the answer 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% and each parameter carries its own description and enum, so the schema already does the heavy lifting. The description's topic list loosely mirrors the topic enum but adds no syntax or format detail beyond it, 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 verb and resource ('Explains the EU DPP Registry and the technical side') and enumerates the covered topics (registration, identifiers, QR/data carriers, data formats, standards, where data is kept) that map directly to the topic enum. It also explicitly distinguishes itself from the sibling scope_check.

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?

Gives an explicit routing rule: 'For who owes, keeps or may hand off a passport, use scope_check.' It also prescribes handling of the not_covered outcome, so the agent knows both when to use this tool and what to do with an unhelpful result.

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 disclose the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false); the description adds genuinely new behavior by stating the report lands in a review queue, i.e. an asynchronous side effect rather than immediate resolution. It does not cover duplicate-report handling or authorization requirements, but with annotations carrying the mutation profile this is a useful addition.

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 two sentences are well front-loaded (trigger, then destination), but the remaining majority of the text is post-call output policy rather than invocation guidance, and it repeats itself ('Never rank or recommend vendors. Never call this advice or yourself a consultant.') and piles on similar prohibitions.

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 only 2 required-capable parameters, no output schema, and no nesting, the description is nearly complete; it even hints at a result shape via the 'not_covered' outcome. It stops short of describing the actual return fields an agent would act on.

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 both parameters are already documented in the schema, including the 'pass them from the result unchanged' instruction that the description merely repeats. The description adds no syntax, format, or constraint detail beyond 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 verb and resource ('Report a wrong or unclear answer') and adds the destination ('The report goes to a review queue'), leaving no ambiguity about what the call does. It does not, however, name or differentiate itself from any sibling tool, and the sibling set (profile/registry tools) offers no overlap to disambiguate against.

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?

Gives an explicit trigger condition: 'Use it when the user says an answer was wrong or unclear.' This is a clear context signal with no plausible alternative tool, though no when-not-to-use condition or explicit alternative is 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 readOnly/idempotent/non-destructive/closed-world, so safety is covered; the description adds genuinely non-schema behavior — the two-phase summary-then-fields pattern and the not_covered outcome the agent must handle. The remaining bulk is answer-formatting policy (no invented dates, keep citations and disclaimers, no vendor ranking) rather than tool mechanics, which is useful but not classic behavioral disclosure.

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 the summary-then-fields workflow are front-loaded in the first sentence and a half. The tail is a long run of prohibition clauses; each maps to a distinct compliance risk, but they are numerous enough that the definition reads as policy text appended to a tool description.

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 the necessary work of naming the returned fields and defining the not_covered result. It doesn't discuss result size, ordering, or behavior for an invalid subType (left to the schema), so a small gap remains, but the definition is sufficient to invoke the tool 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% and already documents `group` (omit for summary, provide for fields), `locale`, `subType` and the category enum with mapping advice. The description's 'call without group / with a group' restates the schema rather than adding syntax or edge-case meaning beyond it, 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 ('Lists the data a passport must contain for a product category') and enumerates the returned facets (requiring article, audience, change frequency, origin). The resource is clearly distinct from siblings like create_draft_passport, registry_guidance or what_changed, so an agent can route 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?

Gives an explicit calling sequence: without `group` for a summary of counts, then with a `group` for the fields, plus a defined branch for the not_covered result. It does not name alternative sibling tools or state when to prefer them over this one, so it stops short of full when/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?

Annotations only cover the safe-read profile, but the description adds substantial behavior: the result can be needs_input or not_covered, data.inScope takes one of four values, and results may carry 'Planned, not law yet' or 'being re-checked' labels that must be preserved. It also constrains what the agent may add, which is real operational context.

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 body is a single dense paragraph mixing retrieval guidance with a long list of output-compliance rules ('never rank vendors', 'never call this advice'...), which makes it harder to scan than it needs to be. Most sentences do earn their place, but the block structure is poor.

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 burden of explaining returns, and it does name the status outcomes and the data.inScope enumeration. It stops short of describing the full response shape (e.g. what citation fields accompany the answer) for a fairly complex, nested-input 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%, with per-parameter descriptions already explaining role mapping, the facts allow-list, locale default, category mapping and date precision. The description adds only the downstream hint that facts may come from a needs_input result, 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?

The first sentence states a specific verb and resource: it checks whether EU law requires a Digital Product Passport for a product type, from when, and per-role obligations. It then enumerates the concrete question shapes the tool answers, which makes it unambiguously different from siblings like create_draft_passport or required_fields.

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 'Use it for' list of user phrasings and prescribes a concrete follow-up loop (if needs_input, ask the user its questions in plain words and call again). It does not name any sibling or state when a different sibling tool is the better choice, so it falls short of full alternative routing.

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 declare destructiveHint=true and idempotentHint=true, but the description usefully clarifies that the operation merges facts rather than replacing the whole profile, resolving the ambiguity around what 'destructive' means here. It does not state permissions or what happens to conflicting existing facts, but it adds genuine 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?

Purpose is front-loaded, but the description runs long with a large trailing block of answer-formatting rules (citations, disclaimers, phrasing rules) that reads as agent policy rather than tool documentation. Those sentences crowd out tool-specific detail for a 8-parameter mutation.

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 an 8-parameter, zero-required mutation with no output schema, the description covers merge behavior, the invocation trigger, and post-call handling of results such as not_covered. Nothing critical to calling it correctly is missing, though field-level usage detail is left entirely 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%, so every parameter is already documented with types, enums and examples. The description only name-drops a few fields (role, categories, markets, own-brand) without adding format or semantic detail, 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 verb+resource ('Saves or corrects company facts') and the merge semantics of the operation. However, the second half of the description shifts into output/answer policy (never rank vendors, don't call yourself a consultant), which blurs the tool's core purpose and never contrasts it with siblings like get_profile or delete_profile.

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?

Gives a concrete trigger ('when the user states a lasting fact about their company… or to save a learnable fact from a result'), which is clear context for invocation. It stops short of naming alternatives or when-not-to-use cases against the sibling profile 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 cover the read-only/idempotent/non-destructive profile, and the description goes well beyond them: it defines the 'Planned, not law yet' and 'being re-checked' output labels, discloses the not_covered result state and how to handle it, and constrains answer phrasing and citation retention.

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-loaded with what it does and when to use it, followed by response-handling rules. It is fairly long, but nearly every sentence is an actionable constraint rather than filler, so it earns most of its length.

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, so the description usefully compensates by describing the label semantics, the not_covered case, and citation expectations. Minor gaps remain around result format or volume, but an agent has enough to call and present this 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 coverage is 100% with three self-documented parameters, including the enum and the since/locale/categories defaults, so the baseline is 3. The description restates only the since-lookback default, adding no syntax or format detail beyond the 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?

States a specific verb and resource — reports changes in EU passport law and standards — scoped to the user's product categories since a date, and gives a concrete default lookback. This is clearly distinguishable from siblings like registry_guidance or scope_check, which serve different intents.

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?

Gives explicit triggers ('what's new' or 'has X been adopted') and a when-not signal (items marked Planned are not yet law; not_covered means say so). It never names alternative sibling tools, so it stops short of the 5-level requirement of explicit alternatives.

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