get_time_entries

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. However, the description provides no behavioral details: no pagination info, no indication of how many entries are returned, no mention of authorization/permissions needed, no sorting or limit semantics. The description adds minimal behavioral context beyond the tool name itself.

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?

Single sentence, zero waste. It's appropriately brief for a simple list-retrieval tool. No filler or redundant phrasing.

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 moderately complex tool with 11 parameters, 64% undocumented by schema, no output schema, and no annotations. The description does not clarify the relationship between filters (e.g., must start_date come with end_date? mutually exclusive filters?), whether result is paginated, or what the return structure looks like. For a tool with this many filter parameters and rich siblings, the single-line description is under-specified.

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 low at 36%, with 5 of 11 parameters lacking descriptions (list_id, task_id, space_id, folder_id, custom_task_ids, include_task_tags, include_location_names have no description). The description says 'optional filters' which maps to the parameter set generically, but the term 'filters' does add some conceptual framing. The description doesn't compensate for the 64% gap in undocumented parameters.

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 clear verb+resource+scope: 'Get time entries for a workspace with optional filters.' It clearly distinguishes this from siblings like get_time_entry (singular), create_time_entry, update_time_entry, and start_timer/stop_timer. While it doesn't mention the return format or that this is a list operation, the verb-resource-scope structure is 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?

No explicit guidance is given about when to use this tool vs alternatives. There are multiple time-related siblings (get_time_entry, get_running_timer, get_time_entry_tags), and the description doesn't explain when to prefer this over get_time_entry or distinguish between them. Usage context is entirely implied by the name and 'workspace' scope.

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