gcfr_execution_log

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 a critical data-population condition (debug level 2+), a field exclusion (Sql_Text CLOB), and default date behavior. This is strong disclosure, though it does not explicitly state read-only behavior or potential output volume.

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 brief and front-loaded, with the main purpose in the first sentence and each subsequent sentence adding a distinct useful constraint or default. There is no filler, repetition, or schema duplication.

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?

Given the tool's moderate complexity, the description covers purpose, usage conditions, key behavioral caveats, defaults, and optional filters. An output schema exists, so return values do not need to be described. Missing details like date format and exact filter behavior are minor and can be inferred from parameter names.

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 0%, so the description must compensate. It explains date defaults and that process_name and stream_key are optional filters, adding meaning beyond the bare property names. However, it does not specify date formats or filtering semantics such as exact match versus wildcard, leaving some 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 opens with a specific verb and resource: 'Show step-level execution trace for detailed process debugging.' This immediately distinguishes the tool from sibling status/history/report tools by emphasizing granular execution-level detail. No ambiguity remains about what the tool produces.

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 gives clear conditions for when the tool is useful: 'detailed process debugging' and only when GCFR runs at debug level 2 or higher. It does not explicitly name sibling alternatives or say when not to use it, but the stated prerequisites and purpose provide adequate usage guidance.

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