public

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), and the description adds meaningful context beyond them: the OAuth/permission requirement and the fact that the payload includes any step only the person can perform, which implies partial results the caller cannot complete.

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 compact sentences with no filler; the return contents are stated before any caveat. The auth sentence leads, which slightly buries the purpose, but nothing in the text 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?

No output schema exists, and the description compensates by enumerating the key returned fields and the unusual 'step only the person can do' element. For a one-parameter read with annotations carrying the safety profile, the only real gap is how to obtain a valid case_id.

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 0%, so the description is the only place semantics could be added. It mentions case_id but adds no format, constraints, or where the identifier comes from (e.g., from list_my_cases), leaving the one parameter under-explained despite a maxLength of 200 in 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 (returns one case by case_id) and names exactly what comes back: current status, verification status, and any user-only step. It is distinguishable from list_my_cases by the singular, id-keyed scope, though it never names that sibling explicitly.

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

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

Gives a prerequisite (OAuth plus the 'share_results' permission) but no when-to-use/when-not guidance. An agent must infer that this is the single-case detail lookup versus list_my_cases or get_removal_route; the usage is implied rather than 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 cover safety (readOnly, idempotent, non-destructive, closed-world), so credit goes to the added semantics: which evidence counts as verified and which does not (inventory rows, aliases, agent callbacks). It doesn't state freshness guarantees beyond 'latest scheduled sweep,' permissions required, or cost of the read.

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, zero waste: the first front-loads the reported fields, the second immediately qualifies the counting rule that governs their meaning. No restatement of the title or schema.

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 params, no output schema and safety carried by annotations, the description must convey what comes back, and it lists the return components plus the counting rule. Minor gap: the shape/format of those counts (per-route vs aggregate) and staleness expectations 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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. It does not need to explain arguments that do not exist.

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?

A concrete verb, 'Read,' tied to a specific resource and an enumerated payload: catalog size, route variants, verified counts, today's checks and latest sweep. It is distinguishable from per-route siblings like get_route_verification by being a coverage snapshot, but the description never names those siblings or draws the contrast explicitly.

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

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

The text explains what gets reported but not when to choose it over get_route_verification, get_service_overview or request_recheck. There are no exclusions, prerequisites or alternative-routing cues, leaving selection to inference from the title.

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, destructiveHint=false and openWorldHint=true, so the description is not obligated to restate the safety profile, and instead adds genuine value: the required permission scope, the exact shape of the returned payload, and explicitly what is NOT returned (no listing URLs, no observed values). It also documents the authorization_required outcome with a connect URL, which an agent needs in order to recover from a failed call.

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?

Four tight sentences with no filler; the payload contents and exclusions are stated before the error behavior. The auth prerequisite leads, which is slightly less useful up front than leading with what the tool returns, but it is defensible.

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 capably substitutes by enumerating the returned fields, the deliberate omissions, and the error envelope. The one meaningful hole is the unresolved subject_id semantics for a tool that declares zero required parameters.

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 0% for the single subject_id parameter, and the description mentions 'the subject' only in passing as part of the permission requirement. It never explains what subject_id identifies, whether it can be omitted (it is not required), or whether it defaults to the caller's own subject.

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+resource combination: it returns the exposure report summary the dashboard shows, and it enumerates the exact per-site fields (site, status, what it exposes, guide link). This is more concrete than a vague 'gets a report', though it never names a sibling to distinguish itself from tools like get_service_overview or get_case_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?

It states prerequisites (OAuth plus the 'share_results' permission) and the failure mode, but gives no guidance on when to pick this tool over the many sibling read tools such as get_case_status or get_service_overview. An agent must infer the choice from the tool name alone.

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 genuinely non-obvious behavior: retired sites return what-to-do-now guidance without historical actionable forms, and the payload includes a content review date plus a separate current native verification. It does not say what happens on an unknown broker (error vs. empty), which is the one remaining gap.

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, all load-bearing, with the guide contents front-loaded. The first sentence is a long comma-list that reads as a run-on, but no clause is filler and the retired-site caveat is placed before the input rules where an agent will see it.

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 must carry the return contract — and it does, enumerating the guide sections (answer, steps, troubleshooting, FAQs, sources, review date, native verification) and the retired-site fallback. The only omission is failure behavior for an unrecognized or missing broker.

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 parameter is fully documented, so the baseline is 3. The description adds a concrete example ('spokeo') and lists the five accepted identifier forms, and the 'no personal lookup' line clarifies what the field must not contain — reinforcing the schema's 'Never a person's details' warning.

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 with full content scope: 'the complete free website guide: direct answer, steps, troubleshooting, FAQs, official sources and content review date, plus separate current native verification.' That distinguishes it clearly from list_opt_out_guides (enumeration) and get_removal_route (routing). It also covers the retired-site variant, so an agent knows the response shape in both branches.

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?

