gc_time

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

No annotations are provided, so the description carries the full burden. It lists 10 actions (several of which are mutating: delete, log, start_timer, stop_timer) but does not disclose what side effects occur, whether data is destroyed on delete, permission requirements, or persistence behavior. It does note 'actual time spent on work' and 'duration models,' but there's no behavioral disclosure about destruction, overwrites, or system state changes.

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 reasonably compact (2 sentences plus a list of action names), and the core-purpose sentence is front-loaded. The list of actions is helpful for discovery but is presented as a bare comma-separated enumeration without any explanation or grouping. It's under-specified rather than genuinely concise, but the format is clean.

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?

This is a high-complexity tool: 18 parameters, 10 dispatch actions, no output schema, and no annotations. The description must carry significant burden to make this usable, but it only provides a one-line purpose and a flat action list. It doesn't explain return formats, which action returns what, how duration_estimate differs from aggregate, how log differs from log_agent_job, or any of the many edge cases. For a tool with this breadth, the description is substantially incomplete.

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 100%, so each of the 18 parameters has its own description in the schema (e.g., 'Start time (ISO 8601)', 'Task description (for log_agent_job)'). However, the tool's description adds nearly zero parameter-level meaning beyond listing the action names. Importantly, there is no mapping of which parameters apply to which action - for a 10-action dispatcher, the description should clarify which params pair with which action, but it doesn't. So the description does not compensate for the complexity of a multi-action tool.

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 'Track actual time spent on work' with specific verbs for actions (start_timer, stop_timer, log, delete, query, etc.). It clearly indicates this is a time-tracking tool. However, it's a broad multi-purpose tool that dispatches to 10 different actions, so the primary purpose is 'time tracking' but the specific verb depends on which action is chosen. It doesn't deeply distinguish from sibling gc_timing which may be a timing-specific tool, but the resource/action framing is reasonably clear.

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 lists 10 available actions but provides no guidance on when to use each action, no prerequisites, and no context on how this tool relates to alternatives like gc_timing or gc_schedule. There is no explanation of when to choose time tracking here vs other sibling tools. The list of actions is enumerative, not instructive.

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