Filter Tasks

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

Annotations already declare readOnly, idempotent, non-destructive behavior, so safety is covered. The description does add a genuinely useful behavioral detail (tags use AND logic), but it says nothing about how other filters combine with each other or with tags, nor about date-range semantics or result limits.

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 short sentences with zero filler, and the scope statement is front-loaded before the tag-logic note. It is efficient, though the extreme brevity is part of why so much parameter meaning is missing.

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?

An output schema exists so return values need not be described, but with six parameters at 0% schema coverage the description should carry more weight. It omits filter value formats (status/priority enums, date strings) and the interaction rules between filters, which an agent needs to call this correctly.

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 0% and six parameters carry no inline documentation. The description only tells us everything is optional and combinable and that tags are ANDed; it does not explain status/priority integer codes, date formats, or how project_ids interacts with tags, leaving most parameters semantically opaque.

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+resource: filtering tasks across projects, which is clear on its own. However, it does not distinguish itself from close siblings like dida365_get_project_tasks, dida365_list_undone_tasks, or dida365_get_completed_tasks, so an agent cannot tell from the description alone which retrieval tool to pick.

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?

Only guidance is 'All parameters are optional and combinable,' which describes mechanics rather than when to use this tool versus the many other task-listing siblings. No context about when filtering is preferable to project-scoped or status-scoped retrieval tools.

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