clickup_get_time_entries

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

With no annotations, the description carries the full burden and does disclose a genuinely important default: omitting assignee silently narrows results to the authenticated user. It also discloses the workspace-wide default when task_id is omitted. It does not cover pagination, result limits, or permissions, which is a notable gap for a list tool.

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?

Three tight sentences, front-loaded with purpose then the two mode rules, with the highest-risk caveat flagged by 'IMPORTANT'. No filler; each sentence carries a distinct decision the caller must make.

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?

All six parameters are optional and the description covers the two defaults an agent could get wrong (assignee scope, task scope), which is the main risk surface. Missing return-shape and pagination context is only partly excused by the absence of an output schema.

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 every parameter is already documented in structured fields, including the assignee default and date format patterns. The description largely restates that guidance rather than adding new semantics (e.g. no timezone handling, no behavior when start_date > end_date). Baseline 3 applies.

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 ("Get time entries") plus the filter dimensions, and clarifies the two query modes (task-scoped vs workspace-wide). It does not explicitly distinguish itself from the close sibling clickup_get_current_time_entry, leaving the agent to infer the plural/collection distinction.

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?

Explicitly says to pass task_id to scope to one task or omit for workspace-wide results, and gives a clear rule for the assignee parameter ('any' vs user IDs vs omission). It stops short of naming the alternative tool (e.g. get_current_time_entry) for running-timer queries, so routing against siblings is only implicit.

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