dida365-agent

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds no behavioral context beyond the name - it says nothing about idempotency, behavior on already-completed or invalid task IDs, or partial-failure handling for a batch mutation.

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?

A single front-loaded sentence with no waste. It is not padded, though it is arguably too terse given the gaps in parameter and failure semantics.

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, and annotations cover the safety profile. Still, key operational details - ID formats and batch partial-failure behavior - are absent, leaving the definition only minimally sufficient for a 2-required-param mutation tool.

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 for two undocumented required parameters. It mentions 'tasks' and 'project' conceptually but gives no ID format, no indication that task_ids is an array, and no guidance on whether all IDs must belong to the given project.

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 ('Mark ... as completed') and resource ('tasks in a project'), and the word 'multiple' distinguishes it from the single-task sibling dida365_complete_task. However, it does not explicitly name or contrast with siblings like dida365_batch_update_tasks, so sibling differentiation is only implied.

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 word 'multiple' implies this is the bulk path versus dida365_complete_task, but no when-to-use/when-not guidance is given. There is no mention of prerequisites (e.g., valid project, task ownership) or of what to do for a single task.

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

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, non-idempotent, openWorld). The description adds genuinely useful behavior beyond them: the return shape {'id2etag','id2error'} discloses that this is a partial-failure batch operation where individual tasks can fail independently — important context for a non-idempotent write.

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 short sentences, zero filler, with the core purpose front-loaded and the return contract last. Every sentence earns its place by supplying information absent from the structured fields.

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?

For a 1-param batch mutation tool, the description covers purpose, required item fields, and the partial-failure return contract, and an output schema exists so return values need no further explanation. It could be more complete by noting ordering limits or whether the request is atomic, but nothing essential to invoking it correctly is missing.

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 0% and the single 'tasks' param is an opaque array of additionalProperties:true objects, so the description carries the full burden. It specifies that each dict requires 'title' and 'projectId' and that optional fields match create_task, which meaningfully compensates. It loses a point only because it defers field details to another tool's schema rather than listing them.

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+scope: 'Batch create multiple tasks in one request.' The word 'batch'/'multiple' cleanly separates it from the single-task sibling create_task without needing to name it. It stops just short of explicit sibling routing, so a 4 rather than 5.

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?

Usage is implied by 'Batch create multiple tasks in one request' — an agent can infer this is the bulk variant — but there is no explicit when-to-use/when-not guidance and no mention of alternatives like create_task. The reference to create_task is for field definitions, not for routing decisions.

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

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

Annotations already declare idempotentHint=true, destructiveHint=false and readOnlyHint=false, covering the safety profile. The description adds genuine value with the partial-update semantics ("Only provided fields are changed"), but says nothing about auth requirements, atomicity across the batch, or partial-failure behavior beyond the return keys.

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 short sentences, front-loaded with the action, then required-input contract, then return shape. No padding, though the return-value line is partly redundant given an output schema exists.

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?

For a batch mutation with an opaque single-param schema, the definition covers required keys and partial-update behavior and an output schema covers the return shape. It still omits the set of updatable fields and any batch-failure semantics, which matter for correct invocation.

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 0% and the schema is fully opaque (array of bare objects with additionalProperties=true), so the description carries the full burden. It usefully specifies the required keys ("id" and "projectId") per dict, though it does not enumerate which other fields can be updated.

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+scope ("Batch update multiple tasks in one request"), clearly a bulk-write tool. It does not explicitly name its sibling dida365_update_task (single) or dida365_batch_complete_tasks, so an agent must infer the batch/single distinction from naming alone.

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 when-to-use guidance is given. It never says when to prefer this over dida365_update_task for a single task or how it differs from dida365_batch_complete_tasks, leaving the agent to infer the selection rationale.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, so the safety profile is covered structurally. The description adds nothing beyond restating the action: no note on whether the task remains retrievable, whether the completion timestamp is set, or what happens on repeated calls, despite idempotency being a relevant behavior.

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?

