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

Goes well beyond the annotations: 180-second loopback callback timeout, Desktop OAuth client flow, the fact that tokens are never returned to the caller, that force only mutates credentials after successful authorization, the requested scope (GOOGLE_GMP_SERVICES), and the read-only surface of this server despite broader scopes. These are exactly the side effects and constraints an agent needs for a non-idempotent, open-world auth call.

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

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

Front-loaded with the core action and the key safety fact (no tokens returned) in the first clause, then progressively deeper operational detail. Dense but every sentence carries information; the scope-vs-exposed-endpoints sentence is slightly wordy but genuinely useful context.

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

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

An output schema exists, so return values need not be described, and the description instead covers everything else an agent needs for a browser-based OAuth flow: host requirement, timeout, callback mechanism, credential-replacement semantics, and scope. The auth flow is fully actionable as written.

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%, so the description must carry the load, and it does: 'account' is explained as a lower-case alias like 'work' that creates a separate login, and 'force=true' is explained as replacing the selected account's saved sign-in only after success. It does not mention the default values (force=false, account=null) or how the default account is chosen, leaving a small gap.

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

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

States a specific verb and resource ('Sign in via the local browser and store credentials') and immediately distinguishes itself from every sibling by declaring it 'never returns tokens', which no other tool can claim. An agent can tell this is the authentication/session-establishment tool without reading the schema.

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

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

Explains the account-alias pattern for separate logins and that force=true replaces a saved sign-in only after successful authorization, which effectively frames when to use force versus not. It also names a prerequisite ('Requires a browser on the server host'), though it never explicitly says when to call this versus proceeding straight to the list/query 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?

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real context beyond them: which URL fields actually exist (progressiveServingUrl/streamingServingUrl for video only), that no download/preview URL is documented for HTML5 backup images, and that missing assets stay missing. It also issues safety guidance not derivable from any structured field ('Never construct CDN URLs from asset names or execute returned htmlCode').

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

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

Front-loaded with the core purpose in the first sentence, followed by short caveat sentences that each add distinct information. The telegraphic fragments are dense but every line earns its place; the only cost is slight terseness.

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?

An output schema exists, so return-shape explanation is unnecessary, and the description instead covers what the agent must know about interpreting returned assets and URLs. The remaining gap is parameter guidance, which is thin relative to a tool with 0% schema coverage.

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 carries the full burden, yet it only implies where creative_id comes from. It says nothing about profile_id (required), the optional account parameter, or expected ID formats, leaving two of three parameters undocumented anywhere.

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 CM360 creative metadata') and enumerates the content domains (sizes, assets, serving URLs), which cleanly separates it from the sibling list_cm360_creatives that it explicitly references for IDs.

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 tells the agent where the required IDs come from ('Use IDs from list_cm360_creatives') and gives an actionable HTML5 inspection path via creativeAssets with role BACKUP_IMAGE. It does not state any when-not-to-use condition or alternative for non-HTML5 cases, so it falls short of a full 5.

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

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

Annotations already establish readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds genuine value beyond that by explicitly negating a behavior the tool name invites agents to assume (no CSV download), preventing a wrong invocation. It omits auth/profile scoping and any note on URL expiry.

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

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

A single compact sentence with the positive purpose front-loaded and the exclusion trailing. Nothing is wasted, though the brevity is partly under-specification given the undocumented parameters.

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 output schema exists, so return values needn't be explained. But with 0% parameter description coverage and three required IDs whose nesting relationship is non-obvious, the description is too thin for an agent to construct a correct call without 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% across 4 parameters, so the description carries full responsibility — and it says nothing about profile_id, report_id, file_id, or account. The hierarchical relationship (profile containing report containing file) is the key thing an agent needs and is completely absent.

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 ('Get') and resource ('CM360 report file metadata and download URLs'), which is meaningfully more precise than the sibling list_cm360_report_files. It also pre-empts a likely misread of the name by specifying it does not return CSV content. It stops short of explicitly contrasting itself with the listing sibling.

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 exclusion ('does not download CSV content') implies this is the metadata step, not the retrieval step, which is useful routing information. However, it never names the alternative an agent should use to actually download content, so the when-to-use decision is left to inference.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds essentially no behavioral context beyond restating that this is a read of settings; it does not explain error conditions, permissions, or what 'settings' includes.

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 single sentence is front-loaded and waste-free. Its terseness is more an issue of missing context than of poor structure, so it fits the conciseness dimension well while leaving completeness gaps elsewhere.

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?

