Task Hub MCP

by zjuphD

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation5/5
Each tool targets a distinct lifecycle step: init creates, save checkpoints, list queries, load restores, resume reactivates, and stop pauses/archives. The only potential overlap between task_load and task_resume is resolved by task_resume's explicit role in reactivating paused tasks, while task_load requires a name and returns context.
Naming Consistency5/5
All tools follow the consistent pattern task_<verb> in snake_case, with clear verbs (init, save, list, load, resume, stop). This makes the toolset predictable and easy to navigate.
Tool Count5/5
With six tools, the server is well-scoped for task tracking: creation, state saving, listing, loading, resuming, and stopping. No redundancy or unnecessary tools are present.
Completeness5/5
The task lifecycle is fully covered: init creates a task, save persists progress, load retrieves context, resume reactivates, stop pauses or archives, and list provides an overview. No obvious missing operations for the stated purpose.
Average 4.2/5 across 6 of 6 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It explains the return value and the optional conversation log, but does not state whether the operation is read-only, whether it modifies task state, or what happens on missing tasks.
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 core purpose and stays reasonably compact. The trigger phrases and Args section are useful, though there is minor redundancy between 'continue working' and 'everything you need to continue the task'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter loader, the description covers the essential input and output semantics. However, it lacks explicit read-only assurance, error behavior, and differentiation from task_resume, so an agent may still be uncertain about side effects or alternatives.
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 0%, but the description's Args section adds real meaning: name is a task name or ID, and include_conversation controls whether the full log is included. This goes beyond the bare schema and effectively documents both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads a task's context to continue working, with a specific verb and resource. It also notes the return value (context.md), which helps distinguish from siblings, though it doesn't explicitly contrast with task_resume.
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 gives explicit trigger phrases ('load task X', '加载 X 任务') and the general case 'wants to resume a specific task'. However, it doesn't mention when not to use it or point to task_resume as an alternative, which is a notable gap given the sibling tool.
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 present, so the description must carry the full burden. It does disclose important behaviors: expected_revision rejects stale saves, progress is appended, messages append to conversation.jsonl, and artifacts are snapshotted. However, it doesn't clarify overwrite vs. merge semantics for the entire task state or behavior when the task doesn't exist, leaving some behavioral ambiguity.
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 well-structured: an action line, a trigger sentence, guidance on the context parameter, and a detailed Args list. Each section adds value, though the initial context guidance slightly overlaps with the context parameter description, preventing a perfect score.
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 tool with 9 parameters and no annotations, the description covers purpose, triggers, and all parameter semantics, and even adds a concurrency note. The output schema exists, so return values need not be explained. However, it omits the relationship to task_init/task_load and failure behavior, leaving some context gaps.
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 coverage is 0%, but the Args section provides meaningful descriptions for all 9 parameters, including formats (e.g., '/abs/path', list of strings) and semantic guidance (e.g., 'distilled, not raw conversation'). This fully compensates for the schema's lack of 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?
The description states 'Save the current state of a task' with a specific verb and resource, clearly identifying the action. The trigger phrasing ('when the user says "save"') also differentiates it from sibling tools like task_load and task_init.
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 explicit trigger conditions: 'Call this when the user says "save", "保存", or wants to checkpoint progress.' This is clear usage guidance, though it does not explicitly mention alternatives or when not to use it. The context is sufficient for a save/checkpoint operation.
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 must carry the behavioral burden. It correctly implies read-only behavior via 'List' but does not explicitly state that it is safe or non-destructive, nor does it mention any permissions or side effects. 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 compact, front-loaded with the main purpose, and includes only necessary usage triggers and parameter explanations. Every sentence earns its place 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 listing tool with two optional parameters and an existing output schema, the description fully covers what the tool does, when to use it, and how parameters behave. No critical information is missing.
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 description adds significant meaning to the parameters beyond the schema by explaining 'Filter by status' and listing the valid statuses ('active', 'paused', 'archived'), and clarifying 'Filter by tag'. Schema coverage is 0%, so the description compensates well.
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 saved tasks ('List all saved tasks'), which distinguishes it from siblings like task_save, task_load, etc. It uses a specific verb and resource, leaving no ambiguity about its function.
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 provides explicit triggers ('what tasks do I have', '有哪些任务') and a clear use case ('before loading one'). It does not explicitly state when not to use it or mention alternatives, but the context is strong enough to guide selection.
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 burden of behavioral disclosure. It reveals that archive is 'Permanently archive instead of pausing' and that expected_revision 'rejects stale updates,' which are useful behavioral traits. Yet it does not elaborate on side effects, reversibility of pause, or what 'stop tracking' entails beyond the basic pause/archive distinction.
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 and well-structured: a one-sentence summary, trigger phrases, and an Args list. It is front-loaded and every sentence earns its place, with no redundant or vague content.
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?
The description explains all four parameters and the core behavior, and since an output schema exists, return values need not be described. Minor gaps remain, such as the exact state transition when pausing vs archiving, but the overall context is sufficiently complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description compensates fully for the 0% schema coverage by explaining every parameter in the Args section, including the purpose of expected_revision ('Revision returned by task_load; rejects stale updates'). This adds meaning far beyond the bare schema titles and defaults.
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 with a specific verb and resource: 'Stop tracking a task by pausing or archiving it.' It also provides concrete trigger phrases, effectively distinguishing it from siblings like task_resume, task_save, and task_init.
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 gives explicit when-to-use context: 'Call this when the user says "stop tracking", "不用追踪了", or wants to archive/finish a task.' However, it does not mention when not to use it or explicitly reference alternatives, so it falls short of a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the save location (~/.task-hub/tasks/<id>/) and the slugification of the task name, plus the fact that it starts tracking immediately. It does not mention potential overwrite behavior or error conditions, but the key side effects are transparent for a create-and-start 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 well-structured: a one-line purpose statement, a usage sentence, a storage location note, and an Args list. Every sentence contributes new information — no fluff or repetition. It is appropriately sized for a three-parameter tool.
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?
The description covers purpose, usage, storage side-effect, and parameter semantics, which is strong for a simple init tool. The output schema is present, so return value details are not required. Minor omissions like duplicate-name behavior or whether tracking auto-stops on errors are not critical for this tool's simplicity.
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?
The input schema has zero description coverage, so the description must explain parameters. It does so comprehensively: 'name' (slugified for directory), 'description' (what the task is about), and 'tags' (optional filtering with an example). This adds meaning beyond the bare schema fields and fully compensates for the missing 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?
The description opens with 'Create a new task and start tracking it' — a specific verb+resource+outcome. It clearly distinguishes this from siblings like task_resume and task_save by emphasizing 'new task' and 'start tracking', which aligns with the tool name 'task_init'.
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 'Use this when the user wants to begin a new tracked task', providing explicit usage context. It does not directly name alternatives, but the 'new' qualifier implicitly differentiates from task_resume/task_load, and sibling names are available in context. Lacks an explicit 'when not to use' clause but is otherwise clear.
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 selection logic for when no name is provided (most recent active, then most recent paused). With no annotations provided, this adds valuable context beyond the tool's name, though it does not mention potential errors or 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?
The description is concise yet informative, front-loading the core purpose and including usage triggers and fallback logic in a compact format.
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 and an output schema, the description covers the essential aspects: purpose, usage, parameter semantics, and default behavior. It does not mention error handling, but that is likely covered by the output schema or is unnecessary.
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?
The description explains the 'name' parameter as an optional task name or ID, and clarifies the default behavior when omitted. Given the schema has no descriptions, this fully compensates for the 0% 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 'Continue a task, reactivating it when paused' with a specific verb and resource. It distinguishes from sibling tools like task_load by emphasizing reactivation and fallback behavior.
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 explicitly specifies trigger phrases including natural language examples and 'resume'. It describes the fallback behavior without naming alternatives, so it lacks explicit when-not-to-use guidance but provides clear context.
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:

[![task-hub-mcp MCP server](https://glama.ai/mcp/servers/zjuphD/task-hub-mcp/badges/card.svg)](https://glama.ai/mcp/servers/zjuphD/task-hub-mcp)

Score Badge

Copy to your README.md:

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

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