output_get_fields

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

With no annotations, the description carries the full behavioral burden. It discloses the object-type restriction, which is useful, and 'Get' implies a read-only operation. However, it does not describe what happens with an invalid path, the return format, or whether missing/wrong-type objects produce errors.

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 two short sentences with no filler. The action is front-loaded and the critical exclusions are stated immediately. Every word contributes.

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 one-parameter getter, the core purpose and scope are adequately explained, but the missing parameter semantics and lack of return/error details leave meaningful gaps. Without an output schema or annotations, the description should be more explicit about how to identify the Output object and what 'field names' means operationally.

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 schema has 0% description coverage, so the description must compensate for the single output_path parameter, but it never explains the path format, expected object naming, or how the path relates to sibling path tools. The parameter name is self-explanatory enough to avoid a score of 1, but the description adds no real semantic value.

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 action and resource: 'Get all configurable field names for an Output.' It also distinguishes the target from Plot objects, and the plural 'fields' differentiates it from the singular output_get_field sibling. This is clear and unambiguous.

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 clearly scopes usage to Output objects and explicitly excludes Plot objects. It does not name an alternative tool like input_get_fields or output_get_field, but the object-type exclusion gives the agent enough context to avoid the most likely misuse.

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