A single front-loaded sentence with no wasted words. The brevity is efficient, though it borders on under-specification rather than deliberate concision.

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 explained, but as a mutation tool with 0% parameter documentation and no annotation-independent behavioral detail, the definition is too thin for a two-required-parameter write operation.

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% for two required parameters (task_id, project_id). The description says only 'a task' and never clarifies parameter roles, formats, or why both a task and project identifier are required, leaving the agent to infer everything from bare field names.

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 ('Mark a task as completed'), so the agent knows exactly what the tool does. However, it does not differentiate from the sibling dida365_batch_complete_tasks, which performs a closely related operation on multiple tasks.

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?

There is no guidance on when to use this tool versus update_task, batch_complete_tasks, or any other sibling. No prerequisites, no exclusions, no alternative routing.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, and idempotentHint=false, so the safety profile is covered structurally. The description adds nothing behavioral beyond that — no note on what happens on duplicate names, no permission/scope requirements, no confirmation that creation persists.

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, front-loaded with the action and then the parameter hints. Nothing is wasted, though the parameter hints read as a terse dump rather than integrated guidance.

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. Still, with 5 parameters at 0% schema coverage and only two optional params touched, the definition is thin for a mutation tool — though the required 'name' is obvious enough that the gap is not fatal.

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 usefully enumerates the allowed values for view_mode (list|kanban|timeline) and kind (TASK|NOTE), but leaves color and sort_order entirely unexplained. Partial compensation only.

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 ('Create a project'), which is unambiguous on its own. However, it offers no differentiation from siblings like dida365_update_project or dida365_create_task beyond the name itself, so an agent must infer routing from the tool name.

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?

There is no when-to-use guidance, no prerequisites (e.g., project-specific vs user-specific creation), and no mention of alternatives such as dida365_create_task. The agent gets no routing help at all.

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

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

Annotations already declare write/non-destructive/non-idempotent/open-world, so the safety profile is covered. The description adds genuine behavioral context beyond that: the cross-parameter dependency between repeat_flag and start_date, and the kanban restriction on column_id.

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?

Front-loads the operation and required args in one sentence, then a note, then a focused Args block. It is not bloated, but the Args list is selectively incomplete, which slightly undercuts its structure.

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, and the conditional requirements are covered. However, for a 15-parameter tool at 0% schema coverage, the unexplained formats and value ranges (priority, dates, reminders) leave meaningful gaps for correct invocation.

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% across 15 parameters, so the description carries the full burden, yet it only documents column_id, kind, sort_order, and the items substructure. Fields like priority (integer scale unknown), due_date/start_date format, reminders, tags, and the desc-vs-content distinction are left unexplained.

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 ('Create a task') and names the two required parameters, so the agent immediately knows the operation. It does not, however, distinguish itself from the sibling dida365_batch_create_tasks, which an agent could easily confuse for bulk creation.

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?

Gives concrete conditional guidance: repeat_flag requires start_date, column_id requires a kanban-view project, and kind should be CHECKLIST when items are passed. These are real preconditions rather than vague suggestions, though there is no routing guidance versus batch_create_tasks.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so 'cannot be undone' is largely redundant. However, the description contributes genuine new behavior by disclosing that the deletion cascades to all tasks in the project, which the annotations do not convey.

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, front-loaded with the action and scope, with the irreversibility warning placed immediately after. Nothing is wasted and nothing is buried.

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?

For a one-parameter destructive tool, the annotations carry most of the safety burden and an output schema exists, so the description only needs to state impact — which it does via the cascade disclosure. Missing only parameter-format and precondition detail.

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 the description says nothing about project_id — no format, source, or how to obtain it. With a single, self-evidently named parameter the gap is small, but the description does not compensate for the near-total lack of schema documentation.

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 ('delete') and resource ('project') and adds the crucial cascade scope ('and all its tasks'), which separates it from the sibling dida365_delete_task. An agent can tell exactly what this tool removes without opening the schema.

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 gives no when-to-use guidance, no preconditions (e.g., whether the project must be empty), and never names the alternative path (e.g., dida365_update_project or delete_task) for partial removal. Usage is only implied by the resource name.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is largely covered. The description adds the irreversibility nuance ('cannot be undone'), which is mild added value, but says nothing about what removal cascades to, whether subtasks/comments go with it, or required permissions.

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, zero padding, with the core action and its irreversibility front-loaded. Nothing could be trimmed without losing information.

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 no explanation, and annotations carry the safety semantics. Still, for an irreversible mutation the description omits any permission or scope context and leaves both parameters unexplained, making it only minimally complete.

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?