'Accepts a slug (spokeo), domain, name, alias, or URL' and 'No login or personal lookup' give input conventions and a privacy constraint, which implies usage. But it never says when to choose this over get_removal_route or list_opt_out_guides, and no exclusions are stated. Usage is inferable rather than instructed.

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, and the description adds real context beyond them: the registry breadth, that a single request may cover sibling sites via the parent company, and the possible method values (form, email, both, guide, none). It omits failure behavior for a site not in the registry.

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

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

One dense sentence with the scope ('950+ sites in the takedown registry') front-loaded, followed by the return payload inventory. Slightly list-heavy but every enumerated item is information the caller would otherwise have to query.

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

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

With no output schema, the description correctly carries the return-value burden by naming every field returned, which is what an agent needs. The main gap is what happens when the site is absent from the registry (empty result vs. error).

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 parameter already documents domain-or-URL with an example; the description's 'Accepts a domain or a URL' merely restates it. No added syntax, normalization, or matching rules.

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 precise verb and resource and enumerates the exact record contents (method, opt-out URL, privacy email, parent company, sibling sites, guide link) so an agent knows what comes back. It does not explicitly name how it differs from nearby siblings like get_opt_out_instructions or list_opt_out_guides, so the distinction must be inferred from 'link to our step-by-step guide'.

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

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

Usage is only implied: it is clear this is the lookup for a single site's removal route, and 'Accepts a domain or a URL' plus the 950+ site scope give context. There is no statement of when to prefer this over get_opt_out_instructions or list_opt_out_guides, and no exclusions.

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 cover read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful context beyond that by clarifying badge semantics ('No badge means the route is not currently verified') and explicitly stating it does not start checks or submit requests. It does not cover auth or rate-limit behavior, but those are less critical here.

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 main action and contains no filler. The first sentence lists several return fields in a dense way, which is slightly less scannable, but the overall text is appropriately sized.

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 responsibility for explaining return values and does so by listing checked scope, actor, region, capture time, expiry, and failures. It also explains the badge interpretation. Some terms like 'independently checked scope' remain vague, but the core behavior is adequately covered.

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 fully documents the single route parameter as an exact route ID, domain, or published guide slug. The description only mentions 'domain or route ID' and omits the guide slug option, so it adds little and slightly narrows the schema's stated 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?

The description states a specific verb-resource pair: read the exact official route variants and current verification details for a domain or route ID. It partially differentiates from siblings by saying it never starts a check or submits a request, which separates it from request_recheck and submit_approved_plan, though it does not explicitly distinguish itself from get_library_verification_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?

Usage is implied rather than explicit: the tool is framed as a read-only status retrieval, and the line 'never starts a check or submits a request' signals it should not be used to trigger rechecks. However, there is no explicit 'use this when...' guidance or direct naming of alternatives such as request_recheck.

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 fully covered. The description adds one genuinely useful behavioral fact: the content is public reference material with no personal or account-specific data, which prevents the agent from expecting user-scoped results. It says nothing about size, freshness, or whether the content changes over time.

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 clauses with no filler; the content enumeration is dense and front-loaded, and the scope restriction lands last. Slightly list-like phrasing rather than a leading verb keeps it from a 5.

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

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

With no parameters and no output schema, the description carries the burden of describing the return value, and the enumerated topics effectively do that. What is missing is whether the returned document is large, static, or versioned, but for a zero-arg reference read this is close to sufficient.

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 are no semantics to explain and the baseline is 4 by rule. The description correctly implies the call needs no input.

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 enumerates the content areas of a static document (tool scope, private check, listing review and pricing, limitations, registry statistics), which goes beyond restating the title. However, it is phrased as a noun list with no verb, so the agent must infer the action is 'read/return this reference document' rather than something computable. It is distinguishable from the personal-data siblings via 'public reference information only', but only implicitly.

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?

