Boundary from Entities

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

Beyond the destructiveHint=false annotation, the description discloses that handles may arrive in any order, that chain ordering is handled internally, and that non-closing chains are refused with an error naming the gap coordinates. It does not explicitly state whether original entities are modified or a new polyline is created, but the annotation reduces that risk.

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?

Three short sentences carry substantial, non-redundant information. The primary purpose is front-loaded, and every sentence earns its place without filler or repetition of 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 two-parameter tool with a full output schema and a safety annotation, the description covers the essential semantics: input, ordering, closure requirement, and failure behavior. A minor gap is the lack of explicit guidance on where the resulting polyline is created or how it relates to the original entities, but this is not critical 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?

Schema coverage is 100%, so the schema already documents both parameters. The description adds meaningful semantic detail by clarifying that handles are order-independent and by tying the close requirement to the tolerance/rejection behavior, which enriches the agent's understanding beyond raw schema properties.

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 and outcome: 'Chain the given entities into one closed polyline.' It also clarifies the tool's unique responsibility—handling arbitrary handle order—which distinguishes it from merely exporting or tracing boundaries.

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: when you have unordered entity handles that need to be chained into a closed boundary. It does not explicitly name alternatives or exclusion conditions, such as when boundary_trace would be preferable, so it falls short of full guidance.

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