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

With no annotations, the description carries the full burden, and it does disclose one non-obvious trait: memoryRef is a reference only and 'DPC never copies memory prose,' clarifying that no content is duplicated onto the card. However, it says nothing about duplicate handling, ordering, permissions, or what happens when project/title collide, which matters for a mutation tool with zero annotation coverage.

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 purpose, with no filler. The final clause is slightly terse and uses the undefined acronym 'DPC,' which costs a bit of clarity but not length.

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 6-parameter mutation tool with no annotations and no output schema, the description is thin: it never indicates what is returned (e.g., the new card id) or how the default column behaves, relying entirely on the schema for the rest. It is minimally adequate rather than 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 coverage is 100%, with every parameter including note, column defaults, and linkedPR already documented in the schema, so baseline is 3. The description only elaborates on memoryRef's non-copy semantics, adding slight value beyond the schema's own 'opaque memory id or tag' wording.

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 first sentence states a specific verb and resource ('Add a Kanban card'), which is enough to distinguish it from siblings like move_card, update_card, and add_project. It stops short of naming those siblings or explicitly delimiting scope, so it is clear but not fully differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus move_card, update_card, or add_project, and no prerequisites or exclusions are stated. The agent must infer that this is the creation path from the verb 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?

With no annotations, the description must carry the behavioral burden, and it does disclose a useful conditional rule: path is required for coding projects but optional otherwise. It says nothing about what happens on duplicate registration, required permissions, or what the call returns.

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 core action, then constraints, then the alternative routing. Every sentence earns its place with no 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 simple create tool with no output schema and no annotations, the description covers the action, the key conditional constraint, and the preferred alternative. Minor gaps remain around duplicate handling and return behavior, but nothing essential for correct invocation 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 100%, so the baseline is 3, but the description adds meaning the schema lacks: the path field is labeled merely 'Optional folder path' in the schema while the description makes it conditionally required for coding projects. The kind field's enumeration and the name field's role are left entirely to the 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 ('Manually register a project') and immediately distinguishes this tool from the sibling register_from_workspace, so an agent can tell them apart without reading either 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 gives clear routing guidance ('Prefer register_from_workspace when an agent is already in a repo') and conditional usage ('Path is optional for non-coding work. Coding projects need a folder'). It does not address edge cases such as duplicate names or when to use it versus list_projects, so it falls just short of fully explicit when/when-not coverage.

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 disclose that the tool may create a project if none exists and that the reply labels the result as new or existing. However, it omits permissions, matching logic, side effects, and what 'no path' means.

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 two short sentences with no wasted text and the find-or-create behavior is front-loaded. The phrase 'with no path' is slightly unclear but does not undermine the overall concision.

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

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

For a find-or-create mutation with no annotations and no output schema, the description is too thin. It does not explain what is being filed, how matching works, or the full return shape beyond the 'Filed under new/existing project' label.

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%, so the schema already documents all three parameters. The description adds no parameter-level meaning beyond the schema, which is the baseline case for full coverage.

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 find-or-create action for non-coding projects, but it never says what is being filed under the project. The name implies assignment, yet the object of the assignment is missing, so the purpose is only partially clear.

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 implies use when you need to find or create a project, but gives no explicit when-to-use guidance versus siblings like add_project or list_projects. There are no exclusions or alternative-selection rules.

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 full behavioral burden. It mentions scores and event counts but does not disclose aggregation behavior, output shape, read-only safety, or any other operational trait an agent would need before invoking 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 short and front-loads the resource and output hints. The three fragments are efficient, though the final guidance sentence is slightly disconnected from the preceding output summary.

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 simple one-parameter read tool with no output schema, the description gives a minimal but adequate picture. It still leaves the return format and aggregation behavior implicit, which is a noticeable gap given the absence of annotations.

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 single parameter has 100% schema description coverage, so the schema already explains 'days'. The description adds only 'recent days', which is consistent but does not extend parameter meaning beyond the 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 identifies the resource as an activity heat map for recent days and mentions it returns scores and event counts. However, it is a noun phrase rather than a specific action verb, and the scope is only loosely defined ('recent days').

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 says 'Prefer get_desk_summary first', which gives a useful ordering hint and names a sibling. But it does not explain when this tool should be used instead of get_desk_summary or other analysis tools, nor does it state 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, the description carries the full burden and does disclose the most important behavioral surprise: done cards older than the archive window are silently excluded from the list, yet the archived count is still reported, and includeArchived overrides the omission. It also caps output expectations under 800 tokens. It does not state read-only semantics or error behavior, but the truncation/filtering disclosure is substantive.

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?

