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 작업 MCP 서버

Google Tasks를 관리하기 위한 MCP(Model Context Protocol) 서버입니다.

이 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)이나 다른 애플리케이션과 쉽게 통합할 수 있습니다.
체계적인 도구 정의를 통해 작업 관리가 직관적이고 접근하기 쉬워집니다.
작업 생성, 나열, 삭제, 업데이트 및 완료 상태 전환을 완벽하게 지원합니다.

용법

서버 실행

서버를 시작하려면:

지엑스피1

사용 가능한 명령

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 작업 MCP 서버

특징

자원

도구

기능성

용법

서버 실행

사용 가능한 명령

complete_task 에 대한 응답 예시

완료 전

완료 후

디버깅

특허

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches

`complete_task` 에 대한 응답 예시