Although the tool is simple and has an output schema, the description leaves both input parameters undocumented and does not clarify how this differs from the list endpoint. For a get-by-id tool with zero schema descriptions, this is insufficient to call correctly without opening the schema.

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

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

Schema description coverage is 0%, so the description carries the full burden for two parameters. It implies advertiser_id identifies the advertiser, but says nothing about the optional 'account' parameter or the expected format of advertiser_id, leaving a meaningful 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 states a specific verb and resource: read one DV360 advertiser's settings. It is clear what the tool does, but it does not explicitly distinguish this from the sibling list_dv360_advertisers tool, leaving the agent to infer that this is single-record retrieval.

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

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

There is no explicit guidance on when to use this tool versus list_dv360_advertisers or how to obtain the required advertiser_id. The word 'one' weakly implies single-item lookup, but no alternatives or conditions are stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile needs no restating. The description adds real value by stating what comes back (status, metadata, URL when available), but it says nothing about authentication/account scoping or the case where a report is still generating and has no URL — the exact edge an agent will hit.

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

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

A single front-loaded sentence with no filler — verb, resource, and return payload in that order. Nothing here could be cut without losing information.

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

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

An output schema exists, so return values need not be detailed, and the description covers them at a high level. But with zero schema coverage on three parameters, including a nullable account selector, the definition leaves an agent guessing about inputs — adequate but with a clear gap.

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 carries the full burden for three parameters and delivers none of it: query_id, report_id, and the nullable 'account' parameter are never explained. It only loosely implies that report_id identifies an existing report, leaving the account/credential-selection semantics completely 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?

States a specific verb (get) and a specific resource (an existing DV360 report), plus what is returned: status, metadata, and the URL when available. That clearly separates it from list_dv360_reports and list_dv360_report_queries, though it never names those siblings 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 word 'existing' hints that the report must already exist, but the description gives no when-to-use guidance, no exclusions, and no pointer to the listing tools that produce the query_id/report_id it requires. An agent must infer the retrieval workflow entirely.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered by structured data. The description adds no behavioral context of its own — no note on failure behavior for unknown IDs, no mention of what the fetch guarantees relative to the list call. With annotations doing all the work, this is thin.

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 sentence, front-loaded with the action and resource, with no filler. The identifier-format hint is packed into the same clause rather than padding 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?

An output schema exists, so return values need no explanation, and annotations cover safety. Still missing for a two-param lookup: what "account" selects and what happens when the ID is not found — gaps that matter given a 0% schema coverage.

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 carry the params. It does partially: it clarifies that "organization" accepts either a bare ID or an "organizations/{id}" resource name, which the schema does not say. However, the "account" parameter is never mentioned, leaving half the input opaque.

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?

Specific verb+resource ("Get a GMP organization") with the lookup key named, which clearly separates it from the sibling list_organizations. It stops short of stating whether it resolves additional fields beyond the list entry, but an agent can tell what this does.

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 phrase "or organizations/{id} from list_organizations" implies the intended workflow: call list_organizations first, then fetch one by its identifier. There is no explicit when-not or statement of what happens if the ID is stale/invalid, so guidance is implied rather than stated.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely non-obvious behavior: dates are inclusive, interpreted in the customer account's timezone, and costMicros must be divided by 1,000,000 into customer.currency_code — real value beyond the annotations, though pagination behavior is never mentioned.

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

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

Four short lines, front-loaded with the returned metrics and followed by the operational constraints. No filler, though the opening is a bare metric list rather than a verb-led statement of what the tool does.

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?

An output schema exists, so return-value explanation is unnecessary, and annotations cover the safety profile. For an 8-parameter reporting tool the remaining gaps — pagination via page_token/page_size and what segment_by_date does to results — are meaningful omissions.

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% across 8 parameters, so the description must carry the load. It clarifies the date format/semantics and the cost_micros unit and hints at account hierarchy, but says nothing about page_size, page_token, segment_by_date (which changes result granularity), account, or login_customer_id.

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

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

The first line names the exact metrics returned (impressions, clicks, cost_micros, conversions, conversion value) and the tool name supplies the campaign/SA360 resource and reporting verb, so the purpose is unmistakable. It also constrains the account type (advertiser/client, not aggregate manager), which separates it from generic query_sa360, though it never names that sibling explicitly.

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

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