Five short sentences, front-loaded with the call-priority instruction, and nothing is padding. The clipped fragments ('Compact desk under 800 tokens') are slightly telegraphic, but every sentence carries a distinct instruction.

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, no-output-schema, no-annotation tool this is mostly adequate: size budget, archive filtering, and sibling routing are all covered. It never says what sections the summary actually returns (projects? card counts? statuses?), which is the main remaining gap for a summarization 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 100% and includeArchived already has a clear schema description, so the schema does the heavy lifting. The description reinforces it with the consequence (archived cards will be listed) and the reason to use it (the count already reveals their existence), which is modest added value over the schema. Baseline 3 applies.

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 establishes that this returns a compact/bounded summary of the desk and routes the agent away from list_projects for shallow needs. The verb is implicit rather than stated ('Compact desk under 800 tokens'), and it never enumerates what the summary contains, but an agent can tell it apart from siblings like get_project_status or search_desk.

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 this first' gives an explicit default-entry-point instruction, and 'Skip list_projects unless the user asks for a deep dive' names the alternative plus the exact condition that selects it. This is exactly the when/when-not/alternative structure the dimension rewards.

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 reveals the return shape (scores, factors, recommendations) but says nothing about computation cost, latency, freshness of data, or scope of projects covered — meaningful gaps 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?

Two short sentences with no filler, and the output shape is front-loaded. It is slightly too clipped — the lack of a verb or scope makes the first sentence read as a fragment rather than a definition.

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

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

With no annotations, no output schema, and no parameters, the description is the only source of context, and it supplies the return contents but not the scope of what is scored or how the score is derived. Adequate to call, but thin for a health-metric 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?

The tool takes zero parameters and the schema is an empty object, so there is nothing to document; per the baseline for 0-param tools this scores a 4. The description adds no parameter information, but none is needed.

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 fragment '0-100 health scores with factors and recommendations' conveys the resource and its payload, but never states a verb or scope (one project vs. all projects). It does partially distinguish itself by naming get_desk_summary as the preferred sibling, which helps an agent place 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?

'Prefer get_desk_summary and the Analytics tab' names alternatives, which is more than most tools do, but gives no positive condition for when this tool is the right call. The agent is told what not to use rather than when to use this.

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 meaningful behavior: archived done cards are omitted from the card list, the archived count is still reported, and includeArchived changes that. It does not explicitly state that the operation is read-only, nor does it mention permissions, side effects, or response shape.

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 short and front-loaded: purpose first, then archived-card behavior, then the includeArchived escape hatch, then sibling routing. Every sentence contributes useful information without 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 two-parameter read tool with full schema coverage, the description provides enough context to select and invoke it: it states the returned content at a high level, explains archived-card filtering, and points to the summary tool first. It lacks a detailed return shape, but no output schema exists and the high-level return description is adequate for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are already documented. The description adds useful meaning for includeArchived by explaining that archived done cards are omitted by default but still counted. It does not add anything beyond the schema for projectName.

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 identifies the resource and scope: full detail for one project, including notes and cards. It also distinguishes itself from the sibling summary tool by saying to prefer get_desk_summary first. The only slight weakness is that it does not use an explicit retrieval verb and the tool name says 'status' while the description promises broader 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 gives one useful routing hint: 'Prefer get_desk_summary first.' However, it does not specify the exact conditions for choosing this tool over get_desk_summary or other siblings, nor does it state when not to use it. The includeArchived note is parameter guidance rather than tool-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?

No annotations are provided, so the description must carry the behavioral burden. It implies a read operation through the name and 'timeline' phrasing, but it does not explicitly confirm read-only behavior, permissions, pagination, or return format.

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 two short, front-loaded sentences with no wasted wording. The purpose comes first, followed by a direct usage preference.

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 simple one-parameter tool with no output schema and no annotations, the description is minimally adequate. It omits return-value context and sibling differentiation that would help an agent invoke it confidently.

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 with 100% schema description coverage, so the schema fully documents projectName. The description adds only 'for one project,' which confirms scope but adds no syntax or format meaning beyond the 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 states a clear resource and scope: a status timeline for one project. However, it does not explicitly distinguish this timeline tool from the sibling get_project_status tool, leaving overlap 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?

It gives a routing hint by saying to prefer get_desk_summary first, but it does not explain when to use this tool instead of get_project_status or what conditions make the timeline appropriate.

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 bears the full behavioral burden. It lists returned data categories but does not disclose whether the operation is read-only, what scope or time range applies, whether results are cached or aggregated, or any authentication/rate-limit considerations.

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 two short sentences with no waste. The main content is front-loaded, and the routing hint follows as a secondary instruction.

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

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

