google_serp_serp: GET /

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

With no annotations, the description carries the full burden of behavioral disclosure. It clearly states what the tool returns (organic results, ads, knowledge graph, related searches, People Also Ask, local pack, featured snippets, AI Overview pageToken) and examples of query patterns. It does not mention rate limits, error handling, or side effects, but for a read-only search scraper it is sufficiently transparent about its 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?

The description is long but dense, front-loaded with the core purpose and then expanding into features and use cases. It uses a single flowing paragraph without bullet points, but each clause adds information. It is not excessively verbose and every sentence earns its place, though a more structured layout would improve scannability.

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

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

For a tool with 19 parameters and no output schema, the description covers a lot: use cases, return types, and example queries. It does not explicitly address edge cases, error responses, or limitations, and it does not differentiate clearly from sibling tools, but the core functionality is well documented and the schema fills in parameter details.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by grouping parameters (location/uule, country, language, domain, device type, safesearch, time/date filters, tbm verticals) and illustrating with real-world queries like 'Roman Milyushkevich LinkedIn' and 'HasData CEO'. This adds semantic value that helps an agent map parameters to use cases.

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

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

The description opens with a clear verb-resource pair ('Get Google Search Results') and then enumerates a vast feature set that distinguishes it from siblings. Phrases like 'Full-featured Google Search scraper' and the list of supported filters and result types (organic, ads, knowledge graph, People Also Ask, AI Overview) make it immediately obvious this is the comprehensive SERP tool compared to niche siblings such as serp_light.

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 provides explicit use cases: SEO rank tracking, keyword research, SERP-feature monitoring, competitor analysis, grounding LLMs, and especially person/company data enrichment with concrete examples. However, it never contrasts itself with the sibling serp_light or states when to choose this over other SERP tools, so it lacks explicit when-not guidance and alternatives.

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