It states a clear usage condition: query an advertiser/client account rather than an aggregate manager for performance metrics. It does not say when to prefer this over query_sa360 or search_sa360_fields, so an agent gets a constraint but no explicit alternative routing.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so safety behavior is covered structurally. The description adds only the hint that hierarchy levels are returned, and says nothing about pagination despite page_size/page_token parameters, nor about how deep the traversal goes.

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

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

A single front-loaded clause with no filler, and the key scoping word ('beneath') appears early. It is efficient, but its brevity comes at the cost of the guidance dimensions rather than being a deliberate tradeoff.

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 five-parameter SA360 hierarchy tool with zero schema descriptions, one sentence is not enough: the caller cannot tell what customer_id means versus account or login_customer_id, nor how pagination should be driven. The output schema covers return values, so that gap is excused, but the input-side gap is not.

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 carries the burden for five parameters — including customer_id vs login_customer_id vs account, which are genuinely confusable in SA360. The description mentions none of them, leaving the manager-vs-login-account distinction entirely 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?

States a specific verb and resource (discover client accounts beneath an SA360 manager) plus the notable attribute of hierarchy levels. It is distinguishable from list_sa360_customers by the 'beneath a manager' framing, though it never names or contrasts any sibling explicitly.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no pointer to list_sa360_customers or query_sa360 as the alternative for flat listings or performance data. An agent must infer from the phrase 'beneath a SA360 manager' that this is a hierarchy-expansion call.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the baseline is low; the description still adds real value by stating no Google request or browser launch occurs and by clarifying that 'ready'/'refreshable' reflects credential presence only, not verified product permissions. That caveat is exactly the kind of nuance annotations cannot carry.

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

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

Two short sentences, front-loaded with the operation and then the constraint. Efficient, though the second sentence is dense and could be split for clarity.

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?

Return values are covered by the output schema and the safety profile by annotations, so the main remaining need is the meaning of the 'account' argument, which is absent. For a simple health check this is nearly complete, but not quite.

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 single optional 'account' parameter is undocumented in both places; the description never explains what supplying an account changes. With only one optional parameter the gap is modest, but the description does not compensate at all.

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 ('Check local configuration and token status') and immediately delimits scope with 'No Google request or browser launch', which separates it from the authenticate and list_* siblings that do touch the API. An agent can tell what it does without opening the schema.

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

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

The exclusion of network/browser activity implies this is a pre-flight sanity check, but the description never says when to prefer it over authenticate or when it should be run (startup, before a batch of calls, after a failure). Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description usefully bounds the result content (links only, no performance metrics), but says nothing about auth/permission requirements, pagination behavior, or result limits.

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

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

A single compact sentence with the resource and its scope front-loaded, no filler. It is efficient, though a fragment more on paging or the account filter would have earned 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?

An output schema exists, so return-value explanation is not required, but with 4 parameters at 0% schema coverage and no annotations covering pagination, the description leaves an agent guessing about the 'account' filter and paging. It is too thin for a paginated listing tool with three optional parameters.

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

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

Schema description coverage is 0% across 4 parameters, so the description must carry the burden. It only clarifies that 'organization' refers to a GMP organization; the 'account' filter, 'page_size', and 'page_token' are never mentioned, leaving pagination and filtering semantics undocumented anywhere.

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 ('List') and resource ('Analytics accounts linked to a GMP organization'), and the qualifier 'no GA4 performance data' separates it from metric-returning tools. It is clearly distinguishable in practice, though it never names a sibling or 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?

Usage is only implied: the 'no GA4 performance data' clause hints this is a discovery/linkage lookup rather than a reporting call. There is no explicit statement of when to choose this over alternatives such as the SA360 or report-oriented 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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds useful behavioral detail — that search matches on native name/ID with '*' wildcards — but says nothing about pagination behavior (page_size/page_token exist) or result limits.

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

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

A single compact sentence, front-loaded with the core action and resource. No filler, though it is arguably too terse given the parameter count.

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?

An output schema exists, so return values need no explanation, and annotations cover the safety profile. But with five undocumented parameters and pagination as a real concern for a list endpoint, the description is only marginally 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?

Schema description coverage is 0% across 5 parameters, so the description must carry the burden. It only explains 'search' (name/ID, '*' wildcards) and hints that profile_id identifies the user profile; account, page_size and page_token are left completely unaddressed.

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?