With no input parameters, no output schema, and no annotations, the description must carry more context. It identifies the general data returned but leaves significant gaps around time range, project scope, aggregation level, and result format.

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, which sets the baseline at 4 per the rubric. There are no parameter semantics to clarify, and the description does not need to compensate for an incomplete 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 clearly identifies the resource dimensions the tool returns: framework usage, emerging tags, and adoption timeline for coding projects. It does not explicitly contrast its scope with every sibling, but its focus on technology trends is distinct from tools like get_project_status or list_projects.

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 routes the agent to get_desk_summary as a preferred first step, which is useful sequencing guidance. However, it does not state when this tool should be used instead of that summary or other siblings once the summary has been consulted.

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 of behavioral disclosure, and it says almost nothing. It does not reveal how many projects might be returned, whether results are paginated, whether the response is expensive or slow, or what fields each roster entry contains. The word "Full" hints at unbounded volume but never confirms or bounds 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?

Three short sentences with no filler, and the routing advice is front-loaded after the one-line purpose. It is arguably over-compressed: the terse fragments leave real gaps rather than trimming redundancy.

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

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

With no parameters and no output schema, the description is the only place an agent can learn what a "project roster" entry looks like or what "deep dive" yields. It establishes routing but not the shape, size, or cost of the result, which is the main remaining question for a bulk-list 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?

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to clarify, and it correctly presents this as an argument-free call.

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?

"Full project roster" names the resource and implies a complete listing, but there is no explicit verb and the phrase is a fragment rather than a stated action. It partially distinguishes itself from get_desk_summary by positioning this as the exhaustive variant, yet an agent must infer that this returns all projects.

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?

