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

With no annotations, the description carries the full burden and does so well: it discloses the default due behavior (next day at Account.defaultTime, default 09:00), timezone semantics, default repeat values, and a failure condition (trial/subscription expired → isError + code=PAYMENT_REQUIRED). It stops short of stating authentication requirements (implied by sign_in) or any rate limits, so it is not exhaustive.

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?

Purpose is front-loaded and no sentence is pure filler, but the definition is a single long run-on paragraph mixing due defaults, repeat vocabulary, and payment failure. Bullets or short sections would improve scanability for an agent parsing it, though the information density is justified by the nested repeat schema.

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 5-parameter tool with a nested repeat object and no output schema, the description covers the tricky invocation aspects (due defaults, recurrence encoding, payment-required error). It omits auth prerequisites and says nothing about the response, but with no output schema defined the latter is less critical. Adequate for correct invocation given the schema's own descriptions.

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 60%, and the description compensates heavily for the complex parameters: it explains due formats and the date-only default-time behavior, and translates natural-language recurrence phrases into repeat object shapes (毎週 月水 → weekdays [2,4], 隔週 → interval 2, etc.). It says nothing about notes or sound, which remain schema-documented only, but adds real meaning beyond the schema for the high-complexity fields.

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+resource (「TODO を追加する」) and adds the creation source (source=mcp). It is trivially distinguishable from siblings like update_todo, complete_todo, snooze_todo, and delete_todo, which all operate on existing TODOs. No ambiguity about what the tool does.

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?

Rich guidance on optional parameters: pass only title for a bare TODO; pass due only when the user states a time (「明日 9 時」「今日 15 時」); pass YYYY-MM-DD for date-only; how to express recurrence. It does not, however, route among sibling tools or state exclusions (e.g., when to use update_todo instead), so it falls short of explicit alternative-selection 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 present, the description carries the full burden and does well: it discloses the exact mutations for each case (status=done + completedAt for one-off; a done Occurrence record keyed by occurrenceDate for recurring). It omits idempotency, error states (e.g., already-completed), and auth requirements, keeping 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 action ('やった、にする') is front-loaded, and the remaining clauses each earn their place by covering the two execution branches. It is dense but free of filler; slightly telegraphic phrasing is the only minor cost.

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 2-parameter mutation tool with no annotations and no output schema, the definition covers the important complexity: the divergence between one-off and recurring completion, plus the optional date semantics. Error/edge behavior and return expectations are the only meaningful 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 coverage is 50%: occurrenceDate is documented, id is not. The description adds real value beyond the schema by specifying the timeZone-aware default ('today in the TODO's timeZone'), which the schema's terse '省略で今日' does not clarify. It adds nothing for the required id parameter, so a 3 is appropriate.

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+resource ('mark as done') and goes further by splitting the behavior into one-off vs. recurring cases. It implicitly separates this from update_todo via completion semantics, but never names or contrasts a sibling explicitly, so it lands at 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 the completion semantics and the single-vs-recurring branch, which tells an agent which code path applies. However, there is no guidance on when to prefer complete_todo over update_todo or snooze_todo, and no stated preconditions or exclusions.

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 provided, the description carries the full behavioral burden and does add real value: it discloses the soft-delete mechanism and the 14-day retention before physical purge. It omits other relevant behavior such as idempotency, what happens when deleting an already-deleted TODO, or any permission requirements, leaving meaningful gaps 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?

Two short, front-loaded sentences with zero filler; the core behavior (soft delete via deletedAt) leads and the follow-on cleanup detail follows immediately.

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 param, no output schema, no annotations), and the description does cover the key lifecycle behavior. Still, it says nothing about the id parameter, return value, or failure modes, and with no annotations those gaps are not covered elsewhere.

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 one parameter (id) with 0% schema description coverage, so the description should compensate but never mentions the identifier at all. It does not clarify what the id refers to or its expected format, leaving the schema's bare string entirely 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 specific operation (soft delete) and its mechanism (writing deletedAt) for the TODO resource. However, it never distinguishes itself from siblings like complete_todo, snooze_todo, or update_todo, which also mutate a TODO, so an agent must infer the difference from the tool name 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?

There is no statement of when to choose this over complete_todo, snooze_todo, or update_todo, nor any prerequisite (e.g. ownership or existing state). The delete intent is only implied by the words 'soft delete'.

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 and does disclose a genuinely non-obvious behavioral trait: defaultDueNext is a derived value tied to the account time zone and only matters as the fallback when due is omitted. It still does not state whether authentication (sibling sign_in) is required or what happens on failure.

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 sentences with no filler: the first front-loads exactly what is returned, the second front-loads the call precondition at the end where it is most actionable. Every clause carries 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?

There is no output schema, so the description must explain return values and it does so field by field, including the derived ISO8601 value. For a zero-parameter read tool the definition gives the agent everything needed to call and interpret 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 baseline is 4 and there is no parameter syntax for the description to add. 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?