Clear specific verb + resource: 'List CM360 advertisers for a user profile'. The CM360 platform qualifier does distinguish it from the sibling list_dv360_advertisers. However, it doesn't explicitly say how it differs from list_cm360_campaigns or other listing siblings beyond the resource noun.

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/when-not guidance, no mention of alternatives, no prerequisites beyond the implicit 'for a user profile'. The agent must infer everything about selecting this over another listing tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so safety is covered. The description adds only the ambiguous sentence 'Omit archived for both active and archived campaigns,' which does not clearly state whether omitting the parameter includes or excludes archived campaigns.

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 short and front-loads the purpose in the first sentence. However, the second sentence is confusing and therefore does not fully earn its place, weakening the overall structure.

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

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

For a seven-parameter listing tool with 0% schema description coverage, the description is far too thin. The output schema handles return values, but the description still leaves parameter meaning and filtering behavior almost entirely unexplained.

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 tool has seven parameters, so the description must compensate. It explains none of them clearly: search, account, page_size, page_token, profile_id, and advertiser_id are completely unaddressed, and the archived parameter is only referenced ambiguously.

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 and resource: 'List CM360 campaigns.' That is clear enough to distinguish this tool from DV360 and SA360 siblings, but it does not explicitly name or compare against sibling tools such as list_dv360_campaigns or list_cm360_profiles.

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 alternatives, nor about prerequisites such as needing a profile_id. The second sentence addresses an archived-filtering behavior, not usage 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?

Beyond the annotations, it discloses pagination behavior, the one-page max of 1000, the need to preserve filters for nextPageToken, and the fact that results are metadata rather than image bytes or rendered HTML5. It also explains a subtle HTML5 backup asset detail.

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

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

The description is front-loaded and dense: purpose and scope first, then filtering and pagination rules, then important asset caveats. Every sentence carries useful information.

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

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

An output schema exists, so return values need not be fully explained, and the description adds useful return-shape caveats. However, with 11 parameters and no schema descriptions, a few parameters remain under-explained.

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 across 11 parameters, the description compensates well by explaining the main filters, wildcard search, active/archived omission, and pagination preservation. It still leaves profile_id, account, page_size, and page_token mechanics largely implicit.

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 ('List CM360 creatives') and names the key returned fields. It clearly distinguishes this list operation from the sibling get_cm360_creative.

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: filters for advertiser/campaign, IDs, types, and search, plus the rule to omit active/archived to include both states. It does not explicitly name get_cm360_creative as the alternative for fetching a single creative.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety and mutability profile is fully covered by structured data. The description adds the downstream purpose of the returned profileId, which is genuinely useful context, but says nothing about pagination, auth/scope requirements, or what 'accessible' means in practice.

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

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

Two short sentences with zero filler, front-loading what the tool returns before explaining why the caller should care. Nothing is padded or redundant.

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?

An output schema exists, so the description need not explain return values, and annotations cover the safety profile. What remains missing is any explanation of the lone `account` filter, which is undocumented in both the schema and the description — a real gap for an otherwise simple one-parameter 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 one parameter (`account`) with 0% schema description coverage, and the description never mentions it — an agent cannot tell whether it takes an account ID, a name, or a numeric key, or what happens when it is omitted (default null). This is the definition's most concrete gap, since the schema does not compensate either.

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 ('Discover accessible CM360 user profiles'), which is unambiguous and distinct from the many list_* siblings covering advertisers, campaigns, and reports. It does not explicitly name a sibling it differs from, but the resource noun alone is enough to separate it.

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?

'Choose profileId for subsequent CM360 tools' implies this is a prerequisite discovery step, which is useful routing context. However, it gives no explicit when-not guidance, no mention of alternatives (e.g. if a profileId is already known), and no indication of how the optional `account` argument changes the scope of discovery.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the useful clarification that it lists existing files and does not generate a new report, but it omits other behavioral context such as pagination behavior or permissions.

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 with no wasted words, and the key distinction—listing existing files and not generating a new report—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?

An output schema exists, so return values need not be explained. But the tool has five parameters with zero schema description coverage, and the description does not compensate for that gap. For a multi-parameter tool requiring profile_id and report_id, the definition is materially 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?

