Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Reclaim.ai MCP Server list my active tasks"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
⚠️ UNOFFICIAL & UNAFFILIATED – This project is not endorsed, sponsored, or supported by Reclaim.ai. It simply uses Reclaim's public API. Use at your own risk and comply with Reclaim's Terms of Service.
Official alternative: Reclaim.ai offers an official remote MCP server at
https://mcp.reclaim.ai. You may prefer the first-party integration over this community server. See Reclaim's setup instructions and #3.
A community‑maintained Model Context Protocol (MCP) server that lets any MCP‑capable client (Claude Desktop, Continue, Cursor, custom scripts, …) interact with the Reclaim.ai API through a set of standard resources & tools.
MCP is the "USB‑C" of LLM integrations – one wire that lets every model talk to every tool.
Run this server once and all your MCP‑aware apps instantly gain Reclaim super‑powers.
Related MCP server: Timesheet MCP Server
Active‑tasks resource (tasks://active)
13 task‑operation tools (list, create, update, complete, timers, …)
🛡 Type‑safe (TypeScript + Zod) & solid error‑handling
📦 Zero‑config stdio transport – perfect for local AI assistants
Tool | Description | Parameters | ✅ Idemp. | ☠️ Destr. |
| List tasks (default = active) |
| ✅ | ❌ |
| Fetch a task |
| ✅ | ❌ |
| Create a new task |
| ❌ | ❌ |
| Update task properties |
| ✅ | ❌ |
| Mark complete |
| ✅ | ❌ |
| Unarchive / mark incomplete |
| ✅ | ❌ |
| Delete permanently |
| ✅ | ✅ |
| Add schedule minutes |
| ❌ | ❌ |
| Start timer |
| ✅ | ❌ |
| Stop timer |
| ✅ | ❌ |
| Log work time |
| ❌ | ❌ |
| Clear scheduling exceptions |
| ✅ | ❌ |
| Prioritise in planner |
| ✅ | ❌ |
COMPLETE ≠ done. Reclaim marks a task COMPLETE when its scheduled block ends, even if you haven't finished the work. This server does include those tasks as active when the LLM uses the tool to pull active tasks (and reminds the model that COMPLETE tasks are still active). However, LLMs (Claude) sometimes ignore COMPLETE tasks when asked for "open" or "active" tasks. If that happens, you may need to prompt the LLM explicitly to "include tasks with status COMPLETE".
Prerequisites
Node.js ≥ 18
Claude Desktop configuration (minimal)
{
"mcpServers": {
"reclaim": {
"command": "npx",
"args": ["reclaim-mcp-server"],
"env": { "RECLAIM_API_KEY": "xxx" }
}
}
}Alternative Configuration:
{
"mcpServers": {
"reclaim": {
"command": "absolute/path/to/node (run `which node` in terminal)",
"args": ["/absolute/path/to/reclaim-mcp-server/dist/index.js"],
"env": { "RECLAIM_API_KEY": "xxx" }
}
}
}If you prefer to install from source:
git clone https://github.com/jj3ny/reclaim-mcp-server.git
cd reclaim-mcp-server
pnpm install && pnpm build
# Run with your API key
RECLAIM_API_KEY=your_api_key node dist/index.jsBug reports & PRs welcome! To contribute:
Fork the repository
Create a feature branch (git checkout -b feature/amazing-feature)
Make your changes (following the code style)
Commit using Conventional Commits (feat:, fix:, etc.)
Push to your branch (git push origin feature/amazing-feature)
Open a Pull Request
Please squash your commits before opening a PR.
MIT – see LICENSE.
Adds scheduled time (in minutes) to a specific Reclaim.ai task. This blocks more time on the user's calendar. Use this if a task needs more time than allocated (e.g., timeChunksRemaining is 0 but work remains) or if a task has status 'COMPLETE' but the user indicates it's not finished.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | The unique ID of the task to add time to. | |
| minutes | Yes | Number of minutes to add. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses the behavioral trait of blocking calendar time, but lacks details on side effects like overwriting existing time or undoability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose. No wasted words; each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with 2 params and no output schema. Description explains the effect (calendar blocking) and provides usage examples, covering all necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; both parameters are described in the schema. Description does not add extra meaning beyond schema descriptions, so baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states verb 'adds time' to a specific Reclaim.ai task and mentions it blocks calendar time. Clearly distinguishes from sibling tools like create_task or update_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides specific scenarios: when timeChunksRemaining is 0 but work remains, or when task status is COMPLETE but unfinished. Gives clear context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clears any scheduling exceptions (e.g., manual adjustments, declines) for a specific Reclaim.ai task, allowing it to reschedule normally.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | The unique ID of the task whose exceptions should be cleared. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond the idempotentHint annotation by defining 'scheduling exceptions' with examples (manual adjustments, declines) and stating the effect (reschedule normally). It does not contradict the annotation, as clearing exceptions is idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action ('clears') and includes context. No wasted words; every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is sufficiently complete. It explains the tool's function and what exceptions are. Could optionally mention that it only affects scheduling exceptions, but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already fully describes the taskId parameter. The description does not add additional meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a specific verb ('clears'), a clear resource ('scheduling exceptions for a Reclaim.ai task'), and the outcome ('allowing it to reschedule normally'). It distinguishes well from sibling tools like reclaim_update_task or reclaim_mark_complete by focusing on exception clearing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a task has scheduling exceptions that prevent normal rescheduling ('allowing it to reschedule normally'). However, it does not explicitly state when not to use it or mention alternative tools for other modifications. Still, the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new task in Reclaim.ai. Requires at least a 'title'. Other fields like 'timeChunksRequired', 'priority', 'deadline', 'notes', 'eventCategory' are optional but recommended.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | Optional notes about the task. | |
| title | Yes | The title of the task. | |
| onDeck | No | Whether to prioritize this task. | |
| status | No | Status of the task. | |
| deadline | No | Deadline: days from now, ISO string, or YYYY-MM-DD. | |
| priority | No | Priority level of the task. | |
| eventColor | No | Color of the task in the calendar. | |
| snoozeUntil | No | Snooze until: days from now, ISO string, or YYYY-MM-DD. | |
| eventSubType | No | Subcategory of the task. | |
| eventCategory | No | Category of the task. | |
| timeChunksRequired | No | Number of 15-minute chunks required. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so description carries full burden. It states creation but omits return value, side effects, permissions, or error conditions. For a write operation, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and required field, second lists recommended optional fields. No redundancy, efficient use of space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers creation purpose and required/recommended fields but lacks output description (no output schema). For a creation tool, agents need to know what is returned to chain actions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, so description adds minimal value. It highlights recommended optional fields (timeChunksRequired, priority, etc.) but does not explain nuances beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Create a new task in Reclaim.ai' with required field 'title' and lists optional fields, distinguishing it from sibling tools like reclaim_update_task or reclaim_list_tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage through purpose but does not explicitly provide when-to-use or alternatives. No guidance on when to use this vs update or other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a specific Reclaim.ai task. This action cannot be undone easily.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | The unique ID of the task to delete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true. The description adds 'cannot be undone easily', which reinforces destructiveness but does not reveal additional behavioral details beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, strictly relevant, no wasted words. Front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, destructive hint, no output schema), the description covers essential purpose and caution. Minor gaps like response format or error handling are not critical for this operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter (taskId). The description does not add any extra semantic meaning beyond the schema, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'permanently delete a specific Reclaim.ai task', specifying the verb and resource. Distinguishes from siblings like 'reclaim_mark_complete' and 'reclaim_update_task' which handle non-destructive or update operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Warns that deletion cannot be undone, implying caution, but does not explicitly state when to use this tool versus alternatives like 'reclaim_mark_complete' for non-permanent removal. Minimal guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves details for a specific Reclaim.ai task by its ID. Note on 'status': If 'COMPLETE', the scheduled time block ended, but the user has NOT marked the task done. It is still considered active/pending.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | The unique ID of the task to fetch. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. The description adds behavioral nuance by explaining that 'COMPLETE' status means the time block ended but user hasn't marked done, which is critical for interpretation. This goes beyond annotation declarations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. First sentence states core purpose, second adds critical behavioral detail. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple tool with one parameter and no output schema, the description adequately covers purpose, parameter usage, and key behavioral nuance. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with a clear description of taskId. The tool description does not add meaning beyond 'by its ID', so it meets the baseline but does not surpass it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Retrieves details for a specific Reclaim.ai task by its ID', using specific verb and resource. It distinguishes from siblings like list_tasks (multiple tasks) and update_task (modification). The additional note on status adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description clearly indicates when to use: when you have a task ID and need details. While it does not explicitly mention when not to use or list alternatives, the sibling tools provide context for differentiation. The semantic note on status helps agent decide based on API behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists Reclaim.ai tasks. Default filter is 'active'. IMPORTANT NOTE ON 'COMPLETE' STATUS: In Reclaim.ai, tasks marked 'COMPLETE' mean their scheduled time block finished, but the user did NOT necessarily finish the work or mark it done. Treat 'COMPLETE' tasks as ACTIVE and PENDING unless they are also ARCHIVED or CANCELLED. If asked for 'active' or 'open' tasks, YOU MUST INCLUDE tasks with status 'COMPLETE'.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Filter tasks: "active" (default) excludes ARCHIVED/CANCELLED/deleted; "all" includes all. | active |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and idempotentHint. The description adds behavioral context: default filter excludes ARCHIVED/CANCELLED tasks, and explains that 'COMPLETE' status does not mean the task is done. This goes beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, then default, then the critical note. It is slightly long due to the important status explanation, but each sentence is necessary to avoid misinterpretation. Could be slightly more concise, but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description covers purpose, default behavior, and the critical status nuance. It doesn't explain return format, but that's acceptable. It is sufficiently complete for the agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The description adds nuance: default behavior of 'active' filter (excluding ARCHIVED/CANCELLED) and the critical note about 'COMPLETE' status. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Lists Reclaim.ai tasks' with a specific verb and resource. It distinguishes from sibling tools like reclaim_get_task (single task) and reclaim_create_task (create) by focusing on listing. The description also specifies default filter and important status nuance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context on when to use this tool (listing tasks) and how to interpret the 'COMPLETE' status, guiding the agent to treat 'COMPLETE' tasks as active. It doesn't explicitly mention when not to use it or compare with siblings, but the important note serves as a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Logs completed work time (in minutes) against a specific Reclaim.ai task. This reduces the remaining time needed and affects future scheduling.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | Optional end time/date (ISO 8601 or YYYY-MM-DD). Defaults to now. | |
| taskId | Yes | The unique ID of the task to log work against. | |
| minutes | Yes | Number of minutes worked. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, the description carries the full burden. It discloses that logging reduces remaining time and affects scheduling, which is helpful. However, it does not mention idempotency, error cases, or required permissions 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The purpose and effect are front-loaded, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter tool with no output schema and empty annotations, the description covers the main action and effect. It could mention the optional end parameter's behavior, but the schema already does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already describes parameters adequately. The description adds no new parameter-specific details beyond the schema, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'logs' and the resource 'completed work time against a Reclaim.ai task', and explains the effect on remaining time and scheduling. It distinguishes from sibling tools like reclaim_start_timer and reclaim_add_time by specifying 'completed work'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for logging completed work but provides no explicit guidance on when to use this tool versus alternatives (e.g., reclaim_add_time, reclaim_start_timer). No when-not-to-use or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Marks a specific Reclaim.ai task as completed/done by the user. This usually archives the task.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | The unique ID of the task to mark as complete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that marking complete 'usually archives the task,' adding context beyond the idempotentHint annotation. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with key action and resource, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose and key behavioral nuance (archiving). For a simple tool with one param and no output schema, it is nearly complete, though it could mention idempotency or state after completion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already fully describes taskId; description adds no additional parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (marks as completed/done) and resource (Reclaim.ai task), with additional detail about archiving. Distinguishes from sibling tools like reclaim_mark_incomplete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for marking tasks complete, but no explicit when-to-use or when-not-to-use guidance, nor mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Marks a specific Reclaim.ai task as incomplete (e.g., unarchives it, moves it back to the planner).
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | The unique ID of the task to mark as incomplete (unarchive). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include idempotentHint: true, which is consistent. The description adds behavioral context by explaining that marking incomplete unarchives and moves back to planner, disclosing side effects beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise, no redundant words. The example parenthetical adds clarity without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (1 param, no output schema, with annotations), the description covers purpose and behavior sufficiently. However, it could mention return behavior or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema's parameter description; it only rephrases 'unarchive' which is already in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('marks') and resource ('task') with a clear state ('incomplete'). It also provides examples ('unarchives it, moves it back to the planner'), distinguishing it from siblings like reclaim_mark_complete and reclaim_delete_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks any guidance on when to use this tool versus alternatives such as reclaim_mark_complete or reclaim_delete_task. No when-not conditions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Marks a specific Reclaim.ai task for prioritization ('On Deck'), increasing its likelihood of being scheduled sooner.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | The unique ID of the task to prioritize. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide idempotentHint: true, indicating multiple calls have same effect. The description adds that the tool increases scheduling likelihood, which is a behavioral outcome not captured by annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence that is front-loaded with the action and immediately clear. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input (one integer parameter) and no output schema, the description sufficiently explains what the tool does and its effect on task scheduling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for taskId, and the description does not add extra meaning beyond what's in the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'marks' and resource 'task', clearly explaining that it prioritizes a task and increases scheduling likelihood. This distinguishes it from sibling tools like reclaim_create_task or reclaim_mark_complete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Does not mention prerequisites, scenarios where it's appropriate, or when not to use it (e.g., compare with reclaim_update_task which might also affect prioritization).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Starts the live timer for a specific Reclaim.ai task. This indicates the user is actively working on it now and helps log time accurately.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | The unique ID of the task to start the timer for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide idempotentHint=true, which the description does not contradict. However, the description adds no extra behavioral context (e.g., what happens if timer already running). Meets minimum given annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no unnecessary words. Purpose is front-loaded and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one required parameter and idempotent annotation, the description covers the essential. Could mention what the return value indicates (e.g., success or current timer state) but not strictly necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage for the single parameter. The description adds no additional meaning beyond the schema's description of 'taskId'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('Starts the live timer') and the resource ('a specific Reclaim.ai task'), distinguishing it from siblings like reclaim_stop_timer and reclaim_add_time.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for actively working on a task but does not explicitly state when not to use (e.g., vs reclaim_add_time for manual logging). Clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stops the live timer for a specific Reclaim.ai task. Time tracked is automatically logged.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | The unique ID of the task to stop the timer for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide idempotentHint=true, reducing the burden. Description adds that time is automatically logged, which is useful. However, no mention of permissions or whether stopping partially logged time affects records.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core action. No wasted words, though combining the two sentences could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with idempotency annotation, the description covers the essential action and outcome. No output schema needed given simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with a clear description of taskId. The description does not add further parameter details beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it stops a live timer for a specific Reclaim.ai task, with the added detail that time is logged. This differentiates it from related tools like reclaim_start_timer, though it could explicitly contrast with reclaim_log_work.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as reclaim_start_timer or reclaim_log_work. The description is purely functional without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update specific fields of an existing Reclaim.ai task using its ID. This performs a PATCH operation – only provided fields are changed. IMPORTANT: Updating fields like 'notes' overwrites the existing content. To append to notes, you MUST first use 'reclaim_get_task' to fetch the current notes, then provide the full combined text (old + new) in the 'notes' field of this update call.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | New notes about the task (overwrites existing). | |
| title | No | The new title of the task. | |
| onDeck | No | New prioritization status. | |
| status | No | New status. | |
| taskId | Yes | The unique ID of the task to update. | |
| deadline | No | New deadline: days from now, ISO string, or YYYY-MM-DD. | |
| priority | No | New priority level. | |
| eventColor | No | New color for the task. | |
| snoozeUntil | No | New snooze until: days from now, ISO string, or YYYY-MM-DD. | |
| eventSubType | No | New subcategory. | |
| eventCategory | No | New category. | |
| timeChunksRequired | No | New number of 15-minute chunks. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool performs a PATCH operation (only provided fields change) and includes an important caveat about notes overwriting. The idempotentHint annotation (false) is consistent with the update behavior described, and no contradictions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences and an important note convey all necessary information with no redundancy. The main action is front-loaded, and the critical usage detail is highlighted effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters and no output schema, the description covers the essential behavioral nuance (PATCH semantics, notes overwrite) and provides a workflow for a common edge case. It lacks examples but is largely complete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the PATCH operation's effect on all parameters and specifically warns about the notes parameter's overwrite behavior, enhancing understanding beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool updates specific fields of an existing Reclaim.ai task via a PATCH operation, which effectively distinguishes it from sibling tools like reclaim_create_task (create) and reclaim_get_task (read).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance for appending to notes (use reclaim_get_task first) and implies use for updating specific fields. While it doesn't exhaustively cover all sibling distinctions, the critical warning about notes offers clear when-to and how-to context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.3reclaim_add_timereclaim_clear_exceptionsreclaim_create_taskreclaim_delete_taskreclaim_get_taskreclaim_list_tasksreclaim_log_workreclaim_mark_completereclaim_mark_incompletereclaim_prioritizereclaim_start_timerreclaim_stop_timerreclaim_update_taskScored across 13 tools
Each tool targets a distinct action on Reclaim.ai tasks: creating, reading, updating, deleting, time management, prioritization, and status changes. No two tools overlap in purpose; even similar verbs like 'add_time' and 'log_work' are clearly differentiated.
All tools follow a consistent 'reclaim_verb_noun' pattern (e.g., reclaim_create_task, reclaim_list_tasks, reclaim_start_timer). The naming is uniform, with clear verbs that describe the action, making it easy to predict tool behavior.
With 13 tools, the server is well-scoped for task management. Each tool covers a necessary operation without being overwhelming. The count is typical for a domain-specific MCP server, providing sufficient functionality without redundancy.
The server covers core CRUD, lifecycle (complete/incomplete), time tracking (add, log, start/stop timer), prioritization, and exception handling. Minor gaps exist, such as no bulk operations or filtering by date range, but the essential workflows are supported.
Manage Superlist tasks and lists in plain language from any MCP-compatible AI agent.
Local-first task manager: create, edit, and complete tasks, projects, and checklists via MCP.
Read tasks, habits, events and scheduling links; create and update Reclaim tasks and habits.
Official Todoist MCP server for AI assistants to manage tasks, projects, and workflows.
