List execution processes

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses important behavioral details: the API returns only failure facts and times, not error messages; with script_id it scopes to one script, without it the scope is all executions by the authorizing user; and it requires the script.processes scope. This is exactly the kind of context that helps an agent anticipate results and avoid misuse.

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 dense but every sentence serves a purpose: it states the resource, enumerates return fields, explains scoping behavior, gives error-hunting guidance, covers time/pagination, and notes auth scope. Information is front-loaded and logically organized.

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 listing tool with no output schema, the description is notably complete: it specifies return fields, scoping rules, filtering semantics, pagination, failure behavior, and required OAuth scope. An agent has enough context to call this tool correctly and interpret its results.

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 already 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema: it explains the script_id omission behavior, that start_time/end_time bound process start time, that page_token paginates, and how statuses relate to error hunting. This is a real value-add over the schema alone.

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 verb and resource: 'Lists execution processes (the execution history)', and enumerates the exact fields returned. This clearly distinguishes it from sibling tools like list_versions, which list versions rather than execution history.

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 explicitly covers when to use this tool, such as filtering 'statuses=["FAILED","TIMED_OUT"]' to hunt errors, and explains a key limitation: no error messages or logs are returned. It names alternatives like run_function and the Apps Script dashboard/Cloud Logging for retrieving actual error messages, giving clear routing guidance.

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