addPolyline

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

Annotations only provide readOnlyHint=false and destructiveHint=false, which are minimal. The description adds value by specifying the return schema ({ success, data: { entityId }, message? }) and instructs to keep entityId for removeEntity, disclosing that the tool creates a persistent entity that can later be removed. It does not mention side effects like persistence across sessions or overlay behavior, but it goes beyond the annotations.

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 only two sentences and front-loaded with the primary purpose. It avoids redundancy, condenses the return format and a key usage hint into the second sentence, and contains zero filler words.

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 six parameters (one required), a rich input schema, and an output schema implicitly defined in the description, the tool is fully specified. The description explains the return value and points to removal, covering the necessary context for an agent to use the tool correctly without requiring additional details about return values or behavior.

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 description coverage is 100%, with each parameter (coordinates, color, width, label, sessionId, clampToGround) having its own detailed description. The tool description adds minimal parameter information beyond what the schema already provides, so it meets the baseline of 3 without compensating for any gaps.

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 the tool draws a path or route from geographic coordinate tuples, using a specific verb ('draw') and resource ('path or route'), and it distinctly differs from siblings like addPolygon, addMarker, and addLabel. It also clarifies the return structure and entityId purpose.

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 does not explicitly state when to use this tool versus alternatives like addPolygon or addGeoJsonPrimitive. The mention of 'path or route' implies use for line-based geometry, but no exclusions or alternative guidance is given. The return note about keeping entityId for removeEntity is a usage hint but not a direct guideline.

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