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 so: precondition (no todo/in_progress tasks), side effects (stores result_markdown as the period's result, marks the milestone done), and re-invocation semantics ('rewrites the retrospective and changes nothing else'). Idempotency and mutation scope are both disclosed, which is unusual and valuable.

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-loaded with the trigger, then precondition, then effects, then re-call behavior — the ordering is sensible. The first and second paragraphs restate the same 'quarter's work is over' idea, a small redundancy that could be merged.

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?

No output schema and no annotations, so the description has to be self-sufficient, and it nearly is: preconditions, side effects, and idempotency are all present. It leaves the `key` argument and any indication of what the call returns undefined, which an agent may need for an unfamiliar 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 coverage is 0%, so the description must compensate. It explains period's YYYYQn format, and constrains result_markdown's language, length (~30 lines), and content (summary vs goal, lessons, carried-over task old id -> new id), including where it is stored. The `key` parameter is left entirely undefined, which keeps it from a 5.

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 plus the key artifact it produces: 'Close a period (YYYYQn) and record its retrospective.' The period-key format and retrospective recording make it unmistakably distinct from sibling open_period and from get_retrospective.

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 triggering condition ('when a quarter's work is over and the user wants it closed with a retrospective') and an explicit refusal condition ('refuses while any task is still todo or in_progress'). It never names open_period as the counterpart to use when the period isn't ready to close, so the routing back to alternatives is only implied.

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 does disclose useful state facts (status starts as active, the project accepts tasks immediately, create_task opens the current quarter). It omits duplicate-key behavior, required permissions, and whether `key` is immutable — meaningful gaps for a create operation.

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-loaded with the trigger sentence, then the operation, then per-parameter notes — good ordering with no filler sentences. The closing paragraph on optional planning is mildly tangential but earns its place by preventing premature set_overview/upsert_milestone calls.

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?

No output schema and no annotations, so the description is the only source of truth; it covers behavior and most parameters but leaves `name` unexplained (unclear how it differs from `description`) and says nothing about what is returned or what happens on a key collision.

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%, so the description must compensate, and it does for three of four parameters: `key` gets format rules and an example (2-5 uppercase letters, DLY), `description` gets length, language, and where it renders, and `repo` gets accepted formats (owner/name or URL). Only `name` is left entirely undefined.

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 ('Register a new project') plus a scope qualifier ('once per codebase, before any planning happens') that separates it from update_project and list_projects. An agent can identify the operation and its one-shot nature 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?

Opens with an explicit trigger ('Use it when the user wants a codebase tracked here') and adds a strong constraint ('once per codebase, before any planning happens') that implies when not to call it. It also names the follow-on siblings (create_task, set_overview, upsert_milestone), but never says what to do if the project already exists (e.g., route to update_project).

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 discloses important behavior: ids are project-global and never reused, the current quarter opens automatically and returns `opened`, other quarters must already be open, and depends_on is a pointer rather than a lock. It does not describe permissions/auth requirements or the full response shape, so it is strong but 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?

The description is long but front-loads purpose and usage, then organizes parameter semantics into clear paragraphs. Most sentences earn their place by adding constraints or routing guidance, though some of the content/title prose is more verbose than strictly necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, no output schema, and 0% schema coverage, the description is largely complete: it explains creation scope, side effects, period handling, and most parameter semantics. The missing `key` semantics and incomplete return-value detail keep it from being fully 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?

Schema description coverage is 0%, so the description must compensate, and it does richly for period, title, content, tags, and depends_on, including syntax and constraints. However, the required `key` parameter is never explained anywhere, leaving a clear gap for one of the three required inputs.

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 ("Create a task"), scopes the unit of work ("one issue/branch-sized unit of work") and status ("todo"), and distinguishes creation from later lifecycle steps by referencing transition_task. An agent can tell this is the creation tool 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?

It opens with a clear trigger ("when you start a piece of work or the user asks to add one") and routes related actions: finishing uses transition_task, other quarters use open_period, and list_tasks/get_status expose tags and waiting_on. It does not explicitly say when to use update_task instead for existing tasks, so it stops short of full when/when-not/alternatives 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 does useful work by disclosing that the read errors while the period is still open and that the returned content is the `result` markdown created by close_period. It does not cover authentication, rate limits, or the exact error shape, but the key behavioral traits are present.

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 primary trigger, followed by the resource semantics and the error/alternative condition. There is no redundant wording.

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 two-parameter read tool with no output schema or annotations, the description covers the trigger, period format, returned content, open-period error behavior, and an alternative for checking closed periods. The missing explanation of `key` is the notable remaining gap.

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, but it only clarifies the `period` parameter's YYYYQn format. The required `key` parameter is never explained, leaving an agent unsure what identifier must be supplied.

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 (Read) and resource (a closed period's retrospective), including the format (YYYYQn) and that the content is the `result` markdown written by close_period. This clearly distinguishes it from siblings such as get_status and close_period.

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?

Explicitly says to use it when the user asks how a past quarter went, and limits it to closed periods. It also names get_status as the way to determine which periods are closed, providing a clear alternative for related context.

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: it frames the tool as a read ('Read a project's plan as written'), discloses that results are goals only and exclude counts, and states a concrete output-modifying behavior ('Timestamps (meta) are left out unless include_meta is set'). It stops short of explicitly asserting it is non-mutating or mentioning any permission/access 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?

Front-loaded with the usage trigger, then scope, then exclusions, then the meta caveat — every sentence carries information. Slight tightening is possible ('as written', 'the names of its periods' is a touch vague), but there is 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?

For a two-parameter read-only tool with no output schema, the description covers purpose, content shape, sibling routing, and the one optional flag. The single material gap is that the required `key` parameter's meaning and source are never explained.

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 is the only source of parameter meaning. It explains the effect of include_meta precisely, but never explains what `key` is (presumably a project identifier) or how to obtain it, leaving the required parameter 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 verb and resource ('Read a project's plan as written') and enumerates exactly what is returned: yearly overviews (goal, now, target, checklist), quarterly milestones, period names. This is clearly distinguishable from get_status (progress/counts) and list_tasks (tasks), so an agent can pick it 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?

Opens with an explicit trigger ('Use it when the user asks for the plan (roadmap, this year's goals, quarter goals)') and then names two alternatives with their conditions ('get_status for progress and the current period, list_tasks for the tasks themselves'). Both when-to-use and when-not-to-use are covered.

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 and does well: it explains what is included in the resume, that closed periods are included, and that recent_done/check are claims to verify. It stops short of explicitly stating read-only behavior, permissions, or side effects, which keeps it from 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 front-loaded with the usage condition and the main value proposition, then details the return payload. It is somewhat long, but the detail is mostly earned because there is no output 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 complex status tool with no output schema, the description does an unusually complete job describing the returned overview, per-period data, open_tasks, and recent_done. The remaining gap is the undocumented required `key` parameter and lack of explicit read-only confirmation.

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 never explains the sole required parameter `key`. The surrounding text implies it identifies a project, but it does not say the expected format or where to obtain it.

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: it returns a project's status/resume snapshot for picking work up cold. It clearly distinguishes itself from list_tasks and get_roadmap, so an agent can identify the right tool without inspecting 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?

It gives explicit when-to-use guidance: call first when starting a project and when the user asks where things stand. It also names alternatives for older/cancelled work and for the plan, and warns not to poll after the initial call.

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?

There are no annotations, so the description carries the behavioral burden. It clearly frames the operation as a read and discloses useful return details such as the record's period and `waiting_on` when applicable, though it does not discuss permissions, rate limits, or not-found 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?

The usage guidance is front-loaded and the description is appropriately short for a one-parameter read tool. There is minor redundancy between the opening usage sentence and the subsequent "Read one task in full by id" sentence, but no significant waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity, one required parameter, no output schema, and no annotations, the description covers purpose, usage, id format, and key return details. It does not fully document the record shape or error behavior, but it is sufficient for an agent to call the tool 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?

With 0% schema description coverage, the description compensates by explaining the id format via the `DLY-042` example and clarifying that the project is derived from the prefix, so no separate project key is needed. It could be slightly more explicit that the single required parameter is `task_id`, but the semantics are clear.

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: "Read one task in full by id" and "get the whole record (task details)." It also distinguishes this tool from siblings by naming list_tasks and search_tasks and the conditions that separate them.

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 states when to use the tool: "when you know a task id and need the whole record." It also names alternatives: use list_tasks when you already know the id is not the need, and search_tasks when you only know a word from 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?

No annotations are provided, so the description carries the full burden. It discloses the return format ('the whole guide as Markdown text') and calls all other tools 'working tools' for data access, which implies that this tool only reads information. It doesn't explicitly say there are no side effects or that the output is large, which would help an agent decide whether to read the full output.

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 main purpose is stated first, followed by the return format, and then the guidance on alternatives, which is separated for clarity. Every sentence adds useful information, and no sentence 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?

No output schema exists, so the description must explain what is returned, and it does so by saying the return value is the whole guide as Markdown text. Combined with the usage guidance and the explicit routing to sibling tools, the description is nearly complete; only the size or structure of the guide 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?

The tool has no parameters, so there is no risk of misuse. The 100% schema coverage is trivially satisfied by an empty object, so there are no parameter semantics to add.

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: it answers questions about FronyBoard itself (what it is for, which tool to call when, how sessions work). This is clearly different from the working tools listed. It falls short of 5 only because 'help' is still a broad label and the description doesn't quite pin down the scope of the guide.

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 usage rule ('read it once before your first other call in a conversation') and explicitly states a use case to avoid: for reading or changing recorded data, call get_status, create_task, transition_task, list_tasks, or search_tasks instead. Both when to use it and when to use alternatives are stated outright.

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 behavioral burden well: it discloses returned fields, archived filtering, summary contents, and explicitly excludes milestones and task detail. It does not mention pagination, ordering, or access constraints, but for a read-only listing tool the core behavior is clearly described.

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 the usage condition, then the listing behavior and parameter effect, then return-value details and sibling guidance. Each sentence adds distinct information, and the structure makes it easy to scan without unnecessary 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?

Given there is no output schema and only one parameter, the description is complete: it explains what is returned, what summary data accompanies each project, what is excluded, and when to use sibling tools instead. An agent can invoke and interpret this tool correctly from the description alone.

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 0% description coverage, so the description must explain the only parameter. It does so directly: archived projects are omitted unless include_archived is set, which gives the parameter clear semantic meaning beyond the schema's bare boolean title.

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 every project') and explicitly states the user scenario it serves: when the user asks which projects are tracked. It also distinguishes the tool from siblings by saying it returns project identity fields and summary counts rather than roadmaps or task detail.

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 says when to use it ('when the user asks which projects are tracked') and names alternatives for adjacent needs: get_roadmap for the plan, get_status for per-period progress, and list_tasks for tasks. It also clarifies archived-project behavior via the include_archived parameter.

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 carries the full burden and does well: it discloses the default that cancelled tasks are excluded unless include_cancelled is set or status='cancelled', that omitting period includes closed periods, and that rows carry `waiting_on` only when non-empty. It does not state read-only/safety or result size/ordering limits, which keeps it short of a 5 for an unannotated 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?

Front-loaded with intent, then routing, then parameter semantics – a logical order with dense, non-repetitive sentences. It is longer than strictly necessary (the tags union advice sits in the same block as core semantics), but no sentence is 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 six-parameter filtered-list tool with no annotations and no output schema, the description covers triggering intent, alternatives, every parameter's format and filter interaction, default exclusion behavior, and the one non-obvious output field (`waiting_on`). Nothing needed to call 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 description coverage is 0%, yet the description documents every parameter: `period` as YYYYQn with omitted-means-all-periods semantics, `status` with its full enum (todo | in_progress | done | blocked | cancelled), `tags` AND-semantics plus the per-tag union advice, `updated_since` accepting durations like '24h'/'7d' or ISO timestamps, and `include_cancelled` interacting with status. This more than compensates for the empty 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 the specific verb and resource ('List one project's tasks') plus its narrowing dimensions, and explicitly distinguishes itself from get_status ('already lists the open ones'), get_task (by id) and search_tasks (cross-project text). An agent can route correctly without opening any 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 opening sentence gives the triggering user intent ('finished, cancelled or tagged work, or a past quarter's'), and the alternatives section names when to use get_status, get_task and search_tasks instead. Both when-to-use and when-not-to-use are explicit.

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 usefully discloses that no milestone is needed and that a planned milestone flips to active, but it does not cover permissions, idempotency, or what happens if the period is already open.

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 constraint is front-loaded and understandable, but the first and second sentences repeat the same 'other than the current quarter' and 'create_task opens current quarter' points. It could be tightened without losing meaning.

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 explains the operation and its quarter-scoping well enough for the period parameter. However, because no output schema or annotations exist and the required key parameter is undocumented, an agent still lacks key invocation context.

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 document both parameters. It explains the period format and meaning with an example, but the required key parameter is not described at all, leaving a critical 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 states a specific verb and resource (open a quarter's period) and clearly scopes it to quarters other than the current one. It distinguishes the tool from create_task by explaining that create_task opens the current quarter automatically.

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 gives explicit when-to-use guidance: only for filing work under another quarter, with a concrete format example. It also names the alternative behavior of create_task, making the selection between the two clear.

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 so: newest-first ordering, the exact returned fields, `ok: false` semantics for rejected calls, the fact that read-only calls are dropped unless writes_only=False, and that task records keep only timestamps. Defaults for since/limit are stated outright.

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-loaded with the usage trigger, then return shape, then parameter semantics — every sentence adds information. The middle block is dense and mixes return-field documentation with parameter documentation, and the unexplained `count` reference costs a point.

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?

No output schema exists, and the description fully documents the return shape, field meanings, ordering, and the write-filtering behavior. Nothing an agent needs in order to call and interpret this tool 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%, so the description must compensate, and it does: `since` accepts a duration ('24h' default, '7d', '90m') or an ISO timestamp, `key` narrows to one project, `limit` caps rows (default 50), and `writes_only=False` restores read-only calls. Only the stray mention of `count` (which is not a declared parameter) introduces minor ambiguity.

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?

Names a specific resource (the call log in tools.jsonl) and what it answers: what changed recently and who did it. It explicitly distinguishes itself from task records ('task records themselves keep only timestamps'), so an agent can tell this apart from get_task/list_tasks in the sibling 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?

'Use it when the user asks what changed recently or who did it' gives a clear triggering condition, and 'This is the mutation history' clarifies the boundary against task-record tools. It stops short of naming an explicit alternative or a when-not-to-use case, so a 4 rather than 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 carries the full burden and does so well: it discloses the matching rules (case-insensitive substring over project key, task id, title, content; excludes branch/tags), the project-key shortcut, inclusion of closed periods, cancelled-task gating, result ordering, the `match` field and compact hit shape. This is unusually rich behavioral disclosure for a search 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 front-loaded with the use case, then moves to matching semantics, inclusion rules, and result shape in a logical order. It is dense but every clause carries information; only the long parenthetical matching sentence is slightly overloaded.

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 search tool with no output schema and no annotations, it covers the essential behavior: matching, ordering, returned fields (`match`, `content`, `count`), and follow-up guidance. It omits permissions/auth expectations and error or empty-result behavior, which are minor for a read search.

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%, so the description must compensate, and it largely does: it explains `query` as text search, `key` as a project narrowing filter, `limit` (default 20) as a hit cap, `include_cancelled`, and `status='cancelled'`. The `status` parameter's full accepted value set is only implied by the ordering list, so a small gap remains.

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 — find tasks by text — and frames the exact user situation ('remembers a word from a task but not its id or project'). It clearly distinguishes itself from get_task, which it names as the follow-up for full records.

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 gives a concrete trigger ('when the user remembers a word from a task but not its id or project') and routes to get_task for full details. It does not explicitly contrast with list_tasks or state when a plain listing is preferable, which keeps it from 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?

No annotations exist, so the description carries the full burden. It usefully discloses that the tool returns the updated overview and that 'done' is the new state, but says nothing about permissions, idempotency, or what happens with an out-of-range index.

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-loaded with the usage condition, then the mechanics, then the alternative. Minor redundancy: 'tick off a checklist item' in parentheses restates the preceding clause.

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-annotation mutation tool with no output schema and 0% schema coverage, key gaps remain: the 'key' parameter is undefined and no failure modes are described. The reference to get_roadmap's checklist for index derivation is a helpful compensating 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 coverage is 0%, so the description must compensate. It explains 'index' (0-based position in get_roadmap's checklist) and 'done' (new state) well, but leaves 'key' completely undocumented and 'year' only implied by 'a year's checklist.'

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: 'tick or untick one item of a year's overview checklist.' It also explicitly contrasts with set_overview for add/remove/reword, so an agent can distinguish it from siblings without opening 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?

Gives both the trigger condition ('when one item of the year's checklist is done or undone') and the exclusion with a named alternative ('To add, remove or reword items use set_overview'). This is explicit when/when-not 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?

With no annotations, the description carries the behavioral burden and does disclose the key destructive trait: calling it again replaces the whole overview, so the checklist must be resent to keep it. It also notes the prerequisite for upsert_milestone, but it does not describe authentication needs or the response/error 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?

The description is front-loaded with the usage trigger, then supplies the replacement semantics and parameter formats. Every sentence adds actionable information, and the formatting makes the key warnings easy to scan.

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 six parameters, no annotations, and no output schema, the description covers purpose, alternatives, destructive replacement behavior, prerequisite ordering, and most parameter formats. The unexplained required `key` parameter and absent return-value context are the remaining 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%, so the description must compensate. It explains year as YYYY, goal as the one-line yearly goal, now and target as one short line each, and checklist as strings or {text, done} maps in display order — but it never explains the required `key` parameter.

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: create or replace a year's overview with goal, now, target, and checklist. It explicitly distinguishes this from sibling tools by saying quarterly goals belong in upsert_milestone and single checklist ticks belong in set_check.

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 gives an explicit trigger — when the user sets or rewrites a year's plan — and names the alternatives for adjacent operations: set_check for ticking one item and upsert_milestone for quarterly goals. It also states the prerequisite that a year needs an overview before upsert_milestone can add a quarter.

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: it discloses that the server stamps started_at/completed_at, that cancelled is a soft delete whose record is kept but hidden from queries, that reason is mandatory for cancellation, and that transitioning a cancelled task restores it. These are exactly the non-obvious side effects an agent needs.

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?

Well front-loaded — the when-to-use and status list come first, then parameter guidance, then the two status-specific rules. It is a bit long, and the check paragraph leans on motivational prose ('all that is left is your word') that restates the same constraint twice, costing a point.

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?

No annotations, no output schema, and six parameters — the description still covers the status set, the auto-stamped timestamps, the soft-delete and restore lifecycle, the check requirement and where the check surfaces (get_status). Nothing an agent needs to invoke this correctly is left to guesswork.

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 there are 6 parameters, yet the description explains each: task_id format (DLY-042) with project derived from the prefix, why key is usually omissible and must match if supplied, the 300-character one-line contract for check, and branch. Critically, the enum of valid statuses exists nowhere in the schema and is only supplied here.

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 ('move a task to a new status') and enumerates the five valid statuses. It explicitly carves itself out from siblings: 'The only tool that changes status — title, content and tags are update_task,' so an agent can route without opening another 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?

Gives explicit triggering events ('when work starts, finishes, stalls or is dropped') and names alternatives (update_task for other fields, set_check, get_status). It also resolves the hardest ambiguity in this domain: 'Use blocked for work that may resume, cancelled for work that will not happen.'

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 so: it explains the key (and task id prefix) is immutable, that paused only changes a badge, that archived hides the project from list_projects and blocks every other mutation until reverted, and that there is no hard delete — exactly the side-effect details an agent needs.

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-loaded with the usage trigger, then the constraint, then per-field semantics. Short declarative sentences, no filler, and the most consequential fact (archived blocks mutations) is stated plainly.

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 five-parameter mutation tool with no annotations and no output schema, this covers triggers, preconditions, field semantics and irreversibility. The only real omission is what repo accepts or how it is validated.

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%, so the description must compensate and largely does: it enumerates the permissible status values with their semantics, marks key as immutable, and points name/description at create_project's language rule. The repo parameter is only listed, never explained, leaving one 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 ('Update a project's own fields') and immediately bounds the scope by naming what it does not touch (roadmap, periods, tasks), which separates it from update_task, upsert_milestone and set_overview.

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 opening sentence gives concrete triggers: renames, re-describes, pauses or archives. It also enforces a precondition ('pass at least one of name, description, repo, status'). It stops short of naming an alternative tool for cases like hard removal, though it does say no hard delete exists.

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 exist, so the description carries the full burden and does so: list fields replace wholesale rather than append, omitted fields are preserved, empty values remove optional fields, title cannot be removed, and `check` is only accepted on an already-done task. These are exactly the mutation semantics that cause silent data loss if unknown.

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-loaded with the trigger and the scope exclusion in the first two lines, then grouped by concern (replace semantics, empty-value removal, id format). Slightly long and repeats the create_task content rule, but every sentence carries information an agent needs to avoid corrupting data.

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 an eight-parameter mutation tool with no annotations and no output schema, this covers inputs thoroughly. The remaining gap is the return side – it never says whether the call returns the updated task or how failures (unknown id, mismatched key, check on an unfinished task) surface.

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 compensates for all eight parameters: branch, content (with length/one-line constraint), check, tags, depends_on, title, and both task_id/key including the DLY-042 prefix format and the derive-project-from-prefix rule that makes `key` optional.

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 (update) and resource (a task's fields) and immediately scopes it: 'everything except status, which is transition_task.' An agent can distinguish this from transition_task and create_task without opening any 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?

Opens with an explicit trigger ('Use it when a task's title, note, branch, tags or links change') and names the excluded case with the correct alternative (status goes to transition_task). It also defers to create_task for the shared one-line/300-char content rule, giving an implicit routing map.

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 load and does well: it discloses upsert semantics ('Omitted fields keep their current value'), the status lifecycle and automatic transitions (opening the period flips planned to active, close_period sets done, new milestones in an open quarter start active), and a validation rule (a new milestone needs a goal). It says nothing about permissions or failure modes when the year overview is missing, which is the remaining 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?

Front-loaded with the when-to-use sentence followed by the one-line definition, then parameter detail — a sensible order. There is mild redundancy between the trigger sentence and 'Create or update a quarterly milestone', but the status-lifecycle parenthetical is dense, useful information rather than 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?

For a 5-parameter mutation tool with no annotations and no output schema, the description covers nearly everything an agent needs: intent, upsert defaults, lifecycle side effects, and most parameter formats. The unexplained required `key` parameter is the one substantive hole.

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 largely does: it defines year format (YYYY with an existing overview), quarter values (Q1-Q4), goal format (one line, user's language, required for creation) and the status enum (planned | active | done) with its transition rules. However, the required `key` parameter is never explained, leaving an agent to guess its meaning and format.

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 — 'Create or update a quarterly milestone — a year's goal for one quarter' — and the leading trigger sentence anchors it to the user intent ('sets or changes a quarter's goal'). It is clearly distinguishable from siblings like open_period and close_period, which only affect the milestone's status.

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 usage trigger ('when the user sets or changes a quarter's goal') plus a when-not/optionality note ('A milestone is optional — tasks never need one') and a prerequisite ('its overview must exist'). It stops short of naming an alternative tool for the goal-setting case, but no sibling actually competes for that job.

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 that the tool returns errors and warnings, that it is a non-writing check, and that its logic is duplicated inside every mutation's write gate. It does not describe the shape or severity of the errors/warnings or whether the check has side effects on the store, leaving a modest 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 core content is well front-loaded, but the instruction 'use it only after the store was edited outside these tools' appears twice (opening and closing), wasting space, and the parenthetical '(check the data)' is redundant with the main sentence.

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, no-output-schema, no-annotation tool, the description covers purpose, when to use it, and roughly what it returns (errors and warnings). The remaining gap is the meaning/format of 'key' and the exact return structure, which is a minor omission given the tool's simplicity.

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% for the single 'key' parameter, so the description must compensate. It only obliquely implies that key identifies the project ('a project's stored data') without stating format, scope, or whether it accepts an ID versus a slug.

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: checks a project's stored data against the FronyBoard schema and rules, returning errors and warnings. It also distinguishes itself from the sibling mutation tools by explaining that every mutation already runs this same gate. The only gap is that it never ties the 'key' parameter to a project explicitly, though 'a project's stored data' implies it.

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 when-to-use ('only after the store was edited outside these tools') and an explicit when-not ('rarely needed on its own'), naming the alternative behavior (mutations run the same gate and refuse to write). Nothing about tool selection is left to inference.

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