Skip to main content
Glama

Milanote MCP Server and API by Cotlet

Add task

add_task
Destructive

Add tasks to the end of an existing to-do list, each with an optional due date and time. Appends the tasks, unchecked, after the last task of the list and returns the whole list with the new task_ids. The tasks already there stay as they were. A due date without a time is due at 5 PM; Milanote reminds you at 9 AM the day it's due. Times are in the Cloud Browser's time zone. Nobody else is notified. To start a new list, use add_todo_list.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "board_id": "<board_id>",
      "card_id": "<card_id>",
      "tasks": "<tasks>"
    },
    "name": "add_task"
  }
}

Input Schema

NameRequiredDescriptionDefault
tasksYes1 to 50 tasks, added in order at the end of the list.
card_idYesTo-do list ID from get_board.
board_idYesBoard ID from list_boards, or the board URL.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare a mutating, non-idempotent, open-world write, but the description adds substantive detail the annotations cannot: tasks are appended unchecked after the last task, existing tasks are untouched, the whole list plus new task_ids is returned, and nobody else is notified. It also documents the due-date default (5 PM) and reminder timing (9 AM on the due day), which are non-obvious side effects.

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?

Front-loaded with the core action and append behavior, then defaults, then the alternative tool. Every sentence carries distinct information (ordering, return value, defaults, timezone, notification, alternative) with no restatement of the name.

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?

No output schema exists, and the description compensates by describing the return ('the whole list with the new task_ids'). Combined with 100% parameter coverage and explicit side-effect notes, an agent has everything needed to call it correctly.

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 the baseline is 3; the description earns above that by adding semantics the schema omits — a date-only due value resolves to 5 PM, times are interpreted in the Cloud Browser's time zone, and the due_date/due_time pairing rule. It does not restate the 1-to-50 task limit already in 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?

States a specific verb and resource ('Add tasks to the end of an existing to-do list') and names the sibling it is not ('To start a new list, use add_todo_list'). An agent can distinguish it from add_todo_list and list_tasks without opening a schema.

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?

Explicitly routes the agent: use this for appending to an existing list, and use add_todo_list to start a new one. The appending-versus-creating distinction is the only real ambiguity among siblings, and it is resolved directly.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.