Both task_id and project_id have 0% schema description coverage and the description supplies no meaning for either — notably why project_id is required alongside task_id. With two undocumented parameters and no compensating description text, this is a clear gap.

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 ('delete a task') with the permanence qualifier, which is unambiguous against siblings like dida365_delete_project. It does not explicitly contrast with other task-mutating siblings such as dida365_complete_task or dida365_update_task, but the resource noun does most of the distinguishing work.

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?

There is no when-to-use guidance, no mention of prerequisites (task ownership, project membership), and no routing to alternatives such as completing a task instead of deleting it. The only usage signal is the implied finality of 'permanently'.

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

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.

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered structurally. The description adds only that filtering is optional; it says nothing about pagination, default time window, or result ordering beyond what annotations provide.

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?

A single tight sentence with the core purpose and the filter scope front-loaded; no filler or redundant restatement of the title.

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 no explanation. However, for a query tool with three completely undocumented parameters and date strings of unspecified format, the description leaves real ambiguity about how to invoke it 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 coverage is 0%, and the description only loosely maps its three parameters to 'project' and 'completion time range'. It never clarifies the date string format, inclusive/exclusive bounds, or whether project_ids accepts multiple projects, so the description partially but not fully compensates for the undocumented schema.

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 (Get) and resource (completed tasks) plus scope of optional filters. It implicitly distinguishes itself from siblings like dida365_list_undone_tasks and dida365_get_project_tasks by the 'completed' qualifier, though it never names an alternative explicitly.

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 mention of optional project and time-range filtering implies when the filters matter, but there is no explicit when-to-use, when-not-to-use, or pointer to the sibling tools (e.g., list_undone_tasks or filter_tasks) that an agent should pick instead.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds no behavioral context beyond that – nothing about what happens with an invalid or missing project_id, or error behavior – so it earns little credit here.

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?

A single short sentence, front-loaded with the verb and resource, with no filler or redundancy. It is terse, though the terseness borders on under-specification rather than excess.

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?

The tool is simple (one required parameter) and an output schema exists, so return values need not be described. However, given the crowded sibling set and zero parameter documentation, the description is thinner than ideal but minimally sufficient for a straightforward fetch-by-ID operation.

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 schema documents nothing about project_id beyond its string type. The phrase "by ID" hints that the parameter is an identifier, but the description gives no format, source, or validity constraints for that ID, leaving most of the semantic burden unmet.

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 specific verb and resource ("Get project details") and scopes it to lookup by ID, which is clear enough to select. It does not, however, distinguish this from sibling tools like dida365_get_project_tasks, dida365_list_projects, or dida365_get_task, so sibling differentiation is absent.

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?

There is no when-to-use guidance, no prerequisite or authorization information, and no mention of alternatives such as list_projects for enumerating projects vs. fetching a single one. The agent must infer the appropriate context entirely on its own.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds the meaningful filtering behavior (only uncompleted tasks), but says nothing about pagination, ordering, or volume limits for an open-world list call.

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?

A single front-loaded sentence with no filler, stating scope before anything else. Nothing is wasted.

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 the definition still omits the one required parameter's meaning and does not clarify its relationship to the overlapping siblings. For a read-only list tool that is adequate but leaves real gaps.

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 the single required parameter project_id has no description in either the schema or the description. The description does not explain where the project_id comes from or its format, leaving the one input undocumented.

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 clear verb (get) and resource (tasks) plus a scope qualifier (all uncompleted, in a project), so the agent knows exactly what is returned. However, it does not differentiate itself from the near-duplicate sibling dida365_list_undone_tasks, which appears to cover the same filtered set.

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?

