weeek-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation5/5
Each tool targets a distinct resource+action pair (members, projects, boards, columns, tags, tasks, watchers, assignees, attachments, time entries, custom fields). Verbs like list/get/create/update/delete/complete/uncomplete are clearly differentiated, with set/remove/add/remove pairs for multi-valued relations keeping boundaries clean.
Naming Consistency3/5
The server uses a consistent `weeek_` prefix and snake_case throughout, but mixes verb styles: list/get/create/update/delete/manage (CRUD verbs) alongside set/remove/add/move/upload/complete/uncomplete (action verbs). The `manage_*` tools bundle multiple operations into single names, deviating from the more granular single-purpose verbs used elsewhere.
Tool Count3/5
31 tools is on the heavy side but justified by the broad domain coverage (tasks, projects, boards, members, tags, custom fields, attachments, time tracking, portfolios). It sits at the upper boundary of what's reasonable; the breadth of Weeek's domain explains most of the count.
Completeness5/5
The surface covers the full task lifecycle (create, read, update, delete, complete, uncomplete, move, add/remove from project, parent nesting), plus supporting domains: members, projects (incl. archive), boards (incl. reorder), columns (incl. reorder), tags, custom fields (including transfers), attachments, time entries, watchers, assignees, and portfolios. No obvious dead ends for core workflows.
Average 3.2/5 across 31 of 31 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 44 commits in the last 12 weeks
- Last stable release on July 19, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Mark a task complete' implies a mutation (changing task state), but doesn't disclose what side effects occur — e.g., whether completing a task affects subtasks, dependencies, timers (there's a weeek_task_timer sibling), or whether the operation is idempotent. An agent has no way to know what happens if the task is already complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is an efficient single sentence with no wasted words. It's appropriately short for a simple operation. However, being concise is not the same as being complete — the brevity here is more under-specification than economy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple single-parameter mutation, so complexity is low. However, it has no annotations, no output schema, and a 0% schema description coverage. A description of just 'Mark a task complete.' for a mutation tool that changes task state is insufficient — it should at least note whether the tool affects the task's status field, whether it's reversible (weeek_uncomplete_task exists implying reversibility), and what the return value is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no descriptions for the single required parameter task_id. The tool description adds zero information about what task_id is, its expected format, or how to find it. With only one parameter and no description, the description must compensate, but it doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Mark a task complete.' uses a clear verb+resource (mark/task) with a specific action (completing). It's distinguishable from the sibling weeek_uncomplete_task which would be the inverse operation. However, it's fairly minimal and doesn't describe any nuances like whether it toggles state or what prerequisites exist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It's implicitly distinct from weeek_uncomplete_task (the opposite operation) and weeek_update_task (which may handle broader updates), but the description doesn't explicitly articulate these distinctions or mention any prerequisites like needing an agent to already have the task retrieved.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. 'Get' implies a read operation, but the description doesn't state whether the returned object includes all fields, whether it returns an error when the id doesn't exist, or any other behavioral properties (auth requirements, rate limits). It adds essentially no behavioral information beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that takes minimal space. However, this borders on under-specification rather than deliberate conciseness — there's no additional detail, so it reads more like a tautological placeholder than an efficiently structured description. Still, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-ID fetch tool with no output schema and no annotations, the description is notably thin. It doesn't explain what the task object contains, whether it includes custom fields, subtasks, or relationships, or how it differs from list operations. While a get-by-id tool is conceptually simple, the absence of any return-format or behavior detail leaves the agent guessing about the response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description's single parameter (task_id) is self-explanatory in both the name and the schema type. The description doesn't add anything about the semantics of task_id beyond what the schema shows — no mention of format constraints, valid range, or where to obtain a task_id (e.g., from weeek_list_tasks). With only one parameter that's self-evidently an ID, the description adds zero value here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get one task by id' with a clear verb (Get) and resource (task), identifying this as a retrieval operation. It's minimally distinguishable from sibling weeek_list_tasks and weeek_get_attachment, but the singular 'one' and 'by id' does set it apart as a single-item fetch. Purpose is clear but thin, not explaining what fields or scope are returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like weeek_list_tasks (list all) or weeek_get_attachment (get attachment file). There's no mention of when a task wasn't provided in list results, or that this is the way to fetch full details for a single task. The agent must infer from the tool name and sibling set rather than from the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Remove' implies mutation, but there's no mention of whether this is reversible, whether it requires specific permissions, whether removing the last assignee has side effects, or what the response looks like. For an unannotated mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single clear sentence, zero wasted words. However, being concise is not the same as being sufficient; the one-liner under-delivers on the detail an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 2 required parameters at 0% schema coverage, no output schema, and no annotations, the single-sentence description is wholly inadequate. The agent cannot determine what format 'assignees' takes, whether partial removal is possible, or what happens after invocation. For a mutation tool with zero structured support, this is completely underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and there are no descriptions in the schema JSON for 'task_id' or 'assignees'. The description's mention of 'assignees' loosely maps to the parameter but adds no semantic depth. The 'assignees' array of strings is ambiguous — it's unclear if these are member IDs, names, or emails, since the schema gives no hint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove assignees from a task' states a clear verb (remove) and resource (assignees from a task). It distinguishes from siblings like set_assignees (which adds/assigns), but it's minimally stated with no additional scope or context about which task system or limitations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There's no mention of when to use remove_assignees vs set_assignees (which could replace the full assignee set), no prerequisites, and no context about whether this partially or fully clears assignees. The sibling set_assignees creates ambiguity that isn't addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Remove watchers' implies a mutating operation, but there's no statement about whether the task must exist, what happens with invalid watcher IDs, error behavior for unknown watchers, or whether the operation is idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence with zero waste. It's appropriately minimal, though the brevity comes at the cost of the missing explanatory content noted in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 0% parameter coverage, this description is thin for a mutating tool. It doesn't address failure modes, idempotency, required permission/authentication context, or relation to the sibling set_watchers tool. The watchers array format ambiguity is a significant gap for a tool that needs correct inputs to avoid errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the undocumented parameters. It doesn't explain what format watchers should take (member IDs, emails, usernames), nor does it clarify what type the task_id values are beyond the schema's integer type. The 'watchers' array semantics (strings — are these emails or user IDs?) are entirely unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('Remove watchers from a task'), which clearly identifies the action. However, it doesn't distinguish itself from the sibling tool weeek_set_watchers, leaving ambiguity about how these differ in their watcher-manipulation semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus the closely related weeek_set_watchers or weeek_remove_assignees. The description gives no context on when removal is appropriate, prerequisites, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals this is a mutating tool (start/stop) but does not state whether calling 'stop' on a non-running timer is harmless, whether 'start' on an already-running timer resets or ignores, what side effects occur (e.g., creating a time entry), or whether 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with zero waste. It is appropriately front-loaded and immediately conveys the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, and there is a closely-related sibling (weeek_manage_time_entry) creating ambiguity. For a mutating tool, the description should clarify behavior on edge cases (double-start, double-stop), whether timers are per-user or per-task, and how it differs from the time entry management tool. This is meaningfully incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it provides no parameter documentation beyond what the schema already contains. The two parameters (task_id, action) are self-explanatory from their names, and the enum makes 'action' clear, so the baseline is reasonable, but no additional semantics are added to justify a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Start or stop the running timer on a task' clearly states the verb (start/stop) and resource (task timer), matching the action and task_id parameters. However, it doesn't meaningfully differentiate from the related weeek_manage_time_entry sibling, which may be the more appropriate tool for some timer operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the closely-related weeek_manage_time_entry, nor are exclusions or prerequisites given. The description implies usage context ('running timer on a task') but does not state whether timers time-track against a project or whether starting requires an existing time entry.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 behavioral disclosure. It states the tool returns metadata and a download URL, but doesn't disclose whether this is a pure read operation with no side effects, whether authentication or specific permissions are required, or what happens if the file_id is invalid or unauthorized. Given zero annotation coverage, more transparency is expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no wasted words. It front-loads the verb and resource. The brevity is appropriate given the tool's simple single-parameter interface.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple single-parameter retrieval tool with no output schema and no annotations. Given the absence of both, the description should at least describe what the returned metadata contains or how the download URL is used. Instead it stops at the bare minimum. It is functional but leaves the agent without clarity on return format or follow-up usage of the download URL.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only mentions 'file id' as the input. The input schema only provides the parameter name 'file_id' with type string and no helper text. The description does not clarify the format or origin of the file_id (e.g., whether it comes from a list attachments call), leaving the agent to infer the meaning from the name alone. This is the minimum needed to use the tool, but no value is added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('get') and resource ('one attachment'), and specifies it returns metadata and download URL by file id. It distinguishes itself from weeek_upload_attachment (which does the opposite operation) and from list-type tools. However, it doesn't explicitly compare against siblings, relying on the name (weeek_get_attachment) to carry differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention that it requires a prior upload or list call to obtain the file_id, nor does it contrast with weeek_upload_attachment or other attachment-related operations. Context for obtaining the file_id parameter is entirely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description doesn't state whether this is a read-only operation, what the response format looks like, whether columns are returned in a specific order, or whether the operation requires specific permissions. For a listing tool with zero annotation coverage, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The parenthetical clarification that columns are 'statuses' is genuinely useful terminology mapping. The tool is simple enough (1 param) that this level of brevity is appropriate, and there's minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with a single required parameter, this is nearly adequate. The description explains the resource and the required parameter. However, the lack of output schema, no annotations, and no mention of related error cases or pagination behavior leave some gaps. The tool is simple enough that these gaps are somewhat tolerable, but a note about what 'columns' returns and their relationship to tasks would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 1 parameter at 0% schema description coverage, the description should compensate. The description does mention that board_id is required by the Weeek API, which reinforces the schema's required field declaration, but adds little beyond what the input schema already states about board_id being required. It doesn't explain what a valid board_id is or how to obtain it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List board columns (statuses) for a board' which uses a specific verb (list) and resource (board columns), clarifying that columns are synonymous with statuses. However, it doesn't distinguish itself clearly from sibling tools like weeek_list_boards or weeek_manage_board_columns, though the verb+resource distinction is somewhat implied by the naming convention.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. The description only notes that board_id is required, which is a parameter constraint rather than usage context. There's no mention of when this tool should be preferred over weeek_manage_board_columns, which relates to the same resource with a different verb, nor any prerequisites like needing to list boards first to get a valid board_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it deletes a task (implying destructive/irreversible behavior) but doesn't disclose whether the operation is cascade-deleting related entities, whether it removes timers/attachments/subtasks, or whether any confirmation or permission is required. For a destructive operation, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with zero wasted words. It front-loads the action ('Delete a task') and provides the identifying mechanism ('by id'). Every word earns its place, though arguably it could add behavioral caveats, but the instruction here is about conciseness, and this is exemplary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a destructive mutation tool with no annotations, no output schema, and 0% schema coverage. The description should compensate by disclosing side effects, irreversibility, and related resources affected (attachments, watchers, time entries, assignees). It does none of that. For a delete operation of this consequence, the single-sentence description is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'by id' which aligns with the single required task_id parameter, but with 0% schema coverage, the schema provides no description. However, with only one simple integer parameter and its purpose clearly stated, the description's implication of 'provide the task id to identify which task' adds sufficient meaning. The description doesn't add format or validation details beyond the schema, but the low complexity keeps this at an acceptable middle score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Delete a task by id'), clearly distinguishing this from siblings like weeek_complete_task, weeek_update_task, and weeek_uncomplete_task. The purpose is clear, though it doesn't explicitly differentiate from the other task-management siblings, making it a solid but not exemplary score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. The description doesn't state when deletion is appropriate, prerequisites (e.g., task must exist), or contrast with alternatives like weeek_complete_task or weeek_uncomplete_task. The context of deleting vs. merely altering task state is left entirely to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden for behavioral disclosure. It only names the operations (list/create/rename/delete) but doesn't disclose that delete is destructive, whether rename is allowed on nested portfolios, any permission or authentication requirements, or what happens on list without filters. A mutation-bearing tool with zero behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence listing all operations plus a clarifying parenthetical. No wasted words, though it front-loads the resource relationship well. Could add helpful usage context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a multi-operation CRUD tool with 7 parameters, no output schema, and no annotations. The description is a single sentence that fails to specify per-action expectations, list-vs-mutation behaviors, or return semantics. For a tool this broad in surface area, significantly more descriptive support is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 86%, high enough that most parameters are documented in the schema itself (name, limit, offset, search, portfolio_id, parent_id). The description adds the context that portfolios are 'folders projects live in' and that parent_id nests a portfolio under another, which the schema conveys. Marginal added value beyond schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: 'List, create, rename or delete portfolios' with parenthetical explaining what portfolios are ('the folders projects live in'). Distinct from siblings like weeek_manage_projects and weeek_list_projects by naming the portfolio resource specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a general sense that the tool handles CRUD for portfolios but provides no guidance on when to use it vs alternatives (e.g., list portfolios vs list projects), no prerequisites, and no note that this is the only portfolio-management tool among siblings. The action enum partially fills this gap but the description adds nothing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Add assignees' implies a mutation, but the description does not state whether this appends to existing assignees or replaces them, whether it requires specific permissions, whether it's reversible, or what the response 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with zero waste. However, it may be slightly under-specified rather than optimally concise, though the brevity is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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, this description is thin. It lacks behavioral detail (append vs. replace semantics), permission requirements, return value expectations, and any error conditions. The reference to weeek_list_members is useful but insufficient for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only mentions that member ids come from weeek_list_members. The description does hint that assignees values are member ids (which maps to the array of strings param), but does not elaborate on the task_id format or any constraints on the assignees array.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') and resource ('assignees to a task'), clearly stating what the tool does. It also references 'weeek_list_members' as the source of member ids, which differentiates it from the sibling 'weeek_remove_assignees'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by referencing 'weeek_list_members' as the source of member ids, but it does not explicitly state when to use this vs. alternatives like weeek_remove_assignees or weeek_set_watchers. No exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions 'Add' which implies mutation, but doesn't disclose whether adding is additive (appends) or replaces existing watchers, whether duplicates are handled, permissions required, or what happens on invalid member ids. For a mutation tool this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with zero filler. It packs the core purpose and a cross-tool reference into minimal words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter mutation tool with no annotations and no output schema, this description is thin. It doesn't explain behavioral semantics (append vs replace), error handling, return value, or required permissions. The watchers source reference helps but doesn't compensate for the missing behavioral and completeness detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only explains where watcher ids come from (weeek_list_members). It adds nothing about what task_id means or the format/semantics of the watchers array items beyond what the schema already implies (string items). The description partially compensates for the lack of schema detail on the watchers param but leaves task_id undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Add) and resource (watchers/subscribers to a task). It also references the source of member ids (weeek_list_members), adding useful context. It doesn't explicitly distinguish from the sibling weeek_remove_watchers, though the contrasting verb is implied in the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on where member ids come from (weeek_list_members), which hints at usage prerequisites. However, it doesn't explicitly state when to use this vs. alternatives like weeek_remove_watchers or weeek_set_assignees, and gives no exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description states the mutating behavior (move), which is clear, but it doesn't disclose whether the move is reversible, what happens to the task's position in the column, whether board_id is applied before column_id as a dependency (the schema does hint this), or what the response looks like. For a mutation tool with zero annotations, more disclosure is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that states the core purpose and the key usage constraint. It's appropriately sized, though it could benefit from a brief note on parameter relationships without bloating.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters, schema coverage at 33%, no output schema, and no annotations, this is a moderately complex mutation tool. The description covers purpose and the key constraint (at least one of two params), but lacks behavioral details like ordering semantics, reversibility, or return behavior. It's adequate but leaves gaps for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 1 of 3 parameters (board_id) has schema description coverage (33%), so the description must compensate for board_column_id and task_id. The description implies the board_column_id is the destination column and mentions the relationship between the two parameters, but it doesn't explain what numeric values are valid or how task_id relates. The description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb+resource: 'Move a task to a board column (status) and/or to another board.' This distinguishes it from siblings like update_task (general updates), complete_task, and delete_task. It's specific about moving, though it could be slightly clearer on what 'status' means in the weeek context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a partial usage constraint: 'Give at least one of board_column_id, board_id.' This clarifies when to use it logically. However, it doesn't explicitly distinguish when to use this tool vs update_task or add_task_to_project, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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's a mutation tool (log/edit/delete) but doesn't disclose side effects, whether changes are reversible, that update must target an existing entry, or if permissions are required. It does NOT contradict annotations since none exist, so no contradiction flag.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that covers the main operations and critical parameter requirements in clear prose. It's efficient without excess. Could arguably front-load the delete action, but overall tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 7-parameter mutation tool with no annotations and no output schema. It's an action-dispatching tool covering three distinct behaviors (create/update/delete) with different required fields. The description should explain behavioral differences per action, return behavior, and edge cases, but only states parameter requirements. For a multi-action CRUD tool with 57% schema coverage, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 57%, covering date, user_id, duration, entry_id, and is_overtime. The description adds action-specific parameter requirements (create/update vs delete), which is useful beyond the schema. However, it doesn't clarify is_overtime semantics or how duration/date interact. Baseline 3 with the action-routing info marginally adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool can log time on a task, or edit/delete a logged entry. It uses a clear verb+resource structure (log/edit/delete time entries). However, it doesn't explicitly distinguish from sibling tools like weeek_task_timer, though the names are reasonably distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies which parameters each action needs ('create and update need user_id, date, duration; delete needs entry_id'), giving helpful action-specific guidance. However, it doesn't provide when-to-use vs alternatives context or any exclusions. The usage guidance is action-routing rather than alternative-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description doesn't state side effects (does removing from a project affect task data? assignments? is it reversible?), whether it requires specific permissions, or what the response looks like. For a mutating operation with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no wasted words. It's appropriately concise for a simple operation, though it could arguably be slightly more informative without losing this conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating operation with no annotations, no output schema, and 0% schema coverage, the description should do more heavy lifting. It doesn't explain behavior when the task belongs to only one project, whether errors occur on invalid project_id, or any side effects. The description is minimally sufficient for basic understanding but incomplete for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the two parameters (task_id, project_id) are completely undocumented except for their names and types. The parameter names are fairly self-explanatory, but the description adds essentially no semantic value beyond what the schema provides. The description gives no context on what these IDs refer to or how they relate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove a task from one of the projects it belongs to' uses a specific verb (remove) and resource (task from project). It distinguishes from siblings like weeek_add_task_to_project and weeek_delete_task (which deletes the task entirely), so the purpose is clear and well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the task belongs to multiple projects ('one of the projects it belongs to'), which gives context on when to use it. However, it provides no explicit guidance on when NOT to use it versus alternatives like weeek_delete_task, and doesn't clarify what happens if a task belongs to only one project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. However, the description is minimal and doesn't explain behavioral traits such as whether it's a mutating operation (it clearly is), what happens if the task is already incomplete, error states, or side effects. 'Mark as not complete' is self-evident but lacks depth on edge behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that fully captures the action. There is zero wasted text, and the brevity is appropriate for a simple single-purpose tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutating tool with one parameter and a clear purpose, the description is almost adequate. However, with no annotations, no output schema, and no parameter documentation, it falls slightly short—it might benefit from noting error conditions (e.g., task not found or already incomplete) or the reverse relationship to weeek_complete_task. Still, the minimal footprint makes this close to sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter (task_id, an integer). Schema description coverage is 0%, so the description doesn't compensate with parameter details. However, with a single obvious integer parameter to identify the task, the schema itself is largely sufficient. The description adds no parameter semantics but the need is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Mark a completed task as not complete' clearly states the verb (mark) and resource (completed task). It's the inverse of weeek_complete_task, which is evident from the sibling list. While it could be more specific about context, the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It implicitly complements weeek_complete_task, but the description doesn't directly reference when one should be used over another, nor does it mention any prerequisites (e.g., task must currently be completed for it to make sense).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. Beyond noting paths must exist locally, it doesn't disclose what happens on failure, whether attachments replace or add to existing files, size limits, permissions required, or the return format. For a write tool with zero annotation coverage, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero wasted words. Every sentence earns its place, and the 'Paths must exist on this machine' caveat is a high-value operational detail. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema and no annotations, the description is close to adequate. It covers both parameters' purpose and a key operational constraint. However, it omits behavioral context like what happens on failure, confirmation of successful upload, or whether attachments are additive, which would help complete the picture for a write operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: paths has 'Absolute file paths' described while task_id has none. The description confirms paths must be local and exist, adding a small operational detail. It doesn't explain the task_id format or validity requirements beyond what the schema's type 'integer' conveys, so it adds marginal value but doesn't fully compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Attach') and resource ('local files to a task'), which is specific and distinct from siblings like get_attachment or move_task. However, it doesn't explicitly contrast with sibling tools, though the attachment name and description make the purpose evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage ('Attach local files to a task') but gives no explicit when-to-use vs alternatives guidance. It does note 'Paths must exist on this machine,' which is a useful operational prerequisite, but there are no exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. "List" clearly implies a read-only operation, which is a positive signal, and "of a project" scopes the operation to a single project. However, it doesn't disclose what happens with an invalid project_id, whether the response includes both board statuses/types, or any pagination/ordering behavior. For a read-only list tool, the disclosure is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five words exactly cover the purpose with zero filler. For a simple single-parameter list tool, this level of conciseness is appropriate and commendable. No wasted sentences, no redundant elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only list tool with no output schema and no nested objects, the description is nearly complete. The main gap is that it doesn't hint at the return structure (board names, IDs, statuses) or the prerequisite of obtaining a project_id first. But given the tool's simplicity and the sibling relationships in the same family (all weeek_list_* follow a predictable pattern), the description is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The description identifies project_id as the scoping filter (boards belonging to a project), which provides some semantic meaning. However, it doesn't specify whether project_id refers to the ID from weeek_list_projects or whether any format constraints apply. With only 1 parameter and the description naming 'project' as the scope, the bare minimum is met.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
"List boards of a project" uses a specific verb (list) + resource (boards) + scope (of a project). It clearly distinguishes from sibling tools like weeek_list_projects (listing projects) and weeek_manage_boards (managing boards). Could be slightly more specific about what a board represents, but the purpose is clear and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like weeek_list_board_columns or weeek_manage_boards. The description simply states what it does without context on selection criteria. It does, however, clearly indicate that project_id is required, implying it must be fetched first (likely via weeek_list_projects), but this prerequisite is not stated explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It doesn't mention whether this is read-only, what happens on error, or return format details. Listing is implicitly read-only but this is never stated. Being a list tool, the risk profile is relatively low, but there's no explicit statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence that states the action, the returned fields, and a practical pointer (use ids as assignees). Zero wasted words. Ideal structure for a parameterless list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless list tool, the description is reasonably complete. It names the output fields and gives usage guidance. However, it doesn't describe pagination, sorting, or whether the list may be large, and given no output schema exists, it could benefit from a bit more detail on return structure. Still adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 0 parameters, and schema coverage is 100%, meaning there's nothing the description needs to document. With no params, the dimension imposes no burden. The description covers the full scope since the tool takes no arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: lists workspace members. Identifies returned fields (id, name, email) which adds specificity. Distinguishes from siblings (weeek_list_projects, weeek_list_boards deal with other resources), though it doesn't explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to obtain member ids for assignment purposes ('use their ids as assignees'), which provides a use case context. However, it doesn't explicitly state when to use this vs alternatives (e.g., weeek_whoami or other member-related tools). The usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the entire burden of behavioral disclosure. It lists the action types but doesn't disclose side effects: what happens to tasks in an archived project, whether delete is permanent or reversible, permission requirements, or whether dependent resources get cascaded. For a mutation tool with five distinct destructive/non-destructive actions, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences, zero filler. Front-loaded with the full action list and immediately points to the read sibling. Could arguably add one sentence of behavioral context (e.g., 'Archive and delete have different task implications'), but overall it's well-structured and skimmable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex multi-action CRUD tool (5 actions) with no output schema and no annotations, yet the description is a single-line action list. It doesn't clarify return values per action, prerequisites (e.g., portfolio_id required for create), or the distinct semantic weight of archive vs unarchive vs delete. For a tool of this complexity, the description under-delivers on the behavioral contract, though schema descriptions offset some of it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 71%, so most parameters (name, color, project_id, is_private, action, portfolio_id) have their own descriptions. The tool description adds no beyond-schema value for parameters. The description adds the 'Required on update' nuance for color, but that's already in the schema. Baseline 3 is appropriate since schema handles most of the work, though the ~29% undocumented remainder (description param) is a minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear action verb 'Create, update, delete, archive or unarchive' with explicit resource 'a project'. Distinguishes from sibling read tool weeek_list_projects. Purpose is well defined and unambiguous, though it doesn't enumerate all operations' effects distinctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly points to weeek_list_projects for reads, establishing a clear read-vs-write boundary. However, it doesn't provide exclusions for when NOT to use this tool vs other manage_* siblings (tags, boards, columns, portfolios), nor scenarios like when project deletion is preferable to archiving.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. The description identifies the four operations, which implies mutation for create/update/delete. However, it doesn't disclose side effects, whether deletion is permanent/destructive, permissions required, or how the rename/recolor behavior interacts with tasks that use the tags. For a mutation tool with zero annotations, this is somewhat thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that efficiently enumerates the four operations and includes an embedded pointer to a related tool (weeek_update_task). It's front-loaded with the key purpose and uses no filler. Slightly more detail could be added about conditionality of parameters, but for its length it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 a multi-action tool covering four different operations with conditional parameters, the description is adequate but not rich. It tells the agent what actions exist but not the full conditional logic (e.g., which parameters are required per action beyond what's implied), nor what the list output looks like for the downstream use case. Given the tool's complexity (4 actions with varying parameter requirements), more context would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, and the schema already describes title (required for create/update), tag_id (required for update/delete), and color (required on update). The description adds minor value by clarifying that list provides tag ids for downstream use in weeek_update_task, but overall the schema carries most of the parameter meaning. Adequate baseline given good coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages workspace tags with four operations (list, create, rename/recolor, delete). The verb 'manage' plus the enumerated operations is reasonably specific, and the note about listing tags with ids for use in weeek_update_task adds sibling differentiation value. It's clear but 'manage' is still slightly generic compared to a tool name that might incorporate the operations directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use cases by enumerating the four actions, and mentions that list output provides ids for use in weeek_update_task. However, it does not explicitly state when to use this tool vs alternatives (e.g., vs weeek_manage_custom_fields or other config tools), nor does it provide any exclusions or when-not-to-use guidance. Some context is present but no explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It reveals the operation is a mutation (nests/detaches) and explains the null-parent semantics, but doesn't state consequences like whether children get orphaned, whether reordering conflicts with existing after/before placements, or any auth/permission requirements. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence front-loading the core purpose (nest/detach) and appending the sibling-placement detail. Efficient with no wasted words, though it could benefit from a brief explicit usage note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description covers the primary behaviors but omits edge cases (after+before conflict, effects on existing subtrees, whether it implicitly moves across projects). Given 4 parameters and 2 required, it's minimally complete but leaves meaningful gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, so most parameters already have descriptions. The tool description adds meaning to parent_id (null makes it top-level) and after/before (placement among new siblings). However, it doesn't clarify interactions—e.g., what happens if both after and before are set, or whether after/before are relative to new or old siblings. Some value added over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states nested (nest a task under another one) or detach with parent_id null, plus placement among siblings via after/before. It uses a specific verb+resource and distinguishes the parent-setting action from sibling tools. However, it doesn't explicitly contrast with weeek_move_task, which shares overlapping positioning semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (setting/changing a task's parent and ordering among siblings) but doesn't name alternatives or give explicit exclusions. The relationship to weeek_move_task (which likely also handles ordering) is unclear, leaving the agent to infer when to prefer this tool over moving.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It reveals the filtering behavior and output is a list, but doesn't disclose pagination behavior (per_page/offset), sort defaults, the meaning of the 'type' parameter (action/meet/call), or what task fields are returned. No contradictions with annotations since none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single efficient sentence, zero wasted words. It front-loads the verb 'List' with resource 'tasks' and immediately enumerates the filter dimensions. Perfectly concise for a list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 14 parameters with only 36% schema coverage, no output schema, and no annotations - a fairly complex tool. The description covers surface-level filtering but omits clarity on several parameters (type, dates, priority, pagination) and doesn't describe the return format. Adequate but leaves meaningful gaps for a tool with this parameter complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 36%, so the description should compensate but doesn't. It mentions the filter dimensions generically (project, board, column, assignee, completion, tags, text search) which maps to some params, but the 'type' filter (action/meet/call), date-range semantics, pagination, and priority are not explained in the description despite being ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists tasks with optional filters, naming key filter dimensions (project, board, column, assignee, completion, tags, text search). It distinguishes from siblings like get_task (single task) and task_timer, though it doesn't explicitly name an alternative for comprehensive filtering searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for filtered task retrieval but provides no explicit guidance on when to use this vs get_task, or when to use search vs filters. No exclusions or alternatives are named, leaving the agent to infer context from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool performs potentially destructive actions (delete) and mutations (rename, reorder) but doesn't explain consequences of deletion (e.g., are tasks/tags lost?), whether reorder has any impact on linked items, or what happens to children when a board is deleted. For a mutation tool with zero annotation coverage, more transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. The first sentence states the full purpose and the second points to the read sibling. Every element earns its place, making this an efficient, front-loaded description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a multi-action tool (create, update, delete, move) with 5 parameters and no output schema, the description is somewhat thin. It doesn't explain per-action requirements or behaviors—e.g., what happens when you delete a board, whether update requires specific fields, or the semantics of reordering. The schema compensates partly (80% param coverage), but the description could add action-specific context that an agent would need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80%, meaning most parameters already have descriptions in the schema. The description itself adds minimal parameter detail. However, the schema mentions the 'move' action's upper_board_id semantics are self-documenting. The description doesn't add meaning beyond the schema for the parameters, earning a baseline score for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (create, rename, delete, reorder) and resource (board). It distinguishes from the sibling read tool weeek_list_boards by explicitly pointing to it for reading, which differentiates this mutating tool from its counterpart. However, it doesn't enumerate the reorder specifics in the purpose line itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use weeek_list_boards to read them,' establishing a clear when-not-to-use boundary. It implies this is for mutations only. While it doesn't cover edge cases like when to prefer update vs delete, the sibling reference provides good context for an agent deciding between read and write tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The description discloses the key behavioral trait that a task can exist in multiple projects, which is non-obvious and helpful. However, it doesn't mention what happens if the task is already in the project, whether membership is idempotent, or if any permission is required. For a mutation tool with zero annotation coverage, the behavioral disclosure is thin but the multi-project property is valuable context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place. The first states the action and a key behavioral nuance; the second adds the optional parameter context. No filler or redundancy. Very efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a relatively simple 3-parameter tool with no output schema and no nested objects. The key context—that tasks can live in multiple projects—is captured, and the optional board column targeting is explained. For a low-complexity mutation tool, this description is reasonably complete, though it could note the counterpart tool for removal or that adding to a project is non-destructive to existing memberships.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The description maps board_column_id to 'target a board column there', which adds meaning beyond the bare type info. However, it says nothing about what task_id and project_id mean semantically beyond their names, which are fairly self-explanatory. The description adds modest value over the zero-coverage schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'Put' is weak but the description is specific: adding a task to a project with optional board column targeting. It distinguishes from weeek_remove_task_from_project and weeek_move_task (which implies moving between locations, whereas this adds membership). The parenthetical that a task can live in several projects adds useful scoping that differentiates from a move.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There's no explicit when-to-use or when-not-to-use guidance. However, the parenthetical '(a task can live in several)' implies this is for adding membership rather than moving, which indirectly distinguishes from weeek_move_task. But no alternatives are named, and no context is given for when to choose this over moving a task or removing it from a project. Implied usage only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It does not state whether actions are destructive (deleting a column could be irreversible), whether reordering has side effects on tasks in those columns, permissions needed, or what the mutation returns. For a tool with create/update/delete/move actions and no annotation coverage, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with zero waste, front-loading the four actions and pointing to the read sibling. It loses a point for not being broken out or elaborating slightly, but it is appropriately minimal for a multi-action tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, 4 enum actions, and no output schema, the description is somewhat thin. It lists the actions but doesn't clarify the action-parameter matrix (which params are needed per action), nor what results/return values to expect. Given no annotations or output schema, it could do more to guide a model in assembling valid call combinations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80% and each parameter has a reasonable inline description (e.g., 'upper_board_column_id: the column to sit after; null moves it first'). The description itself adds little beyond naming the four actions, which maps to the action enum. Since the schema already documents parameters well, baseline 3 applies and the description doesn't add significant extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb set (creates, renames, deletes, reorders) tied to the resource (board column/status), clearly outlining all four actions. It distinguishes from the sibling weeek_list_board_columns by noting that tool is for reading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description names the sibling read tool (weeek_list_board_columns) as the association for reading, providing reasonable context. However, it doesn't give explicit when-to-use/when-not-to-use guidance or detail which parameters apply to which action, though the schema's per-parameter 'required' hints partially cover this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It clarifies the ownership/scope semantics (which is genuine behavioral context beyond the schema), but doesn't address auth/required permissions, side effects of transfer (what happens to existing task data), reversibility, or response behavior. Given no annotations, this is a moderate disclosure that could go further.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact 3 sentences with the key concept (scope) front-loaded. It's efficient but packs in a lot without explicit structure; the action-to-param mappings are implied via schema descriptions rather than enumerated. Slightly dense for a complex 13-param, 9-action tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a genuinely complex tool: 13 params, 9 actions in an enum, nested objects, multiple scopes, and per-action parameter requirements. With no output schema and no annotations, the description would need to spell out which params apply to which action to be fully complete. The scope explanation helps but the action-specific parameter requirements are left implicit in the schema, making the description incomplete for an agent to confidently drive this high-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high at 92%, so the schema already documents most parameters. The description adds the scope model explanation (scope + scope_id relationship) which goes beyond the schema's 'Where the field lives.' However, with 13 parameters and only ~92% covered, the description doesn't compensate for the undocumented remainder, and doesn't explain the action-to-parameter matrix (which params are needed per action).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists specific verbs (Create, update, delete, move or transfer) tied to a clear resource (custom fields and their select options). It also adds the scope concept (board/project/global) that distinguishes this tool from siblings like weeek_list_custom_fields, and even names that reader tool explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the scope model (field belongs to one board, project, or global, set scope and scope_id accordingly), which is a crucial usage condition. It also calls out weeek_list_custom_fields as the reader for what a project's tasks show. However, it doesn't explicitly state when NOT to use this vs other manage_* tools or provide negative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. The description correctly implies a read-only operation without stating it explicitly. It doesn't mention potential failure modes like invalid tokens, but for a simple identity lookup, the behavioral expectations are reasonably clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, both highly informative. The first states the purpose and return shape; the second provides practical usage context. Zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema read-only tool, the description is essentially complete. It specifies the return values (id, name), the authentication source (API token), and a practical use case. There's little more it could add without being verbose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema coverage (empty object), so there's nothing for the description to explain. The baseline of 4 for no-param tools is appropriate here; the description adds the return content hint (id, name) which is helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the current user (id, name) based on the API token. It uses specific verbs and identifies the resource. It doesn't explicitly distinguish from siblings, but among list/manage tasks, this is a self-identifying action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes practical guidance: 'Useful to get your userId for assignments.' This tells the agent a concrete use case, though it doesn't explicitly name alternatives or when-not-to-use. For a whoami-style tool, the purpose is self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the behavioral burden. It discloses that description field takes HTML (vs Markdown on update), that custom_fields only work with ids here (names only on existing tasks), and that a field not belonging to a project is an error. Decent disclosure but doesn't cover return values, permissions, or auth requirements for a create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Opening sentence is front-loaded and direct. The parenthetical about board_column_id and the date-separation note are efficient. However, the priority explanation and some parameter details are somewhat dense, and the description mixes essential guidance with a few edge-case details that could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter create tool with no output schema and no annotations, this is reasonably complete. It covers the required params, the common gotchas (board_column_id, dates, custom_fields ids), and format quirks. It could mention what the response contains, but for a create operation with 70% schema coverage this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 70%, and the description adds meaningful extras beyond the schema: it explains the HTML/Markdown difference for description, the custom_fields id-vs-name behavior, the board_column_id null semantics (board default), and the priority number-to-label mapping. This goes well beyond what the schema alone provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Create a task' with a specific verb+resource. It mentions required params (project_id, board_column_id) and a crucial differentiator: dates are set separately via weeek_update_task. However, it doesn't clearly distinguish from related tools like weeek_set_task_parent or weeek_add_task_to_project, though the core create-purpose is apparent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says dates are set separately via weeek_update_task, clearly identifying when NOT to use this tool for date-setting. It also names weeek_list_board_columns as the source for board_column_id. This is strong when-vs-alternative guidance, especially with the sibling set including weeek_update_task and several manage_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 'List' clearly signals a read operation (non-destructive, no mutation), which is accurate given the tool's read-oriented nature. However, it doesn't disclose behavioral details like return format, pagination, error cases, or whether authentication is required — though for a simple list tool with zero parameters, the risk is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is perfectly sized — verb, resource, scope, and output fields in nine words. Zero waste, no filler, fully front-loaded. An exemplar of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema listing tool, the description is nearly complete. It covers what it lists (projects), scope (all), and output fields (id, name). The only gaps are minor: no mention of pagination or authorization requirements, but these are unlikely to be critical for a simple read-only list of projects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 to document. The description correctly notes the output fields (id, name), which is the most relevant semantic information an agent needs. With no parameters, the baseline of 4 applies, and the field disclosure adds value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all task-manager projects (id, name)' uses a specific verb (List) with clear resource (projects) and scope (all), explicitly stating the returned fields (id, name). It distinguishes clearly from siblings like weeek_manage_projects (which handles mutations) and other list tools targeting different resources (boards, members, tasks).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is a read-oriented listing operation via the 'List all' phrasing, but provides no explicit guidance on when to use it versus alternatives. It doesn't name sibling alternatives (such as weeek_list_boards or weeek_manage_projects) or state when-not-to-use it, though the read/list orientation is reasonably clear from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It notably discloses that the description update requires a knowledge base session and drives a headless browser (taking a few seconds) since Weeek's REST API ignores it on update. This is valuable transparency about side effects and requirements beyond the schema, though it doesn't fully explain behavior for every field combination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that efficiently enumerates the updateable fields. It's front-loaded with the main purpose and wastes no words. Slightly more structure could delineate the three categories more clearly, but the current format is economical and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 12 parameters including nested objects and enums, no output schema, and no annotations. The description covers the primary scope (fields, custom fields, description) and compensates for the lack of annotations by revealing the headless-browser behavior for description updates. It could be more complete by noting reversibility or partial-update semantics, but it addresses the key complexities reasonably well for its complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, so most parameters already have descriptions in the schema (dates format, priority semantics, tags referencing weeek_manage_tags). The description adds context for custom_fields (keyed by name or id, clearing behavior) and description (Markdown, headless browser via weeek_kb_update). With moderate coverage and a nested custom_fields object, the description adds value but doesn't fully detail the nesting semantics beyond what the schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a task's core fields (title, priority, type, dates, duration, tags), custom field values, and description. It uses a specific verb ('Update') with a concrete resource ('a task's fields') and enumerates exactly what can be changed, differentiating it from sibling update tools like weeek_complete_task or weeek_move_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when updating task attributes, custom fields, or description), though it doesn't explicitly state when NOT to use it or mention alternatives for other task operations like moving, assignees, or watchers. The specific mention of alternatives isn't required here since siblings handle discrete operations, but explicit exclusions would improve the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It transparently discloses the notable behavioral quirk that results may include fields belonging to other projects (since tasks list every workspace field), and warns that writing to those is reported as an error. This is honest, non-obvious, and highly valuable behavioral context beyond any schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, all earning their place. Each sentence adds distinct value: what it lists, why the workaround exists, and the caveat about cross-project fields. Slightly dense but nothing wasteful — no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter listing tool with no output schema, this description covers the important essentials: what's returned, the empty-project edge case, how the data is sourced, and the cross-project caveat. There is no output schema to compensate, so the description carries full completeness burden and does so well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (project_id) exists, and the description names 'project' as the scope. Schema coverage is 0%, so the description compensates by clarifying semantics: it's a project-scoped read. However, it doesn't specify the exact format/type of project_id, though this is minor given the tool's self-contained single param.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource+scope: 'List the task custom fields visible in a project' with the exact fields returned (id, name, type, select options). Distinguishes from siblings: it's the read counterpart to weeek_manage_custom_fields, and it's clearly a listing tool (not a whoami/member/project lister).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes the critical limitation: 'a project with no tasks yet returns nothing' — a key condition agents must know before invoking. Also explains the workaround mechanism (reads fields off a task because no schema endpoint exists) and the consequence of writing to other-project fields (reported as an error).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![weeek-mcp MCP server](https://glama.ai/mcp/servers/adalekin/weeek-mcp/badges/card.svg)](https://glama.ai/mcp/servers/adalekin/weeek-mcp)

Score Badge

Copy to your README.md:

[![weeek-mcp MCP server](https://glama.ai/mcp/servers/adalekin/weeek-mcp/badges/score.svg)](https://glama.ai/mcp/servers/adalekin/weeek-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/adalekin/weeek-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server