Fenlight

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

Goes well beyond the readOnlyHint/openWorldHint annotations with cost mechanics (worst case held first, only calls made charged, failed calls free, per-call pricing in credits), the keyless-assistant fallback to not_configured, and the fact that metrics rather than raw answers are returned. These are real operational traits an agent could not infer from the structured fields.

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-loads what the tool does before the engine/samples/cost caveats, and every sentence carries information (engine routing, sampling semantics, cost and failure behavior). It is dense and long, but not padded or repetitive.

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

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

With 8 parameters, no output schema, and a non-trivial billing model, the description is nearly complete: it describes the returned metrics (mention, rank, citations, domains) and the billing edge cases. It omits return-shape specifics such as metric field names or pagination/limits per engine, which is a minor gap given no output schema exists.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds meaning: it explains that `samples` exists to produce a mention rate and that `engine` accepts only the three named non-default assistants, and it frames `brand`/`competitors`/`brand_domain` as the tracked entities. Parameter usage gains real context over the schema text.

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

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

Names a specific verb (ask a buyer's question to an AI assistant searching the live web) and a specific resource/output (brand + competitor mentions, rank, citations, cited domains). This is clearly distinct from the SERP/extraction siblings (google_serp, keyword_ideas, extract_local_places), so an agent can route without opening a 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?

Gives concrete operating conditions: the assistant defaults to ChatGPT unless `engine` names claude/perplexity/gemini, and `samples` (1-5, default 1) is for computing a mention rate. It also explains the failure/cost path (not_configured answers cost nothing). It stops short of naming an explicit alternative sibling or stating 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.

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety/scope profile is covered. The description usefully discloses the output taxonomy (owned properties, entity profiles, Maps locations, mentions, PAA), which adds context beyond the annotations, but says nothing about rate limits, cost, or fetch behavior.

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

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

Two tight sentences, front-loaded with the audit purpose and followed by the result breakdown. No filler, though the second sentence is a bare list that could have carried parameter or usage guidance instead.

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 7-parameter, output-schema-less tool, the description covers the return categories but leaves every non-required parameter undocumented, including non-obvious defaults and locale controls. An agent can call it with just 'company' but cannot use the tool well.

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 7 parameters, so the description carries the full burden and fails it. It never explains gl/hl, depth, fresh, domain, or the surprising defaults (gl='ae', location='Dubai'), leaving the agent to guess at locale and scope semantics.

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

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

The description uses a specific verb ('Audit') plus well-defined resources (SERP footprint, brand reputation, owned domains, entity profiles) and enumerates the result categories. This distinguishes it reasonably well from generic siblings like google_serp, though it never names the alternatives 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 what the tool returns but gives no when-to-use context, no prerequisites, and no indication of when to prefer it over google_serp, ai_answers, or geo_citation_radar. The agent must infer the choice 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 and openWorldHint=true, so the safety profile is covered by structured data rather than the description. The description adds useful scope context (Local Pack 3-pack vs. full Places listings) and enumerates returned entities, but discloses nothing about rate limits, caching/freshness behavior, or auth requirements.

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

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

Two tight sentences with the purpose front-loaded and zero filler. The second sentence is a return-field enumeration, which is defensible given there is no output schema, though it is a list rather than high-value prose.

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, listing returned fields (place_id/cid, rating, review count, etc.) is a genuine contribution and roughly compensates on the output side. However, four of five input parameters remain undocumented anywhere, and there is no guidance on geo/language or freshness, so the definition is not complete enough for confident 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% across 5 parameters, and the description adds no meaning for any of them: gl, hl, fresh, and location are entirely unexplained, and even query is only loosely implied by "local queries." For a tool where gl/hl control geo-language targeting and fresh controls cache behavior, this leaves real invocation ambiguity.

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

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

States a specific verb ("Extract") and resource ("Google Local Pack (3-pack) and Google Places listings") scoped to local queries, which is clearly distinct from siblings like extract_shopping_results or keyword_ideas. It does not explicitly name or differentiate against siblings such as google_serp, so it falls short of a 5.

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

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

The description says the tool is for "local queries" but gives no when-to-use/when-not-to-use guidance, no prerequisites, and never references the obvious alternative (google_serp) for non-local SERP data. An agent must infer routing entirely from the resource name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile (non-mutating, live web retrieval) is covered structurally. The description adds a useful return-field inventory, which is meaningful given no output schema, but says nothing about rate limits, pagination, or failure behavior.

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

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

Two sentences with no filler, and the purpose is front-loaded ahead of the return inventory. Efficient, though the second sentence is a flat field dump 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?

With no output schema, the return-field list does useful work in describing what comes back. But for a 5-parameter tool with 0% schema coverage, the total omission of parameter meaning leaves the definition incomplete for correct invocation.

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

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

Five parameters with 0% schema description coverage and zero enum constraints, yet the description never mentions gl, hl, fresh, or location. The geolocation, language, and freshness controls are entirely undocumented in both schema and prose, a real gap for a tool whose results are locale-dependent.

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: 'Extract Google Shopping carousel listings' clearly states what is retrieved and scopes it to 'e-commerce and product queries'. It is distinguishable from siblings like google_serp or extract_local_places by the Shopping carousel framing, though it never names or contrasts those siblings.

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

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

'For e-commerce and product queries' implies the domain in which this tool applies, giving usable context. However, it offers no explicit when-not guidance or alternatives (e.g., use google_serp for organic results, extract_local_places for local listings), leaving routing 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?

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds non-obvious behavioral context: results are constrained to organic positions 1-100 and filtered to forum/community domains, which tells the agent what kind of result set it will get. It omits rate limits, result count, and how the filtering is applied, keeping it below a 5.

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

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

Two sentences, front-loaded with the mechanism (search + filter) before the use cases, with no filler. The second sentence drifts slightly into soft marketing framing ('customer problem discovery') rather than adding operational detail.

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

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

With no output schema and six undocumented parameters, the description explains the tool's purpose but not enough for an agent to configure a call correctly (locale, depth, freshness behavior). It is adequate for understanding what comes back but incomplete for parameterized 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% across six parameters (gl, hl, depth, fresh, query, location), so the description carries the full burden. It only loosely gestures at position range, which may relate to 'depth', and says nothing about gl/hl locale codes or location. The parameter gap is largely 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?

States a concrete verb+resource ('Search Google and filter organic results ... for community discussions and forum threads') and enumerates the target sources (Reddit, Quora, HackerNews, StackExchange, niche forums). This is clearly differentiated from siblings like google_serp or ai_answers without opening either 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?

Gives explicit use cases ('ideal for sentiment analysis, user discussions, and customer problem discovery'), which is clear context for when to reach for this tool. It does not, however, name an alternative tool or state when not to use it (e.g., vs. plain google_serp or ai_answers), so it falls short of full routing guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safe, web-touching nature is covered. The description adds that the tool aggregates multiple external sources and emits a computed score plus a markdown brief, but says nothing about runtime cost, whether results are cached, or how the 'fresh' flag changes behavior.

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

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

It is a single comma-spliced sentence with five output clauses; each clause carries information, but the lack of structure makes it hard to scan and there is no lead statement of the primary outcome (citation probability) ahead of the tail outputs.

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

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

With no output schema, the description usefully sketches the return payload, which partially offsets the missing schema docs. However, for a 9-parameter, multi-source analysis tool it omits parameter meaning, defaults, and any latency or scope caveats, so an agent still lacks what it needs to invoke it precisely.

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 9 parameters, so the description carries the whole burden and it only mentions two of them ('query' and 'brand'), leaving gl, hl, depth, fresh, domain, engine, and location entirely unexplained. It also implies brand is part of the call when the schema shows brand is optional with a null default.

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 GEO Citation & Injection Radar') and enumerates five concrete outputs (citation probability score, Reddit/Quora threads, listicle PR targets, AEO question gaps, injection brief), which distinguishes it from siblings like google_serp and ai_answers. It never names a sibling explicitly, so differentiation is inferred rather than stated.

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

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

The description says what it does 'for a topic query and brand' but gives no when-to-use condition, no prerequisites, and no routing guidance versus the seven sibling tools. An agent cannot tell from this text when to pick the radar over ai_answers or find_discussion_candidates.

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 this a read-only, open-world call, so safety is covered. The description adds real behavioral context beyond that: the 10-100 depth range, the fact that local pack and shopping are opt-in add-ons rather than defaults, and a cache-vs-live tradeoff where fresh=true costs more. It stops short of stating rate limits, latency, or failure modes.

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 sentences, front-loaded with the core action and scope, then the add-on flags, then the cache tradeoff. Dense but each sentence carries distinct information; only the classification-tagging enumeration is arguably decorative.

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

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

With no output schema, the description correctly spends words on return composition (organic results plus page features like AI Overview, PAA, Knowledge Graph), which is exactly what an agent needs. The gap is the undocumented gl/hl/location parameters and the absence of routing against siblings that fetch local or shopping data directly.

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

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

Schema description coverage is 0%, so the schema contributes only titles and defaults; the description must carry the load. It explains query, depth, fresh, local_pack and shopping semantics well but says nothing about gl, hl, or location, leaving three geo/locale parameters with no meaning assigned 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 states a specific verb+resource ('Execute a full Google SERP search query') and a concrete scope constraint (depth 10 to 100). It also enumerates what comes back (organic results, classification tags, page features), so an agent knows exactly what this tool produces. It does not, however, name or differentiate itself from close siblings like ai_answers, extract_local_places, or extract_shopping_results, which cover overlapping surface area.

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 per-flag usage guidance (set local_pack and/or shopping to include those blocks; set fresh to true to search live instead of using the 24-hour cache), which is genuinely actionable. What is missing is tool-level routing: nothing says when to choose google_serp over ai_answers or extract_local_places, so the agent must infer that from the siblings' own descriptions.

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

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

With annotations covering only safety (readOnlyHint, openWorldHint), the description adds substantial operational detail: per-call credit costs for the results page (3 live / 1 cached), 3 credits per autocomplete call returning suggestions, computed worst-case totals per expand mode, early termination once limit is reached, and that autocomplete is always live. It also caps expectations explicitly with 'Ideas only: no search volumes.' This is far beyond what the annotations convey.

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?

Purpose and output contents are front-loaded in the first two sentences, and the cost sentence, while long, is information-dense and decision-relevant rather than filler. The dense credit enumeration reads as one run-on but each figure maps to a distinct expand mode, so little 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?

For an 8-parameter tool with no output schema and no schema-level descriptions, the description covers the essentials: what is returned (ideas with sources and intent labels), safety profile via annotations, cost model, caching, and the expand vocabulary. It falls short on the geo/language parameters (gl, hl, location, location_code) and on return-shape specifics beyond the per-idea fields.

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 load, and it does document several parameters: expand's permitted values (none/questions/alphabet/all), fresh's meaning, limit's early-stop role, and Arabic seed support. But gl, hl, location, and location_code are left completely undocumented in both schema and description, so half the parameters remain 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?

The description names a specific verb+resource ('keyword ideas for a seed keyword') and enumerates the sources (Google autocomplete, People Also Ask, related searches) plus the enrichment applied (cleaned, de-duplicated, intent labels). It clearly separates this from SERP-scraping siblings by producing ideas rather than results. What it lacks is an explicit contrast with the other keyword-adjacent sibling tools, so it stops short of a 5.

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

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

It gives real decision context: expand modes with their credit ceilings let an agent trade breadth against cost, default is stated ('questions'), and the fresh flag's live-vs-cache behavior is explained. It does not, however, say when to prefer this tool over google_serp or ai_answers, so no explicit exclusions or alternative routing.

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