A task board for daily standups: columns, due dates, priorities, weekly review.
Scored across 17 tools
Most tools map cleanly to distinct actions, but a few pairs overlap: board vs project_list both surface board-level rollups, task_list vs task_search both find tasks, and task_done vs task_move both result in done-column completion. The descriptions resolve the boundaries well enough for an agent.
There is a strong resource_action convention in task_*, project_*, and license_*, but board, overdue, weekly_review, and columns_set break the pattern. Names are still all lowercase snake_case and readable, so this is a minor deviation rather than a chaotic mix.
17 tools is slightly above the 3-15 sweet spot, but the surface covers boards, tasks, columns, time logging, licensing, and a weekly review, so the count is not inflated. A few utility functions such as license_activate and task_start_timer are peripheral, but they support real workflows.
The task lifecycle is well covered: add, list, update, search, move, done, delete, log time, and timer handoff. The main gaps are minor: there is no explicit board creation or rename operation, and no standalone task get by id.
Show one board column by column: tasks, estimate, actual and overdue count in each, then the board totals and the estimate still open. Defaults to your busiest board. Use project_list for every board.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Which board; defaults to your busiest one |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no safety profile (readOnlyHint, idempotentHint, destructiveHint are all false), so the description carries the burden. It discloses the output contents, the column-by-column format, and the default board selection. It does not explicitly discuss side effects or error behavior, but its 'Show' framing describes a presentation 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?
Two tight sentences cover the action, the output layout, the default, and the sibling alternative. There is no filler, and the most important behavioral information is front-loaded in the first 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 simple tool with one optional parameter and no output schema, the description covers what is shown, the output arrangement, the default, and the routing to project_list. Minor ambiguity around phrases like 'estimate still open' and what exactly counts as overdue keeps 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?
The input schema already documents the only parameter, project, including the fact that it defaults to the busiest board. The description repeats that default but adds no new parameter-level meaning, so with 100% schema coverage the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Show'), a specific resource ('one board'), and the exact output structure (columns with tasks, estimate, actual, overdue counts, totals, and estimate still open). It also distinguishes itself from project_list by saying that project_list is the way to get every board.
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 the default behavior when no board is chosen ('Defaults to your busiest board') and gives a clear alternative for a different need ('Use project_list for every board'). This is concrete when-to-use versus when-to-use-something-else guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace one board's columns, in order, with 2 to 12 unique names. Tasks in a removed column move to the FIRST column. Blanks are dropped first, so a list normalising below two names is refused. Pro.
| Name | Required | Description | Default |
|---|---|---|---|
| columns | Yes | The new column names in order, at most 12, e.g. ['inbox','next','doing','done'] | |
| project | Yes | Which board |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate this is a non-read-only, non-idempotent operation. The description adds meaningful behavioral details beyond those annotations: tasks in removed columns move to the FIRST column, blanks are dropped first, and lists normalizing below two names are refused. This gives an agent a solid sense of side effects without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded: the primary purpose and constraints appear in the first sentence, with behavioral edge cases following compactly. Every sentence earns its place, including the terse 'Pro.' note, which communicates an availability restriction without 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 operation with no output schema, the description covers the essential behavior: replacement, ordering, uniqueness, blank handling, minimum-size refusal, and task migration. It does not explain the return value or error responses, but that is less critical given the simple parameter set and annotations. The 'Pro.' note is slightly ambiguous but not a major 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 coverage is 100%, so the schema already documents both parameters and provides an example for columns. The description adds value by clarifying that names must be unique, that blanks are dropped, and that the final list must still meet the 2-item minimum after normalization. This goes beyond the schema's basic constraints.
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: 'Replace one board's columns, in order, with 2 to 12 unique names.' It also defines key constraints and behavior, so an agent can clearly tell what the tool does. No sibling tool targets column replacement, so there is no 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 gives clear context: use this when you need to replace a board's columns in a specific order. It does not explicitly name alternatives, but no sibling tool provides this capability, so the use case is unambiguous. The trailing 'Pro.' adds a plan/availability qualifier, though it could be more explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn Pro on for this connection with key, an MCPL1.. issued at checkout for this server or the bundle. Data under your token stays; a wrong or expired key changes nothing. license_status confirms it.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | License key from checkout, MCPL1.<payload>.<signature> |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only and not destructive, and the description adds useful behavioral detail: existing data under the token stays, and a wrong or expired key changes nothing. This goes beyond the annotation hints by explaining failure semantics and safety of the 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?
The description is two sentences with no filler. It front-loads the core action, then gives the key format and safety guarantees, and closes with the verification tool. Every sentence contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter activation tool with annotations covering the safety profile, the description is complete: it states what the tool does, what input is needed, what happens on failure, and how to confirm success. There is no missing critical information for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the key parameter and its format with 100% coverage. The description adds meaning by specifying that the key must be issued at checkout for this server or the bundle, which clarifies validity requirements not present in 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 uses a specific verb and resource: it 'turns Pro on' for the connection using a license key. It also distinguishes itself from the sibling license_status tool by saying license_status confirms the activation. This leaves no ambiguity about what the tool accomplishes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for use: the key must be an MCPL1.<payload>.<signature> issued at checkout for this server or the bundle. It does not explicitly list exclusions or alternative tools, but it does reference license_status as the confirmation path, giving the agent a sense of the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report this endpoint's licence state for your token as JSON: the product, the tier free or pro, why it is not Pro, and the checkout URL. Call it to explain a free-tier refusal. No arguments, nothing changes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds useful context beyond annotations by specifying the JSON response contents and stating 'nothing changes,' reinforcing the read-only nature of the call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences cover output, purpose, usage context, and side-effect guarantee. Every sentence earns its place and the most important information is front-loaded.
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 output schema, the description sufficiently describes the return value. With no parameters, annotations covering safety, and a clear use case, nothing essential is missing for an agent to invoke this 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?
There are zero parameters and the schema already fully documents that fact. The description explicitly says 'No arguments,' which is accurate and reinforces the schema without needing further elaboration.
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 begins with a specific verb ('Report') and a precise resource ('this endpoint's licence state for your token'), and enumerates the exact output fields: product, tier, reason, and checkout URL. This clearly distinguishes it from sibling tools like license_activate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to call it: 'Call it to explain a free-tier refusal.' This is clear contextual guidance, though it does not name alternatives or explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every task whose due day is already past, across all boards, oldest first, in the task_list table. as_of measures against a day you name. A finished task, or one with no due date, never counts.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | Measure against this day instead of today (YYYY-MM-DD, 'next Monday', '+7d') | |
| limit | No | Rows to print; default 200 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral context beyond those: as_of changes the reference day, finished tasks are excluded, tasks without due dates are excluded, and ordering is oldest first. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place: the main behavior, the as_of parameter semantics, and the key exclusions. Information is front-loaded and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, two-parameter tool with no output schema, the description covers the essential behavior, ordering, date semantics, and edge-case exclusions. Nothing needed to invoke 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 100%, so the schema already documents as_of and limit. The description lightly reinforces as_of's meaning but adds no new parameter-level detail 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 specific verb ('List') with a clear resource (tasks whose due day is past), and adds distinguishing scope: across all boards, oldest first, in the task_list table. This separates it from generic list/search siblings even without naming 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?
The context for use is clear: retrieve overdue tasks across all boards. However, it gives no explicit guidance on when not to use it or which sibling to prefer for related needs, such as task_list or task_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an empty board and give its free-tier slot back. A board still holding tasks, open or done, is refused with one named, because task_add creates boards as a side effect and the work would be lost.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Board to remove, e.g. 'Nova Site'. It must hold no tasks at all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry destructiveHint=true, but the description adds the crucial guard that only empty boards are deleted, that non-empty boards are refused, and that task_add creates boards as a side effect so deletion would lose work. This explains the real-world consequence beyond the annotation flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded main action, and each clause supports safe use. The garbled phrase 'with one named' is a clarity defect that prevents a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter destructive tool with no output schema, this is nearly complete: purpose, refusal condition, rationale, and consequence are all present. It only misses an explicit pointer that tasks must be removed via task_delete before retrying, plus a clear statement of the success response.
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 already documents project as the board to remove with the 'must hold no tasks' constraint. The description's 'empty board' and 'free-tier slot back' add useful context but not new parameter-level meaning, so the 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 opens with a concrete verb and object — 'Delete an empty board' — and immediately distinguishes itself from task_delete and project_list by scoping to boards and requiring emptiness. The free-tier-slot note adds context beyond the title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states the condition for use (board must be empty) and explicitly warns that non-empty boards are refused, which prevents misuse. It does not name a sibling like task_delete as the fallback for clearing tasks first, so the alternative path is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every board with its task-id prefix, open and done counts, estimate still open and overdue count, plus free-tier use (3 boards, 200 open tasks). Use board for one board broken down by column.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds value by disclosing what data is listed and the free-tier constraints, which are not present in the structured annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the core action and output contents, then gives the routing hint. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only listing tool, the description fully covers what an agent needs: what is returned, the scope ('every board'), and when to use the sibling board tool instead. The absence of an output schema is mitigated by the explicit list of returned fields.
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 the empty input schema is fully covered and there is nothing for the description to explain about parameter behavior. Baseline 4 is appropriate because the description need not compensate for any schema gaps.
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 action ('List every board') with a defined resource and enumerates the returned fields (task-id prefix, open/done counts, estimate still open, overdue count, free-tier use). It also distinguishes itself from the sibling board tool by naming that alternative, so an agent can tell them apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The final sentence explicitly provides routing guidance: 'Use board for one board broken down by column.' This names the alternative tool and the condition under which it should be selected, which is exactly what an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one task to a board and return its id, board and column. The board is created on first use, so pass an existing project or leave it out. An identical open task is refused. Free: 3 boards, 200 open.
| Name | Required | Description | Default |
|---|---|---|---|
| due | No | Due date: YYYY-MM-DD, 'today', 'tomorrow', 'Friday', 'next Monday' or '+3d' | |
| tags | No | Free-form tags, e.g. ['writing','client'] | |
| notes | No | Longer notes for the task | |
| title | Yes | What the task is, e.g. 'Write the launch email' | |
| column | No | Column to start in; defaults to the first column (backlog) | |
| project | No | Project or board name. A partial name matching exactly one existing project is used as that project. Defaults to your only board. | |
| priority | No | Priority; defaults to normal | |
| estimate_minutes | No | How long you think it will take, in minutes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (which only say readOnly=false, etc.), the description discloses real behavioral traits: board creation as a side effect, refusal of identical open tasks, free-tier board/open-task limits, and the returned fields. This gives an agent meaningful expectations about state changes and constraints without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no filler. The primary action and return value are front-loaded, followed by side effects and constraints. Every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key behaviors an agent needs: what is added, what is returned, how board creation works, duplicate handling, and free-tier limits. With no output schema, it still discloses return fields. Combined with the richly described input schema, this is complete for a tool of this 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 coverage is 100%, so the baseline is 3. The description adds semantic value by explaining the project parameter's optionality and the auto-creation behavior ('pass an existing project or leave it out'), which is not obvious from the schema alone. It does not need to restate every field because the schema already documents them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Add one task to a board'), states the returned data ('id, board and column'), and is easily distinguished from siblings like task_list and task_update. It is not a tautology and immediately tells an agent what operation this tool performs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear contextual guidance: the board is auto-created on first use, so the caller can pass an existing project or omit it. It also warns about duplicate refusal and free-tier limits. It does not explicitly name sibling alternatives or when-not-to-use conditions, but the context is strong enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete one task by id, permanently; the id is never reused. The answer names any logged minutes lost. time-tracker entries are a separate store and are untouched. Use task_done to keep the record.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Task id, e.g. NOVA-12 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, but the description adds rich behavioral context: permanence, id never reused, loss of logged minutes, and that time-tracker entries in a separate store are untouched. These disclosures go well beyond the structured annotations and clarify real side effects.
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, each earning its place: core action and permanence, side-effect disclosure, and the alternative tool. No redundancy, and the most important information is front-loaded.
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 destructive one-ID delete with a rich annotation set, this description is complete: it specifies what is deleted, permanence, related side effects, unaffected data, output hint about logged minutes, and the alternative to preserve the record. Nothing an agent needs 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 coverage is 100% for the single 'id' parameter, including an example. The description reuses 'by id' but adds no new parameter syntax, constraints, or format details. Baseline 3 is appropriate since the schema carries the full burden.
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 ('Delete'), a resource ('one task'), and the scope ('by id'), while adding the consequential detail that deletion is permanent and the id never reused. This clearly distinguishes it from siblings like task_done, task_update, and task_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names the alternative: 'Use task_done to keep the record.' This tells an agent when not to use task_delete (when the record must be kept) and provides the correct sibling to use instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark one task finished: it moves to the board's done column (named done, else the last) and is stamped, leaving task_list and the open counts. Returns estimate against actual when both are known.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Task id, e.g. NOVA-12 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description reveals meaningful behavioral details: the done-column fallback logic ('named done, else the last'), the stamping side effect, the removal from task_list and open counts, and the conditional return of estimate vs actual when both are known. This is rich, non-obvious 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 two dense, purposeful sentences. It front-loads the action and then efficiently lists consequences, with no filler or redundant restatement of the tool name.
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 low-complexity tool with one required parameter and no output schema, the description is complete. It explains the main side effects and the only return-value condition; the agent has enough information to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single parameter id, including an example, so description-level parameter detail is not necessary. The description adds no parameter-specific semantics, but schema coverage is 100%, which meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb phrase, 'Mark one task finished,' and identifies the exact resource ('one task') and the resulting effect (moves to the done column, stamped). This clearly distinguishes it from siblings like task_delete, task_update, and task_move.
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 clearly implies when to use this tool: when the user wants to complete one task. It does not explicitly name alternatives or state when not to use it, but the semantic contrast with task_update and task_move is strong enough that the intended use is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tasks as a table of id, project, column, title, priority, due, estimate, actual and tags, sorted by due date, with the total estimate. Done tasks are left out unless include_done. 200 rows default.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Only tasks carrying this tag | |
| limit | No | Rows to print; default 200 | |
| column | No | Only this column, e.g. 'doing' | |
| overdue | No | Only tasks past their due date | |
| project | No | Only this project | |
| due_before | No | Only tasks due on or before this day (YYYY-MM-DD, 'today', 'Friday', '+7d') | |
| include_done | No | Include finished tasks; default false |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds substantial operational behavior: output column layout, due-date sort order, total estimate, done-task filtering, and the 200-row default. This goes well beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with no filler. The most decision-relevant information is front-loaded: output shape, sort order, done-task behavior, and default row count.
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 read-only list tool with fully documented parameters and safety annotations, the description covers the output contract, filtering default, sorting, and row limit. No critical behavior an agent needs to invoke or interpret the result 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 100%, so the baseline applies. The description mentions include_done and the 200-row default, but those duplicate the schema descriptions; it does not add new parameter-level 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?
States a clear verb and resource: 'List tasks as a table of...' with exact columns, sort order, and exclusion of done tasks. This level of specificity lets an agent distinguish it from siblings like task_search or overdue without needing to inspect 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?
No guidance about when to use this tool versus alternatives such as task_search, overdue, or board. The description explains what the tool does but gives no exclusions or conditions that would route an agent to a sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add real minutes worked to one task so estimate and actual can be compared. Minutes ADD; a negative corrects an over-count. Below zero or past 100,000 is refused. This counter is the board's own.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Task id, e.g. NOVA-12 | |
| minutes | Yes | Minutes to add; a negative number corrects an over-count |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond annotations: explains that minutes are incremental, that negatives correct over-counts, that values outside -100000..100000 are refused, and that the counter is scoped to the board. This is critical behavioral context the annotations do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose, add/correct semantics, and bounds/scope. No filler or redundancy. Front-loaded with the core action.
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?
Complete for a simple two-parameter mutation tool: it covers purpose, mechanics, bounds, and scope. It doesn't describe the success response, but no output schema exists and the additive behavior makes the outcome self-evident. Minor gap: no mention of prereq such as task existence, but that's implied by 'task id'.
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 the schema already describes 'Minutes to add; a negative number corrects an over-count'. The description adds the real-worked context and board scope but does not materially 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?
States a specific verb and resource: 'Add real minutes worked to one task'. It explains the purpose (estimate vs actual comparison) and clarifies the additive semantics, which distinguishes it from other task mutation tools like task_start_timer or task_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (to log actual time worked against a task) but never explicitly names alternatives or says when not to use. Sibling tools like task_start_timer and task_update exist, but the description doesn't guide selection between them beyond purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move one task to another column of its own board and report the old and new column. An unknown column is refused, listing the real ones. Entering the done column stamps completion; leaving it clears it.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Task id, e.g. NOVA-12 | |
| column | Yes | Target column, e.g. 'doing' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false and carry no behavioral detail, so the description bears the full burden, and it delivers: it discloses the return value ('report the old and new column'), the error behavior for unknown columns ('refused, listing the real ones'), and the side effect on completion status. This substantially exceeds what the structured annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: core action+return, error handling, and side effects. The most decision-relevant fact (moving and reporting columns) is front-loaded, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no output schema and no annotation detail, the description covers the success return ('old and new column'), error mode (unknown column), and completion side effects — the key things an agent needs. Minor gaps remain: behavior for an invalid/nonexistent id or moving to the same column is unspecified, but these are low-stakes for this 2-parameter 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% with both parameters already described (e.g., 'NOVA-12', 'doing'), so the baseline is 3. The description adds only validation behavior for the column parameter (unknown columns are refused), which is behavioral rather than semantic. It does not add format, constraints, or default info 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?
States a specific verb-resource pair ('Move one task to another column of its own board') and immediately differentiates scope from siblings via the board constraint. The done-column nuance ('stamps completion; leaving it clears it') distinguishes it from task_done and task_update, so an agent can select it correctly.
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?
Provides clear operational context: the board constraint and done-column side effects tell an agent when this tool accomplishes status changes. However, it never names sibling alternatives explicitly (e.g., task_done or task_update) nor says when not to use them, so the guidance is contextual rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find tasks whose id, title, notes or tags contain the query, across every board, finished ones included. Plain case-insensitive substring, never a regex. Use task_list for structured filters.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Rows to print; default 200 | |
| query | Yes | Text to look for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint=false), the description reveals important search behavior: case-insensitive substring matching, no regex support, cross-board scope, and inclusion of finished tasks. This adds meaningful behavioral context not present in the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action and scope, followed by the behavioral caveat and the pointer to the alternative tool. Every sentence adds value with no filler or 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?
This is a simple read-only search tool with only two parameters, both fully schema-documented, and annotations covering safety. The description supplies the essential behavioral constraints and sibling routing, making it fully actionable for an agent.
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%, with both 'query' and 'limit' already documented in the input schema. The description adds some contextual meaning by naming the searched fields, but it does not materially change parameter understanding 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 names a specific verb ('Find') and resource ('tasks'), and precisely scopes the search by fields ('id, title, notes or tags'), scope ('across every board'), and inclusion ('finished ones included'). This clearly distinguishes it from siblings like task_list and task_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool for free-text substring matching and directs the agent to task_list for structured filters. It also gives a concrete exclusion ('never a regex'), leaving little ambiguity about selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the exact arguments to pass to the time-tracker's timer_start for one task, and record the link here. It starts nothing itself, and warns when the tracker's own project names would misfile the time.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Task id, e.g. NOVA-12 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavior beyond annotations by disclosing that the tool does not start the timer itself, records a link, and issues warnings when project names would misfile time. This is especially useful because all annotations are false and say little about side effects. No contradictions with readOnlyHint false or other flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences convey the function, the non-action, and the warning without filler; the operative clause is front-loaded. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema and uninformative annotations, the description covers what it outputs, what it does, and a warning condition. It leaves minor gaps such as the exact shape of the returned arguments and the meaning of 'the link here,' but nothing critical blocks a call.
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 id parameter is fully documented in the schema with 100% coverage and an example value, 'NOVA-12', so the description does not need to add much. It only reinforces 'for one task,' which adds no meaningful semantic detail 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 names a specific behavior—returning exact arguments for timer_start for one task—and explicitly disambiguates from a direct timer start by saying 'It starts nothing itself.' The full scope is clear: compute args, record a link, and warn about misfiling.
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 context is implied rather than stated: the tool is meant for a single-task time-tracker invocation, and the warning hints at when it matters. There are no explicit when-to-use or when-not-to-use statements or named alternatives among siblings, so an agent must infer the selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change a task by id: only the fields you pass are touched. tags REPLACES the whole list, due 'none' clears it, and project moves the task to a board that already exists. Returns the task's new row.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Task id, e.g. NOVA-12 | |
| due | No | New due date, or 'none' to clear it | |
| tags | No | Replaces the whole tag list | |
| notes | No | ||
| title | No | ||
| column | No | ||
| project | No | Move the task to another existing project board | |
| priority | No | ||
| estimate_minutes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the sparse annotations (all hints false), the description reveals partial-update behavior, the whole-list replacement semantics of tags, the clearing sentinel for due, and the existing-board prerequisite for project. It also promises a return value (the new row), which is valuable since there is no output schema.
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-load the core behavior, then cover special cases and the return value. There is no filler and no redundant restating of schema details.
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 9-parameter state-changing tool with no output schema, it covers the primary use case, partial update semantics, key special values, a prerequisite, and the return value. It doesn't enumerate error cases or clearing semantics for other text fields, but those are minor 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 only 44%, but the description compensates with the global rule 'only the fields you pass are touched' plus specific behaviors for tags, due, and project. Remaining parameters like notes, title, column, priority, and estimate_minutes rely on their names and schema types, so the compensation is good but not exhaustive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening clause 'Change a task by id' names the operation and target resource precisely, and 'only the fields you pass are touched' defines the update scope. The listed semantics for tags, due, and project make it easy to distinguish from sibling operations like task_add, task_delete, task_done, and task_move.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete invocation guidance: pass only fields to change, use 'none' to clear due, and use an existing board for project. It doesn't explicitly name alternatives or state when not to use this tool, but the context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare done against planned for one ISO week per project: how many were due, how many of those are finished, how many were completed, and estimate against actual minutes. Any week but this one is Pro.
| Name | Required | Description | Default |
|---|---|---|---|
| week | No | ISO week, e.g. '2026-W36'. Defaults to this week. Past weeks are a Pro feature. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key operational constraint (non-current weeks are Pro) and describes the report content. However, the annotations provide no read-only/destructive guarantees (readOnlyHint=false), and the description does not clarify whether the review is purely analytical or has side effects, nor what the returned structure looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the first sentence front-loads the operation and metrics, and the second states the one important usage limitation. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single optional parameter and no output schema, the description covers what the tool reports, the date format, the default, and the Pro limitation. It does not define the difference between 'finished' and 'completed' or explain the estimate-vs-actual comparison, but the core call envelope is clear.
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 the week parameter already has a clear description with an example, default, and Pro restriction. The tool description adds that the review is per project but does not add materially beyond the schema for the single 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?
Description names a concrete operation ('Compare done against planned') with a clear scope ('one ISO week per project') and enumerates the exact metrics produced (due, finished, completed, estimate vs actual minutes). This is specific enough to distinguish from siblings like overdue and task_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used for weekly per-project completion reviews, and the 'Any week but this one is Pro' line signals a restriction on non-current weeks. However, it never explicitly says when to prefer this over alternatives such as task_list or overdue, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
boardcolumns_setlicense_activatelicense_statusoverdueproject_deleteproject_listtask_addtask_deletetask_donetask_listtask_log_timetask_movetask_searchtask_start_timertask_updateweekly_reviewA local task board per project: columns, due dates, estimates, priorities, overdue, weekly review.
Task & board management for AI agents + humans. Kanban, comments, digests via MCP.
A finishing tool, not a to-do list: file tasks, read today's plan, and work dispatched queues.
Task manager your agent can fully operate: boards, tasks, sprints, roles, worklogs, day planner.
Add one secure layer between your agents and this server.
