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

No annotations are provided, so the description must carry the behavioral disclosure burden. It does disclose that the tool returns organic results as JSON and that it works 'without getting blocked,' which adds useful context. However, it omits details such as authentication requirements, rate limits, failure modes, or whether non-organic results (ads) are included.

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 concise sentences, front-loaded with the primary action and output format. The second sentence adds relevant use-case context without unnecessary elaboration, so every word earns its place.

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

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

For a low-complexity search tool with a fully documented schema, the description covers the core purpose, output type, and primary use cases. The lack of an output schema means return-field details are not specified, but the phrase 'structured organic results as JSON' provides adequate context given the tool's simplicity.

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 input schema provides complete descriptions for all four parameters (100% coverage), so the baseline is 3. The tool description does not add parameter-level guidance beyond what the schema already supplies, but this is acceptable given the rich schema.

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 action ('Run a Google search') and resource ('through UnblockingAPI'), and clarifies the output as structured organic results in JSON. It also distinguishes itself from sibling tools by emphasizing unblocked access and the SERP use case.

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

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

The description provides clear use cases ('SERP data, research, and competitive analysis') and highlights the benefit of avoiding blocks. It does not explicitly contrast with sibling tools or state when not to use it, but the context is sufficient for an agent to make a reasonable 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?

With no annotations, the description must carry the burden. It discloses the output format (JSON) and the key input requirement, but it does not mention failure modes, rate limits, scraping behavior, or what happens with invalid/private listings. This is acceptable but not rich.

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 one dense sentence that front-loads the purpose and output, lists example fields, and ends with the invocation instruction. There is no filler or repetition beyond the small overlap with the 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 single-parameter tool with no output schema, the description provides enough context by enumerating the extracted fields and stating the output is JSON. It doesn't cover error or edge cases, but the tool is simple and the key usage details are present.

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

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

The schema already fully describes the single `url` parameter with format, example, and 'Full idealista.com listing URL' context. The description's 'Pass the full listing URL' reinforces this but adds no new semantic detail beyond the schema, so it lands at the baseline for high schema coverage.

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

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

The description uses the specific verb 'Extract structured data' and clearly identifies the resource (idealista.com property listing) plus the output format (JSON). The enumerated fields (price, size, rooms, bathrooms, etc.) give concrete scope that distinguishes it from the sibling tools like google_search or unblock_fetch.

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 instruction 'Pass the full listing URL' makes the primary usage context clear: use this when you already have a specific idealista listing URL and want structured data rather than search results or raw fetch output. It doesn't explicitly name alternatives or exclusions, but the context is straightforward.

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

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

With no annotations provided, the description must carry the behavioral transparency burden. It discloses the proxy rotation, bypassing, and render behavior, which is valuable. However, it does not mention potential API key requirements, rate limits, latency, or that some target sites may still block the request. This is moderate transparency, not comprehensive.

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

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

Two sentences, both valuable. The first states the core functionality and output; the second provides key guidance on when to use render mode. No wasted words or repetition of schema details.

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

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

The description is adequate but not thorough for a tool with 8 parameters and no output schema. It explains the high-level function and render toggle but omits operational context like API authentication, response size limits, or error behavior. The detailed schema compensates for parameter semantics, but the description leaves gaps for an agent on when this tool is worth invoking versus alternatives (like direct HTTP fetching).

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 input schema covers 100% of parameters with detailed descriptions, so the baseline is 3. The description adds a minor usage hint about render=true for SPAs/dynamic content, which aligns with the schema but doesn't add new semantics beyond it. The schema already explains wait, block_assets defaults, and other quirks.

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

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

The description clearly states the primary action ('Fetch a URL'), the resource (through UnblockingAPI), and the specific value added (bypassing bot detection, CAPTCHAs, geo-blocks with rotating proxies). It also distinguishes itself from sibling tools like google_search and idealista_property, which are domain-specific rather than generic fetching.

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

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

The description implies when to use the tool: fetching URLs that need bypassing or geo-relocation. It also gives a clear conditional for the render parameter ('for JavaScript-heavy sites'). However, it does not explicitly address when not to use it or mention alternative tools, but context is clear enough.

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