en es ja ko zh

Google Tasks MCP Server

Name: Google Tasks MCP Server
Author: mstfe

by mstfe

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

Google Tasks MCP 服务器

用于管理 Google Tasks 的模型上下文协议 (MCP) 服务器。

这款基于 TypeScript 的 MCP 服务器通过与 Google Tasks API 集成，演示了 MCP 的核心概念。它允许以结构化且高效的方式管理任务。

特征

资源

默认任务列表：通过 URI tasks://default访问默认 Google 任务列表中的任务。
任务详情：提供有关任务的元数据，例如标题、注释和完成状态。
JSON Mime 类型：任务以机器可读的 JSON 格式表示。

工具

create_task ：在默认任务列表中创建新任务。
- 参数：
  - title （字符串，可选）：任务的标题。
  - notes （字符串，可选）：任务的附加注释。
  - taskId （字符串，可选）：任务的唯一 ID。
  - status （字符串，可选）：任务的状态（例如“needsAction”或“completed”）。
- 响应：返回已创建任务的详细信息。
list_tasks ：列出默认任务列表中的所有任务。
- 参数：无。
- 响应：返回默认任务列表中所有任务的 JSON 数组。
delete_task ：从默认任务列表中删除一项任务。
- 参数：
  - taskId （字符串，必需）：要删除的任务的 ID。
- 响应：确认成功删除任务。
update_task ：更新默认任务列表中的现有任务。
- 参数：
  - taskId （字符串，必需）：要更新的任务的 ID。
  - title （字符串，可选）：任务的新标题。
  - notes （字符串，可选）：任务的新注释。
- 响应：返回任务的更新详情。
complete_task ：切换任务的完成状态。
- 参数：
  - taskId （字符串，必需）：用于切换完成状态的任务的 ID。
- 响应：返回更新的任务详细信息，包括新状态。

Related MCP server: MCP Server

功能

通过 MCP 轻松与大型语言模型 (LLM) 或其他应用程序集成。
结构化的工具定义使任务管理变得直观且易于访问。
全面支持创建、列出、删除、更新和切换任务的完成状态。

用法

运行服务器

要启动服务器：

node build/index.js

可用命令

create_task ：使用可选参数创建新任务。

{
  "title": "Complete project",
  "notes": "Finalize module 3",
  "status": "needsAction"
}

list_tasks ：检索默认任务列表中的所有任务。
- 无需任何参数。
- 返回任务数组。
delete_task ：通过 ID 删除任务。
```
{
  "taskId": "unique-task-id"
}
```

update_task ：通过任务 ID 更新任务的标题、注释或其他详细信息。

{
  "taskId": "unique-task-id",
  "title": "Updated task title",
  "notes": "Updated task notes"
}

complete_task ：切换任务的完成状态。
```
{
  "taskId": "unique-task-id"
}
```

`complete_task`的示例响应

完成之前

{
  "taskId": "unique-task-id",
  "title": "Finish the report",
  "status": "needsAction"
}

完成后

{
  "taskId": "unique-task-id",
  "title": "Finish the report",
  "status": "completed"
}

调试

由于 MCP 服务器通过 stdio 进行通信，因此调试需要额外的工具。我们建议使用MCP Inspector 。

启动检查器：

npm run inspector

检查器将提供一个 URL 来访问浏览器中的调试工具，从而更轻松地测试和调试服务器。

执照

此 MCP 服务器遵循 MIT 许可证。这意味着您可以自由使用、修改和分发该软件，但须遵守 MIT 许可证的条款和条件。

Available Tools

4 tools

complete_taskC

Toggle the completion status of a task

ParametersJSON Schema

Name	Required	Description	Default
`taskId`	Yes	ID of the task to toggle completion status
`status`	No	Status of task, needsAction or completed

TDQS

