tocaro_search_tasks

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

With no annotations, the description carries the full burden, and it does disclose an important, non-obvious behavioral trait: specifying last_updated_after ignores page/per_page/sort/direction and returns all results in ascending update order. It also clarifies the mandatory project identifier format. However, it does not mention other search semantics (e.g., how query or status filters combine), so it is not fully exhaustive but goes well beyond the schema.

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 compact and well-structured: main purpose first, then the required project parameter and its source, then the important caveat about last_updated_after. Every sentence adds useful information, and the caveat is front-loaded enough that an agent will not miss it.

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?

Given the tool has an output schema, the description does not need to describe return values. It covers the core requirement, a prerequisite lookup, and the most impactful edge case (last_updated_after overriding pagination/sort), which is enough for an agent to call it correctly in most situations. It could be more complete by clarifying what 'query' searches against, but overall it is solid.

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%, so the description must compensate. It adds meaningful semantics for the project parameter (required format and source) and the last_updated_after parameter (override behavior). However, it does not explain the meanings or interactions of query, sort, direction, status, priority, page, and per_page, leaving a clear gap for an agent that needs to understand filtering behavior.

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?

Description states a specific action ('タスクを検索する' – search tasks) and a specific scope (specified ToDo list / project), which clearly distinguishes it from sibling tools like tocaro_search_users and tocaro_list_todo_lists. It also gives the exact project code format ('tr' + 9 chars), leaving no ambiguity about the resource being operated on.

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 provides clear context for usage: project is required and should be obtained via tocaro_list_todo_lists, which is an explicit prerequisite and sibling-tool pointer. It also warns about the special last_updated_after mode that changes pagination/sort behavior, but it does not explicitly state when not to use this tool or compare it with alternatives beyond the one pointer.

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