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

With no annotations, the description bears the burden of behavioral disclosure. It explicitly states the operation is non-mutating ('nothing is created in the account') and that results are bounded by row limits with pagination tokens. This adds meaningful behavioral context beyond the input 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?

The description is two sentences and front-loaded with the core purpose, followed by side-effect and pagination context. Every sentence earns its place without redundancy or 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?

The description covers the main behavior, non-mutation, and pagination, but it does not mention the customer_id parameter or clarify whether at least one of seed_keywords or page_url is needed. Given the lack of an output schema and no annotations, an agent has a moderate but not complete picture.

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 must compensate. It maps seed_keywords to 'seed terms', page_url to 'page URL', and page_token to 'pagination tokens', but it does not mention customer_id at all. It adds partial value but leaves one parameter unexplained.

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 action: generating keyword ideas from seed terms and/or a page URL, with average monthly searches and competition. It clearly identifies the resource and purpose, though it does not explicitly differentiate this from siblings like get_keyword_forecasts.

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

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

The description gives clear context for when to use the tool: when keyword ideas are needed from seed terms or a page URL. It does not name alternatives or exclusions, but the usage scenario is concrete enough to guide selection.

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 description discloses that this is a live, authenticated read, which conveys freshness and implies a non-mutating operation—useful since no annotations are present. However, it does not address auth permissions, error behavior, or how the optional parameter affects 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?

The definition is a single compact sentence with no filler and no redundant restatement. The field list is front-loaded, and the live-read qualifier adds useful behavioral context without bloating the description.

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

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

For a one-parameter read tool without an output schema, the description lists the returned fields and states the read is live and authenticated, covering the basic default call. It is incomplete regarding customer_id semantics, return formatting, and error behavior, so it is only minimally complete.

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

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

Schema description coverage is 0%, and the description never mentions customer_id, so it adds no meaning beyond the property title and default null. The relationship between the optional customer_id and the authenticated account is left completely unexplained.

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 clearly identifies the resource ('Account identity') and enumerates the returned fields, making the tool's purpose understandable. It is implicitly distinct from sibling tools like list_accounts or performance reports, but it lacks an explicit verb such as 'gets' or 'returns'.

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

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

The description gives no guidance on when to use this tool versus list_accounts, run_gaql, or the performance tools. It names no alternatives, exclusions, or selection criteria; 'live authenticated read' provides context but not usage direction.

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 description mentions pagination tokens, indicating paginated results. However, with no annotations, it does not disclose whether the operation is read-only, permission requirements, or rate limits—significant gaps for a tool with no annotation support.

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 a single 12-word sentence that front-loads the core purpose and adds the pagination note. No filler or 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 6 optional parameters, no annotations, and no output schema, the description fails to explain what metrics are returned, how to specify date ranges, or how pagination tokens are used. An agent would be unable to invoke this tool correctly based on the description alone.

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

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

Schema description coverage is 0%, so the description must compensate for 6 undocumented parameters. It only hints at a 'date window' and 'pagination tokens', but does not explain date formats, mutual exclusivity, or the roles of customer_id/campaign_id—insufficient for the parameter count.

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 tool returns ad-level metrics within a date window, which identifies the resource and scope. It distinguishes from sibling tools like get_campaign_performance and get_keyword_performance via 'ad-level', though it does not explicitly name an alternative.

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 guidance is provided on when to use this tool versus get_campaign_performance, get_keyword_performance, or other siblings. The description only states what it does, leaving selection entirely to inference.

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

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

With no annotations provided, the description carries the full burden. It discloses that money is decimal with currency, that enabled_only filters server-side, and that the date window can be explicit or last_n_days. It doesn't mention pagination behavior, rate limits, or what happens if both date_range and last_n_days are provided. The description adds some behavioral context but not comprehensive.

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 compact and front-loaded with the core purpose. It packs useful details into three sentences without excessive verbosity. The structure is logical: what it returns, then key details about money and filtering. It could be slightly more organized but is efficient overall.

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 7 parameters, no output schema, and no annotations, the description is incomplete. It doesn't explain pagination (page_token), required identifiers (campaign_id, customer_id), or the interaction between date_range and last_n_days. An agent would need to infer or experiment to call this correctly. The description provides a good start but lacks critical operational details.

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 must compensate for 7 parameters. It mentions date window (explicit range or last_n_days), budget, bidding strategy, status trio, and enabled_only. However, it doesn't explain page_token, campaign_id, customer_id, or the exact format of date strings. The description covers some parameters but leaves several undocumented, which is a significant gap given zero 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?

