bing_portal_tools

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds the crucial behavioral fact beyond annotations: this returns only URLs and cannot actually execute a scan, setting correct expectations about what the agent will receive. It could go further on the exact return shape, but the key limitation is disclosed.

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 tight sentence with the resource front-loaded and the API caveat following. Nothing extraneous; the semicolon-joined clause is slightly telegraphic but earns its place by explaining the tool's existence.

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 one enum parameter, no output schema, and full annotation coverage, the description supplies nearly everything needed: what it returns (official links), why it exists (no API), and which two destinations are available. Only the concrete response shape (single URL vs. list) is left unstated.

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 carries the burden for the single 'tool' parameter. It names the two options ('Robots.txt Tester' and 'Site Scan'), which maps usable concepts onto the enum values robots_tester and site_scan — adequate compensation, but no detail on what each option yields or how the two differ in output.

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 resource — official links to Bing's Robots.txt Tester and Site Scan — rather than a data operation. The clause 'no tienen API pública' implicitly separates it from all the API-backed bing_* siblings that return metrics, so an agent can tell this is a link-provider, not a data-fetcher.

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 implied rather than stated: because no public API exists, this tool is the fallback when a user wants the robots tester or site scan. It never explicitly says when to choose it over a sibling like bing_crawl_issues or bing_sitemaps, nor does it say these links must be opened by the human user.

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