"Prefer get_desk_summary first. Use this for a deep dive only" explicitly names the sibling alternative and sets a clear ordering: start with the summary, escalate here. What is missing is any criterion for what makes a deep dive warranted (e.g., needing every project's metadata vs. an overview).

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-disclosure burden. It mentions that cards move to the target, but it does not say whether the source project is deleted or archived, whether the merge is irreversible, or what permissions are required.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences are front-loaded and contain no wasted text. The purpose comes first, followed by the key side effect.

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 simple two-parameter mutation, the description covers the core action and card movement. It still leaves out important operational context, such as the fate of the source project and irreversibility, with no annotations or output schema to fill those 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 100%, so the parameter meanings are already documented in the input schema. The description reinforces the source-to-target flow but adds no format or constraint details beyond the schema's "absorb" and "keep" wording.

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: "Merge a duplicate project into another." It also clarifies the outcome, "Cards move to the target," which makes the operation distinct from siblings such as rename_project or update_project_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?

It gives a clear use case: merging a duplicate project. However, it does not explicitly state when not to use it, whether the operation is reversible, or what alternatives exist for non-duplicate cleanup.

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 two important side effects: moving a card regenerates the desk page, and leaving 'done' unarchives the card. It does not cover permissions, error conditions, or return behavior, but the key non-obvious behaviors are surfaced.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two tight sentences with the core action front-loaded and a valuable caveat second. There is no redundant or filler 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 simple mutation tool with a fully described schema and no output schema, the description covers the purpose and key side effects. It does not explain return value or edge-case handling, but it is largely sufficient 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%, so the parameters are already well documented in the schema. The description reinforces the meaning of 'column' but adds no details beyond what the schema provides for id, note, or column.

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: moving a card to another column. It clearly differentiates the operation from generic card updates, though it does not explicitly name or contrast sibling tools like update_card.

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 purpose, and the note about leaving 'done' provides a useful caveat. However, it does not explicitly say when to use this tool versus update_card or other alternatives, nor does it state 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?

No annotations are provided, so the description carries the full burden for a mutating tool. It discloses that it writes a fixed file and opens it, but does not state whether it overwrites an existing file, what content is written, what permissions are needed, 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?

The description is two short sentences with no filler, and the main action is front-loaded. It could be slightly clearer about whether 'open' is a side effect after writing, but it is efficiently structured.

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 tool with no annotations, no output schema, and a mutating file-write behavior, the description omits important context: overwrite behavior, content source, error conditions, and prerequisites. The zero-parameter schema simplifies the call, but the behavioral gaps remain significant.

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 are no parameter semantics for the description to clarify. The baseline score of 4 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 names specific actions and a concrete resource: writing KnowledgeBase/desk/index.html, returning its path, and opening the file from disk. This is clearer than a vague 'open desk' description, though it does not distinguish the tool from siblings such as start_desk_server or get_desk_summary.

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 provides no guidance on when to use this tool versus alternatives like start_desk_server, get_desk_summary, or search_desk. The agent must infer the context entirely.

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; it does disclose meaningful behavior — 'Silently' (no user-facing notification), upsert semantics ('register or update'), and the negative guarantee 'Never creates folders.' It stops short of saying what happens on conflicts, what permissions are needed, or what 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 short sentences, both front-loaded with the operation and the key safety constraint. No filler and nothing that could be cut without losing information.

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

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

There is no output schema and no annotations, so the description is the only behavioral source; it covers purpose and one side-effect boundary but omits the outcome of the call, error behavior, and how 'update' merges with existing project data. Adequate but with clear gaps for a 4-parameter mutation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all four parameters, making 3 the baseline. The description adds only the mapping that cwd/gitRemote are auto-derived from the workspace, with no extra detail on branch or openPR semantics.

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 ('register or update') and resource ('a coding project') plus the source of the data (working directory and git remote). It implicitly differentiates from add_project by being workspace-derived rather than manually specified, but it never names that sibling, so an agent must infer the distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'from the agent's working directory and git remote' implies the context in which this applies, and 'Never creates folders' is a useful exclusion. However, there is no explicit guidance on when to prefer this over add_project or update_project_status, and no stated prerequisites.

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 it does disclose a real side effect: cards in the column follow the new name. It does not state what happens if 'from' doesn't exist, whether renaming is reversible, whether names must be unique, or what permissions are required for this mutation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, zero waste, with the core action front-loaded and the side effect immediately after. Nothing redundant is included.

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 mutation with no annotations and no output schema, the description covers the action and its cascade effect but omits failure modes, idempotency, and permission context. Adequate but with clear gaps for a write operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% — 'from' is documented as 'Current column name' and 'to' as 'New column name' — so the description adds no parameter meaning beyond the schema. Baseline 3 applies.

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 ('Rename a Kanban column'), which is clearly distinct from card-level siblings like move_card and update_card. It does not explicitly contrast itself with update_card or update_project_status, but the object of the operation leaves little 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?

The description never says when to use this versus update_card or move_card, nor does it state prerequisites (does the column need to exist, must names be unique?). The second sentence is behavioral, not usage guidance, so an agent gets no routing help.

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 does not say whether renaming is reversible, what happens if `from` does not match an existing project, whether other references to the project break, or whether permissions are required — significant 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?

It is short and front-loaded with the action, but the second half ("after a wrong guess") is speculative framing that consumes space without informing invocation.

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 mutation with no annotations and no output schema, the definition should state failure behavior and side effects. Neither is covered, leaving the agent unable to predict outcomes.

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% (both `from` and `to` are documented as current/new name), so the baseline is 3. The description adds no additional meaning about naming constraints, uniqueness, or case sensitivity.

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 verb+resource ("Rename a project") is identifiable, but the trailing clause "after a wrong guess" is cryptic and reframes the tool as an error-correction action rather than a general rename. It does not distinguish it from siblings like rename_column or merge_projects, which are the nearest alternatives.

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?

"After a wrong guess" loosely implies a corrective scenario but gives no explicit when-to-use or when-not-to-use guidance, and never mentions the adjacent alternatives (rename_column for columns, merge_projects for consolidation).

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 does disclose the critical trait that this tool is deprecated. However, it doesn't say what actually happens on invocation – whether it still executes, transparently redirects, or errors out – nor whether results may be stale or the endpoint will be removed.

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 deprecation warning and the preferred alternative. Every clause carries directive value and 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 one-parameter deprecated alias, the description covers the essentials: it's deprecated, what to use instead, and what to run first. The one residual gap is whether calling it still works – minor, but relevant if an agent encounters it in an older workflow.

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 a single parameter at 100% schema description coverage, the schema already documents 'pattern' as the keyword to search for, so baseline 3 applies. The description adds nothing about the parameter – notably, since this aliases search_desk, it's unclear whether 'pattern' is interpreted as a code pattern or a plain keyword.

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 identifies the tool as a deprecated alias of search_desk, which lets an agent place it relative to siblings without opening either schema. It stops short of stating the actual operation (what is searched or what a 'desk' is), deferring that entirely to the target tool's own definition.

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 instructs 'Prefer search_desk' and names the prerequisite 'Use get_desk_summary first' – an alternative, an exclusion, and a sequencing rule in one line. An agent needs no inference to decide what to do.

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 archived done cards are included and marked archived, which is a meaningful result-set trait, but it does not describe result limits, matching behavior, or return structure.

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, front-loaded sentences with no filler. Each sentence contributes either scope, behavioral context, or usage ordering.

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 search tool with no output schema and no annotations, this covers the essentials: what is searched, archived behavior, and a preferred ordering. It could be more complete by clarifying matching semantics, such as substring versus pattern matching.

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 lone 'pattern' parameter is already documented. The description still adds meaning by specifying the content types the pattern applies to: notes, card titles, kinds, and KnowledgeBase markdown.

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, 'Search', and enumerates the searchable resources: notes, card titles, kinds, and KnowledgeBase markdown. It is clear what the tool does, though it does not explicitly distinguish itself from the sibling search_code_patterns 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?

It includes a useful sequencing instruction: 'Prefer get_desk_summary first,' which tells the agent when this tool should be considered. However, it does not explicitly state when to use this instead of search_code_patterns or other search-like siblings.

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 substantial work: it discloses the loopback-only binding, the default port, that the bookmark URL carries no token, that the sign-in URL is single-use and expires in 10 minutes, that re-calling does not rotate the write token, and the 0600 token file mode. Gaps remain around server lifecycle (how to stop it, whether it survives the session) and failure 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?

Four short sentences, front-loaded with the core fact (what the server is and where it binds), then return values, then re-call semantics. 'Token file mode 0600' is terse to the point of being cryptic, a minor deduction.

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 compensates by describing exactly what is returned (bookmark URL plus one-time sign-in URL) and their lifetimes. For a zero-required-parameter tool this is nearly sufficient; only lifecycle and shutdown behavior are absent.

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% for the single optional parameter, so the baseline would be 3. The description adds value beyond the schema by describing the default path — calling again without rotate mints a fresh sign-in code while preserving the write token — which clarifies what the parameter actually changes.

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 — an opt-in localhost Kanban server bound to 127.0.0.1 on a fixed port — so an agent immediately knows what is being started. It does not name the closely related sibling (open_desk) or state how it differs, which keeps it from 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?

'Opt-in' and 'Static index.html still works without it' imply this is an optional enhancement rather than a required step, and 'Calling again while running mints a new sign-in code' implies repeat calls are safe. However, there is no explicit statement of when to call this versus open_desk, nor of any prerequisites, so usage 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 burden, and it does disclose one genuinely non-obvious side effect: editing an archived card returns it to the board. That is valuable. However, it omits permissions, whether unspecified fields are preserved (only implied by the note param), error behavior, and how the 'done'/updated refresh interacts with the update.

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 first sentence is well front-loaded. The second sentence is compressed to the point of ambiguity ('Leaving done, or any edit that refreshes updated'), making a real behavioral rule hard to parse.

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 partially compensates by disclosing the unarchive side effect, but it lacks usage boundaries against move_card/add_card and leaves the phantom 'done' reference unexplained. It is adequate but with 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 100%, so each parameter is already documented in the schema, giving a baseline of 3. The description restates three of the five fields but adds no syntax, format, or constraint detail, and it mentions a 'done' concept absent from the schema, which adds confusion rather than meaning.

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 card') and enumerates the mutable fields (title, column, memoryRef), which lets an agent distinguish it from read-only siblings like get_desk_summary. It does not differentiate itself from move_card or rename_column, which also manipulate columns, so the boundary is blurred.

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 use this versus alternatives, despite siblings move_card and add_card covering adjacent operations. The phrase about 'leaving done' hints at a condition but is not explained, and it references a 'done' field that does not exist in the input schema, leaving the agent to guess.

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 behavioral burden. It says the tool updates status or notes but does not disclose permissions, reversibility, whether omitted fields are preserved, or any side effects of the mutation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the action and followed by a useful routing hint. There is no wasted 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?

The schema fully covers the parameters and the description gives enough to invoke the tool. However, for a mutation tool with no annotations and no output schema, it should explain the effect of the update more fully, such as whether notes replace existing content and what status values are acceptable.

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%, so all three parameters are already documented in the schema. The description adds only the high-level idea that status and notes are updatable, not any syntax or meaning beyond what the schema 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 uses a clear verb+resource ("Update status or notes for a project") and names the mutable fields. It does not explicitly distinguish this tool from siblings like get_project_status or update_card, so it falls 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?

It gives a concrete prerequisite/alternative: "Prefer get_desk_summary first." That is clear context for when to use this tool, though it does not state when not to use it or name other alternatives.

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