What can you do with this server?

This server allows you to manage Google Tasks via the Model Context Protocol (MCP) interface. You can: * Create new tasks with a title and optional notes * List all tasks in the default task list * Delete tasks using their unique ID * Toggle task completion status (e.g., mark as "completed" or "needsAction")

Which integrations are available for this server?

Provides tools for managing Google Tasks, including creating, listing, deleting, updating, and toggling the completion status of tasks in the default task list.

How do I use Google Tasks MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Google Tasks MCP Server list my 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.

en es ja ko zh

Google Tasks MCP Server

by mstfe

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Google Tasks MCP Server

A Model Context Protocol (MCP) server for managing Google Tasks.

This TypeScript-based MCP server demonstrates core MCP concepts by integrating with the Google Tasks API. It allows managing tasks in a structured and efficient way.

Features

Resources

Default Task List: Access tasks in the default Google Tasks list via the URI tasks://default.
Task Details: Provides metadata about tasks such as title, notes, and completion status.
JSON Mime Type: Tasks are represented in a machine-readable JSON format.

Tools

create_task: Create a new task in the default task list.
- Parameters:
  - title (string, optional): Title of the task.
  - notes (string, optional): Additional notes for the task.
  - taskId (string, optional): Unique ID for the task.
  - status (string, optional): Status of the task (e.g., "needsAction" or "completed").
- Response: Returns the details of the created task.
list_tasks: List all tasks in the default task list.
- Parameters: None.
- Response: Returns a JSON array of all tasks in the default task list.
delete_task: Delete a task from the default task list.
- Parameters:
  - taskId (string, required): ID of the task to delete.
- Response: Confirms successful deletion of the task.
update_task: Update an existing task in the default task list.
- Parameters:
  - taskId (string, required): ID of the task to update.
  - title (string, optional): New title for the task.
  - notes (string, optional): New notes for the task.
- Response: Returns the updated details of the task.
complete_task: Toggle the completion status of a task.
- Parameters:
  - taskId (string, required): ID of the task to toggle completion status.
- Response: Returns the updated task details, including the new status.

Related MCP server: MCP Server

Functionality

Provides easy integration with Large Language Models (LLMs) or other applications via MCP.
Structured tool definitions make task management intuitive and accessible.
Full support for creating, listing, deleting, updating, and toggling the completion status of tasks.

Usage

Running the Server

To start the server:

node build/index.js

Available Commands

create_task: Create a new task with optional parameters.

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

list_tasks: Retrieve all tasks in the default task list.
- No parameters required.
- Returns an array of tasks.
delete_task: Delete a task by its ID.
```
{
  "taskId": "unique-task-id"
}
```

update_task: Update a task's title, notes, or other details by its ID.

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

complete_task: Toggle the completion status of a task.
```
{
  "taskId": "unique-task-id"
}
```

Example Response for `complete_task`

Before Completion

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

After Completion

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

Debugging

Since MCP servers communicate over stdio, debugging requires additional tools. We recommend using the MCP Inspector.

To start the inspector:

npm run inspector

The Inspector will provide a URL to access debugging tools in your browser, making it easier to test and debug the server.

License

This MCP server is licensed under the MIT License. This means you are free to use, modify, and distribute the software, subject to the terms and conditions of the MIT License.

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. Dates show when Glama detected each change.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

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

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

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
151
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
237
OrbitOAuth
io.github.Noveum
Task management for people and AI agents, with scoped OAuth access to issues, projects, and docs.
130

Related MCP Servers

Google Tasks MCP Server
App Automation Project Management
arpitbatra123
A
license
A
quality
F
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 4 months ago (2026-04-22 17:04 UTC)
15
97
48
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 a year ago (2025-04-02 12:22 UTC)
131
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

Appeared in Searches

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mstfe/mcp-google-tasks'

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

Google Tasks MCP Server

Features

Resources

Tools

Functionality

Usage

Running the Server

Available Commands

Example Response for complete_task

Before Completion

After Completion

Debugging

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

Example Response for `complete_task`