No explicit when-to-use guidance and no named alternatives among the many siblings. The only usage signal is the trailing clause 'Contains public reference information only', which weakly implies this is for general/pricing/limitation questions rather than case or subject lookups, but the agent must infer that.

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 and destructiveHint=false, so the safety profile is covered; the description adds genuinely non-redundant context by stating OAuth plus the 'share_results' permission is required. It also reveals the identity/visibility scope ('my' cases) and the state vocabulary, though it says nothing about pagination or result volume.

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

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

Three tight sentences with zero filler, though front-loading the OAuth/permission prerequisite ahead of what the tool actually does slightly delays the agent's primary read; the purpose could have come first.

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

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

With no output schema, the description correctly steps in to list the returned fields, which is the main completeness need. However, an undocumented filtering parameter and absent pagination/result-size guidance leave a real hole for a list operation.

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 0% and the single optional parameter subject_id is never mentioned in the description, so an agent gets no clue whether it filters by person, workspace, or something else. The description must compensate for a 0%-coverage schema and does not.

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 opens with a specific verb+resource ('Lists removal cases') and enumerates the returned fields (site, action, request status, verification status, human-only steps, dates), which clearly separates it from singular siblings like get_case_status. It stops short of naming an alternative, but the scope 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?

Usage is implied by 'my removal cases' and the note that filed/pending/needs review/verified removed are distinct states, but there is no explicit when-to-use versus when-not, and no routing to get_case_status or list_my_subjects for narrower questions.

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 and destructiveHint=false, so the safety profile is covered; the description adds real context beyond that — an OAuth requirement and the fact that account setup and grant problems surface as structured statuses rather than errors. It stops short of describing pagination or how many subjects may come back.

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 OAuth prerequisite and then the most decision-relevant fact (what a subject record contains). No filler, though the final sentence about 'structured statuses' is vaguely worded and slightly undercuts the precision of the rest.

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 must carry return-value detail, and it does name the fields returned and the side-channel statuses. Remaining gaps are minor: no indication of whether the result is a single subject or a collection, and no pagination or ordering note.

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 nothing for the description to compensate for; the baseline for a 0-param tool is 4. No parameter detail is needed or missing.

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 a specific verb (lists) and resource (the subjects/persons on the account) and clarifies what a 'subject' is — first name, city, state, verification status — plus that it exposes the subject_id used by account tools. That clearly separates it from siblings like list_my_cases or get_my_report, though no sibling is named explicitly.

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

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

Usage is implied rather than stated: the mention of 'the subject_id used by account tools' hints this is an id-lookup step before other account calls, and 'Requires OAuth' sets a prerequisite. But there is no explicit when-to-use, no when-not-to-use, and no alternate tool named for overlapping needs.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile needs no restating. The description adds genuinely new behavior: results are deduplicated, undocumented facts come back as null rather than being omitted, and the list spans both active guides and retired-site explanations. It does not cover default page size or ordering, which keeps it at a 4.

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

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

Two tight sentences, front-loaded with what the tool returns before the capability note. Every clause carries information; the field enumeration is dense but earns its place by telling the agent what to expect back.

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 read-only, no-required-parameter list tool with no output schema, the description covers the important ground: returned fields, null semantics, deduplication, and the two filter/paging dimensions. Missing only paging defaults and result ordering, a minor gap rather than a blocking one.

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 0%, so the schema documents only types and bounds. The description compensates partially by revealing that 'limit'/'offset' are paging controls and 'category' is a filter, but it never states defaults, max page size, or whether offset-based paging is stable, leaving real ambiguity for a 0%-coverage schema.

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

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

The description states the resource precisely ('summaries of every curated website guide and retired-site explanation, without duplicates') and enumerates the fields returned (kind, domain, category, method, review date), so an agent knows exactly what this tool yields. It does not name or contrast itself with the nearest sibling, get_opt_out_instructions, so it falls short of a 5.

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

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

