Google Workspace MCP Server

by tom275275

Overview Schema Source Related Servers Discussions Admin

Python

Remote

manage_task

Create, update, delete, or move tasks in Google Task lists to keep your to-dos organized.

Instructions

Manage tasks: create, update, delete, or move tasks within task lists.

Args: user_google_email (str): The user's Google email address. Required. action (str): The action to perform. Must be one of: "create", "update", "delete", "move". task_list_id (str): The ID of the task list. Required for all actions. task_id (Optional[str]): The ID of the task. Required for "update", "delete", and "move" actions. title (Optional[str]): The title of the task. Required for "create", optional for "update". notes (Optional[str]): Notes/description for the task. Used by "create" and "update" actions. status (Optional[str]): Task status ("needsAction" or "completed"). Used by "update" action. due (Optional[str]): Due date in RFC 3339 format (e.g., "2024-12-31T23:59:59Z"). Used by "create" and "update" actions. parent (Optional[str]): Parent task ID (for subtasks). Used by "create" and "move" actions. previous (Optional[str]): Previous sibling task ID (for positioning). Used by "create" and "move" actions. destination_task_list (Optional[str]): Destination task list ID (for moving between lists). Used by "move" action.

Returns: str: Result of the requested action.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`due`	No
`notes`	No
`title`	No
`action`	Yes
`parent`	No
`status`	No
`task_id`	No
`previous`	No
`task_list_id`	Yes
`user_google_email`	Yes
`destination_task_list`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.14.3Sep 6, 2026

TDQS

A4.3/5.0

Behavior3/5

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

With no annotations, the description carries the transparency burden and does disclose the core behaviors: create, update, delete, move, and per-action parameter usage. However, it does not state whether delete is irreversible, what happens to subtasks/ordering, or any authentication requirements beyond the user email parameter.

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 opens with a one-line purpose, then uses a structured Args list where every entry earns its place. The level of detail is justified given the large parameter count and zero schema-level descriptions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description provides a complete calling contract for all actions and parameters, and the output schema covers the return type. It lacks only minor contextual details such as destructive side effects, move semantics across lists, and auth prerequisites.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description fully compensates by documenting all 11 parameters, including requiredness, which actions each parameter applies to, enum values for action/status, and date format. This is essential and well-executed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear resource ('tasks') and the exact operations available: create, update, delete, or move. This distinguishes manage_task from sibling task tools like list_tasks/get_task and manage_task_list, which operate on task lists rather than tasks.

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

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly communicates it is for mutating tasks via create/update/delete/move. It does not explicitly mention alternatives like list_tasks or get_task for read-only needs, but the action set and resource scope provide strong contextual guidance.

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

Deploy Server