Skip to main content
Glama

Add or close a task

task

Adds a task to do, marks one done, or opens it again, as this person. A new task can be for this person or someone else on the project (by name), due on a day, in a folder, and stand on § addresses. A new task can also say what it is expected to bring and by when, up to three lines, each with a number of the project in brackets when one measures it; Alcoven measures that number when the day ends. came_of_it records what came of an expectation in the person's words. The answer reads each expectation back.

Input Schema

NameRequiredDescriptionDefault
dueNoFor add: YYYY-MM-DD.
forNoFor add: who it is for, by name. Default: this person.
taskNoFor done and reopen: the task's § address.
titleNoFor add.
whichNoFor came_of_it: which of the task's expectations, 1 to 3. Default: the first one still waiting for its words.
wordsNoFor came_of_it: what came of it, in the person's words.
actionYes
expectNoFor add: what the task is expected to bring and by when, one line each, like "1 call by 2026-10-30 (numbers/conversations.widget.md)"; the path in brackets names the number that measures it, a widget or a source and its measure.
folderNoFor add: the folder it belongs to.
detailsNoFor add: more about the task.
projectNoThe project's slug, from open_project, like acme. Not needed when a § address names the project, or when the person is on one project.
stands_onNoFor add: § addresses it builds on.

Output Schema

NameRequiredDescriptionDefault
nextNo
addressYes
expectsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / action / enum
      Previous value: -[
      -  "add",
      -  "done",
      -  "reopen"
      -]New value: +[
      +  "add",
      +  "done",
      +  "reopen",
      +  "came_of_it"
      +]
    • addedInput schema / properties / expect
      Added value: +{
      +  "description": "For add: what the task is expected to bring and by when, one line each, like \"1 call by 2026-10-30 (numbers/conversations.widget.md)\"; the path in brackets names the number that measures it, a widget or a source and its measure.",
      +  "items": {
      +    "maxLength": 600,
      +    "minLength": 3,
      +    "type": "string"
      +  },
      +  "maxItems": 3,
      +  "type": "array"
      +}
    • addedInput schema / properties / which
      Added value: +{
      +  "description": "For came_of_it: which of the task's expectations, 1 to 3. Default: the first one still waiting for its words.",
      +  "maximum": 3,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • addedInput schema / properties / words
      Added value: +{
      +  "description": "For came_of_it: what came of it, in the person's words.",
      +  "maxLength": 500,
      +  "minLength": 1,
      +  "type": "string"
      +}
    • addedOutput schema / properties / expects
      Added value: +{
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  2. Changed1 schema field changed
    • addedOutput schema / properties / next
      Added value: +{
      +  "additionalProperties": {},
      +  "properties": {
      +    "acts": {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "address": {
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "empty": {
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "more": {
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "rung": {
      +      "type": [
      +        "number",
      +        "null"
      +      ]
      +    },
      +    "skipped": {
      +      "type": "number"
      +    },
      +    "step": {
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "then": {
      +      "anyOf": [
      +        {
      +          "additionalProperties": {},
      +          "properties": {
      +            "address": {
      +              "type": [
      +                "string",
      +                "null"
      +              ]
      +            },
      +            "step": {
      +              "type": "string"
      +            },
      +            "why": {
      +              "type": "string"
      +            }
      +          },
      +          "required": [
      +            "step",
      +            "why",
      +            "address"
      +          ],
      +          "type": "object"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ]
      +    },
      +    "why": {
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    }
      +  },
      +  "required": [
      +    "step",
      +    "why",
      +    "address",
      +    "acts",
      +    "more",
      +    "rung",
      +    "then",
      +    "empty",
      +    "skipped"
      +  ],
      +  "type": "object"
      +}
  3. First observed

TDQS

B3.1/5.0
Behavior3/5

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

Annotations already cover the key safety profile: not read-only, not idempotent, not destructive, closed-world. The description adds useful domain behavior, especially that Alcoven measures expectation numbers when the day ends and that the answer reads expectations back. It still does not clarify mutation side effects, duplicate handling, or what happens to existing task data on done/reopen.

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

Conciseness3/5

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

The description is front-loaded with the three main actions and stays reasonably short. However, the wording is dense and occasionally opaque, with undefined terms such as § and Alcoven and a run-on explanation of expectations that could be clearer.

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?

An output schema exists, so the description need not explain return values. Given 12 parameters and four actions, it covers the unusual expect and came_of_it behavior but leaves gaps around action-specific routing and when to prefer this tool over related task tools.

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 92%, so the schema already carries most parameter meaning. The description adds some domain context around expect and came_of_it, but mostly repeats what the schema says for fields like expect, title, folder, and stands_on, and does not explain the action enum values.

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 states specific verbs and resources: it adds a task, marks one done, or reopens it, acting as this person. It also distinguishes add behavior (for this person or someone else, due, folder, stands-on addresses) from the other actions. It does not explicitly distinguish itself from siblings such as my_tasks or add_note.

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 explains what the action values do but gives no explicit guidance on when to use this tool versus alternatives like my_tasks, task_context, add_note, or remind. There are no exclusions or decision rules for choosing this tool over those siblings.

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.

Resources