C2.9/5.0

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 of behavioral disclosure. It states the tool 'toggles' completion status, which implies a mutation operation, but doesn't specify whether this requires permissions, is reversible, has side effects, or what the response looks like. The description lacks details on rate limits, error conditions, or how the toggle interacts with the 'status' parameter, leaving behavioral traits unclear.

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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse. Every part of the sentence earns its place by conveying essential information concisely.

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?

Given the tool's complexity (a mutation operation with 2 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, reversibility, or response format, nor does it provide usage context relative to siblings. For a mutation tool with no structured safety or output information, the description should do more to compensate.

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 clear descriptions for both parameters ('taskId' and 'status'). The description adds no additional meaning beyond what the schema provides—it doesn't explain parameter interactions, constraints, or usage examples. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description neither compensates for gaps nor adds value.

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 action ('toggle') and resource ('completion status of a task'), making the purpose immediately understandable. It doesn't explicitly distinguish from siblings like 'create_task' or 'delete_task', but the verb 'toggle' implies a different operation than creation or deletion. The description avoids tautology by not just restating the name 'complete_task'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage 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 like 'create_task' or 'delete_task'. It doesn't mention prerequisites (e.g., needing an existing task), exclusions, or contextual factors. While the action 'toggle' implies it modifies existing tasks, this is only implied rather than explicitly stated as usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_taskB

Create a new task in Google Tasks

ParametersJSON Schema