There is no when-to-use guidance and no mention of alternatives, despite siblings dida365_get_completed_tasks and dida365_list_undone_tasks sitting right next to it. The agent must infer the boundary between this tool and list_undone_tasks on its own.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld behavior, so safety is fully covered. The description adds nothing beyond restating the name — no note on scope, cross-project access, or failure behavior for a missing ID. With an output schema present, return format needn't be described, but the description still contributes no behavioral context beyond the annotations.

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?

A single short, front-loaded sentence with no filler. It is appropriately sized, though the extreme brevity contributes to the gaps noted elsewhere rather than being a virtue in itself.

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?

The presence of an output schema means return values need not be explained, and annotations cover the safety profile. But the required project_id parameter is entirely unaddressed, and the ambiguity with dida365_get_task_by_id remains unresolved, so the definition is only minimally complete for a two-parameter lookup tool.

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 both task_id and project_id are plain strings with no descriptions. The phrase 'by ID' loosely maps to task_id, but the description never mentions that project_id is also required or what it scopes, so it fails to compensate for the 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?

States a clear verb and resource ('Get a single task by ID'), which is adequate on its own. However, the sibling list contains both 'dida365_get_task' and 'dida365_get_task_by_id', and the description does nothing to distinguish this tool from that near-identical sibling, leaving the agent unable to tell them apart.

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?

There is no guidance on when to use this tool versus the many alternatives (get_task_by_id, get_project_tasks, filter_tasks, etc.). Nothing states prerequisites or exclusion conditions, so the agent must infer usage purely from the name.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and open-world access, so the safety profile is fully covered without the description. The description adds only the project_id-free lookup constraint, with no details on error behavior, permissions, or lookup scope.

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?

A single short sentence that front-loads the action and the key constraint. No filler or redundancy.

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?

With an output schema present, return values need not be explained, and annotations cover the behavioral profile, so the description is nearly sufficient. The only gap is the absence of task_id format guidance and any explicit contrast with dida365_get_task.

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?

There is a single parameter (task_id) and schema description coverage is 0%, so the schema gives the agent no format hints. The description confirms the lookup is keyed on an ID but adds no syntax, format, or example beyond that.

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 a task by ID) and implicitly distinguishes itself from the sibling dida365_get_task by noting it needs no project_id. An agent can tell what it retrieves, though the distinction from get_task is stated as a constraint rather than an explicit contrast.

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 phrase 'without needing project_id' effectively encodes the condition under which this tool is preferred over dida365_get_task, so the selection logic is inferable. It stops short of explicitly naming the alternative or stating when not to use it.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive, so the safety profile is fully covered. The description adds only the discovery-role framing, not details like return size or pagination, so a baseline 3 is appropriate.

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 core purpose is front-loaded before the usage hint. Every sentence earns its place.

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, and the annotations cover the behavioral profile. For a no-param read tool, the description supplies everything an agent needs to select and call it.

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?

The tool takes zero parameters, so the description carries no parameter burden and the baseline is 4. Nothing in the schema needs compensating for.

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 ('List') and resource ('projects') with scope ('all'), clearly distinguishing it from get_project. It doesn't explicitly name siblings, but the list vs. get distinction is self-evident from the name.

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?

"Call this first to discover project IDs for other operations" gives concrete sequencing guidance that tells the agent when to reach for this tool. No explicit alternatives or exclusions are named, keeping it just short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, covering the safety profile. The description adds essentially no behavioral context beyond that – it does not say what happens when the optional dates or project_ids are omitted, whether results are paginated, or what the default scope is.

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?

A single front-loaded sentence with no filler, and the scoping constraints follow the verb immediately. It is efficient, though there is little content to structure.

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 explained, but for a 3-parameter tool with 0% schema coverage the definition is under-specified: date format, null-default behavior, and result set semantics (all undone tasks across projects vs. a bounded set) are all left to inference.

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 all three parameters default to null, yet the description only loosely maps to them ('date range' -> start_date/end_date, 'projects' -> project_ids) without specifying date string format, whether the range is inclusive, or what null/omitted means. It does not compensate for the coverage gap.

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 gives a specific verb and resource ('List undone tasks') with its scope ('within a date range, optionally filtered by projects'). The qualifier 'undone' usefully distinguishes it from the sibling get_completed_tasks, though it never names that sibling explicitly.

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?

