Skip to main content
Glama

Local MCP

by com.local-mcp
OverviewDiscussionsAdmin

To Do List Tasks

todo_list_tasks
Read-only

Lists tasks from a Microsoft To Do list (or any Reminders list). Syncs via macOS Reminders. The answer names the account(s) it read (accounts_used, and account on each task). When the list name exists in several accounts it refuses and lists them: pass account, or list as "Account/List".

Input Schema

NameRequiredDescriptionDefault
listNoList name (from todo_get_folders), or "Account/List". Leave empty to show all.
limitNoMax tasks to return (default 50)
accountNoAccount that owns the list (from todo_get_folders), to tell apart lists with the same name. Optional.
include_completedNoInclude completed tasks (default false)

Output Schema

NameRequiredDescriptionDefault
countNo
tasksNo
accounts_usedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / account
      Added value: +{
+  "description": "Account that owns the list (from todo_get_folders), to tell apart lists with the same name. Optional.",
+  "type": "string"
+}
    • changedInput schema / properties / list / description
      Previous value: -"List name (from todo_get_folders). Leave empty to show all."New value: +"List name (from todo_get_folders), or \"Account/List\". Leave empty to show all."
    • addedOutput schema / properties / accounts_used
      Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedOutput schema / properties / tasks / items / properties / account
      Added value: +{
+  "type": "string"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / list / description
      Previous value: -"List name (from todo_list_lists). Leave empty to show all."New value: +"List name (from todo_get_folders). Leave empty to show all."
  3. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds real behavior beyond them: it syncs through macOS Reminders, it refuses on ambiguous list names rather than guessing, and it names the accounts it read. The refusal-on-ambiguity behavior is exactly the kind of thing an agent must anticipate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the core action and mechanism before the edge-case handling. The middle sentence about accounts_used and per-task `account` is somewhat redundant given an output schema exists, but the overall size is appropriate.

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 an output schema and fully documented parameters, the description covers the non-obvious parts: the Reminders sync backend, the account disambiguation rule, and the refusal behavior. Only the sibling-selection question is left unanswered.

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 coverage is 100%, so baseline is 3. The description exceeds that by explaining how `list` and `account` interact — the cross-account collision case and the "Account/List" compound format — which the individual per-parameter descriptions only imply.

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?

States a specific verb and resource: 'Lists tasks from a Microsoft To Do list', and adds the storage mechanism ('Syncs via macOS Reminders'). It does not differentiate itself from siblings like todoist_list_tasks or list_reminders, and the parenthetical 'or any Reminders list' slightly blurs the boundary, so it stops short of a 5.

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?

Gives concrete guidance for one scenario — when a list name is ambiguous across accounts, pass `account` or use "Account/List" — which is genuinely useful. But it never says when to pick this tool over todoist_list_tasks or list_reminders, which is the harder selection decision for an agent facing this sibling set.

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

All Local MCP toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources