Movahedi Privacy API

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

Annotations already establish that this is a read-only, idempotent, non-destructive, closed-world lookup. The description adds substantive behavioral context beyond that: first-party cookies can be third-party in substance, _ga is given as an example, and unknown names return known: false rather than a guess.

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 front-loaded and generally efficient, with purpose first and routing guidance at the end. There is some redundancy between the narrative sentence about who asks what and the separate Use when / Do not use when lines, which keeps it from being maximally tight.

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 a rich output schema and read-only annotations already present, the description supplies everything else an agent needs: purpose, return concept, edge-case behavior for unknown cookies, and sibling routing. Nothing material appears missing for correct invocation.

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 the single name parameter, including that it is a cookie name only and not a value or URL. The description reinforces that it classifies by name but does not add syntax or constraints beyond the schema, 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?

The description states a specific verb and resource: classify one cookie by name, and enumerates the returned dimensions (vendor pattern, legal party, purpose, retention, control class). It also distinguishes itself from lookup_tracker, so an agent can select it without opening sibling 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 explicitly says when to use this tool: when someone names one cookie and asks who receives its data, or asks what a cookie is / first-party vs third-party. It also explicitly says when not to use it and names the alternative, lookup_tracker, for browsing many cookies.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered; the description adds the pagination trait and names the closed registry scope. It stops short of saying how filters combine or what ordering results come back in, which would be the remaining behavioral detail.

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 the core action and filters, then use cases, then exclusions — good ordering. Minor waste: the 'Use when' line largely repeats the opening sentence's filter list.

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 an output schema present (including next_offset) and full annotation coverage, the description needn't explain return values, and it correctly flags pagination. The one gap is filter-combination behavior, which matters for a six-parameter list tool but is not addressed.

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 enums are already documented, so the schema carries the parameter burden. The description restates the filter dimensions and their accepted values (operator examples, the five purpose classes) but adds no semantics the schema lacks, such as whether multiple filters AND together or how `query` interacts with the structured filters.

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 ('List AI crawlers from the registry') plus the three filter axes, and implicitly separates itself from lookup_crawler by telling the agent not to use it for a named token. An agent can pick this over the lookup siblings without opening a 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?

Contains explicit 'Use when' and 'Do not use when' clauses, with the exclusion naming the alternative behavior ('look that token up directly' = lookup_crawler). It also gives two concrete motivating scenarios (comparing operator training/search splits, enumerating training crawlers before writing robots.txt rules).

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, and closed-world, so the safety profile is fully covered structurally. The description adds genuinely useful behavioral detail beyond that: matching is case-insensitive but exact, with 'GPT does not match GPTBot' as a concrete failure mode. However, the listed return fields (operator, purpose, robots.txt, documentation) largely duplicate what the output schema already conveys, so the net addition is moderate rather than rich.

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 the core action, followed by return value, matching rule, and a clean conditional block. Every sentence carries distinct information; nothing is padding despite the multi-part structure.

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 one required parameter, full schema coverage, rich annotations, and an output schema, the description covers the remaining gaps: what the tool returns conceptually, how matching behaves, and when to route elsewhere. An agent has everything needed to call it correctly on the first attempt.

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 contributes semantics the schema does not state: matching is case-insensitive yet exact, and a near-miss token returns nothing. That matching rule directly changes how an agent should construct the argument, which is real added value.

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 ('Look up one AI crawler or bot by its exact user-agent token') and immediately clarifies scope with named examples (GPTBot, Claude-User). The 'one' vs. list distinction makes it trivially separable from list_crawlers without opening either 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?

Uses explicit 'Use when' / 'Do not use when' framing, and the negative case names the correct alternative (list_crawlers). The condition that selects this tool — a single named token — 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 declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds that results are paginated and that it is a knowledge-base search rather than a live crawl, which is useful context beyond the annotations, though it doesn't mention ordering or whether matches include both cookies and non-cookie trackers in one result set.

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 purpose and search dimensions, then structured use/don't-use and a pagination note. Slight redundancy: the "Use when" clause restates the opening sentence's searchable fields almost verbatim.

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 an output schema present, return-value explanation is unnecessary, and annotations cover safety. The description covers purpose, discovery routes, the sibling exclusion, and pagination, leaving only minor gaps such as result ordering or whether vendor and query filters combine.

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 four parameters are already well documented, including query scope and offset/next_offset paging. The description's list of searchable fields largely restates the query parameter's documented coverage, adding only illustrative use cases rather than new parameter semantics.

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 ("Search the cookie and tracker knowledge base") and enumerates the searchable dimensions: cookie name, vendor, recipient organisation, purpose. It also explicitly contrasts with the sibling classify_cookie, so an agent can distinguish the two without inspecting 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?

Provides explicit "Use when" and "Do not use when" clauses and names the alternative (classify_cookie) for the excluded case of a single known cookie. The routing decision is fully determined by the description.

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 read-only, idempotent, non-destructive, and closed-world behavior. The description adds important beyond-schema behavior: each operation counts against the daily quota, a failed operation returns its error in place without aborting later independent operations, and $ref can pass values between operations.

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 front-loaded with the core behavior and then usage guidance. It is slightly repetitive in the 'Use when: use when...' and 'Do not use when: do not use...' phrasing, but every major sentence contributes useful operational context.

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 rich annotations, 100% schema coverage, and an output schema, the description covers what is still needed: batching semantics, quota impact, failure isolation, and cross-operation references. Nothing critical for correct invocation 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?

Schema description coverage is 100%, so the nested operation fields are already documented. The description adds meaning beyond the schema by explaining the cross-operation $ref pattern and the shaping options in the context of batched execution.

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: run several read-only privacy API operations in one call using allowlisted GET path templates. It explicitly distinguishes this batch tool from many single-tool calls and, in the guidance, from the native tool for single lookups.

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 explicit when-to-use guidance ('a question needs several lookups') and when-not-to-use guidance ('a single lookup; call the native tool directly'). The alternative tool choice is named directly, leaving little 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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is fully covered. The description's field list (summary, outcome, penalty, source link) largely restates what the output schema already exposes. It does not say what happens for an unknown or malformed ID, which would be the genuinely additive detail.

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 purpose and contents, then usage rules, so structure is good. The 'Use when' line however restates the first paragraph almost verbatim ('someone has a case id and wants that one case in full'), which is mild 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?

With an output schema present, the description needn't explain return values, and it correctly focuses on selection and sequencing. The only gap is error behavior for invalid IDs, a minor omission for a single-parameter read 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 a regex pattern and an example ID already present. The description adds only that the ID originates 'from a search result,' which is marginal beyond the schema. Baseline 3 applies when the schema carries the parameter meaning.

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 ('Get the full record of one privacy enforcement action by its ID') and enumerates what the record contains. It is clearly distinguishable from privacy_search_enforcement_actions, which is named as the search counterpart.

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 sequencing ('Use this after privacy_search_enforcement_actions'), an alternate trigger (case ID already known, with a concrete example ID), and an explicit exclusion ('Do not use when someone is searching by topic'). Both when and when-not are covered.

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 this is a read-only, idempotent, non-destructive lookup with no open-world behavior. The description adds useful behavioral context about what the checklist covers and how category filtering works, without contradicting annotations. It could mention freshness or static-reference nature, but it is otherwise transparent.

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 key purpose is front-loaded and the description is reasonably sized. However, the later 'Use when' sentence partially repeats the earlier sentence about what Law 25 requires, adding mild 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?

Given the read-only reference nature, full parameter schema coverage, and presence of an output schema, the description supplies enough context for an agent to call it correctly. It covers scope, filtering, and exclusions.

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 single optional category parameter is fully documented with an enum and description. The description gives examples like 'Consent' and 'Incident response' and says omit for the full checklist, but this largely repeats the schema's own description rather than adding new semantics.

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: get the Quebec Law 25 compliance checklist. It enumerates the substantive coverage areas and distinguishes it from federal PIPEDA or case-specific queries, so an agent can identify 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?

Explicitly provides both when to use it and when not to use it, including the optional category-filtering scenario. The alternative-boundary language about PIPEDA terms or cases alone 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 declare this as a read-only, idempotent, non-destructive, closed-world operation, so the safety profile is covered. The description adds genuinely new behavioral context: the corpus size (331 terms) and the pagination contract (follow next_offset while has_more is true), which the annotations do not convey. It stops short of describing match/sort semantics for combined query plus starts_with filters.

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 opening sentence is front-loaded with scope, capability, and pagination, and the Use when / Do not use when lines are easy to scan. There is mild redundancy between the 'Use this to explore...' clause and the 'Use when someone wants to browse or search' line, which restates the same intent in different words.

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 paginated browse/search tool with four optional parameters, full schema coverage, and an existing output schema, the description covers everything an agent needs: corpus scope, filtering modes, the sibling to use for single-term lookups, and the pagination loop. Return-value details are correctly left to 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 description coverage is 100%, so all four parameters (limit, query, offset, starts_with) are already documented with defaults, bounds, and patterns; the baseline of 3 applies. The description confirms that search and first-letter filtering are optional and independent, but adds no detail on how query matching or filter combination behaves 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 and resource (browse the 331-term Canadian privacy glossary) plus the two filtering modes, and explicitly distinguishes it from the sibling privacy_lookup_glossary_term by pointing at slug discovery and exploration rather than single-term retrieval.

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 explicit use cases (explore existing terms, find a slug for the lookup tool, gather definitions on a topic) and an explicit exclusion: do not use it when one known term is requested, look that term up directly. The alternative sibling is named, not implied.

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, and closed-world, so the safety profile needs no restating. The description adds useful operational context — lookup is keyed strictly by slug and requires a discovery step for unknown terms — but says nothing about what the payload contains, which is acceptable given an output schema exists.

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 opening sentence is well front-loaded and the when/when-not blocks are scannable. There is mild redundancy — the slug/discovery note appears in the opening paragraph and is partly restated in 'by slug' — 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?

For a single-parameter, read-only lookup with an output schema and full annotation coverage, the description supplies everything an agent needs: trigger condition, exclusion, slug format, and the discovery path for unknown slugs. Nothing material 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?

Schema coverage is 100% and the schema already supplies the slug pattern and examples, so the baseline would be 3. The description goes beyond it by clarifying the semantic role of the parameter (a slug, not a free-text term name) and by naming the sibling tool that produces valid slugs, which prevents the most likely invocation error.

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 ('Look up') and resource ('plain-language definition of a privacy or data-protection term') with concrete examples spanning Law 25, PIPEDA, and AI governance concepts. It is clearly distinguishable from siblings like privacy_list_glossary_terms (enumeration) and privacy_search_enforcement_actions (fines/cases).

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 'Use when' and 'Do not use when' blocks name the exact trigger (a user asking what one term means, by slug) and route the enforcement/fine case to a named alternative. It also proactively points to privacy_list_glossary_terms for slug discovery, so the agent has a complete decision path.

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 readOnly/idempotent annotations, it discloses that ranking is deterministic with no model call and that each hit carries method, path, parameters, use-when and do-not-use guidance plus an example query. That is exactly the context an agent needs to trust and act on the results.

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 purpose, examples, and return shape, then structured Use-when/Do-not-use lines. The 'use when unsure which operation fits a question' idea is stated three times, which costs a little tightness.

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?

Annotations cover safety, an output schema covers return shape, and the prose adds the one thing neither provides: that results are deterministically scored and include per-operation usage guidance. Nothing needed to call it correctly 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?

Schema coverage is 100%, with descriptions and examples for both query and limit, so the schema carries parameter meaning. The description adds no additional semantics about query phrasing or limit behavior, making baseline 3 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 ('Search the movahedi.ca public API') and frames the input as a plain question rather than an endpoint guess. This clearly distinguishes it from lookup/execute siblings such as lookup_tracker or privacy_execute_plan, which act on a known operation.

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 when/when-not blocks: 'search first, then call the best match' versus 'do not use when the right operation is already known; call it directly.' It even supplies concrete sample questions, so routing 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 declare readOnlyHint, idempotentHint, destructiveHint=false, and closed-world scope, so the safety profile is covered. The description adds real value beyond that: what the response contains (dates, plain-language summaries, penalties, source links) and the intended two-step workflow into privacy_get_enforcement_case. It stops short of noting result ordering or search matching behavior.

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 the core statement, then workflow, then structured Use/Do-not-use lines. Slight redundancy: the 'Use when' line largely restates the opening sentence about fines and enforcement cases, costing a little space.

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 an output schema, full parameter documentation, and rich annotations, the description covers purpose, scope, response contents, and next steps. Minor gap: nothing about result ordering or how paging interacts with the query/regulator filters beyond what the offset field says.

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 already documents its meaning and constraints. The description implies the year/regulator/query filters through examples but adds no syntax or semantics beyond the schema, 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 (search) and resource (verified Canadian privacy enforcement actions), and names the two covered regulator corpora (CAI/Law 25, OPC/PIPEDA). It distinguishes itself from privacy_get_enforcement_case by framing this as the discovery step that yields a case 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?

Explicit 'Use when' triggers (fines, penalties, cases, investigations), concrete example queries, and an explicit 'Do not use when' pointing to a glossary tool for definitional questions. The alternative tool for full case details is named.

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