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 disclosing behavioral characteristics. It does state that updates go 'via the Things URL scheme' and that a summary is returned, but it does not cover partial success, failure handling, idempotency, reversibility, or side effects. For a mutating operation without annotations, this is a significant transparency gap.

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 well-structured with a one-sentence overview followed by Args and Returns sections. It is mostly concise, though the requirement that each update dict must have an 'id' is stated twice: once in the opening paragraph and again in the Args block. This minor redundancy prevents a 5.

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 single-parameter tool with no output schema and no annotations, the description covers the essential invocation details: update shape, required id, allowed fields, and response summary. It does not document date format constraints, invalid-id behavior, or partial-failure semantics, but those are non-blocking for correct basic 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?

The input schema only says updates is an array of additionalProperties objects, giving no field-level detail. The description fully compensates by specifying the required 'id' key, the allowed mutation fields (title, notes, when, deadline, tags, completed, canceled), types for boolean fields, and a concrete example. This is exactly the parameter semantic guidance an agent needs.

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 opens with a clear verb and resource: 'Update multiple todos at once via the Things URL scheme.' It states the mechanism and the object being changed, so an agent can tell it apart from read-only siblings like get_dashboard. However, it does not explicitly distinguish it from sibling tools like bulk_complete or bulk_reschedule.

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 choose batch_update instead of alternatives. No exclusions or comparisons to siblings such as bulk_complete or bulk_reschedule are provided. The only usable hint is the phrase 'multiple todos at once,' which only vaguely implies batch usage.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It does reveal that the operation transitions todos to a completed state and is batched, but it omits important details for a mutating bulk operation: idempotency, partial failure behavior, handling of invalid or missing IDs, return value, and permission requirements.

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 front-loaded with a clear one-sentence purpose, followed by a minimal and relevant Args block. There is no filler or redundant detail; every part 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?

The tool is simple with one parameter and no output schema, but it is still a mutating bulk operation with no annotations. The description covers what the tool does and what the parameter means, but it leaves meaningful gaps around return behavior and failure semantics. Adequate, yet not fully complete for safe autonomous 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%, so the description must compensate, and it does by defining todo_ids as 'List of todo UUIDs to complete.' This adds UUID format and clarifies the role of the parameter beyond the schema's generic 'Todo Ids' title. It does not add constraints like limits or uniqueness, but for a single list parameter the explanation is sufficient.

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 uses a specific verb ('Mark'), a clear resource ('todos'), and an explicit outcome ('completed' in one call). It is immediately distinguishable from siblings like bulk_reschedule or update_checklist without needing to inspect schemas.

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 no guidance on when to use this tool versus alternatives such as batch_update or bulk_reschedule. It does not state any exclusions, prerequisites, or selection criteria, so the agent must infer usage from the name alone.

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?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It indicates a mutating operation and lists accepted schedule values, but it does not state whether existing schedules are overwritten, whether the operation is atomic, what permissions are required, or what the tool returns. This is a significant gap for a mutation 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?

The description is compact, front-loaded with the main purpose, and then provides a concise parameter breakdown. There is no filler or redundant content; every sentence contributes essential 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?

The description is adequate for invoking the tool: both required parameters are explained and the supported values are enumerated. However, with no annotations and no output schema, the lack of behavioral details about side effects, return value, and failure behavior leaves it only minimally complete for an agent operating autonomously.

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 prose must fully explain the parameters. The description does this well: it defines todo_ids as UUIDs and gives the complete accepted set for when, including natural-language options and the YYYY-MM-DD format. This fully compensates for the sparse 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?

The description opens with a specific verb and resource: 'Reschedule multiple todos to the same date/time in one call.' It clearly describes the batch nature and the shared-target constraint, making it distinguishable from sibling tools like bulk_complete or batch_update by the unique rescheduling action.

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 implies the use case: rescheduling several todos at once to a common schedule. However, it does not explicitly state when to prefer this over alternatives, nor does it mention exclusions or situations where a different sibling tool should be used.

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?

With no annotations, the description carries the behavioral burden. It discloses the return type ('dict') and lists top-level keys (projects, areas, tags). However, it inconsistently lists 'headings' in the first sentence but omits them from the return dict, leaving ambiguity about whether headings are a separate key or nested. It also never explicitly states the operation is read-only, though the verb implies it.

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 three short sentences, front-loading the core function and then adding the return shape. Every sentence earns its place with 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?

For a no-arg getter with no annotations and no output schema, the description gives the essential purpose and a high-level return structure. However, the incomplete return disclosure (missing 'headings') and the lack of detail about areas and tags leave an agent with less than full information about what it will receive. The startup context is helpful for judging when to 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 input schema has zero parameters with 100% coverage, so the baseline is 4. The description implies a no-argument call ('in one call') but does not explicitly say no parameters are needed. No further parameter detail is required.

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 names a specific verb ('Get') and resource ('all structural metadata'), then enumerates projects, areas, tags, and headings. This clearly differentiates it from sibling tools like get_dashboard, get_review_data, and get_project_health, which target other data categories.

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 second sentence states that this replaces 3-4 separate MCP calls needed at startup, giving a clear when-to-use signal. It does not explicitly name alternate tools or exclusion conditions, but the startup/consolidation context is strong and not misleading.

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?

