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

No annotations are provided, so the description carries the full burden. It discloses the return shape and the 10-patent limit, and 'Get' implies a read-only operation, but it says nothing about behavior on invalid or unknown publication numbers, partial failures, result ordering, or whether citations include non-patent literature.

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: the first states the operation and the return shape, the second states the hard limit. Nothing is padded, though the field list is dense inline prose that could be marginally cleaner.

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 inline return field list ({publication_number, cited_by_count, cited_by_patents, cited_by_url}) is exactly what is needed for the agent to know what comes back, and the batch cap is stated. Missing details about error handling are minor for a simple 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?

There is a single parameter and schema description coverage is 100%, with the example format (CN110286864A) already documented in the schema. The description adds only the batch-size constraint, which is relevant semantics but not parameter-level clarification 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 ('Get cited-by counts and lists') and scopes it to the batch case with 'for multiple patents in a single call', which implicitly separates it from the sibling get_cited_by. It never names that sibling directly, so the differentiation requires the agent to infer it from the plural framing.

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 agent can infer this is for multiple patents, and the 'Max 10 patents per call' constraint tells it when to be careful. However, there is no explicit guidance on choosing this over get_cited_by for a single patent, or what to do when more than 10 numbers are needed.

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?

No annotations are provided, so the description carries the full burden. It usefully discloses the hard limit of 20 patents per call and the return type, but says nothing about what happens on exceeding the limit, error/failure handling for invalid publication numbers, or permission requirements.

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 short sentences, all earning their place: purpose, sibling comparison, return shape, and limit. The core value proposition (batch speed) is front-loaded.

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 one-parameter batch read with no output schema, the description covers purpose, return type, and the batch ceiling. Minor gaps remain around limit-exceeded behavior and failure handling, but nothing an agent needs in order to invoke 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?

There is a single parameter with 100% schema description coverage, including an example format (CN110286864A), so the schema already documents it fully. The description adds only the implicit constraint that the array size is capped at 20, which is baseline-level 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 ('Get full details for multiple patents in a single call') and explicitly distinguishes itself from the sibling get_patent by framing the batch operation as faster than N separate calls. It also names the return shape (list of PatentDetail objects).

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 clear usage context by contrasting with get_patent N times and states the batch ceiling (max 20 per call), which tells the agent when this is the right choice. It stops short of an explicit when-not rule (e.g. prefer get_patent for a single lookup).

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?

With no annotations, the description carries the full burden, and it does disclose the internal pipeline (Google Patents search, then forward and backward citation fetches, optional competitor matrix). It does not state that the operation is read-only, that it performs many sequential network calls with associated latency/cost, or how partial failures are handled. Adequate but incomplete for a multi-step network 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?

Three short sentences, front-loaded with the purpose, then the mechanism, then the conditional branch and return fields. No sentence is redundant and nothing is buried.

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 or annotations, and the description compensates by listing the returned artifacts (patents list, forward_graph, backward_graph, competitor_matrix). All three parameters are documented and the conditional path is explained, though operational caveats like latency and read-only behavior are absent.

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 baseline is 3, but the description adds real semantics beyond the schema by explaining that competitor_keywords triggers an additional competitor citation matrix. It also implies the graph scope is bounded by the company's core patents, complementing the limit parameter.

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 gives a specific verb+resource ('Build full bidirectional citation graph') and immediately scopes it to a company's core patents. The word 'bidirectional' cleanly distinguishes it from the directional siblings get_cited_by and batch_get_cited_by, and the mention of the competitor matrix separates it from competitor_citation_matrix.

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 the conditional trigger for one behavior ('If competitor_keywords provided, also runs competitor citation matrix'), which is useful. However, it never says when to choose this tool over get_cited_by, batch_get_cited_by, or competitor_citation_matrix, so usage relative to alternatives is only 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?

No annotations are provided, so the description carries the full burden, and it does substantial work: it discloses the data source ('scrapes Google Patents directly'), the cost profile ('Zero BigQuery cost'), and expected latency (5-10s). It omits auth requirements, rate limits, and failure modes, but the disclosed operational traits are well above baseline.

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 purpose, then outputs, cost, use cases, and latency in a compact block. The enumerated return fields are dense but justified since no output schema exists; each sentence carries information rather than filler.

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 compensates by enumerating returned fields (total count, top tech areas, jurisdiction coverage, activity level, risk assessment), plus cost and latency. A practitioner could call it correctly; only cross-sibling routing guidance is thin.

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 single company_name parameter is fully documented in the schema, including Chinese/English examples. The description's mention of 'Chinese or English' duplicates the schema, so it adds no meaning beyond structured data — baseline 3 for full schema coverage.

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

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