Name	Required	Description	Default
`title`	Yes	Title of the task
`notes`	No	Notes for the task

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. While 'Create' implies a write/mutation operation, the description doesn't address permission requirements, whether the operation is idempotent, what happens on failure, or any rate limits. It provides minimal behavioral context beyond the basic action.

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, efficient sentence that states the core purpose without any wasted words. It's appropriately sized for a simple creation tool and gets straight to the point.

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 creation tool with no annotations and no output schema, the description provides basic purpose but lacks important context about behavioral traits, error handling, and relationship to sibling tools. It's minimally adequate but has clear gaps in completeness given the mutation nature of the 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 both parameters ('title' and 'notes') fully documented in the schema. The description adds no additional parameter information beyond what the schema already provides, so the baseline score of 3 is appropriate when the schema does the heavy lifting.

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 action ('Create a new task') and the target resource ('in Google Tasks'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'complete_task' or 'delete_task' beyond the obvious action difference.

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. The description doesn't mention prerequisites, when not to use it, or how it relates to sibling tools like 'list_tasks' for viewing existing tasks before creating new ones.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete_taskC

Delete a task from the default task list

ParametersJSON Schema

Name	Required	Description	Default
`taskId`	Yes	ID of the task to delete

TDQS

C2.9/5.0

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 of behavioral disclosure. It states this is a deletion operation, implying it's destructive, but doesn't clarify if deletions are permanent/reversible, what permissions are required, or what happens on success/failure. For a mutation tool with zero annotation coverage, 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core action ('Delete a task') without any wasted words. It's appropriately sized for a simple tool with one parameter.

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?

Given this is a destructive mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address critical context like what 'delete' entails (permanent removal?), error conditions, or return values, leaving significant gaps for agent 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?

The input schema has 100% description coverage, with the single parameter 'taskId' clearly documented. The description adds no additional parameter semantics beyond implying deletion targets a specific task ID, so it meets the baseline of 3 where the schema does the heavy lifting.

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 verb ('Delete') and resource ('a task from the default task list'), making the purpose immediately understandable. However, it doesn't explicitly distinguish this from sibling tools like 'complete_task' which might also remove tasks from view, though deletion is more permanent.

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 like 'complete_task' or 'list_tasks'. It doesn't mention prerequisites (e.g., needing an existing task ID) or warn against misuse, leaving the agent to infer usage from context alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_tasksB

List all tasks in the default task list

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden for behavioral disclosure. It states this lists 'all tasks' but doesn't clarify what 'all' means (e.g., completed vs. pending, pagination limits, or sorting). For a read operation with zero annotation coverage, this leaves significant gaps in understanding the tool's 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, efficient sentence that communicates the core purpose without any wasted words. It's front-loaded with the essential information and appropriately sized for a simple tool with no parameters.

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 (0 parameters, no output schema, no annotations), the description is minimally adequate. However, for a listing operation, it should ideally mention what 'all tasks' includes (e.g., status filters, limits) or the return format, especially since there's no output schema to clarify this.

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 0 parameters with 100% coverage, so there's no parameter documentation burden. The description appropriately doesn't waste space discussing nonexistent parameters, earning a baseline score of 4 for not adding unnecessary information.

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 action ('List') and resource ('tasks in the default task list'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'complete_task' or 'create_task', but the verb 'List' inherently distinguishes it from mutation operations.

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. While it's obvious this is for listing tasks rather than creating or deleting them, it doesn't mention whether this should be used for initial discovery, how it relates to filtering or searching capabilities, or any prerequisites for accessing the default task list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesAug 18, 2025
- First observedcomplete_task
- First observedcreate_task
- First observeddelete_task
- First observedlist_tasks

Deploy Server

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

B3.4/5.0

Scored 2026-04-18 11:30 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose targeting specific CRUD operations for tasks: list_tasks retrieves, create_task adds, complete_task updates status, and delete_task removes. There is no overlap or ambiguity between these functions.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case (e.g., list_tasks, create_task, complete_task, delete_task). The naming is uniform and predictable throughout the set.

Tool Count4/5

With 4 tools, the count is reasonable for a task management server, covering core operations. It is slightly lean but functional; minor additions like updating task details could enhance it without being necessary.

Completeness4/5

The toolset provides essential CRUD coverage for tasks (list, create, update via complete, delete), but lacks a dedicated update tool for modifying task details like title or notes. This minor gap is workable for basic workflows.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

todo.vu AOAuth
io.github.mooball
Model Context Protocol server for todo.vu task management and time tracking.
Payments & Billing Project Management Workplace & Productivity
2
Done Bear A
com.donebear
Local-first task manager: create, edit, and complete tasks, projects, and checklists via MCP.
Project Management App Automation
171
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
238
Orbit BOAuth
io.github.Noveum
Task management for people and AI agents, with scoped OAuth access to issues, projects, and docs.
Project Management Workplace & Productivity
94130

Related MCP Servers

Google Tasks MCP Server
App Automation Project Management
arpitbatra123
A
license
A
quality
D
maintenance
A Model Context Protocol server that bridges Claude with Google Tasks, allowing users to manage task lists and tasks directly through Claude interface.
Updated 23 days ago (2026-09-22 11:57 UTC)
15
55 npm
50
MIT
MCP Server
Project Management Communication
RahulRana0707
A
license
Not graded
quality
D
maintenance
A TypeScript implementation of Model Context Protocol that provides integration tools for JIRA ticket creation and TODO management, allowing users to manage tasks through natural language interfaces.
Updated 2 years ago (2025-04-02 12:22 UTC)
38 npm
ISC
Simple TypeScript MCP Server
Note Taking Developer Tools
jasonkneen
F
license
C
quality
D
maintenance
A TypeScript template for building Model Context Protocol servers that implements basic note-taking CRUD operations with JSON responses.
Updated a year ago (2025-05-11 09:03 UTC)
5
1
-
TickTick MCP Server
App Automation Project Management
rafliruslan
A
license
A
quality
D
maintenance
A Model Context Protocol server that integrates with TickTick task management service, allowing AI assistants to list, create, update, and complete tasks with proper timezone handling.
Updated a year ago (2025-05-30 19:41 UTC)
9
5
MIT

Google Tasks MCP 服务器

特征

资源

工具

功能

用法

运行服务器

可用命令

complete_task的示例响应

完成之前

完成后

调试

执照

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches

`complete_task`的示例响应