The tool has five parameters including two required ones, but schema description coverage is 0%. The description says nothing about profile_id, report_id, account, page_size, or page_token, so it provides no semantic meaning beyond the bare parameter 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: "List existing CM360 report files and their status." It clearly distinguishes this from generating a new report, though it does not explicitly name sibling tools like list_cm360_reports or get_cm360_report_file.

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 phrase "no new report is generated" implies this should be used for inspecting existing report files rather than creating reports. However, it gives no explicit guidance on when to use this tool versus list_cm360_reports or get_cm360_report_file, and no exclusions are stated.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds the valuable clarification that this returns definitions only and does not run reports, but says nothing about pagination behavior or what 'visible to this profile' means in terms of permissions.

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

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

Two short sentences, front-loaded with the core action and immediately followed by the key constraint. 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?

An output schema exists, so return values need no explanation. However, for a 5-parameter tool with 0% schema coverage and paginated listing semantics, the description omits how to page or how the scope/account filters interact with profile visibility.

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% across 5 parameters. The description hints at profile scoping via 'this profile' but never explains the scope enum (MINE vs ALL), the account filter, or how page_size/page_token drive pagination. With no schema documentation, this leaves most parameters opaque.

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?

Specific verb+resource: 'List saved CM360 report definitions'. The qualifier 'visible to this profile' adds scope, and 'definitions' implicitly separates it from list_cm360_report_files. It stops short of naming the sibling that handles generated files, 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?

'Does not execute reports' gives a useful negative boundary, but it names no alternative for actually running or retrieving report output (e.g., list_cm360_report_files). Usage is implied rather than routed.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description contributes one real behavioral fact — a 200 cap — plus a DV360 v4 API-version note, but leaves pagination behavior, the meaning of the cap (results vs page size), and filtering semantics undisclosed.

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

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

A single front-loaded sentence with the scope stated before the parenthetical caveat. Nothing is redundant, though the parenthetical packs two unrelated facts into one clause, which costs some readability.

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?

An output schema exists so return values need no explanation, but with 5 parameters at 0% schema coverage the description should carry the parameter burden and does not. An agent still cannot tell how to paginate or how to use filter/account without 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% across 5 parameters, so the description must compensate and largely does not. Only partner_id is explained (and its provenance, "discovered"); filter, account, page_size and page_token are never mentioned, and "max 200" is ambiguous about which parameter or behavior it constrains.

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

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

States a specific verb and resource ("List advertisers") and adds the scoping entity (partner ID), so an agent can distinguish it from get_dv360_advertiser and the cm360 advertiser listers. It stops short of explicitly naming those siblings, so differentiation is inferred rather than stated.

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

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

"for a discovered partner ID" implies the prerequisite call (list_dv360_partners) and thereby the correct position in the call chain, but it is a hint, not an instruction. No explicit when-not-use or alternative routing is given.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the description's job is lighter. It still adds real context: a 200-item cap and the requirement that the filter be identical across pages, which is exactly the kind of behavioral constraint that isn't in the annotations or 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?

Three short, front-loaded sentences with zero filler; the limit and the pagination caveat are surfaced before any elaboration. Nothing here repeats structured fields verbatim.

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

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

An output schema exists, so return values need no explanation, and the pagination semantics are covered. But for a five-parameter tool with zero schema coverage, the undefined roles of account, page_token, and the required advertiser_id leave the agent guessing about how to scope the call correctly.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, yet it only explains 'filter' (optional, native DV360 syntax, must be repeated for paging) and hints at the page_size ceiling of 200. The roles of account, page_token, and the required advertiser_id are entirely undocumented in both places.

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 ('List DV360 campaigns settings') and adds a scoping clarification ('These are not performance metrics') that separates it from performance-oriented siblings. It does not, however, distinguish itself from adjacent entity listings such as list_dv360_insertion_orders or list_dv360_line_items.

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 pagination instruction ('use the same filter when requesting the next page') is a genuine usage rule, but there is no guidance on when to call this instead of the sibling listing tools or what an appropriate advertiser_id/account context is. Usage is implied rather than advised.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the lower bar applies. The description still adds real behavioral context beyond them: the 200-item ceiling and the constraint that the filter must be held constant across pages. Auth requirements and what happens if the filter is changed mid-pagination are not covered.

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 scope and the cap, no filler. It is efficient, though the fragmentary last sentence reads like an afterthought rather than structured guidance.

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?

An output schema exists, so return values need no explanation, and the max-200 cap is surfaced. But for a paged, filtered listing with five undocumented parameters, the description leaves the agent guessing about page_size, page_token, and advertiser_id semantics.

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% across five parameters, so the description carries the full burden, yet it explains only 'filter' (native DV360 filter, reused across pages). advertiser_id (the sole required param), account, page_size (the parameter that governs the 200 cap), and page_token receive no explanation at all.

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

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

States a specific verb and resource (list DV360 creatives settings) plus a hard cap (max 200), and explicitly distinguishes the payload from performance metrics. It does not name how it differs from sibling listers like list_dv360_campaigns or list_cm360_creatives, 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?

The description gives pagination guidance ('use the same filter when requesting the next page'), which is genuinely actionable. However, it never states when to choose this over the sibling creatives/report tools, and no prerequisites or exclusions are given.

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

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

Annotations already declare read-only, idempotent and non-destructive behavior, so the description does not need to cover safety. It adds two pieces of real behavioral context the annotations cannot carry: a hard 200-item cap and the instruction to reuse the same native DV360 filter when fetching the next page. What it omits is whether the cap applies to the response or to page_size, and any auth/scope expectations.

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 clauses, front-loaded with the core action and result cap, with no filler. The trailing pagination note is slightly orphaned from its parameter but still 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?

An output schema exists, so return-value explanation is not required, and the pagination hint covers the trickiest calling pattern. The gaps are the undocumented account/advertiser_id distinction and the interaction between the 200 cap and page_size, which matter for a five-parameter paged listing tool.

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

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

Schema description coverage is 0% across five parameters, so the description must carry the full explanatory burden and it largely doesn't. It only clarifies the 'filter' parameter (a native DV360 filter, reused across pages) and gestures at paging, leaving account, page_size, page_token and advertiser_id undefined in both schema and prose.

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 and resource ('List DV360 insertion orders settings') and explicitly rules out performance metrics, which is a meaningful distinction among the DV360 siblings. It does not differentiate itself from adjacent list tools such as list_dv360_campaigns or list_dv360_line_items, 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?

The clause 'These are not performance metrics' is a genuine when-not-to-use signal and implicitly routes reporting needs to the report tools. However, there is no guidance on when to pick this over the other DV360 list tools, and no prerequisites are stated beyond the required advertiser_id.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior, so the bar is lower and the description adds real value on top: a 200-result cap, the warning that this returns settings rather than metrics, and the constraint that the filter must be reused across pages. The one gap is that it doesn't explain what page_token returns or how exhaustion is signalled, though the output schema likely covers 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?

Three short sentences, purpose front-loaded, caveats after. Efficient with no filler, though the fragment-style phrasing makes the filter/pagination note slightly cryptic.

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?

An output schema exists so return values need no explanation, and the description covers purpose, pagination, and the metric-vs-settings distinction. But with five parameters at 0% schema coverage and the required advertiser_id unexplained, an agent still lacks enough to invoke confidently without trial and error.

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

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

Schema description coverage is 0%, so the description carries the full burden, yet it only clarifies the 'filter' parameter (native DV360 syntax, reused across pages). The required advertiser_id and the account, page_size, and page_token parameters get no explanation at all, leaving half the invocation contract 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?

States a specific verb and resource ('List DV360 line items settings') and explicitly separates itself from performance-metric tooling, so the agent knows this is a configuration-listing operation, not a reporting one. It does not differentiate itself from the adjacent list_dv360_campaigns / insertion_orders / creatives siblings, so it stops short of a top score.

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 line 'These are not performance metrics' implicitly steers the agent toward the report tools for metrics, and 'use the same filter when requesting the next page' gives concrete pagination guidance. However, no alternative tool is named explicitly and no prerequisites (e.g., needing an advertiser_id from list_dv360_advertisers) are stated.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds one genuinely useful behavioral fact — a hard cap of 200 results per page — but says nothing about how pagination continuation works or what the account parameter scopes.

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

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

Two short sentences, front-loaded with the resource and the page cap; nothing is padded. The brevity borders on under-specification, but as a conciseness measure it is 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?

An output schema exists, so return-value explanation is rightly omitted, and annotations cover the safety profile. However, for a four-parameter tool with zero schema documentation, leaving `account` and `page_token` semantics entirely unstated means an agent must guess at scoping and pagination.

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% across 4 parameters, so the description must carry the load. It only partially does: it implies the `filter` parameter is a native DV360 expression and that results are capped at 200 per page, but `account` and `page_token` get no explanation and `page_size` isn't related to the 200 cap.

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?