States a specific verb and resource ('Get a quick patent portfolio summary for a company') and immediately frames it as an aggregate/portfolio-level tool, which implicitly separates it from the patent-level siblings like get_patent or get_patent_claims.

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?

Names three concrete scenarios ('initial company screening, competitor overview, due diligence triage'), giving an agent a clear sense of when this is the right entry point. It stops short of naming an alternative sibling or stating when NOT to use it (e.g., when you already have a company ID and want full results).

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?

No annotations are provided, so the description carries the full burden, and it does disclose the non-obvious behavior: per-patent cited-by traversal, case-insensitive substring matching of assignees, and the exact return structure. It omits rate limits, handling of invalid publication numbers, and pagination, but the core algorithmic behavior is 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?

Three tight sentences: purpose first, matching mechanism second, return shape last. Every sentence earns its place with no filler.

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 explains the return shape (matrix plus summary counts), which is essential. Largely complete for a two-parameter read tool, though edge cases like empty matches or invalid patent numbers are unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both parameters are documented with examples, so the schema does the heavy lifting. The description reinforces the keyword matching semantics (case-insensitive substring) but adds 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: checking whether target patents are cited by competitors, with the exact matching mechanism named. This is clearly distinguishable from siblings like get_cited_by (unfiltered) and bidirectional_citation_graph.

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 implies when to use it (filtering citing assignees by competitor keywords) but never states it explicitly or names alternatives such as get_cited_by for an unfiltered cited-by list. Usage must be inferred from the sibling set.

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?

With no annotations, the description carries the full burden. It does disclose the data source ('Extracted from Google Patents HTML') and enumerates return fields, implying a read-only scraping operation, but says nothing about auth, rate limits, missing-data behavior, or accuracy/freshness caveats.

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, front-loaded with the core purpose, then return shape, then provenance. Every sentence carries information; nothing is 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?

For a simple single-parameter read tool with no output schema, describing the returned fields (cited_by_count, cited_by_patents structure) closes the main information gap. Only the missing routing guidance against siblings keeps it from a 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and there is a single parameter with a concrete example format, so the schema fully documents the input. The description adds no format syntax or constraint beyond that, 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 and clarifies direction with '(who cites this patent)', which is genuinely useful given the bidirectional_citation_graph sibling. It doesn't explicitly name the sibling alternatives (batch_get_cited_by, bidirectional_citation_graph), so it stops 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?

No when-to-use guidance, no exclusions, and no mention of batch_get_cited_by or bidirectional_citation_graph, which are the obvious alternative entry points for citation data. The agent must infer from the name alone when this single-patent version is preferable.

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?

With no annotations, the description carries the full burden, and it does disclose an important behavioral trait: the data is scraped from a Google Patents page, implying external dependency and possible failure. It does not state whether the operation is read-only (implied by 'Get'), what happens for unsupported jurisdictions, or any rate-limit/auth constraints.

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; the core action is front-loaded and the field list and jurisdiction note follow in support. The enumeration of returned fields is long but earns its place since there is no output 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?

Without an output schema, the description correctly compensates by enumerating the returned fields and the supported jurisdictions. Remaining gaps are behavioral rather than informational: no error/fallback behavior for unsupported jurisdictions and no timing or rate-limit expectations.

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?

Single parameter with 100% schema description coverage, including worked examples ('US-7650331-B1', 'CN-110286864-A'). The description adds no format or syntax detail 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?

The description names a specific verb and resource ('Get legal status of a patent') and enumerates exactly what it extracts (status, kind_code, dates, assignee, legal events timeline), which separates it from siblings like get_patent_claims or get_patent_family. However, it never explicitly contrasts itself with get_patent, which likely also returns bibliographic data, so an agent must infer the boundary.

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 or when-not-to-use guidance and no named alternative. The jurisdiction note ('Works for CN, US, EP, and most other jurisdictions') implies applicability scope but does not tell the agent when this tool is the right choice versus get_patent.

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?

With no annotations, the description carries the full burden and does so reasonably: it discloses the return surface (classifications, citations, family ID, dates, inventors, assignees) and the DOCDB format requirement, and explains the X/Y citation markers, which is genuine domain context beyond the name. It omits edge cases like invalid-number behavior, but for a read-only lookup this is solid 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?

Three tight sentences, front-loaded with the core action, followed by return contents and the citation-marker interpretation. Every sentence contributes; nothing is padding.

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

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

