screen_site

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the return format (pass/warn/fail with layers_available/layers_unavailable) and notes the lack of API key requirement. It does not mention rate limits, error behavior, or side effects, but for a read-only screening tool this is reasonably transparent.

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 exceptionally concise: two sentences that front-load the purpose, itemize the scope, and state the output. Every word earns its place with no filler 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?

Given the tool's moderate complexity and lack of output schema, the description covers the essential points: what it does, where it applies, what layers are used, and what it returns. It doesn't explain how verdicts are computed, but that is not required for selection and invocation. Minor gaps like exact EU country support are handled in the schema.

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 already provides 100% coverage for all four parameters, giving a baseline of 3. The description adds meaning by explaining how the 'country' parameter influences the analysis (GB-specific layers vs EU-specific layers including Natura 2000 and CORINE), which goes beyond the schema's generic ISO code note.

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 specific verb ('Composite PV/BESS site screening') and clearly defines the resource and scope: GB and EU locations. It enumerates the factors included (terrain, grid, solar, land constraints, etc.), which distinguishes it from sibling tools that focus on individual layers or data sources.

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 establishes clear context: this is a composite screening tool for PV/BESS across GB and EU, returning a verdict. It implicitly signals when to use it (for an integrated multi-criteria assessment) but does not explicitly state when to prefer alternative sibling tools or provide exclusions. The 'No API key' note adds practical usage guidance.

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