"Discover DV360 partners" names a specific verb and resource, and the partner entity is distinguishable from the sibling list_dv360_advertisers/campaigns/etc. tools. It falls short of a 5 because 'Discover' is an unusual verb for what siblings call 'list' and no explicit sibling differentiation is offered.

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

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

There is no statement of when to use this tool versus the many other DV360 list tools, nor any prerequisite (e.g. that an advertiser or partner context may be required). 'Optional native DV360 filter' hints at input style but gives no exclusion or alternative routing.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered by structured data. The description adds two genuinely new facts: a 100-item cap and the Bid Manager v2 backend. It says nothing about pagination continuation or quota/rate behavior, which is the main remaining unknown for a paged list call.

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

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

Two short sentences, no filler, with the core action front-loaded before the exclusion. The 'No report creation' fragment is clipped enough to be slightly ambiguous, but nothing is wasted.

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

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

An output schema exists, so return values need not be explained, and the annotations cover safety. What remains missing is the one thing the agent cannot get elsewhere: what to pass for 'account' and how to page through results beyond the first 100.

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% across all three parameters, so the description carries the burden and largely fails it: the meaning and expected format of 'account' (partner ID? advertiser ID? name?) is never addressed. The '(max 100)' phrase loosely maps to page_size, but page_token and its continuation semantics are undocumented anywhere.

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

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

States a specific verb and resource ('List existing DV360 report definitions') plus the backing API (Bid Manager v2), which distinguishes it from write-path tools. However, it does not disambiguate itself from the close sibling list_dv360_reports or get_dv360_report, leaving the query-definition vs report distinction implicit.

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 report creation' excludes one adjacent behavior, which is useful negative guidance. But it names no alternative tool for creating reports or for retrieving actual report output, so the agent must infer the rest of the routing decision from sibling names 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?

The annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds useful behavioral context by clarifying that the tool lists existing runs and metadata/URLs but does not execute reports or fetch CSVs. It does not discuss pagination behavior or auth requirements, but the annotations carry much of that burden.

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 short and front-loaded: it states the purpose first, then the exclusion, then where to get the required query ID. Every sentence contributes useful routing or scoping information.

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

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

The tool has an output schema, so return values need not be explained, and the annotations cover safety and idempotency. However, with 0% schema description coverage, the description should say more about account, page_size, and page_token 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?

Schema description coverage is 0%, so the description must compensate for all four parameters. It only explains the source of query_id and says nothing about account, page_size, or page_token, leaving most parameter semantics 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 uses a specific verb and resource: list existing runs of a DV360 report query. It further clarifies the return scope by mentioning report metadata and URLs, and explicitly differentiates the tool from running reports or fetching report CSVs. This is enough for an agent to identify the tool's purpose without opening the schema.

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

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

It clearly states the prerequisite for query_id by directing the agent to list_dv360_report_queries, and it explicitly says what the tool does not do: run reports or fetch CSVs. However, it does not name the alternate tool for actually running or retrieving reports, so it lacks a fully explicit alternative routing.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral information — results come back as a single page capped at 1000 — which tells the agent to expect truncation and paging rather than a complete listing.

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

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

A single front-loaded sentence that states the resource, the scope, the pagination limit, and the disambiguation. Nothing is padded 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?

An output schema exists, so return values need not be explained, and the page cap is a valuable addition. Still, for a 0%-coverage schema the description does not say what 'account' scopes or how page_token is used, leaving real gaps for a paged list tool.

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

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

Schema description coverage is 0% and none of the three parameters are documented in the schema. The description's 'one page, max 1000' implicitly caps page_size, but the 'account' parameter and the page_token continuation mechanism are left entirely 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 names a specific verb and resource ('List accessible GMP organizations') and scopes it to accessible entities, which is more precise than a bare restatement. It also pre-empts a likely confusion by excluding Google Cloud organizations, though it does not differentiate from the sibling get_organization.

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

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

The word 'accessible' implies this is the entry point for enumerating orgs you can see, and the Google Cloud exclusion usefully rules out a false match. However, there is no explicit guidance on when to call this versus get_organization or list_analytics_account_links, and no prerequisites are stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered structurally. The description adds nothing beyond that — no mention of pagination, remote-fetch latency implied by openWorldHint, or whether the result is scoped to one customer 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?

A single short sentence with the resource front-loaded and zero filler. It is efficient, though the terseness contributes to the specification gaps noted elsewhere rather than resolving them.

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?

