List function history

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

Annotations already cover safety (readOnlyHint, idempotentHint, non-destructive), so the bar is lower; the description adds genuinely useful behavior the annotations don't carry: the exact auth requirements (services:read for API keys, Functions read permission for OAuth) and the pagination traversal rule. It omits return shape and rate limits, keeping it out of 5 territory.

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 tightly packed sentences: scope and operation first, then filtering/pagination behavior, then the permission requirements. No filler, and every clause carries actionable information.

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 correctly covers the operational essentials an agent needs — scope, filters, pagination, and auth. What's missing is how the returned history differs from list_function_invocations/get_function_invocation, which leaves a real routing ambiguity among close siblings.

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 60%, with page/limit/function_id documented in the schema and search/status undocumented there. The description adds the filter vocabulary ('filter by function, status or search') but no syntax, format, or matching semantics beyond what the schema already provides, so it neither compensates for the gap nor detracts.

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 ('Read ... Firecracker Function invocation history') plus the account-wide scope, which is more than the name conveys. However, it does not differentiate itself from the near-identical sibling list_function_invocations, leaving the agent to guess which history/invocation listing to call.

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?

Gives implied usage guidance through the filterable dimensions (function, status, search) and the instruction to follow pagination.pages for older runs, which tells the agent how to traverse results. It stops short of saying when to use this tool versus list_function_invocations or get_function_invocation, and gives no explicit exclusions.

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