Google Tasks MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource-action pair (e.g., list_tasklists vs list_tasks, create_task vs create_tasks, clear_completed vs delete_task). The descriptions make the boundaries clear, so an agent should rarely misselect.
Naming Consistency5/5
All tools follow a consistent verb_noun snake_case pattern (list_tasklists, create_task, move_task, etc.). The only variation is plural for batch operations (create_tasks), which is intuitive and consistent.
Tool Count5/5
With 14 tools, the set is well-scoped for Google Tasks. Each tool covers a distinct operation, and the count falls within the ideal 3-15 range without redundancy or bloat.
Completeness5/5
The surface provides full CRUD and lifecycle coverage for both task lists (list, create, rename, delete) and tasks (create, list, get, update, complete, reopen, move, delete, clear completed). No obvious gaps exist for the domain.
Average 4.1/5 across 14 of 14 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description accurately discloses the mutation to completed status, but it adds no context about reversibility, preconditions (e.g., task must not already be completed), or error 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 short sentence with zero redundancy. It is front-loaded and to the point, containing no filler.
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?
For a simple state-change tool with well-documented parameters and annotations, the brief description plus schema is sufficient. It does not explain return values or side effects, but none are necessary for this low-complexity 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?
The input schema fully documents both parameters (list and taskId) with descriptions, so the tool description adds no parameter-specific meaning. This is acceptable given 100% schema coverage.
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 ('Mark a task as completed') with a specific verb and resource. It is unambiguous, though it does not explicitly distinguish from siblings like reopen_task or update_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?
No guidance is given about when to use this tool versus alternatives. The description and schema do not mention when this should be preferred over update_task or delete_task, nor any prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, indicating this is a write operation but not destructive. The description adds that the list is 'empty', which is a useful detail, but it does not disclose other behaviors such as whether authentication is required, whether duplicate titles are allowed, or what the response contains.
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 concise sentence: 'Create a new, empty task list.' It is front-loaded, contains no filler, and every word adds value.
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?
Given the tool's low complexity (one parameter, no output schema), the description is nearly complete. It states the action and result (a new, empty list), but it could be more complete by mentioning what is returned (e.g., the ID of the created list) or any side effects. This minor gap prevents a perfect score.
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 for the single 'title' parameter (described as 'List title'), and the tool description adds no additional parameter semantics beyond that. With full schema coverage, a baseline score of 3 is appropriate.
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 uses the specific verb 'Create' with the resource 'task list' and adds that it is 'empty', distinguishing it from sibling tools like create_task (which creates a task) and list_tasklists (which lists). This clearly states what the tool does and differentiates it from similar 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. It does not mention exclusions, such as when to prefer create_tasks to add tasks to an existing list, or clarify that this is only for creating a new, empty list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds no additional behavioral context beyond the verb 'Fetch'. It doesn't disclose potential error behavior, return format, or rate limits. With annotations covering safety, the description still adds no extra transparency.
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, front-loaded sentence with no fluff. Every word is necessary.
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?
For a simple single-fetch tool with rich schema descriptions and clear annotations, the description is largely sufficient. It could optionally mention behavior when the task is not found, but given the tool's simplicity and the schema's parameter documentation, the context is adequately complete.
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 coverage is 100% for both parameters, with detailed descriptions for taskId and list. The description itself ('by id') aligns with the schema but adds no new meaning beyond what is already documented. Baseline 3 applies since schema does the heavy lifting.
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 clearly states the action ('Fetch') and the resource ('a single task by id'), which distinguishes it from siblings like list_tasks (which fetches multiple tasks). It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a specific task by id but does not explicitly state when to use it over alternatives like list_tasks, nor does it mention exclusions. The schema provides parameter guidance ('Call list_tasklists') but not tool selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations indicate readOnlyHint=false and destructiveHint=false, so the tool is known to be a non-destructive mutation. The description adds little beyond 'existing', which clarifies scope but does not disclose side effects or permissions. Given annotations cover the safety profile, a 3 is appropriate.
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, short sentence that directly states the action and resource. It is front-loaded and wastes no words, earning a perfect score for conciseness.
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?
For a simple rename operation, the description is adequate when combined with the thorough parameter descriptions and annotations. There is no output schema, but the tool is simple enough that missing return-value information is not critical. A small gap is the lack of explicit mention that the rename preserves the task list ID and tasks, but this is not essential.
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 coverage is 100% with both parameters fully described. The 'list' parameter description includes case-insensitivity, default handling, and a pointer to list_tasklists, which is rich. Since the tool description itself adds no extra parameter meaning, the baseline 3 applies.
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 'Rename an existing task list' uses a specific verb (rename) and resource (task list), and the word 'existing' distinguishes it from creation. This clearly sets it apart from sibling tools like create_tasklist and delete_tasklist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description, but no explicit alternatives or exclusions are given. However, the parameter description for 'list' provides practical guidance: it mentions calling list_tasklists to see existing lists and how to handle the default list, which gives some usage context beyond the bare description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true, readOnlyHint=false), the description adds crucial behavioral detail: 'Permanently delete' and 'Irreversible' emphasize the permanence, while 'AND every task in it' reveals the cascading deletion of all contained tasks. This significantly enriches the safety understanding beyond the annotation alone.
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 three short, impactful sentences. It front-loads the action, then immediately follows with critical warnings ('Irreversible') and a requirement ('Requires confirm=true'). Every word earns its place with no filler or redundancy.
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 covers all essential behavioral aspects: permanence, cascading deletion, and the confirmation requirement. There is no output schema, so return values are not expected. The only minor gap is the lack of explicit differentiation from clear_completed, but overall the description is sufficient for a simple destructive tool.
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 already provides 100% coverage with detailed descriptions for both list (id or exact title) and confirm (const true). The description's mention of 'requires confirm=true' adds no new information beyond what the schema already states, so the baseline score of 3 is appropriate.
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 clearly states 'Permanently delete a task list AND every task in it,' specifying the exact resource and scope. This distinguishes it from sibling tools like delete_task, which removes only a single task, and clear_completed, which removes only completed items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides important context: it deletes the list and all tasks, and requires confirm=true. However, it does not explicitly mention when to use this tool versus alternatives like delete_task or clear_completed, leaving usage boundaries implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only, and the description adds useful context: defaults to open tasks in the default list, and dates are formatted YYYY-MM-DD. This goes beyond the annotations without redundancy.
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 three concise sentences that are front-loaded with the core purpose, followed by defaults and date format. Every sentence provides value with no fluff.
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?
For a read-only list tool with no output schema, the description covers the function, filters, defaults, and date format. Missing are notes about pagination or return shape, but these are not critical for tool selection and the schema provides parameter details.
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 71%, with descriptions for most parameters. The description adds meaning by explaining the due-date window concept and defaults (which are already in the schema), but does not describe limit or includeDeleted. This is adequate but not exceptional.
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 clearly states the tool lists tasks in a specific task list, distinguishing it from sibling tools like list_tasklists which list task lists. It also specifies filtering options and defaults, giving a precise scope.
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?
While the purpose is clear, the description doesn't explicitly mention alternatives or exclusions such as 'use get_task for a single task'. However, the context of listing tasks with defaults and filters provides enough clarity for selection, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is not read-only and not destructive, but the description adds a non-obvious behavioral constraint: recurring tasks cannot be moved between lists. It also clarifies that omitting parentTaskId moves a task to top level. This goes beyond what annotations alone convey and helps avoid failed calls.
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 three concise sentences, front-loaded with the core operations. Every sentence adds value: the first lists capabilities, the second explains a key parameter behavior, and the third warns about a limitation. No filler or redundancy.
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?
Given a 5-parameter mutation tool with no output schema, the description covers the main operation types and important edge cases (recurring tasks, top-level behavior). It does not detail interactions between 'list' and 'toList' parameters, but the schema handles those descriptions. Overall, it is sufficiently complete for an agent to select and invoke correctly.
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 coverage is 100% with each parameter having a meaningful description. The description adds one semantic nuance (omit parentTaskId for top level) which is already present in the schema. Since the schema carries the full parameter burden, a baseline score of 3 is appropriate.
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 clearly states the tool's purpose with specific verbs: 'Reorder a task, nest it under a parent, un-nest it, or move it to another list.' This distinguishes it from sibling tools like update_task (which updates fields) and complete_task (which changes status). The phrase 'move_task' is directly explained and expanded upon.
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 implicitly defines when to use this tool by enumerating its operations (reorder, nest, un-nest, move across lists). It also provides a clear exclusion: 'Recurring tasks cannot be moved between lists.' However, it does not explicitly compare to alternatives like update_task or list_tasks, so guidance is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the safe mutation nature is known. The description adds the specific behavior: it changes the task's state from completed to not done. This goes beyond the annotations and provides the core effect without contradicting them.
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, clear sentence with no unnecessary words. It immediately conveys the tool's purpose and nothing more, making it highly skimmable.
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?
For a simple 2-parameter mutation tool with full schema coverage and annotations, the description is sufficient. It explains the action and implicitly requires a completed task. It does not mention return values, but the absence of an output schema and the simplicity of the operation do not demand more.
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%, so both parameters (list and taskId) are fully documented. The description does not add any additional parameter semantics beyond what the schema already provides. Baseline of 3 applies since the schema carries the burden.
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 clearly states the action: 'Mark a completed task as not done again.' It specifies the verb (mark), the resource (task), and the state change (from completed to not done). This distinguishes it from sibling tools like complete_task (which does the opposite) and update_task (which modifies general fields).
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 gives clear context that this tool is for reopening tasks that are completed. It implies the use case without explicitly naming alternatives, but the phrase 'a completed task' establishes when to use it. No exclusions or when-not-to-use are stated, which keeps it at a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the mutation is expected. The description adds valuable behavioral context by disclosing the partial-update semantics ('Only the fields you pass are changed') and the special null-clearing behavior for due and notes. It does not contradict annotations.
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 two concise sentences, front-loaded with the action and target fields. Every sentence earns its place: the first states the purpose, the second explains null behavior and partial updates. No redundancy or fluff.
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?
For a 6-parameter update tool with no output schema, the description covers the core purpose, editable fields, null-clearing semantics, and partial-update behavior. It does not mention return values, but the absence of an output schema makes that less critical. It could be more complete with explicit usage exclusions, but given the richness of the schema, it is largely sufficient.
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?
Schema descriptions cover about half the parameters (per context), and the description enhances semantics by explaining null handling for due and notes. It also clarifies that omitted fields remain unchanged, which adds meaning beyond the schema's per-field descriptions. The description compensates for the moderate schema coverage.
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 uses the specific verb 'Change' with a clear resource ('a task') and enumerates the editable fields (title, notes, due date, status). This clearly distinguishes it from sibling tools like create_task, delete_task, complete_task, and move_task, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying task fields but does not explicitly state when to prefer this tool over siblings like complete_task, reopen_task, or move_task. The 'Only the fields you pass are changed' line provides partial-update guidance, but there is no explicit when-to-use or alternative comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only and non-destructive behavior. The description adds a meaningful behavioral detail: the due field renders as an all-day item on Google Calendar. It does not describe return values, but no output schema exists, and the core mutation semantics are already covered by annotations.
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?
Two concise sentences: the first states the core purpose, the second clarifies the due format and points to the bulk alternative. No wasted words; information is front-loaded.
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?
With 6 parameters but 100% schema coverage, the description doesn't need to repeat all parameter details. It covers the key single-vs-bulk distinction and the due behavior. It omits mention of return values or permissions, but these are not critical given the annotations and schema, making this adequately complete.
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%, so the baseline is 3. The description repeats the due date format (already in the schema) and adds the calendar rendering note, which the schema also already states. No additional parameter semantics are provided beyond the schema.
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 clearly states the tool's action ('Create one task') and specifies the resource (task). It explicitly distinguishes from the sibling tool create_tasks by noting it creates a single task, not several at once.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides direct usage guidance: use this for one task, and explicitly names create_tasks as the alternative for multiple tasks. This is clear when-to-use and alternative guidance, satisfying the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true, but the description adds crucial nuance: it hides rather than deletes, tasks remain retrievable with status=completed, and the action is not reversible via the API. This goes beyond the simple destructive flag.
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?
Two concise sentences: first states purpose and UI analogy, second explains the hidden-but-retrievable outcome and irreversibility. Front-loaded and zero fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema and clear annotations, the description covers all essential aspects: what it does, how it behaves, how to recover, and reversibility. Sibling tools are implicitly differentiated via the 'hide not delete' nuance.
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 only parameter 'list' is fully described in the schema (id or title, default list, lookup via list_tasklists). The tool description adds no extra parameter semantics, so baseline score of 3 is appropriate given 100% schema coverage.
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?
Description clearly states the action (Hide all completed tasks) and the resource (in a list), with a useful UI analogy. It distinguishes itself from sibling tools like delete_task by noting tasks remain retrievable.
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?
Provides clear context: it mimics the 'Clear completed' UI action, and notes tasks stay retrievable via list_tasks status=completed, implying when to use instead of delete. Warns it is not reversible via API, but does not explicitly name alternative tools for permanent deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true, but the description adds valuable context: that deletion cascades to subtasks and is irreversible. This goes beyond the annotation's binary flag and helps the agent understand the full impact.
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, front-loaded sentence containing the essential info (permanent deletion, subtask scope, irreversibility). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with annotations and full schema coverage, the description covers key behavioral aspects (cascade, irreversibility). No output schema means return values don't need explanation. The tool is fully specified for an agent.
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%, so both parameters are already well-documented in the input schema. The description doesn't add parameter-level semantics, which is fine given the schema's completeness.
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 clearly states the verb and resource: 'Permanently delete a task', and adds scope ('and its subtasks') plus irreversibility. This distinguishes it from sibling tools like complete_task or move_task, which perform different operations.
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 context is clear: use this when you want to remove a task permanently. It doesn't explicitly name alternatives or exclusions, but the behavior is unambiguous enough for an agent to choose it over other task operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint, and the description adds that it returns ids and titles, clarifying the output. It does not introduce contradictions and provides useful scoping ('authorized account'), though it omits details like pagination.
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?
Two sentences, front-loaded with the action 'List', and every word earns its place. Extremely concise while conveying purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing tool with strong annotations, the description fully covers purpose, expected output, and usage sequence. No additional behavioral details are necessary.
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 tool has zero parameters, so the baseline is 4. The description confirms there are no user-supplied inputs and implicit account scope, but adds no further parameter detail since none exist.
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 clearly states the tool lists all Google Tasks lists in the authorized account, including ids and titles. It uses the specific verb 'List' and resource 'Google Tasks lists', and distinguishes from sibling tool 'list_tasks' which lists tasks within a list.
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?
Explicitly instructs to 'Call this first to learn which list to target,' providing clear usage context. However, it does not explicitly mention alternatives or when not to use, so it lacks full exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true and destructiveHint=false. The description adds crucial behavioral detail: skipIfExists default matching rule (title AND due match existing open task), and that the response is a per-item report requiring checks for partial failures. This goes well beyond annotations.
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?
Three concise sentences deliver the core purpose, key parameter semantics, and error-handling guidance. No filler or redundant repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's bulk-create complexity, the description covers list default, item fields, idempotency, and partial-failure reporting. Even without an output schema, the agent knows what to expect and how to handle errors. The description is sufficiently complete for safe invocation.
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?
Schema description coverage is low (33%), so the description must compensate. It explains the due format as all-day, the default skipIfExists=true, and the safe retry semantics. It does not cover parentTaskId, but the schema does describe it. Overall it adds meaningful meaning beyond the schema.
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 opens with 'Create up to 100 tasks in one call', which is a specific verb+resource+capacity statement. The example 'e.g. every reading from a syllabus' and the bulk nature clearly distinguish this from the sibling create_task (singular).
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 implies use for bulk creation ('up to 100 tasks', 'every reading from a syllabus') and explains idempotent retry behavior with skipIfExists. It does not explicitly mention when not to use this vs create_task, but the 'one call' contrast and sibling names provide sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![google-tasks-mcp MCP server](https://glama.ai/mcp/servers/ezrazhang7/google-tasks-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ezrazhang7/google-tasks-mcp)

Score Badge

Copy to your README.md:

[![google-tasks-mcp MCP server](https://glama.ai/mcp/servers/ezrazhang7/google-tasks-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ezrazhang7/google-tasks-mcp)

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/ezrazhang7/google-tasks-mcp'

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