taskboi

Server Quality Checklist

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

Latest release: v1.1.0
Disambiguation5/5
Each tool targets a distinct action on a specific resource type (projects vs tasks), with specialized query tools (today, upcoming, subtasks) clearly differentiated by their purpose. The only potential overlap, get_inbox vs get_project, is resolved by get_inbox being a convenience for the default project. No two tools appear to do the same thing.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case, using verbs like list, get, create, update, delete, complete, and uncomplete. Even the specialized queries get_today_tasks and get_subtasks adhere to the same pattern, making the set predictable and easy to navigate.
Tool Count4/5
With 16 tools, the set is slightly above the typical 3-15 range but still well-scoped for a task management server covering both projects and tasks. Each tool earns its place, covering CRUD plus specialized list and task-state operations. The count feels appropriate, not bloated.
Completeness5/5
The tool surface provides complete CRUD coverage for both projects and tasks, along with essential task lifecycle operations like complete and uncomplete. Specialized queries for today, upcoming, and subtasks fill common workflow needs. There are no obvious dead ends or missing critical operations for the stated domain.
Average 3.5/5 across 16 of 16 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- Last stable release on August 4, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only states the bare action. It fails to mention side effects, permissions, return values, or validation behavior, making it nearly tautological with the tool name.
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 short sentence that is front-loaded and contains zero wasted words. It is appropriately minimal for its purpose, though this brevity contributes to gaps in other dimensions.
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?
The tool has no output schema and no annotations, so the description needs to explain what the tool returns and any behavioral context. It does neither, omitting whether the created project is returned, error conditions, or success semantics, making it inadequate for a create operation with three parameters.
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 input schema covers all 3 parameters (name, icon, color) with descriptions, including constraints like minLength and hex pattern. The description adds no additional parameter meaning beyond what the schema offers, so the baseline score of 3 applies.
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 'Create a new project' clearly states the verb (create) and resource (project), distinguishing it from sibling tools like update_project and delete_project. However, it does not explicitly contrast with siblings, so it loses the top 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?
The description provides no guidance on when to use this tool versus alternatives. It simply states the action without context or exclusions, leaving the agent to infer usage from the name alone.
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 must carry the full burden of disclosing behavior. It only says 'Create', implying a write operation, but does not mention side effects, return value, permissions, or idempotency. This is minimal beyond the purpose.
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, front-loaded sentence with no filler. It is concise and easy to parse, though it may be too sparse to fully function as a standalone definition.
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?
Despite a rich input schema, the description lacks any information about the result of the operation (e.g., whether it returns the created task), when to use it, or constraints like required projectId. With no output schema or annotations, the agent must rely on guesses for important contextual behavior.
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 100%, with each of the 8 parameters explained (e.g., priority meanings, date formats, recurrence rule). The description itself adds no parameter information, so the baseline of 3 applies.
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 states a clear action ('Create') and resource ('a new task'), so the tool's core function is understandable. However, it does not differentiate from sibling task tools like update_task or complete_task, and essentially restates the tool name.
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 such as list_tasks or update_task. There are no prerequisites, exclusions, or context for creating tasks (e.g., which project is needed).
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, the description carries the full burden of behavioral disclosure. It only states 'Delete a task' without indicating whether the deletion is permanent, irreversible, or whether it cascades to subtasks. This is a significant gap for a destructive 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?
The description is a single, concise sentence with no wasted words. It is front-loaded with the action and resource. However, it is so minimal that it edges toward under-specification, lacking useful contextual detail 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?
For a tool that deletes data, the description is incomplete. It does not explain the consequences of deletion, whether it affects related subtasks, or what response to expect (no output schema). The lack of annotations and output schema heightens the need for richer description, which is absent.
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 input schema fully describes the `id` parameter as 'The task ID to delete' with 100% coverage, so the description adds no additional parameter semantics. The baseline of 3 applies because the schema handles the documentation effectively.
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 identifies the action ('Delete') and resource ('a task'), which is specific and unambiguous. However, it does not distinguish from sibling tools like complete_task or update_task, which could be alternatives depending on the desired outcome. It lacks a note about whether deletion is permanent or a soft-delete.
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 on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., task must exist), no scenarios for use, and no exclusions. Sibling tools such as complete_task suggest an alternative workflow, but the description does not address this.
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, the description carries the burden of behavioral disclosure, but it only repeats the tool's name. It does not state whether the update is partial, what happens to unmentioned fields, or any side effects or error conditions.
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, clear sentence with no wasted words. It is appropriately concise, though under-specification limits its usefulness.
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?
As a mutation tool with no annotations and no output schema, the description is too thin. It does not explain return values, failure modes, or the behavior when the project does not exist. The schema covers parameters, but behavioral context is missing.
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 100%, so the parameters are fully documented in the schema. The description adds no parameter-level meaning, which is acceptable given the high coverage, but it does not explain update semantics (e.g., whether all fields are optional or partial).
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 'Update an existing project' clearly states the action (update) and the resource (project), and distinguishes it from create/delete/get siblings. However, it lacks specifics about what aspects can be updated, making it slightly less informative than ideal.
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 alternatives such as create_project or delete_project. It does not mention prerequisites like an existing project ID or the distinction between partial and full updates.
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 present, so the description must carry the behavioral disclosure burden. It merely restates the tool's function ('Get details') without elaborating on return format, fields included, error behavior, or authorization requirements.
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, grammatically complete sentence with no filler or redundancy. It is appropriately sized for a simple retrieve operation and front-loads the core action.
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 one parameter and no output schema, the description is minimally adequate. However, it does not clarify what 'details' encompasses, nor does it differentiate this from sibling tools like get_subtasks, which limits contextual 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?
The schema already covers 100% of the parameter with a description of 'id' as 'The task ID'. The description's mention of 'specific task' aligns with the schema but adds no extra meaning, so the baseline of 3 applies.
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 'Get' and resource 'details of a specific task', clearly indicating a single-task read operation. It is distinguishable from sibling tools like list_tasks or get_project, though it does not explicitly name alternatives.
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 alternatives such as list_tasks, get_today_tasks, or get_subtasks. The schema implies an ID is required, but the description does not explicitly state the typical use case or exclusions.
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 implies read-only via 'Get' but does not state whether this operation modifies data, what 'upcoming' precisely means (e.g., includes today or excludes overdue), or whether completed tasks are filtered out.
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 one short sentence, front-loaded with the verb and resource, and contains no extraneous words. It is appropriately concise and well-structured.
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 is simple with no parameters, but the description leaves ambiguity about the definition of 'upcoming' and how it relates to sibling tools like get_today_tasks. Without an output schema or annotations, more context could be given, but the minimal description is still adequate for a basic read operation.
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 input schema has zero parameters, so the baseline is 4. The description clarifies the scope (upcoming tasks with due dates) but adds no parameter-specific information since there are no parameters to describe.
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 ('Get') and resource ('all upcoming tasks with due dates'), making the purpose clear. It distinguishes from siblings like list_tasks and get_today_tasks by focusing on upcoming tasks with due dates, though it doesn't explicitly name alternatives.
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 siblings like get_today_tasks or list_tasks. There are no exclusions or alternative recommendations, so an agent gets no help choosing among the task-listing tools.
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 simply states the operation without mentioning ordering, recursion depth (e.g., whether nested subtasks are included), error behavior, or return format. This is minimal but not misleading.
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 clear sentence with no filler. It is front-loaded and immediately conveys the action and target resource.
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?
Given the tool's simplicity, the description is adequate but leaves gaps: it does not explain the return value shape, whether subtasks are returned recursively, or what happens if the parent ID does not exist. There is no output schema or annotations to compensate, so an agent may need additional 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?
The schema has 100% coverage for the single parameter parentId, already describing it as 'The parent task ID'. The tool description adds no additional parameter semantics beyond restating that these are subtasks of a parent task, which is already implicit from the tool name and parameter name.
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 'Get all subtasks of a parent task' uses a specific verb ('Get all') and resource ('subtasks of a parent task'), clearly distinguishing it from sibling tools like list_tasks or get_task. The scope 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or conditions that would help an agent decide between get_subtasks and get_task/list_tasks.
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, the description carries full responsibility for disclosing side effects. It only states the action, but does not mention behavior when the task is already incomplete, potential errors, permission requirements, or whether the action is reversible or idempotent.
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, front-loaded sentence (verb 'Mark' + object) with no filler or redundancy. It is an appropriately minimal expression for a simple state-transition 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 description is adequate for a simple single-parameter tool, but lacks edge-case context (e.g., what happens if the task isn't complete), expected return value, and any usage clarification. Given there is no output schema and no annotations, more detail would be expected 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?
The schema already provides 100% coverage with a clear description of the 'id' parameter. The tool description adds no additional meaning beyond that, so the baseline of 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?
The description uses a specific verb ('Mark') and clearly identifies the resource ('a completed task') and its new state ('incomplete'). It directly distinguishes itself from its sibling 'complete_task' by stating the opposite action.
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 does not provide any context for when to use this tool, nor does it mention alternative tools or prerequisites. It does not explicitly say 'use this when reverting a task completion' or contrast with 'complete_task'.
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 must disclose behavioral traits. It only says 'Get details' which essentially restates the tool name and does not explain read-only nature, potential errors (e.g., 404 if not found), or what fields are included in the response. For a simple getter this is a minimal disclosure.
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, complete sentence with no filler. It is front-loaded and uses minimal words to convey the core purpose.
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?
Given the simplicity (one required parameter, no output schema) the description is minimally viable. However, it omits any detail about response structure or error behavior, and with no annotations to compensate, it is not fully complete for a read 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 description coverage is 100% with 'The project ID' for the id parameter. The description adds no extra meaning beyond what the schema already provides, 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?
The description 'Get details of a specific project' clearly states a specific verb (get) and resource (project), and the qualifier 'specific' distinguishes it from list_projects, which retrieves multiple projects. It is unambiguous and aligns with the tool's 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 implies usage for retrieving one project by ID, but does not explicitly mention when to use it over list_projects or state exclusions. There is no guidance on prerequisites or alternative tools, so it meets only the baseline for implied context.
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. It discloses the Inbox deletion restriction, but does not state whether deletion is permanent, cascades to tasks, requires specific permissions, or what the response looks like. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that delivers the core purpose and a key constraint without any redundancy or filler.
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 only one parameter, no output schema, and no annotations, the description should provide more context about deletion consequences, such as impact on associated tasks, reversibility, or required permissions. The Inbox restriction is helpful but leaves significant gaps in understanding.
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%, with the single parameter id fully described as 'The project ID to delete'. The description adds no extra semantics beyond the schema, so the baseline score of 3 applies.
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 'Delete a project' with a specific verb and resource, distinguishing it from sibling tools like create_project, update_project, and list_projects. The additional constraint '(cannot delete Inbox)' provides precise scope.
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 implicitly indicates the tool is for deleting projects, and the 'cannot delete Inbox' exclusion provides a clear when-not-to-use signal. However, it does not explicitly mention alternatives like update_project for modifying a project or list_projects to view projects first.
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. It only says 'Get', which implies a read operation, but does not disclose any behavioral traits such as error handling, permissions, or return format. It is a minimal statement of purpose rather than a disclosure of behavior.
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 no waste. It is appropriately concise for a tool with no parameters.
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?
Given the low complexity (no parameters, no output schema), the description is fairly complete: it states what is returned (the default Inbox project). It could slightly benefit from mentioning what the returned object looks like, but the resource name is self-explanatory.
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 zero parameters, so the description has no need to explain parameter semantics. The baseline for 0 params is 4, and the description adds no irrelevant info.
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 action 'Get' and the specific resource 'default Inbox project', which distinguishes it from sibling tools like list_projects or get_project that operate on arbitrary projects.
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 when the default Inbox is needed, but it does not explicitly contrast with alternatives such as get_project or list_projects. There is no 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It correctly conveys this is a read-only list operation and explains the optional filtering behavior. However, it does not disclose whether the result includes subtasks, whether completed tasks are included, or any default ordering. These are potential gaps, but the core behavior is transparent and not misleading.
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, front-loaded sentence that immediately identifies the action and resource. It is appropriately sized for the tool's simplicity, with no redundant words or filler.
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 simple tool with one optional parameter, no output schema, and no annotations, the description is mostly complete. It states the purpose and the filter option. However, it could benefit from a note clarifying whether subtasks are included and how it relates to specialized sibling views like get_subtasks or get_today_tasks, which would make it fully self-contained.
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 input schema has one optional parameter (projectId) with a description 'Filter by project ID', and the tool description says 'optionally filtered by project'. Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema; it only reaffirms the parameter's purpose without extra context.
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 tasks, optionally filtered by project' uses a specific verb (list) and resource (tasks) with clear scope ('all tasks'). It distinguishes from sibling tools like get_task (singular), get_subtasks (subtasks only), and get_today_tasks/get_upcoming_tasks (specialized views) by explicitly stating the all-encompassing scope without needing to 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 when to use the tool: whenever you need to list tasks, optionally narrowing by projectId. However, it does not explicitly state when not to use it or mention alternatives like get_today_tasks for due-date-specific views. The guidance 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.
Behavior4/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 discloses an important side effect: creating the next occurrence for recurring tasks. This goes beyond the basic 'mark complete' action. It does not cover permissions or error cases, but the disclosed behavior is key for an agent to know.
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, front-loaded sentences with no unnecessary words. The primary action is stated first, and the recurring behavior is a compact second sentence.
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 simple single-parameter tool with no output schema, the description is sufficiently complete: it states the action, notes the recurring task side effect, and matches the sibling context. It could mention return value or error behavior, but these are not required given the tool's simplicity.
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% for the single 'id' parameter, which is self-explanatory. The description adds no additional parameter context, but the baseline is 3 given the schema already documents everything.
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 the specific verb 'Mark' and resource 'task', clearly stating the action. It also distinguishes from siblings by noting the task is completed, and adds recurring-task behavior, which differentiates it from uncomplete_task and update_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 clearly implies when to use this tool (to mark a task complete) and provides a specific context: recurring tasks. It does not explicitly mention alternatives or exclusions, but the context is unambiguous.
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, the description carries the full burden of behavioral disclosure. The verb 'List' implies a non-mutating read operation, but the description does not specify the response format, ordering, or whether archived projects are included. It adds minimal context beyond the obvious.
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, front-loaded sentence with no wasted words. It directly states the action and object, making it highly 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?
For a zero-parameter list tool, the description sufficiently conveys the purpose. However, without an output schema, it could provide more detail on return fields or limitations (e.g., archived vs. active projects), leaving minor gaps for an agent.
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 the description adds no parameter-specific details. The schema already fully covers the (empty) parameters, and the description's mention of 'all projects' aligns with the parameterless scope. Baseline for 0 parameters is 4.
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 the verb 'List' and specifies the resource 'projects in your Taskboi workspace' with scope 'all'. This clearly distinguishes it from siblings like get_project (single project) and create_project (create operation).
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 states it lists all projects, giving clear context for use. It does not explicitly mention alternatives or exclusions, such as using get_project for a single project, so it falls short of the highest bar for usage guidance.
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?
There are no annotations, so the description carries the full burden. It discloses a key behavioral detail: it includes overdue recurring tasks, which is not obvious from the name. It does not mention other behavioral aspects (e.g., whether tasks without due dates are included), but for a simple read operation this is acceptable.
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 sentence that front-loads the primary action ('Get all tasks due today') and appends a clarifying clause. No redundant information.
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 parameterless read tool with no output schema, the description fully explains the tool's scope and a key edge case. It is sufficient for an agent to know what results to expect. The sibling context provides additional disambiguation, but the description itself is complete.
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 the empty schema is fully descriptive. The description doesn't need to explain parameters, and per the baseline for 0-param tools, a score of 4 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?
The description uses a specific verb 'Get' and clearly identifies the resource as 'tasks due today', with an explicit inclusion of 'overdue recurring tasks'. This distinguishes it from sibling tools like get_upcoming_tasks (future tasks) and list_tasks (all 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 a use case for viewing today's actionable tasks, but it does not explicitly state when to use this tool versus siblings like get_upcoming_tasks or list_tasks. No exclusions or alternatives are mentioned, so the agent must infer from the name and scope.
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, the description carries the burden. It transparently explains partial-update behavior and how to remove a due date, which are non-obvious traits. It does not mention permissions or return format, but the core behavioral semantics are disclosed.
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 concise, front-loaded sentences with zero wasted words. The key information about partial updates and clearing due date is presented efficiently.
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?
Given 9 parameters and no output schema, the description is appropriately complete for a CRUD update tool. It covers the main behavioral nuance (partial update) and the special case for clearing due date. It doesn't explain return values, but that is often unnecessary and inferable from context.
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 beyond the schema by explaining that omitted fields are unchanged and that clearDueDate: true removes the due date, clarifying parameter intent and interplay.
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 identifies the tool as updating an existing task, using a specific verb and resource. It distinguishes itself from sibling tools like create_task, complete_task, and delete_task by focusing on modification of existing tasks.
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?
It provides clear context: use when updating an existing task, and notes that omitted fields are unchanged, meaning partial updates are supported. No explicit exclusions or alternative tool mentions, but the purpose is clear enough against its siblings.
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:

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

Score Badge

Copy to your README.md:

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

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