There is no statement of when to call this versus get_opt_out_instructions or search_privacy_library, both of which sound closely related. The only usage-adjacent content is 'supports paging and category filters', which describes capability rather than selection criteria.

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 say readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds what matters beyond that: OAuth plus the 'run_check' permission, a 24-hour rate limit, entitlement gating, and the full set of terminal outcomes including retry_after and pricing_url. That is exactly the extra context annotations cannot carry.

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 dense sentences, front-loaded with the auth requirement and the core action, then eligibility, then return values. Every clause carries distinct information with no repetition of the title or schema.

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 enumerates return states and their payload fields, covering the return-value gap well. The one hole is behavior when subject_id is absent, which leaves an agent unsure how to invoke it for a single-subject versus default case.

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 0% for the single parameter, so the description must carry the load — and it never names subject_id nor explains that it is optional (required list is empty) or how the subject is chosen when omitted. 'Verified subjects only' and 'existing details' give indirect meaning but do not resolve the ambiguity.

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 — 'Queues a fresh check of the person's existing details (the same re-scan Patrol runs monthly)' — and immediately scopes it against what it is not ('never starts a first check and never takes new details'). This distinguishes it from every sibling, which are get/list read tools.

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 preconditions and exclusions: Patrol plan only, verified subjects only, once per 24 hours, and it will not start a first check. It also redirects purchase intent to the website, giving the agent a clear alternative 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds meaningful context beyond that: the corpus is public/published content and results are 'ranked hits with canonical source URLs', which tells the agent about ranking and citability — important since 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?

A single front-loaded sentence that names the corpus first, then the topics, then the return shape. No filler, no restatement of the title, and every clause carries information.

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

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

With no output schema, the mention of ranked hits and canonical URLs is a valuable partial substitute. But for a search tool with two undocumented range-constrained parameters, the description omits query formulation guidance, result ranking/ordering rules, and whether results are paginated or capped by limit, leaving gaps an agent would have to discover by trial.

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 0% for both parameters; the schema only supplies constraints (query 2-200 chars, limit 1-20). The description says nothing about what a good query should contain, whether natural language or keywords work, or what limit defaults to or how it affects ranking. Only the topical list hints at query subject matter, which is insufficient compensation for a full coverage gap.

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 a precise resource scope: My Privacy Agent's published articles, opt-out guides, help answers, and plan facts, with topical coverage spelled out (data brokers, opt-outs, relisting, pricing, service limitations). It implicitly separates from lookup siblings like get_opt_out_instructions or get_service_overview, but never names them, so differentiation is inferred rather than stated.

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 word 'search' and the phrase 'published articles ... help answers' imply exploratory/discovery usage rather than record retrieval, which is enough to prefer it over the get_* lookups in some cases. However, there is no explicit when-to-use statement, no when-not-to-use, and no mention that specific lookups (get_removal_route, list_opt_out_guides) should be preferred once the user knows what they want.

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 destructiveHint/openWorldHint annotations, it discloses the OAuth and 'submit_requests' permission requirement, the two-phase preview/commit contract, the fact that it consumes an already-granted website approval and paid entitlement, and the 'a request is not a removal' caveat. It does not say whether queued requests can be cancelled or what the preview/queue payload looks like, which keeps it off a 5.

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?

Four short sentences with no waste, front-loaded with the access requirement and the preview/commit split, then the hard limits, then the closing caveat. Every sentence carries information an agent needs.

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 destructive, open-world mutation tool with no output schema, the description covers prerequisites, mode semantics, error branches, and scope limits — enough to call it safely. The only real hole is what subject_id refers to and what a successful response returns, neither of which is recoverable from structured data.

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 50%: confirm is already documented in the schema and the description reinforces it with the 'only after the person has seen the preview' safeguard. subject_id has no description in either place, so the agent must infer that it identifies the person whose approved listings are being submitted.

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 — it queues removal requests for the exact listings shown in a preview — and explicitly separates the preview mode (no confirm) from the commit mode (confirm: true). The negative scope clause ('cannot approve listings, pick new sites or buy anything') makes it unmistakable against the read-only get_/list_ 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?

Explicitly gives the when-to-use condition for each mode: omit confirm to preview eligible listings, pass confirm: true only after the person has seen the preview and agreed. It also names the failure branches (approval_required, entitlement_required) so an agent knows what to do when prerequisites are unmet.

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