Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@WEEEK MCP Server list my projects"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP (Model Context Protocol) server for the WEEEK task tracker. Gives AI coding agents (Claude Desktop, Cursor, Cline, and any other MCP client) direct read/write access to WEEEK projects, boards, tasks, and comments — no context switching.
12 tools — 7 read (projects, boards, columns, tasks, comments) + 5 write (create/update/move/complete tasks, post comments)
Read/write split — tools are grouped so MCP clients can auto-approve reads while gating writes
Stdio transport — zero server infrastructure, runs via npx
Token auth — single WEEEK_API_TOKEN env var, never logged
Safe defaults — list tools paginate (default 20, max 50) so responses stay under the 25k token MCP limit
Structured errors — API failures return isError: true with a human-readable message, the server never crashes
Related MCP server: Yougile MCP Server
No installation needed — configure your MCP client to run it via npx.
Sign in to WEEEK.
Open Workspace settings → API.
Generate a personal API token.
Treat it like a password — it grants full read/write access to your workspace. Rotate it if it leaks.
Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"weeek": {
"command": "npx",
"args": ["-y", "weeek-mcp-server"],
"env": {
"WEEEK_API_TOKEN": "your-weeek-token-here"
}
}
}
}Restart Claude Desktop.
Edit ~/.cursor/mcp.json (or use Cursor Settings → MCP → Add new MCP server):
{
"mcpServers": {
"weeek": {
"command": "npx",
"args": ["-y", "weeek-mcp-server"],
"env": {
"WEEEK_API_TOKEN": "your-weeek-token-here"
}
}
}
}Any MCP client that supports stdio transport can launch:
command: npx
args: ["-y", "weeek-mcp-server"]
env: { WEEEK_API_TOKEN: "<your token>" }If you installed Node via nvm, GUI applications (Claude Desktop, Cursor) do not source your shell startup files, so npx is not on their PATH. You will see spawn npx ENOENT in the client logs.
Fix: use the absolute path to your nvm npx binary.
In your terminal, run:
which npxExample output: /Users/you/.nvm/versions/node/v22.0.0/bin/npx
Put that absolute path in your MCP client config as the command:
{
"mcpServers": {
"weeek": {
"command": "/Users/you/.nvm/versions/node/v22.0.0/bin/npx",
"args": ["-y", "weeek-mcp-server"],
"env": {
"WEEEK_API_TOKEN": "your-weeek-token-here"
}
}
}
}This is the single most common setup failure across all npx-based MCP servers. If you upgrade Node via nvm, update the path.
All tools are prefixed weeek_. Read tools are side-effect free and safe for auto-approve. Write tools mutate WEEEK state and should prompt for user confirmation.
Tool | Purpose |
| List projects in the workspace. Use FIRST to discover project IDs. |
| Get a single project's full details by ID. |
| List boards inside a project. |
| List columns (statuses) inside a board. Required before moving tasks. |
| List tasks with filters (project, board, column, assignee, completion) and pagination. |
| Get full details of a single task by ID. |
| List comments on a task. |
Tool | Purpose |
| Create a NEW task. Requires title + project_id. |
| Edit fields (title, description, priority, assignee, due date) of an existing task. |
| Move a task to a different board column (status change). |
| Mark a task complete, or reopen a completed task. |
| Post a comment on a task. |
Read/write separation: read tools and write tools are registered in separate groups. Configure your MCP client to auto-approve reads while gating writes.
No delete operations: v1 intentionally does not expose delete endpoints — too destructive for an AI agent.
Pagination defaults: list tools default to 20 results (max 50) to stay under the 25,000 token MCP response cap.
Token handling: WEEEK_API_TOKEN is read from the env block only. It is never logged, echoed, or included in error messages.
Symptom | Fix |
| You are using nvm — see the NVM Workaround section above. |
| The |
| Token is wrong, revoked, or expired — regenerate in WEEEK workspace settings. |
Server disconnects immediately after starting | You are on Node < 20. Upgrade Node ( |
Tool returns "Resource not found (404)" | The ID doesn't exist in the workspace — list the parent resource first (e.g., |
git clone <this-repo>
cd weeek-mcp-server
npm install
npm run build
npm testScripts:
npm run build — compile TypeScript to dist/
npm run dev — run from source via tsx
npm run lint — ESLint (enforces no-console rule for stdio safety)
npm run typecheck — tsc --noEmit
npm test — vitest unit tests
To smoke-test the built binary:
npm run build
WEEEK_API_TOKEN=test node dist/index.js
# server blocks on stdin — press Ctrl+C to exitNode.js >= 20.0.0
A WEEEK account with API access
MIT — see LICENSE.
Mark a WEEEK task as COMPLETE or REOPEN a completed task. WRITE OPERATION — the MCP client may prompt for confirmation. Required: task_id. Optional: completed (default true), mr_url (records a merge/pull request link on the "МР" custom field in the same call), field_name (only with mr_url). Pass completed=false to reopen. Returns the updated task. DISTINCT from weeek_move_task: completing a task is a done/undone toggle, independent of which column it lives in. DISTINCT from weeek_update_task: completion is not an editable field — it has its own dedicated semantics in WEEEK. Use this tool when the user says 'mark done', 'complete', 'finish', 'close', 'reopen', or 'uncomplete'. task_id must come from weeek_list_tasks.
| Name | Required | Description | Default |
|---|---|---|---|
| mr_url | No | Merge/pull request URL to record on the task's "МР" custom field in the same call as completion. Optional. Omit to leave the field unchanged. Use weeek_set_task_mr_link instead if there is no completion change happening. | |
| task_id | Yes | WEEEK task ID to complete or reopen. Required. Obtain from weeek_list_tasks. | |
| completed | No | Whether to mark the task as completed. Default: true (mark done). Pass false to REOPEN a previously-completed task. | |
| field_name | No | Name of the custom field to write mr_url into. Optional — defaults to "МР". Only used when mr_url is provided. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the tool is a WRITE OPERATION that may prompt for confirmation, explains the complete/reopen toggle behavior, and details the optional mr_url functionality. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and uses clear formatting. It is slightly verbose but every sentence adds value, especially the distinctions and usage hints. Could be streamlined slightly, but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (1 required) and no output schema, the description is complete. It explains return value ('Returns the updated task'), prerequisites (task_id from weeek_list_tasks), and behavioral details. No gaps for correct tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions for all 4 parameters. The description adds value beyond schema: it clarifies that completed=false reopens, mr_url records a link on the 'МР' field, and field_name is optional with mr_url. This extra context justifies a 4 despite high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Mark a WEEEK task as COMPLETE or REOPEN a completed task.' It specifies the verb (mark) and resource (task), and explicitly distinguishes from siblings like weeek_move_task and weeek_update_task, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Use this tool when the user says mark done, complete, finish, close, reopen, or uncomplete.' It clearly differentiates from alternatives, instructs that task_id must come from weeek_list_tasks, and suggests an alternative tool when no completion change is involved.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a NEW task in WEEEK. WRITE OPERATION — the MCP client may prompt for user confirmation before this runs. Required: title and project_id. Optional: description, board_id, board_column_id (status), priority, assignee_id, due_date. Returns the created task object in the same shape as weeek_get_task. Use this ONLY when creating a brand-new task; to change an existing task's fields use weeek_update_task, to move it to a different column use weeek_move_task, to mark it done use weeek_complete_task. All *_id parameters must come from the corresponding list tools — do not guess IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Task title. Required. Shown as the task's headline in WEEEK. | |
| board_id | No | Board to place the task on. Optional. Obtain from weeek_list_boards. If omitted, WEEEK assigns to the project's default board. | |
| date_end | No | Due date in ISO 8601 format (e.g. 2026-04-15 or 2026-04-15T12:00:00Z). Optional. WEEEK's task model uses dateEnd, not dueDate. | |
| priority | No | Task priority as an integer (WEEEK uses numeric priority levels, e.g. 0=none, 1=low, 2=medium, 3=high). Optional. | |
| project_id | Yes | WEEEK project ID. Required. Obtain from weeek_list_projects — do not guess. | |
| assignee_id | No | WEEEK user UUID to assign as primary. Optional. Obtain from weeek_list_workspace_members — do not guess IDs. | |
| description | No | Task description / body. Optional. Plain text; WEEEK may render basic formatting. | |
| board_column_id | No | Column (status) to place the task in. Optional. Obtain from weeek_list_board_columns. Determines the task's initial status. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it's a WRITE OPERATION and may prompt for confirmation. No annotations are present, so the description carries the burden. It could mention side effects like notifications or dependencies, but overall sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with front-loaded purpose, parameter requirements, and usage guidelines. Slightly lengthy but every sentence adds value. Could be more concise by combining a few sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters with 2 required, no output schema, and no annotations, the description is thorough: explains all parameters, return shape (same as weeek_get_task), and provides contextual guidance for ID sources and sibling tool differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema description coverage, the description adds significant value by explaining where to obtain IDs (list tools), format expectations (ISO 8601 dates, integer priority), and optional behaviors (default board assignment).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a NEW task in WEEEK, specifies required parameters (title, project_id), and distinguishes from sibling tools like weeek_update_task, weeek_move_task, and weeek_complete_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (creating a brand-new task) and when not to (use update, move, complete instead). Also warns not to guess IDs, directing to list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details of a specific WEEEK project by ID. Use this AFTER weeek_list_projects to drill into a project and see its description, creation date, and settings. Returns the full project object. For listing boards inside the project, use weeek_list_boards with this project's id. The project_id parameter must be obtained from weeek_list_projects (do not guess IDs).
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | WEEEK project ID. Obtain from weeek_list_projects — do not guess. Required. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States 'Returns the full project object' but does not disclose any potential side effects, authentication needs, or response structure details. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences; front-loaded with purpose. Every sentence adds necessary context without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one parameter, the description covers workflow integration and return value. No output schema needed; 'full project object' suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter with 100% schema coverage. Description adds value by specifying how to obtain the ID and that guessing is disallowed, which is beyond the schema's basic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool gets full details of a specific project by ID. Distinguishes from siblings like weeek_list_projects for listing all projects and weeek_list_boards for boards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use after weeek_list_projects, warns against guessing IDs, and directs to weeek_list_boards for boards. Provides clear sequencing and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details of a single WEEEK task by ID. Use this AFTER weeek_list_tasks when an agent needs the complete task context — full description, priority, assignee, due date, board/column location, timestamps. The task_id must come from weeek_list_tasks — do not guess IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | WEEEK task ID. Obtain from weeek_list_tasks. Required. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return fields (description, priority, assignee, etc.) and implies read-only behavior. However, it doesn't explicitly state that the tool has no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, followed by usage guidance. Every sentence adds value with no redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool with no output schema, the description lists the key return fields (description, priority, assignee, etc.) and provides complete context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (task_id) with 100% schema coverage. The description adds meaning by stating 'must come from weeek_list_tasks' and 'do not guess IDs,' which the schema alone does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Get full details of a single WEEEK task by ID,' which is a specific verb+resource. It clearly distinguishes from sibling tools like weeek_list_tasks (list vs. single) and weeek_update_task (update vs. get).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this AFTER weeek_list_tasks when an agent needs the complete task context' and instructs 'do not guess IDs,' providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List columns (status buckets) of a specific WEEEK board. Use this AFTER weeek_list_boards to understand the statuses that exist on a board — e.g. 'Todo', 'In Progress', 'Done'. Columns are the task status mechanism in WEEEK; you MUST call this before weeek_move_task (Phase 3) to know which column_id to target. Returns array of {id, name, boardId, order}. The board_id parameter must come from weeek_list_boards — do not guess.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (1-50, default: 20). Default protects against 25k-token MCP response cap. | |
| offset | No | Number of items to skip for pagination (default: 0) | |
| board_id | Yes | WEEEK board ID whose columns to list. Obtain from weeek_list_boards. Required. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses return format as array of {id, name, boardId, order}. Notes that default limit of 20 protects against MCP response cap, indicating rate awareness. Could explicitly state read-only nature, but sufficiently safe implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero fluff. First sentence states purpose, second covers usage order and return format, third clarifies parameter source. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no annotations or output schema, description provides purpose, usage ordering, parameter constraints, return structure, and rationales. Covers all essential information for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema documentation covers all 3 parameters. Description adds value: explains board_id must be obtained from weeek_list_boards and warns against guessing. Also contextualizes default limit as protection against token cap. This extra guidance elevates above baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly describes the tool as listing columns (status buckets) of a specific WEEEK board. Defines verb, resource, and clarifies columns as task status mechanism. Differentiates from sibling tools by specifying use after weeek_list_boards and before 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use this AFTER weeek_list_boards' and 'MUST call this before weeek_move_task (Phase 3)'. Also warns that board_id must come from weeek_list_boards and not to guess, providing clear sequencing and prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all boards inside a WEEEK project. Use this AFTER weeek_list_projects to discover kanban boards within a project. A board is a container of columns (statuses) and tasks. Returns array of {id, name, projectId, type}. To see the columns/statuses of a specific board, use weeek_list_board_columns next. The project_id parameter must come from weeek_list_projects — do not guess.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (1-50, default: 20). Default protects against 25k-token MCP response cap. | |
| offset | No | Number of items to skip for pagination (default: 0) | |
| project_id | Yes | WEEEK project ID whose boards to list. Obtain from weeek_list_projects. Required. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return format but does not mention auth requirements, rate limits, or side effects. For a read-only list operation, this is adequate but not excessive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, no wasted words, purpose front-loaded. Every sentence earns its place: purpose, usage order, return description, next step.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description explains return structure. Includes prerequisites, parameter source, and next tool. Completeness is high for a list tool with well-described schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters, but the description adds value for project_id by specifying its source and for limit by explaining the default protects against response cap. This extra context justifies above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all boards inside a WEEEK project' with specific verb and resource, and distinguishes from siblings like weeek_list_projects and weeek_list_board_columns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use this tool 'AFTER weeek_list_projects' and specifies that the project_id must come from that tool, with a warning not to guess. Also provides the next step of using weeek_list_board_columns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List projects in the WEEEK workspace. Use this FIRST when an agent needs to discover what projects exist before drilling into boards or tasks. Returns an array of projects with id, name, parentId (for nested projects), and isArchived flag. For a specific project's full details, use weeek_get_project with the id returned here. For board discovery within a project, use weeek_list_boards next.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (1-50, default: 20). Default protects against 25k-token MCP response cap. | |
| offset | No | Number of items to skip for pagination (default: 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return format (array with id, name, parentId, isArchived) and the typical workflow, which adds value. However, it does not discuss other behavioral traits like rate limits, idempotency, or side effects. Still, the return structure and workflow context make it a 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with no wasted words. It starts with the main purpose, then gives usage guidance, return format, and clear next steps. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return structure. It also covers the typical workflow (first tool to use) and references sibling tools for next steps. Parameter details are fully covered in the schema. The description is complete for a list tool in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add any parameter-specific information beyond what the schema already provides via descriptions for limit and offset. No additional meaning is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List projects in the WEEEK workspace' with a specific verb and resource. It distinguishes itself from sibling tools by positioning it as the first tool to use for discovery before drilling into boards or tasks, and directly references alternatives for specific details (weeek_get_project) and board discovery (weeek_list_boards).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this FIRST when an agent needs to discover what projects exist before drilling into boards or tasks.' It provides clear context for when to use it and when to use alternatives, such as 'For a specific project's full details, use weeek_get_project' and 'For board discovery within a project, use weeek_list_boards next.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tasks in WEEEK with optional filters. This is the PRIMARY tool for 'what needs doing?' queries. Filter by project_id, board_id, column_id (status), assignee_id, or is_completed. Pagination is ENFORCED: default 20, max 50 per response, to stay under the 25k-token MCP response cap — call again with a higher offset if more are needed. Returns shaped tasks with id, title, projectId, boardId, boardColumnId, assigneeId, isCompleted, priority, dueDate. For full task description and details, use weeek_get_task with an id returned here. All *_id parameters must come from weeek_list_projects / weeek_list_boards / weeek_list_board_columns — do not guess IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (1-50, default: 20). Default protects against 25k-token MCP response cap. | |
| offset | No | Number of items to skip for pagination (default: 0) | |
| board_id | No | Filter to tasks on this board. Obtain from weeek_list_boards. | |
| column_id | No | Filter to tasks in this column (status). Obtain from weeek_list_board_columns. | |
| project_id | No | Filter to tasks in this project. Obtain from weeek_list_projects. | |
| assignee_id | No | Filter to tasks assigned to this user (WEEEK user UUID). Obtain from weeek_list_workspace_members. | |
| is_completed | No | If true, return only completed tasks; if false, only open; if omitted, both. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses enforced pagination (default 20, max 50) with rationale (25k-token cap), describes the return shape (specific fields), and clarifies that full details require a separate tool call. No annotations exist to contradict.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Compact (~120 words) yet comprehensive; every sentence adds value with no redundancy. Front-loaded with purpose and key instructions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-param list tool with no output schema and no annotations, the description covers filters, pagination, return shape, limitations, dependencies, and alternative tool usage. Thorough and complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description adds critical context: each filter parameter must come from designated tools (weeek_list_boards, etc.), explains pagination defaults and limits, and clarifies is_completed behavior. This goes well beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists tasks with optional filters and positions itself as the PRIMARY tool for 'what needs doing?' queries, distinguishing it from sibling tools that list other entities (boards, projects, etc.) or retrieve full task details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use context, explains filtering options, pagination behavior, and cautions against guessing IDs, directing the agent to companion tools for valid parameter values.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List members (users) of the WEEEK workspace. Use this FIRST when an agent needs to resolve a person's name to a user ID — required before filtering tasks by assignee_id in weeek_list_tasks or setting assignee_id on weeek_create_task / weeek_update_task. Returns shaped members with id, name, email, role. Pagination ENFORCED: default 20, max 50 per response. The WEEEK workspace is determined by the API token.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return (1-50, default: 20). Default protects against 25k-token MCP response cap. | |
| offset | No | Number of items to skip for pagination (default: 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it is a read operation (lists members), enforces pagination (default 20, max 50), and returns shaped members. It does not contradict any safety hints because none are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but thorough, with no wasted words. Each sentence serves a purpose: purpose, usage guidance, return shape, pagination, and token determination. The most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides return shape, pagination details, and when to use. It covers all necessary context for an agent to correctly invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema already covers both parameters (limit, offset) with descriptions. The description adds value by explaining the default limit protects against the 25k-token response cap, which is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists workspace members with specific return fields (id, name, email, role). It distinguishes from siblings by stating it is needed for resolving names to IDs before using other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this FIRST when an agent needs to resolve a person's name to a user ID' and lists specific sibling tools (weeek_list_tasks, weeek_create_task, weeek_update_task) that require the output. It also notes workspace is determined by API token.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move a WEEEK task to a different board column. This IS how you change a task's status in WEEEK — columns ARE the status mechanism. WRITE OPERATION — the MCP client may prompt for confirmation. Required: task_id and board_column_id. Optional: board_id (only when moving across boards), mr_url (records a merge/pull request link on the "МР" custom field in the same call), field_name (only with mr_url). Returns the updated task. DISTINCT from weeek_update_task: use update for field edits (title, description, priority, assignee, due date); use move for column/status changes. DISTINCT from weeek_complete_task: use complete for the done/undone toggle even though 'completed' is visually similar to a 'Done' column. board_column_id must come from weeek_list_board_columns — do not guess.
| Name | Required | Description | Default |
|---|---|---|---|
| mr_url | No | Merge/pull request URL to record on the task's "МР" custom field in the same call as the status change. Optional. Omit to leave the field unchanged. Use weeek_set_task_mr_link instead if there is no status change happening. | |
| task_id | Yes | WEEEK task ID to move. Required. Obtain from weeek_list_tasks. | |
| board_id | No | Destination board ID. Optional — only needed when moving the task to a column on a DIFFERENT board than its current one. | |
| field_name | No | Name of the custom field to write mr_url into. Optional — defaults to "МР". Only used when mr_url is provided. | |
| board_column_id | Yes | Destination column ID. Required. Obtain from weeek_list_board_columns. Moving a task to a new column IS the status change in WEEEK. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It labels itself as a WRITE OPERATION with possible confirmation prompt, describes effect (status change, optional MR link), and notes board_id usage. Some minor behavioral details (reversibility, notifications) omitted, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is somewhat lengthy but every sentence contributes value. Front-loaded with core purpose. Could combine some points for slightly tighter prose, but still well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description notes it returns updated task. All 5 parameters covered, required ones emphasized, sibling distinctions provided. Complete for the tool's complexity and context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but description adds key context: board_column_id is the destination column, moving equals status change, warns against guessing column IDs, explains mr_url and field_name relationship, and clarifies board_id optionality across boards.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Move' and resource 'task to a different board column', immediately distinguishing it from update and complete tools. It avoids tautology and is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (changing column/status) and when not (use update for field edits, complete for done/undone, set_mr_link without status change). Also specifies prerequisite: get board_column_id from weeek_list_board_columns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Attach a merge/pull request URL to a WEEEK task by writing it into the "МР" custom field. WRITE OPERATION — the MCP client may prompt for confirmation. Required: task_id, mr_url. Optional: field_name (defaults to "МР"). Call this right after opening an MR/PR for a task. The custom field must already exist on the task's project in WEEEK — this tool only writes to it, it does not create custom fields. To record the MR link at the same time as a status change, pass mr_url to weeek_move_task or weeek_complete_task instead. task_id must come from weeek_list_tasks.
| Name | Required | Description | Default |
|---|---|---|---|
| mr_url | Yes | Merge/pull request URL to store on the task. Required. | |
| task_id | Yes | WEEEK task ID to update. Required. Obtain from weeek_list_tasks — do not guess. | |
| field_name | No | Name of the WEEEK custom field to write mr_url into. Optional — defaults to "МР". Must match an existing custom field on the task's project exactly (case-insensitive). This tool does not create the field. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that this is a write operation and may prompt for confirmation, explains it only writes to existing fields, and lists required parameters. Does not mention overwrite behavior, but 'write' implies replacement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with purpose and write warning. Follows with required/optional parameters, usage context, and alternatives. Every sentence adds value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description is fully complete for this simple write tool. Covers purpose, when to use, parameter details, prerequisites, and alternatives. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. Description adds meaning: mr_url is the URL to store, task_id must be obtained from weeek_list_tasks, field_name defaults to 'МР', must match exactly (case-insensitive), and that the tool does not create the field. This goes beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action: attaching a merge/pull request URL to a WEEEK task by writing into a specific custom field. Distinguishes from sibling tools like weeek_move_task and weeek_complete_task by noting they can record the MR link simultaneously with a status change.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage: 'Call this right after opening an MR/PR for a task.' Gives clear alternatives for simultaneous status changes and warns that the custom field must already exist. Includes prerequisites and source for task_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update editable fields of an EXISTING task in WEEEK. WRITE OPERATION — the MCP client may prompt for confirmation. Required: task_id. Optional: title, description, priority, assignee_id, due_date — only provided fields are sent, omitted fields remain unchanged. Returns the updated task. Do NOT use this to move tasks between columns (use weeek_move_task) or to mark tasks complete (use weeek_complete_task) — those are separate operations in WEEEK. The task_id must come from weeek_list_tasks.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | New task title. Optional. Omit to leave unchanged. | |
| task_id | Yes | WEEEK task ID to update. Required. Obtain from weeek_list_tasks — do not guess. | |
| date_end | No | New due date in ISO 8601. Optional. Omit to leave unchanged. WEEEK's task model uses dateEnd, not dueDate. | |
| priority | No | New priority integer (e.g. 0=none, 1=low, 2=medium, 3=high). Optional. | |
| assignee_id | No | New primary assignee WEEEK user UUID. Optional. Obtain from weeek_list_workspace_members. Omit to leave unchanged. | |
| description | No | New task description. Optional. Omit to leave unchanged. Pass empty string to clear. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses it is a WRITE OPERATION and warns the MCP client may prompt for confirmation. It notes that only provided fields are sent and omitted fields remain unchanged. Without annotations, this adds good behavioral context, though it could mention error handling or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with 5 sentences, front-loaded with the main action, and each sentence provides essential information without fluff. Warnings are placed logically.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description states 'Returns the updated task', which is sufficient. Covers required and optional parameters, and separates concerns by referencing sibling tools. Complete for a simple update tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by summarizing which parameters are optional and the partial-update behavior. However, there is a minor mismatch: description refers to 'due_date' while schema uses 'date_end', which could cause confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update editable fields of an EXISTING task in WEEEK' with specific editable fields listed. It distinguishes from sibling tools by explicitly mentioning not to move or complete tasks, referencing weeek_move_task and weeek_complete_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-not-to-use guidance: 'Do NOT use this to move tasks between columns (use weeek_move_task) or to mark tasks complete (use weeek_complete_task).' Also specifies that task_id must come from weeek_list_tasks, giving a clear prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0weeek_complete_taskweeek_create_taskweeek_get_projectweeek_get_taskweeek_list_board_columnsweeek_list_boardsweeek_list_projectsweeek_list_tasksweeek_list_workspace_membersweeek_move_taskweeek_set_task_mr_linkweeek_update_taskScored across 12 tools
Each tool targets a distinct operation (complete, create, move, update, list, etc.) with explicit differentiation. Even similar tools like complete_task vs move_task vs update_task are clearly separated by descriptions and use cases.
All 12 tools follow the consistent pattern `weeek_<verb>_<noun>` using snake_case. Verbs (list, get, create, update, move, complete, set) are uniformly applied across the set.
12 tools is a well-scoped number for a task management server. It covers essential operations for tasks, projects, boards, columns, and members without unnecessary redundancy.
The tool surface is nearly complete for task management: create, read, update, move, complete, and link MRs. Minor gaps exist (no task deletion, no project/board/column creation or update), but core workflows are fully covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Task management for people and AI agents, with scoped OAuth access to issues, projects, and docs.
AI agents use CalmBoard MCP to access board data, tasks, insights, and project workflows.
Task & board management for AI agents + humans. Kanban, comments, digests via MCP.
Give your AI agents the tools to build, manage, and run automation workflows.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/MakarGlavanar/weeek-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
