WEEEK MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 4.7/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
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. 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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/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 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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/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 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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

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/MakarGlavanar/weeek-mcp/badges/card.svg)](https://glama.ai/mcp/servers/MakarGlavanar/weeek-mcp)

Score Badge

Copy to your README.md:

[![weeek-mcp MCP server](https://glama.ai/mcp/servers/MakarGlavanar/weeek-mcp/badges/score.svg)](https://glama.ai/mcp/servers/MakarGlavanar/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/MakarGlavanar/weeek-mcp'

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