An output schema exists, so return values need not be explained, but for a three-parameter tool with ambiguous identity parameters and distant siblings, the description leaves the agent without enough to call it confidently. It should minimally clarify the customer_id/login_customer_id roles and the scope of the listing.

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 all three parameters (account, customer_id, login_customer_id) are undocumented. The description doesn't explain the distinction between customer_id and login_customer_id (a non-obvious SA360/Google Ads manager-account concept) or what 'account' selects, so it fails to compensate for the schema 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 names a specific verb and resource ('List custom columns') scoped to an SA360 customer, which is clear enough to understand the operation. It does not distinguish itself from nearby siblings such as search_sa360_fields or query_sa360, which could also plausibly surface column metadata.

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

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

There is no statement of when to use this tool versus search_sa360_fields or query_sa360, nor any prerequisite or exclusion. The agent must infer the selection context entirely.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavior: the result set is partial and omits children reachable only via a manager, which prevents wrong assumptions about completeness.

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, no filler, with the scope constraint front-loaded and the alternative routing placed second. Every clause carries information.

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

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

An output schema and rich annotations mean return format and safety need no explanation, and the partiality caveat is covered. However, the meaning of the 'account' parameter is left entirely unexplained, which is a real gap for a tool whose only input is undocumented.

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 optional 'account' parameter has 0% schema description coverage and the description never explains what it does — whether it scopes the listing, acts as a manager filter, or is a resource name. The description does not compensate for the documentation 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 states a specific verb and resource ('List ... SA360 customer resource names') and immediately narrows the scope to 'directly accessible', which distinguishes it from the hierarchy-walking sibling. An agent can tell what this returns without opening the schema.

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

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

It names the alternative explicitly ('Use get_sa360_customer_clients on a manager to discover child accounts') and states the condition that selects it, plus a warning that this list is not exhaustive. Only the absence of an explicit 'use this tool when...' framing keeps it from a 5.

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

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

Annotations already declare read-only, idempotent, open-world, and non-destructive behavior, so the description's extra value is in disclosing the one-page limit, Google-side field validation, and pagination continuation requirements. It does not cover error modes or rate limits, but it adds useful operational context beyond the annotations.

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

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

The description is front-loaded with the core operation and then adds only high-value operational notes. Each sentence contributes distinct guidance, with no redundant restatement of the name or schema.

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

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

For a SQL-like SA360 query tool, the description covers the essentials: read-only SELECT semantics, one-page behavior, manager scoping, field validation, field discovery, and pagination. It is mostly complete, but the lack of explanation for the account parameter and query syntax details keeps it short of fully self-contained.

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 carry parameter meaning, and it partially does: it explains bare numeric customer_id format, login_customer_id manager selection, and argument preservation for page_token. However, it leaves the account parameter unexplained and does not clarify page_size behavior beyond the page maximum, so several parameter semantics remain ambiguous.

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: run a read-only Search Ads 360 SELECT query and return one page. The purpose is clear, and it names search_sa360_fields as the field-discovery sibling, but it does not distinguish this flexible query tool from siblings like get_sa360_campaign_performance or list_sa360_customers.

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

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

Gives practical usage guidance: use bare numeric customer IDs, use login_customer_id for manager access, and preserve arguments when following nextPageToken. It also points agents to search_sa360_fields for discovering fields, though it does not explicitly say when to prefer this tool over prebuilt SA360 retrieval tools.

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

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

Annotations already establish read-only, idempotent, non-destructive, open-world behavior. The description adds useful behavioral context by clarifying the special SELECT-without-FROM query form, but it does not cover account scoping, pagination behavior, or result format.

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 short sentences with no filler. The core purpose is front-loaded, and the example directly illustrates the expected query syntax.

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 output schema exists, so return values need not be explained, and annotations cover safety. However, for a tool with four parameters and zero schema descriptions, the missing explanation of account and pagination parameters leaves the definition incomplete for reliable invocation.

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

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

Schema description coverage is 0%, so the description must compensate for all four parameters. It partially explains the query format through an example, but says nothing about account, page_size, or page_token, leaving three 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 clearly states that the tool discovers SA360 query fields and compatibility, and specifies the metadata-SELECT-without-FROM mechanism. This distinguishes it from data-query tools like query_sa360, though it does not name that sibling explicitly.

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

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

The metadata SELECT and example imply when the tool is appropriate for field discovery, but there is no explicit guidance about when to use this instead of query_sa360 or when not to use it.

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