The description names the exact resource (Account レコード) and enumerates the fields returned (trialStartedAt, subscribedUntil, timeZone, defaultTime, defaultDueNext), so an agent knows precisely what it gets. It does not explicitly contrast itself with siblings like list_todos or sign_in, but the resource is distinctive enough that confusion is unlikely.

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 closing line "日付を扱う前に呼ぶ" gives an explicit precondition for calling the tool, which is real usage guidance rather than implication. It stops short of naming a when-not case or an alternative tool, so it is not a full 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 carries the full behavioral burden and does well: it discloses that deleted records (deletedAt present) are excluded, that recurring items are not expanded but returned as 'repeating' templates plus in-range occurrences, and that expansion is the app's job, not the MCP's. It stops short of stating the read-only nature or the response shape explicitly, but the read semantics are strongly implied by 一覧する.

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 purpose and filtering rules are front-loaded, and the dense recurrence-rule block at the end is justified because there is no output schema describing the 'repeating' template. Every clause is information-bearing, though the spec-dump style for recurrence could be tightened.

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-required-param list tool with no output schema, the description covers filtering, defaults, exclusion rules, and the structure of recurring items and their occurrences. Given the complexity of the recurrence domain, it is largely complete, though the shape of a returned TODO item itself is left unspecified.

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 the baseline is 3, but the description adds real meaning beyond the schema: from/to are inclusive on both ends, dates are interpreted in the Account's timeZone, and status defaults to pending. These are semantic details the schema fields do not convey.

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 'TODO を一覧する' states a specific verb (list) and resource (TODO), immediately separable from the mutation siblings (add_todo, update_todo, complete_todo, delete_todo). It also defines the scope precisely with the date/from-to filtering semantics.

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 clearly says when to use date (single day) vs. from/to (inclusive range) and what the omission default is (全期間). It also states the status default (pending) and that deleted items are excluded. It does not explicitly name sibling alternatives, but the filtering guidance is unambiguous.

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 and does well: it discloses the side effect (a browser flow), the persisted artifact and its exact path (~/.mustdo/auth.json), and the human-in-the-loop prerequisite. It is silent on failure/timeout behavior and whether an existing token is overwritten, 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?

Three tight sentences: action, trigger, precondition. The routing constraint is front-loaded and every clause earns its place with no filler.

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-optional-parameter, no-output-schema tool, the description covers purpose, trigger, precondition, and side effect. Only minor gaps remain (failure/timeout handling, token-overwrite semantics), which are not essential 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 100% and only one optional parameter exists, so the schema already fully documents waitSeconds (default 90, range 5-300). The description adds no parameter syntax or defaults beyond that, making the baseline 3 correct.

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 (opens Apple's sign-in page, persists ckWebAuthToken to ~/.mustdo/auth.json). This is unmistakably different from every sibling tool, all of which are todo operations, so an agent can route to it without ambiguity.

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 an explicit trigger (when another tool returns NOT_SIGNED_IN) and an explicit exclusion (call only when the user can operate the browser). Both the when and the when-not are stated, leaving nothing to inference.

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, yet it only discloses the suppression effect and that recurring items are scoped to one occurrence. It omits whether auth is required, how it interacts with existing reminders, idempotency, and what value is returned.

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 compact clauses with no filler, and the cardinal constraint (until) is front-loaded. It is dense to the point of being slightly cryptic but wastes no words.

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 mutation tool with no annotations and no output schema, the description covers the core timing parameters but omits the id parameter, sibling routing, side effects, and return behavior. It is minimally sufficient but leaves clear 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 coverage is 67%; the description restates the until format and clarifies recurring-occurrence behavior, adding some meaning beyond the schema. However, it leaves id undocumented and its timeZone wording ("TODO の timeZone") conflicts with the schema's "Account の timeZone", which is a minor semantic inconsistency rather than added clarity.

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 conveys a specific action and effect—suppressing firing until a given time ("〜まで鳴らさない")—which, with the name snooze_todo, is distinguishable from update_todo or complete_todo. It does not explicitly name or contrast a sibling, keeping it short of a 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?

There is no stated when-to-use or when-not-to-use versus the siblings (e.g. update_todo, complete_todo). The only usage hint is the recurrence note ("繰り返しは occurrenceDate の回だけ"), which is narrow and does not help an agent choose this tool over alternatives.

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 burden well: it discloses partial mutation, wholesale replacement of repeat, repeat removal via null or {kind:none}, notes deletion via null, and the status restriction on repeating TODOs. It stops short of auth, error, or return behavior, but covers the main mutation semantics.

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, moving from the general update operation to key semantic caveats without wasted sentences.

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 7-parameter mutation tool with no annotations and no output schema, the description provides the crucial update semantics an agent needs. Minor gaps remain around id requirements and error/return behavior, but core invocation safety is covered.

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 only 43%, so the description must compensate. It adds valuable semantics for repeat, notes, and status, but does not explain id, due-time formatting, or sound choices beyond what the schema already provides.

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 (TODO), enumerates the mutable fields, and distinguishes the tool from complete_todo and snooze_todo for repeating TODO status operations.

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 clearly explains partial-update behavior (渡した項目だけ変わる) and routes the agent away from using this tool to change status on repeating TODOs, naming complete_todo and snooze_todo as alternatives. It does not cover every sibling relationship, but the relevant exclusion is explicit.

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