With no output schema and no annotations, the description is the only source for return-value expectations, and it enumerates the payload fields well. Minor gaps remain (no paging/error behavior), but for a single-record lookup it is close to 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 coverage is 100% and there is a single parameter, so the baseline is 3. The description reinforces the DOCDB format constraint, but the schema's own example ('US-7650331-B1') already conveys the expected format, so the description adds little beyond it.

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 ('Get full patent details') and scopes it by publication number in DOCDB format, then enumerates the returned data. This effectively distinguishes it from narrower siblings like get_patent_claims or get_legal_status, though it never names those alternatives directly.

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 explicit guidance on when to use this versus siblings such as get_patent_claims, get_legal_status, or batch_get_patents for multiple numbers. The agent must infer that 'full details' means the general-purpose lookup, and there are no stated exclusions or prerequisites.

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?

With no annotations, the description must carry the full burden, and it does disclose useful behavioral context: data coverage across US, CN, and most other countries via Google Patents. It does not mention return format beyond 'text', rate limits, or failure behavior for unknown publication numbers, so a mid score is warranted.

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 short sentences, front-loaded with the action, and nothing is redundant. The middle sentence is slightly educational but earns its place by justifying why an agent would fetch claims.

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

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

For a simple one-parameter retrieval tool with no output schema, the description covers what it fetches, the identifier to use, and country coverage. It is close to sufficient, with only minor gaps around return format and error behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single required parameter with 100% schema coverage and concrete example formats ('US-7650331-B1', 'CN-103257828-A'), so the schema does the heavy lifting. The description only restates 'by publication number' and adds no format or parsing detail beyond that.

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

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

States a specific verb+resource (get patent claims text) and keys off a publication number, which clearly separates it from siblings like get_patent, get_legal_status, or search_patents. It could be sharper by explicitly noting it returns claims only rather than the full patent, but the resource 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 ('Claims define the legal scope of patent protection') which hints at when an agent should want claims rather than a full patent, but it names no alternative tools or explicit when-not conditions. No routing guidance is given despite several closely related siblings.

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?

With no annotations, the description carries the burden and does well: it discloses the two-step mechanism (BigQuery family_id lookup, then a broad unfiltered retrieval of ALL members), which sets expectations about scope and latency. It omits edge-case behavior (e.g., what happens when no family_id exists) and any auth/rate-limit notes.

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 the core purpose front-loaded, followed by the lookup mechanism and the return shape. Every sentence carries information, including the BigQuery detail, which usefully hints at a multi-step lookup.

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?

Since there is no output schema, the description correctly enumerates the return payload (family_id, member_count, and member fields), which is exactly what an agent needs to consume the result. It stops short of describing failure/empty-result behavior for an unknown or family-less publication number.

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 single parameter is documented with format examples in the schema, so baseline 3 applies. The description adds nothing about the identifier format beyond what the schema already shows.

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 patent family members for a patent') and explains the domain concept ('same invention filed in different countries'), which cleanly separates it from siblings like get_patent, get_patent_claims, and get_cited_by.

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 the resource name rather than stated: an agent can infer you call this when you want international family members instead of the patent record itself, but there is no explicit when-to-use/when-not guidance or named alternative such as get_patent.

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the cost-control requirement, the shape of the returned data (titles, abstracts, inventors, assignees, CPC codes), and a locale-specific behavior (CN patents include Chinese titles and abstracts). It does not mention pagination, rate limits, or auth, keeping it short of 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?

Three sentences, all load-bearing: purpose with facets first, the cost-control constraint second, and the return-shape/locale notes last. No filler or restatement of the tool name.

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 8 parameters, 100% schema coverage, and no output schema, the description supplies the missing pieces an agent needs: the prerequisite filter constraint and a summary of the return payload including CN-specific behavior. Minor gaps remain around result ordering and whether limit is the only pagination mechanism, but nothing essential to calling it correctly is absent.

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 already 100%, so the baseline is 3, but the description adds a genuine cross-parameter constraint absent from the schema: at least one of country, cpc, or after is required. It also clarifies that query is optional and that results are summaries, both of which are not obvious from the schema defaults alone.

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 (Search) and resource (global patents) and enumerates the four filterable facets (keyword, country, CPC, date range), so an agent knows exactly what the tool does. It does not explicitly contrast itself with siblings like get_patent or get_cited_by, but the search-vs-fetch distinction is clear from the phrasing.

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 actionable usage constraint: at least one of country, cpc, or after must be provided to control query cost. That is clear operational guidance for selecting and shaping a call, though it stops short of naming an alternative tool for the cases where the constraint can't be met.

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