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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so 'Kein Schreibaufruf' largely restates them. The genuinely additive details are that data is sourced from an existing keyword retrieval rather than a fresh fetch, and that extended conversion signals are returned as field names only without plaintext values — a meaningful data-exposure caveat. It says nothing about result volume, limits, or behaviour when the referenced keyword retrieval is missing.

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-loading the verb is good, but the first sentence is a nine-item field dump that reads as a list rather than a purpose statement. The two trailing sentences are short and each adds a distinct constraint, so nothing is pure filler, though the density of nouns makes it slower to parse than a shorter 'read X for Y' framing would be.

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

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

With no output schema, enumerating the returned field groups is the right use of the description and it does so thoroughly, including the plaintext-free conversion signals. However, for a three-parameter tool the description never explains its inputs or how they scope the read, leaving the agent to rely entirely on the bare schema before calling.

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 three parameters, so the description must carry the full burden, and it does not: offerKey (required, 1-200 chars), the channel enum (google_ads/microsoft_ads) and surfaceKey are never mentioned. The phrase 'je Suchbegriff' hints that results are per-keyword but gives no clue how offerKey, channel or surfaceKey shape the query or what happens when channel is omitted.

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 concrete verb ('Liest') and enumerates the exact field groups returned per keyword (channel, connection, readiness, evidence, budget, spend guard, landing-page protection, location performance, quality factor). The closing sentence 'Kein Schreibaufruf' signals it is the read counterpart to the sibling apply_/prepare_search_ads_campaign_control tools, though it never names them 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: 'aus dem bestehenden Keyword-Abruf' suggests it operates on already-retrieved keyword data, and 'Kein Schreibaufruf' indirectly tells the agent not to use it for mutations. There is no explicit when-to-use statement and no named alternative, so the agent must infer the read-vs-apply split 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.