list_feature_classes

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

With no annotations, the description carries the behavioral burden. It adds meaningful behavior: using the current workspace when the workspace argument is empty, applying a wildcard pattern, and filtering by feature_type. It does not explicitly say 'read-only' or describe failure behavior, but listing is inherently non-mutating and the key scoping behaviors are 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?

The description is compact: a one-sentence purpose statement followed by brief parameter clarifications. Every line adds value, especially given the sparse schema. It is front-loaded with the core purpose and uses a clean Args structure.

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?

An output schema exists, so return-value documentation is unnecessary. The description covers workspace types, defaults, and filtering, which is sufficient for a straightforward listing tool. Minor gaps like error behavior when no current workspace is set are not addressed, but these are low-stakes for a read-only listing operation.

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%, but the description compensates fully. It explains all three parameters: workspace path and its empty-string default behavior, pattern with a concrete wildcard example ('road*'), and feature_type with geometry examples. This is exactly the semantic layer the schema lacks.

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 exact operation: 'List feature classes in a workspace (folder, GDB, or feature dataset).' This clearly distinguishes it from sibling tools like list_tables, list_rasters, and list_layers by naming the specific resource type being listed.

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 context is clear: this tool operates on feature classes within a workspace, and the description explicitly enumerates valid workspace kinds. It does not explicitly mention alternatives or when not to use it, but the resource-type distinction from siblings makes the usage context reasonably evident.

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