It states the filtering capability but gives no guidance on when to choose this tool over the overlapping siblings dida365_filter_tasks, dida365_get_project_tasks, or dida365_get_completed_tasks. The date-range emphasis is implied usage at best, with no exclusions or alternatives named.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the safety profile is covered structurally. The description adds nothing beyond them: it does not say whether the task is removed from the source project, what happens if task_id is not in from_project_id, or how errors are surfaced.

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?

A single front-loaded sentence with zero waste, so it is structurally clean. However, for a three-parameter mutation tool the brevity reads as under-specification rather than tight editing.

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?

The output schema exists, so return-value explanation is not required. Even so, for a mutation tool with three required, fully undocumented parameters, the description leaves key operational questions unanswered.

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 the description supplies no meaning for any of the three parameters. The phrase 'between projects' only loosely implies the from/to pairing that the parameter names already convey, so it does not compensate for the coverage gap.

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 (Move) and resource (task) plus the scope of the operation (between projects), which is clearer than a bare name restatement. It does not distinguish itself from close siblings such as dida365_update_task, which could plausibly also relocate a task.

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 guidance on when to use this rather than dida365_update_task (which may also change a task's project) or when-not to use it. No prerequisites or preconditions stated despite all three parameters being required.

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

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

Annotations already disclose that this is a non-read-only, idempotent, non-destructive mutation. The description adds one genuinely useful behavioral fact beyond them: the partial-update semantics ("Only provided fields are changed"), which tells the agent unspecified fields are preserved rather than cleared. It does not cover permissions, failure modes, or invalid project_id behavior.

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, no filler, with the core action front-loaded and the partial-update rule immediately after. It is efficient, though the brevity reflects under-specification rather than disciplined economy.

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 explained. But for a six-parameter update tool with zero schema coverage and no enums, the description leaves the agent without any field-level meaning or usage context; it is far too thin for the tool's complexity.

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 none of the six parameters (kind, name, color, view_mode, sort_order, project_id) are documented anywhere. The sentence about only-provided-fields being changed hints at the nullable/default semantics visible in the schema, but it names no field or its accepted values, so it does not compensate for the coverage gap.

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?

"Update a project" states a clear verb and resource, so the basic intent is unambiguous. However, it does nothing to distinguish this from sibling mutation tools such as dida365_update_task or dida365_create_project beyond the noun. It is minimum viable rather than specific.

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?

There is no guidance on when to use this tool versus alternatives, no mention of prerequisites (the project must already exist), and no exclusions. The agent must infer usage entirely from the name.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: omitted fields are preserved, and column_id only works when the project is in kanban view. It omits any note about permissions or side effects on subtasks when kind changes, which keeps it short of a 5.

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 front-loaded: the mutation contract is stated in the first two sentences, followed by an Args block that only covers fields needing explanation rather than restating all 16. Slightly repetitive 'for CHECKLIST kind' phrasing, but no padding.

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 explained, and annotations cover the safety profile. For a 16-parameter mutation tool with 0% schema coverage, though, roughly three-quarters of the parameters rely on name inference alone, leaving the definition short of fully self-contained.

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% across 16 parameters, so the prose carries the burden. It does a good job on four of them — column_id (kanban constraint), kind (TEXT/NOTE/CHECKLIST with usage rule), sort_order (lower-first ordering), and items (required 'title' plus optional camelCase keys with value encoding) — but says nothing about desc, content, tags, due_date, priority, reminders, time_zone, is_all_day, start_date, or repeat_flag.

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 specific verb and resource ('Update a task') and immediately clarifies the partial-update semantics ('Only provided fields are changed; omitted fields remain unchanged'). It does not, however, distinguish itself from close siblings like dida365_move_task, dida365_complete_task, or dida365_batch_update_tasks, which an agent must disambiguate among.

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?

There is no explicit when-to-use guidance and no mention of alternatives. The partial-update sentence implies this is the general-purpose editor (versus specialized siblings like move_task/complete_task), but the agent is left to infer that routing decision rather than being told it.

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