With no annotations, the description carries the behavioral burden. It discloses that the call aggregates today, inbox count, upcoming, and overdue into a single dashboard, and that it is an efficiency-oriented read operation. It does not explicitly state read-only status, but 'Get' and the dashboard framing make the non-mutating nature clear enough.

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, with the core action and payload stated first. The usage rationale and parameter documentation each earn their place with no redundant text.

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-optional-parameter read tool with no output schema, the description covers the key elements: what the dashboard contains and how the parameter behaves. Minor gaps like timezone handling or the exact shape of response fields are not critical 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?

Although schema description coverage is 0%, the description fully documents the only parameter: 'upcoming_days: How many days ahead to include in upcoming (default 3).' This adds meaningful semantic context beyond the schema's title and default.

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 a complete daily dashboard in one call' and enumerates what it includes (today, inbox count, upcoming, overdue). It is clearly differentiated from sibling getters like get_context and get_project_health by being an aggregation tool.

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 an explicit use case: 'for morning standup / plan-day' and says it replaces 4+ separate MCP calls. It does not name specific alternative tools or state when not to use it, so it stops short of the highest bar.

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?

With no annotations, the description carries the behavioral burden. It discloses the operation is read-oriented ('Get'), specifies that only active projects are included, and describes the return shape in detail. It does not cover error behavior or rate limits, but these are not critical for a zero-parameter read 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?

The description is well-organized, front-loads the core purpose, and uses short line breaks for different aspects: purpose, per-project fields, and return container. Every sentence adds useful information with no repetition.

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 zero-parameter, no-output-schema tool, this description is complete: it explains the purpose, the exact per-project fields, the return structure, and how it consolidates alternative query patterns. An agent has enough information to invoke and interpret the result 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?

The tool has zero parameters, so there is nothing to document. The description instead explains what the response contains, which is the relevant semantic information for this tool.

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?

Clearly states the verb and resource: 'Get project health data for stalled-project detection.' It also lists the specific fields returned and positions the tool as an aggregation over multiple query patterns, distinguishing it from sibling data tools.

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 a clear use context: stalled-project detection, and explicitly notes that one call replaces the get_projects + get_logbook + per-project todo queries pattern. It does not, however, contrast it with siblings like get_dashboard or get_review_data, so it lacks explicit when-not guidance.

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?

With no annotations, the description carries the full behavioral burden. It discloses that this is a broad composite read, lists the contents it returns, and fully specifies how logbook_period behaves. It does not explicitly say 'read-only' or warn about payload size, but the 'get' semantics make the behavior clear enough.

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: it front-loads the purpose, lists bundled content in a single line, and reserves a short 'Args' block for the one parameter. Every sentence earns its place with no filler or tautology.

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?

It covers the tool's return scope and the only parameter well, and there is no output schema requiring elaboration. It stops short of a 5 because the description never hints at the exact response shape or the potentially large payload of such an aggregate call, which would help an agent set expectations.

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 schema only defines a default string, so the description compensates completely by explaining the meaning, default value, format pattern (Nd/Nw/Nm/Ny), and concrete examples. This gives an agent everything needed to supply the argument correctly.

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 clearly states a specific verb ('Get') and a concrete resource ('all data needed for a weekly/daily review'), then enumerates the bundled categories. This makes it easy to distinguish from sibling tools like get_dashboard or get_context.

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 explicitly identifies the intended use case ('weekly/daily review') and frames the tool as a replacement for '10+ separate MCP calls,' so an agent knows to select it for whole-review retrieval. It does not name alternatives or state when not to use it, which prevents 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?

With no annotations, the description must carry the behavioral burden. It discloses that this wraps the Things URL scheme and that it modifies an existing todo's checklist. However, it does not clarify the destructive implications of 'replace' mode, whether existing checklist items are removed, or what happens on failure or partial success.

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, with the core purpose stated first and implementation context second. The Args block is cleanly formatted and matches the schema parameters without unnecessary repetition or fluff.

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 has an output schema, so return-value documentation is not the description's job. Parameters are documented, and the fit relative to update_todo is explained. The main gap is behavioral detail about what each mode does to existing checklist items, which is important for an agent deciding how to invoke it safely.

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, and it largely does. It explains todo_id as a UUID, items as checklist item strings, and mode as one of replace/append/prepend with a default. It could add more detail about mode behavior, but it provides enough meaning beyond the bare 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?

The opening line states a clear verb and resource: 'Update checklist items on an existing todo.' It also distinguishes itself from the standard update_todo tool by explaining that it wraps the Things URL scheme to handle checklist operations that update_todo cannot. This gives an agent a precise understanding of the tool's niche.

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 explicitly names the alternative (update_todo) and explains why this tool should be used instead: it handles checklist operations the standard tool can't do. It does not explicitly list exclusions or when to prefer update_todo, but the guidance is clear enough for most selection scenarios.

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