The description clearly states the tool returns campaign metrics for a date window, including budget, bidding strategy, and status fields. It distinguishes itself from sibling tools by focusing on campaign-level metrics rather than ad, keyword, or geo performance. However, it doesn't explicitly name a sibling alternative, so it loses a point for not directly differentiating from similar performance 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?

The description implies usage context: it's for campaign metrics with date range options and a server-side filter. It mentions 'enabled_only=true filters server-side,' which gives some guidance on when to use that parameter. However, it doesn't explicitly state when to use this tool versus alternatives like get_ad_performance or get_keyword_performance, nor does it provide 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 provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It discloses the date range policy (29 days before today through today), the LIMIT 1000 cap, the possibly_truncated signal on every local page, the fact that local tokens cannot recover beyond the cap, and the upstream maximum LIMIT 10000. It also clarifies the end-date boundary behavior (including fractional seconds, up to but excluding the next calendar day's midnight). This is rich behavioral context that an agent needs to handle pagination and truncation correctly.

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 dense but well-structured, front-loading the core purpose in the first sentence and then layering constraints and edge cases. Every sentence adds meaningful information about date handling, pagination, truncation, or alternatives. It is longer than average, but the complexity of the tool (date boundaries, pagination caps, truncation signals) justifies the length. A slight deduction for the density of the truncation explanation, which could be more scannable, but overall it earns its place.

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 tool's complexity (date range semantics, pagination, truncation, upstream limits) and the absence of both annotations and an output schema, the description is remarkably complete. It covers the key behavioral aspects an agent needs to call the tool correctly: date format, date range, time zone, end-date boundary, LIMIT 1000, possibly_truncated signal, token limitations, and the alternative run_gaql for larger queries. The only minor gap is the lack of explicit description for optional parameters like customer_id and resource_type, but the overall context and schema structure make their roles inferable.

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 must compensate for the schema's lack of parameter documentation. The description explains the date range semantics (strict YYYY-MM-DD, inclusive from 29 days before today through today) and the LIMIT 1000 behavior, which directly informs how date_range_start and date_range_end should be set. However, it does not explicitly describe page_token, customer_id, or resource_type parameters, though the overall context implies their roles. Given the 0% coverage, the description adds substantial meaning for the required parameters but leaves some optional parameters undocumented.

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 clear, specific verb and resource: 'Who changed what, when, with which client: change events with actor email, client type, and old/new values per changed field.' This precisely states what the tool returns and distinguishes it from sibling tools like get_campaign_performance or get_ad_performance, which focus on performance metrics rather than change history.

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 provides explicit usage guidance: strict YYYY-MM-DD dates, inclusive from 29 days before today through today in the verified account time zone, and a LIMIT 1000 with a note that more than 1000 events may need a different run_gaql query. It also distinguishes this tool's local 30-calendar-date policy from provider sub-day retention, and explicitly mentions when to use run_gaql as an alternative for larger result sets.

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 present, so the description carries the full burden of behavioral disclosure. It only enumerates output fields and does not state whether the operation is read-only, what customer_id does, whether the result is a list, or any pagination/rate-limit behavior. This is a data summary rather than a behavioral contract.

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 a single concise phrase that front-loads the resource and compactly lists the key fields without fluff. It is appropriately short, though its fragmentary noun-phrase structure prevents it from being a complete, structured sentence.

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

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

Given there is no output schema and no annotations, the description still leaves several gaps: the return shape, whether multiple items are returned, and the semantics of the optional customer_id parameter. The listed attributes give partial context but not enough to invoke the tool correctly with confidence.

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 schema has one parameter, customer_id, with 0% schema description coverage, and the tool description completely ignores it. The description adds no meaning about what customer ID should be passed or how it affects the results, thus failing to compensate for the missing schema documentation.

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 resource ('conversion actions') and lists the exact attributes returned (category, type, status, counting type, primary-for-goal flags), which clearly distinguishes it from sibling get_* tools. It lacks an explicit verb like 'retrieves' or 'lists,' leaning on the tool name for the implied action, but the agent can still infer the purpose precisely.

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 guidance about when to use this tool versus any of the 19 sibling tools, nor any mention of conditions or prerequisites. The description gives no routing information, so an agent must infer usage solely from the resource name.

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 behavioral context. It does disclose that results are date-window bounded and pagination tokens are used, implying a batched read operation. However, it doesn't describe return contents, page size, or how date filters interact with last_n_days.

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 compact sentence with no redundancy. The key facts—geographic scope, date window, and pagination bound—are front-loaded and every phrase earns its place.

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 six-parameter tool with no annotations and no output schema, this description is incomplete. It doesn't explain required filters, how pagination tokens are obtained or used, or what the returned geographic performance data looks like.

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 six parameters, so the description must compensate. It only glosses the date-window and pagination concepts; campaign_id, customer_id, and the relationship between last_n_days and date_range_start/end remain unclear.

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 identifies the resource as geographic performance and scopes it to a date window, which matches the tool name. It lacks an explicit verb and doesn't differentiate it from sibling performance tools, but the 'geographic' dimension makes the purpose reasonably clear.

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 guidance on when to use this tool versus alternatives such as get_campaign_performance or get_keyword_performance. No exclusions, prerequisites, or selection criteria are provided.

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 present, so the description carries full burden. It discloses null impressions and absent estimates, preservation of zero/fractional clicks, strict date parsing, February 29 clamping, account time zone refusal, decimal currency, and side-effect-free computation—exceptionally 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 description is dense but every sentence carries a substantive constraint or behavior; the main action is front-loaded. It would be more skimmable with bullets, but no filler is present.

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 no output schema and no annotations, the description covers input constraints, output nullability and numeric preservation, currency, and side effects. The only minor gap, explicit customer_id roles, is arguably covered by 'requested account's time zone.'

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%, but the description compensates well by explaining date-range semantics, the keyword_texts alias and agreement rule, and monetary output format. It leaves customer_id largely implicit, so it is not a perfect 5.

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?

Opens with a specific verb and resource: 'Forecast clicks, cost, and average CPC for supplied keywords.' It then distinguishes itself by noting the nonpersisting v25 API and explicitly 'no KeywordPlan is ever created,' which separates it from sibling planning and reporting 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?

Clear context is given: this is for forecasting future date ranges, with start must be future and end within one calendar year, and defaults to next 30 account-local days. It does not explicitly name alternative tools or give when-not-to-use conditions, so it misses the top bar but is more than merely 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 present, so the description carries the burden of behavioral disclosure. It does add one meaningful behavioral detail: results are bounded with pagination tokens, which signals a paged API. It does not mention read-only semantics, response shape, aggregation behavior, or any rate limits, so transparency is only partial.

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 a single, compact sentence that front-loads the core purpose and adds pagination behavior without filler. Every word contributes to understanding the tool.

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

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

For a six-parameter tool with no output schema and no annotations, the description leaves important gaps: whether campaign_id or customer_id are required, default date-window behavior, conflict rules between last_n_days and explicit date ranges, pagination page size, and expected return structure. The agent cannot confidently invoke this tool correctly without additional inference.

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 must compensate for six undocumented parameters. It loosely maps 'date window' to the date-related parameters and 'pagination tokens' to page_token, but it does not explain campaign_id or customer_id, nor how last_n_days relates to date_range_start/date_range_end. This is not enough compensation for the schema's complete lack of parameter descriptions.

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 identifies the resource as keyword metrics and lists specific fields (text, match type, bid, quality signals), which is more specific than the tool name alone. It also states the date-window scope brief. However, it lacks an explicit verb like 'retrieves' or 'returns,' and it does not explicitly differentiate itself from sibling performance tools beyond the keyword focus.

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 guidance on when to use this tool versus siblings such as get_campaign_performance, get_ad_performance, discover_keywords, or get_keyword_forecasts. The description only says it provides keyword metrics for a date window, leaving the selection criteria entirely implicit.

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 of behavioral disclosure. It includes a notable behavior: 'Empty trees are valid results,' which sets expectations about possible empty responses. However, it doesn't disclose other important behaviors such as whether the campaign must be a Shopping campaign, how deep the tree goes, or any pagination or latency implications.

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 concise (one sentence plus a note) and front-loads the key concept ('Listing-group trees'). The note about empty trees adds value without padding. It could be slightly more structured, but it is efficient and to the point.

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 tool's moderate complexity (tree structure with parent links, dimensions, exclusions) and the lack of output schema, the description gives a good high-level overview but omits details like the exact data shape, whether the tree is nested or flat, and how to interpret the response. The note about empty trees is helpful. There is room for improvement in specifying the response format.

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% because the property titles ('Campaign Id' and 'Customer Id') are generic and the schema does not provide descriptions. The description does not elaborate on the parameters beyond the tool's general scope. For instance, it does not explain that campaign_id is required and identifies the target campaign, or that customer_id is optional. This is a gap for agents to understand required vs. optional and how to fill them.

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 identifies a clear verb ('get') and resource ('listing-group trees') and specifies the scope ('per PMax asset group and standard Shopping ad group for the requested campaign'). It conveys the purpose well, though it does not explicitly distinguish from sibling tools like get_shopping_performance or get_product_status, which are thematically related.

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 usage in the context of campaigns and ad groups, suggesting it is used for retrieving listing-group structure rather than performance data. However, it lacks explicit guidance on when to choose this tool over alternatives or any exclusions (e.g., 'use get_shopping_performance for metrics'). No when/not-when guidance is provided.

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 exist, so the description carries the full behavioral burden, but it only names a resource and says nothing about read-only behavior, permissions, data scope, or response characteristics. It is a minimal fragment rather than a disclosure of 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?

'Campaign-level negative keywords.' is tight and front-loaded with no filler, but it is a noun fragment rather than a complete description. It is concise but under-specified for a tool definition.

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 tool with no output schema and no annotations, this one-line description leaves the agent without information about return shape, how customer_id affects behavior, or any edge cases. The minimal resource label is not enough to fully support 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?

The schema has 0% parameter description coverage and the description does not mention customer_id at all. Since the description must compensate for low schema coverage and does not, the agent gains no additional parameter meaning beyond the parameter name and nullable/default metadata.

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 phrase 'campaign-level negative keywords' clearly identifies the resource and scope of this retrieval call, and the 'get' verb in the tool name completes the action. It does not explicitly contrast with sibling tools such as get_keyword_performance, so it stops short of full differentiation.

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 provides no guidance on when to use this tool instead of alternatives like run_gaql or get_keyword_performance. There is no mention of intended scenarios, exclusions, or other tools to prefer.

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 provided, the description carries the full disclosure burden. It clearly states behavioral traits: summary returns a bounded topic histogram and entity-status breakdown, while full paginates with filters. The explicit 'never an unbounded dump' warning improves transparency. It does not cover permissions or data freshness, but the described behaviors are substantial and useful.

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 two sentences with no fluff. It front-loads the resource and scope, then packs mode behavior, output shape, filters, and a safety guarantee into the second sentence. Every clause adds value.

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 tool with no output schema and no annotations, the description covers the core behavior well: summary output and full-mode pagination. But it leaves page_token and customer_id undefined, and it doesn't clarify what full mode returns per page (only that it paginates). These gaps prevent it from being fully complete for an agent.

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 must compensate. It explains the meaning of mode=summary vs full and names the filters enabled_only, campaign_id, and topic. However, it omits page_token and customer_id semantics, leaving two of six parameters unexplained. Partial compensation but incomplete.

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

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

The description names the resource as 'policy issues' and specifies the exact scope: ads, PMax asset-group assets, and campaign-linked sitelink assets. It also differentiates the two modes (summary vs full), making the tool's function clear. It does not explicitly contrast with sibling tools, but the domain is distinctive enough to stand apart.

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

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

The description gives clear within-tool guidance: summary mode is bounded, full mode paginates with filters, and there is never an unbounded dump. This tells an agent when to use each mode and signals the tool is appropriate for inspecting policy issues. It does not mention cross-tool alternatives, but the context is sufficient for selecting this tool over performance-focused 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 provided, the description carries the full burden. It discloses an important behavioral nuance: a campaign without a feed link returns NOT_FEED_LINKED rather than an error. This is non-obvious and adds real value. However, it does not mention other behaviors like read-only nature, permissions, or error handling beyond that specific case. Given the tool is a simple getter, this level of disclosure is above average.

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 two sentences with no fluff. The first sentence states the core purpose and scope, the second adds a caveat. Information is front-loaded and every word earns its place. It is concise while still providing the essential details.

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?

The tool is simple with only two parameters and no output schema, yet the description omits important details: it does not describe the output structure or the meaning of eligibility statuses. It also leaves the customer_id parameter unexplained. While the core purpose is clear, the lack of parameter clarification and response format makes it incomplete for an agent to confidently invoke the tool without further guessing.

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 must explain parameters. It mentions 'requested campaign' and 'linked merchant' but does not explicitly map them to campaign_id and customer_id. The description does not clarify whether customer_id is required or how it relates to the merchant. At 0% coverage, this is a significant gap; the agent must infer param meaning from names alone, which may not be sufficient.

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 exactly what the tool does: it retrieves Merchant Center feed health, specifically product counts by eligibility status scoped to a campaign and linked merchant. The verb 'get' and resource 'product status' are specific, and the scope (campaign and merchant) distinguishes it from siblings like get_shopping_performance or get_listing_groups. The mention of the NOT_FEED_LINKED return value further clarifies the tool's role.

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 the tool (when you need Merchant Center feed health for a campaign) but does not explicitly mention alternatives or conditions when not to use it. There is no reference to sibling tools like get_shopping_performance or get_listing_groups, so an agent might not know if this is the right choice versus those. The context is clear but lacks explicit routing guidance.

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

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

With no annotations, the description carries the burden. It discloses pagination-bounded behavior ('no unbounded dumps'), which is useful, but it does not disclose whether the operation is read-only, whether it requires specific IDs, what the response shape is, or any rate-limit implications. The pagination note adds value but leaves significant behavioral gaps.

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 a single compact sentence that front-loads the core purpose and adds a meaningful constraint. It is efficient, though it could earn a 5 by adding a brief usage pointer without bloating.

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 6-parameter tool with no annotations, no output schema, and 0% schema description coverage, the description is too thin. An agent cannot tell which parameters are required, how date filtering works, what the report contains, or what the pagination token flow is. The pagination note is a good start, but the overall context is incomplete.

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 must compensate, but it only mentions 'date window' and 'pagination tokens' generically. It does not explain the roles of campaign_id, customer_id, last_n_days, date_range_start, or date_range_end, nor how they interact. The description adds minimal meaning beyond the schema's bare field names.

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 ('Search-term report for a date window') and adds a distinguishing behavioral note about pagination tokens. It is clear enough to separate from siblings like get_keyword_performance, though it does not explicitly name a sibling alternative.

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 the tool is for date-windowed search-term reports and mentions pagination, but it does not state when to prefer this over get_keyword_performance or other reporting tools, nor does it mention required parameters or exclusions. Usage context is implied rather than explicit.

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 bears the full burden of explaining behavior. It only states what the tool returns and its scope, without explaining pagination (page_token), optional customer context, data freshness, rate limits, or whether results are aggregated. The read-only nature is implied by 'metrics' but not made explicit.

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 a single concise sentence with minimal filler, and the key qualifiers ('product-level', 'campaign', 'date window') are front-loaded. Every phrase contributes meaning. However, it is so brief that it omits important behavioral detail, which prevents 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?

The tool has 6 parameters, no output schema, and no annotations, yet the description provides only a high-level summary. It does not explain how to specify the date window unambiguously, whether pagination is needed, or what 'product-level' means in terms of result granularity. Given the tool's complexity, this is insufficient 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?

With 0% schema description coverage, the description must compensate for the parameter documentation gap, but it only mentions 'campaign' and 'date window' generically. It does not explain how last_n_days relates to date_range_start/date_range_end, what page_token does, or how customer_id affects the query. Parameter names are somewhat self-explanatory, but critical combinations and constraints are left undocumented.

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 communicates a specific verb ('get') and resource ('product-level shopping metrics') with clear scope ('for a campaign and date window'). It distinguishes itself from sibling tools like get_campaign_performance and get_ad_performance by using the term 'product-level shopping metrics'. However, it could be more explicit about exactly which metrics are returned.

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 offers no guidance on when to use this tool versus alternatives, nor does it mention exclusions or complementary tools. The intended context is vaguely implied by the phrase 'for a campaign and date window', but no explicit comparison to siblings is provided. An agent would have to infer usage 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?

With no annotations provided, the description carries the full burden and does substantial work: it discloses that the check makes a real authenticated API call, that OK means the API responded, and that it reports config, credentials, and guardrail state. It stops short of describing failure modes or response format, but the core behavioral truth is clearly exposed.

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 two tight sentences with no filler. 'Truthful liveness' is front-loaded, and every phrase adds meaning: real, authenticated, read, reports what it reports, and the explicit clarification of what OK means.

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 parameterless diagnostic tool with no output schema, the description is complete. It states the tool's behavior, the meaning of a successful result, and the categories of state it reports, giving an agent enough context to invoke it and interpret its purpose without further documentation.

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 has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics; it instead clarifies what the check reports, which is appropriate for a parameterless health check.

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: it performs a real authenticated Google Ads read and reports configuration, credential, and guardrail state. It also distinguishes itself from naive file-existence checks with the explicit 'never that config files merely exist' contrast, setting it clearly apart from the data-fetching sibling 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?

The description implies when to use this tool: to verify live API connectivity, credentials, and guardrails before relying on other operations. However, it does not explicitly name sibling alternatives or state when not to use it, leaving some inference required.

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 of behavioral disclosure. It only states what the tool does ('Accessible accounts') but does not clarify what 'accessible' means (e.g., permission-dependent), whether the result is a list of IDs, names, or objects, or if any pagination or filtering exists. No operational traits (e.g., read-only, rate limits) are disclosed.

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 a single, front-loaded sentence with no filler words. It communicates the core purpose efficiently. However, it is so brief that it borders on under-specification, which slightly detracts from an otherwise concise presentation.

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 tool with no parameters and no output schema, the description should at least hint at the return format or the meaning of 'accessible'. It provides only a minimal definition, leaving the agent without context on what the response contains or how to interpret 'accessible'. Given the simplicity, this is still inadequate.

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 has zero parameters, so the input schema is empty (coverage 100%). The baseline for 0 parameters is 4 because there is nothing to document. The description adds no parameter information, which is acceptable given there are none.

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 clearly states the verb ('list') and resource ('accounts') with a specific scope ('under the configured login customer'). It distinguishes itself from sibling tools like get_campaign_performance or run_gaql, which focus on data retrieval or query execution, not account enumeration. However, it doesn't explicitly name any alternative, so it's not a perfect 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 guidance on when to use this tool versus alternatives. While the name 'list_accounts' makes its purpose obvious, the description doesn't explain scenarios (e.g., 'use this to enumerate accounts before querying performance') or any exclusions. The agent must infer usage from the 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?

No annotations are provided, so the description carries the full burden for behavioral disclosure, but it only states the resource scope and that status is included. It does not explicitly confirm read-only behavior, default scoping when customer_id is absent, pagination, or any constraints. The verb 'list' weakly implies read-only, but the description adds minimal behavioral context beyond that.

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 very short and front-loaded with the core subject, and there is no filler or repetition. However, it is a fragment rather than a full sentence, and the brevity leaves substantive gaps in usage and parameter meaning.

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 list tool with one optional parameter and no output schema, the description names the returned content and status but leaves customer scoping and result shape ambiguous. The absence of annotations and output schema increases the burden on the description, yet it does not explain how customer_id is used or what the returned list looks like. An agent could probably invoke it, but the description is not fully self-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 schema has one property, customer_id, with 0% description coverage and no enums, and the description never mentions customer_id or explains how it affects results. The only meaning available is the property title 'Customer Id' and its default null, which is insufficient for an agent to understand scoping semantics. The description does nothing to compensate for the schema's lack of parameter documentation.

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 identifies the resource as campaign-level extensions/assets and names concrete types (sitelinks, callouts, structured snippets), making the target clear. The verb is implied by the tool name 'list,' and the phrase 'with status' adds a distinct output intent. It is distinguishable from sibling tools because it names extension asset types rather than accounts, performance metrics, or health data.

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 guidance is given about when to use this tool versus alternatives such as get_campaign_performance, run_gaql, or list_accounts. There are no conditions, exclusions, or mention of when this is the preferred access path. Usage context must be inferred entirely from the tool name and brief noun-phrase 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?

With no annotations provided, the description carries the burden. It discloses the operation is read-only, which is a key behavioral trait, and clarifies that apply/dismiss actions are not performed here but routed elsewhere. This adds meaningful context beyond the bare minimum, though it doesn't mention authentication, rate limits, or side effects (none expected for read-only).

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 two sentences with no filler. The primary purpose is front-loaded, and the behavioral note about read-only and routing is concise. Every sentence contributes meaning, making it appropriately sized and efficient.

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?

The description conveys the return type (typed impact projections with costs and conversions) and the read-only nature. However, it omits details on the customer_id parameter and any filtering or pagination behavior. For a simple list tool with no output schema, this is mostly complete but could be improved with a note on the parameter.

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 schema has one optional parameter (customer_id) with 0% description coverage in the schema. The description does not mention or explain this parameter at all, so it fails to compensate for the missing schema documentation. The agent is left to guess what customer_id does, making this a significant 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?

The description clearly states the tool lists Google's active recommendations and specifies the type of data returned (base vs potential cost and conversions). It uses a specific verb 'list' and a resource 'recommendations', which distinguishes it from the many get_* siblings, though it doesn't name an alternative 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 description implies use for viewing recommendations and notes it is read-only, but doesn't explicitly state when to choose this over alternatives. It mentions that applying/dismissing goes through a different flow, which gives some context, but no specific alternative tool is named. It is adequate but not explicit.

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 provided, the description carries the behavioral disclosure burden. It does well by describing the tool as a read, noting that results are returned in chosen formats, and that queries are 'passed through faithfully,' implying no internal filtering or transformation. It stops short of mentioning pagination, error behavior, or rate limits, but the core behaviors are 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?

Two sentences with no wasted words. The core action, scope, output formats, and pass-through nature are all front-loaded, and the 'workhorse read' phrasing is efficient and informative.

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 tool with 5 parameters, no annotations, no output schema, and zero schema description coverage, the description provides the essential query and format semantics but leaves pagination, customer scoping, and explicit sibling routing unaddressed. It is usable but not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the query parameter as a raw GAQL query and clarifies that format accepts json, table, or csv, but it says nothing about page_size, page_token, or customer_id. These parameters remain semantically vague aside from their names, leaving a meaningful gap for an agent selecting values.

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 ('Execute'), the resource ('raw GAQL query'), and the deliverable (rows in json, table, or csv). It also frames itself as the 'workhorse read' for any resource or field, which clearly distinguishes it from the specialized sibling 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?

The description clearly implies when to use this tool: when you need a raw GAQL query across any resource or field, as opposed to the pre-built specialized tools. It does not explicitly name alternatives or state when not to use it, but the 'any resource, any field' framing provides solid contextual guidance.

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

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

No annotations are present, so the description carries the full disclosure burden. It only states the search-by-name behavior; it does not mention matching semantics, pagination, returned fields, or the role of the optional customer_id.

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 tightly-scoped sentence with a helpful example and no filler. The verb and resource are front-loaded, and every word earns its place.

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 tool with no output schema and no annotations, the description leaves the agent guessing about return values, page size, and whether customer_id affects results. It is minimally usable but incomplete for a production call.

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 description only clarifies that results are found by name (query). It does not explain customer_id at all, nor does it hint at expected query formats like exact versus partial matches.

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'), resource ('geo target constants'), and method ('by name') with a concrete example. It clearly differentiates from performance-report siblings like get_geo_performance, which report metrics rather than performing constant lookup.

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 no guidance on when to use this tool versus alternatives or whether it is a prerequisite for geo targeting. The intended context is only implied by the name and example, with no exclusions or sibling differentiation.

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