Skip to main content
Glama
Sign In
UnClick MCP Server

UnClick MCP Server

by malamutemayhem
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Create a Boardroom todo

create_todo

Creates a todo card on the shared Jobs board so agents and humans both see tracked action items, and posts an event to alert other agents without polling.

Instructions

Creates a new todo card on the shared Jobs board (the Boardroom Todos kanban; humans watch the same queue at /admin/jobs) so the agent pack and the human both see what's on deck. Use when you decide an action item needs tracking beyond a single message: a follow-up task, a chore, a deliverable. Provide agent_id (yours), a short title, and optional description, priority, and assignee. Posts a 'todo-created' Boardroom event so other agents notice without polling. When a forge PR finishes the job, put 'Closes UnClick todo: ' in the PR body and the merge auto-completes the card.

Input Schema

NameRequiredDescriptionDefault
titleYesShort title (max 200 chars)
due_atNoOptional due date in ISO format. A date-only value like 2026-06-15 means due by the end of that day.
agent_idYesStable identifier for the calling agent. Same value as set_my_emoji.
priorityNonormal
descriptionNoOptional longer description (max 4000 chars)
assigned_to_agent_idNoOptional agent_id of the agent who should own this todo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.11
    • addedInput schema / properties / due_at
      Added value: +{
+  "description": "Optional due date in ISO format. A date-only value like 2026-06-15 means due by the end of that day.",
+  "type": "string"
+}
  2. Addedv0.1.5

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare the write/non-idempotent/non-destructive/closed-world profile, and the description adds genuinely new behavior: humans see the same queue, a 'todo-created' Boardroom event is emitted so peers notice without polling, and merge-time auto-completion via a PR body marker. It omits duplicate-creation risk given idempotentHint=false, which keeps it at 4.

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?

Four dense sentences, front-loaded with the action and destination, then usage, then side effects, then the lifecycle hook. Every sentence carries information; only the second half of the final sentence drifts into workflow lore that could be trimmed.

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 no output schema, the description still communicates the side effects (Boardroom event), the human-visible surface, and how the card eventually closes. It leaves the return value implicit — the reader must infer that the created card's uuid is returned, since the PR-body instruction needs it.

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 83% and the schema documents title, description, due_at and assigned_to_agent_id in detail. The description only restates the required fields and adds the useful clarification that agent_id is 'yours'; it says nothing about due_at or priority semantics, so it adds little 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?

States a specific verb and resource ('Creates a new todo card') plus the concrete destination ('shared Jobs board / Boardroom Todos kanban'), which makes it trivially separable from update_todo, complete_todo, drop_todo and list_todos. The parenthetical URL adds verifiable grounding.

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?

Gives a clear trigger ('when you decide an action item needs tracking beyond a single message') with examples of the kinds of items that qualify. It does not name the alternatives (update_todo, brain_dump, post_message) or say when not to create a card, so it falls short of a 5.

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

Deploy Server

Other Tools