find_features

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

No annotations are supplied, so the description carries the behavioral burden by itself. It discloses the return shape and the result_id handoff to render_map, but the server-side geometry retention is already stated in the geometry parameter schema, and it says nothing about result_id lifetime, the server-side row cap magnitude, or error behavior on an invalid column name — meaningful gaps for a no-annotation tool.

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 tight sentences with the exclusion and the return contract front-loaded, followed by the prerequisite action. No filler, no restatement of the tool name.

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 no output schema, the description usefully compensates by naming the return format and the result_id token consumed by render_map, and it flags the prerequisite for valid column identifiers. Missing only secondary operational details such as what an invalid column or over-cap limit produces.

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 71% and the schema already documents filter operators, geometry modes, limit defaults, and ordering in detail. The description contributes only the advice to resolve column names via describe_layer; it adds no meaning for order_by, descending, or the AND-combination semantics of filters beyond what the nested schema states.

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 specific verb and resource ('Find features') and immediately scopes it ('by attribute filters (no spatial predicate)'), which cleanly separates it from spatial siblings like spatial_filter, within_distance, and bbox_of. It also names the output ('GeoJSON + result_id for render_map'), so an agent knows both what it does and where the result goes.

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 parenthetical 'no spatial predicate' is an effective when-not-to-use signal pointing the agent toward the spatial siblings, and 'Use describe_layer first to learn column names and values' is an explicit prerequisite step. It stops short of naming the specific alternative tool by name, so routing still requires a small inference.

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