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

Servidor MCP de Google Tasks

Un servidor de Protocolo de Contexto de Modelo (MCP) para administrar Tareas de Google.

Este servidor MCP basado en TypeScript demuestra los conceptos básicos de MCP al integrarse con la API de Google Tasks. Permite gestionar tareas de forma estructurada y eficiente.

Características

Recursos

Lista de tareas predeterminada : acceda a las tareas en la lista de tareas predeterminada de Google a través del URI tasks://default .
Detalles de la tarea : proporciona metadatos sobre las tareas, como título, notas y estado de finalización.
Tipo MIME JSON : Las tareas se representan en un formato JSON legible por máquina.

Herramientas

create_task : crea una nueva tarea en la lista de tareas predeterminada.
- Parámetros :
  - title (cadena, opcional): Título de la tarea.
  - notes (cadena, opcional): notas adicionales para la tarea.
  - taskId (cadena, opcional): ID único para la tarea.
  - status (cadena, opcional): estado de la tarea (por ejemplo, "necesita acción" o "completada").
- Respuesta : Devuelve los detalles de la tarea creada.
list_tasks : enumera todas las tareas en la lista de tareas predeterminada.
- Parámetros : Ninguno.
- Respuesta : Devuelve una matriz JSON de todas las tareas en la lista de tareas predeterminada.
delete_task : elimina una tarea de la lista de tareas predeterminada.
- Parámetros :
  - taskId (cadena, obligatoria): ID de la tarea a eliminar.
- Respuesta : Confirma la eliminación exitosa de la tarea.
update_task : actualiza una tarea existente en la lista de tareas predeterminada.
- Parámetros :
  - taskId (cadena, obligatoria): ID de la tarea a actualizar.
  - title (cadena, opcional): nuevo título para la tarea.
  - notes (cadena, opcional): Nuevas notas para la tarea.
- Respuesta : Devuelve los detalles actualizados de la tarea.
complete_task : alterna el estado de finalización de una tarea.
- Parámetros :
  - taskId (cadena, obligatoria): ID de la tarea cuyo estado de finalización se alternará.
- Respuesta : Devuelve los detalles de la tarea actualizados, incluido el nuevo estado.

Related MCP server: MCP Server

Funcionalidad

Proporciona una fácil integración con modelos de lenguaje grandes (LLM) u otras aplicaciones a través de MCP.
Las definiciones de herramientas estructuradas hacen que la gestión de tareas sea intuitiva y accesible.
Soporte completo para crear, enumerar, eliminar, actualizar y alternar el estado de finalización de las tareas.

Uso

Ejecución del servidor

Para iniciar el servidor:

node build/index.js

Comandos disponibles

create_task : crea una nueva tarea con parámetros opcionales.

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

list_tasks : recupera todas las tareas en la lista de tareas predeterminada.
- No se requieren parámetros.
- Devuelve una matriz de tareas.
delete_task : elimina una tarea por su ID.
```
{
  "taskId": "unique-task-id"
}
```

update_task : actualiza el título, las notas u otros detalles de una tarea por su ID.

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

complete_task : alterna el estado de finalización de una tarea.
```
{
  "taskId": "unique-task-id"
}
```

Ejemplo de respuesta para `complete_task`

Antes de la finalización

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

Después de la finalización

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

Depuración

Dado que los servidores MCP se comunican mediante stdio, la depuración requiere herramientas adicionales. Recomendamos usar el Inspector MCP .

Para iniciar el inspector:

npm run inspector

El Inspector proporcionará una URL para acceder a las herramientas de depuración en su navegador, lo que facilitará la prueba y depuración del servidor.

Licencia

Este servidor MCP está licenciado bajo la Licencia MIT. Esto significa que usted tiene libertad de usar, modificar y distribuir el software, sujeto a los términos y condiciones de la Licencia 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

Servidor MCP de Google Tasks

Características

Recursos

Herramientas

Funcionalidad

Uso

Ejecución del servidor

Comandos disponibles

Ejemplo de respuesta para complete_task

Antes de la finalización

Después de la finalización

Depuración

Licencia

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Ejemplo de respuesta para `complete_task`