Skip to main content
Glama
Sign In
UnClick MCP Server

UnClick MCP Server

by malamutemayhem
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Update a Boardroom todo

update_todo
Idempotent

Modify a todo's title, description, priority, status, assignee, or due date when scope, ownership, or kanban stage changes; include agent_id for attribution.

Instructions

Update a todo's title, description, priority, status, assignee, or due date. Use when scope changes, ownership shifts, or you move it between kanban columns ('open', 'in_progress', 'done', 'dropped'). agent_id required for attribution.

Input Schema

NameRequiredDescriptionDefault
titleNo
due_atNoOptional due date in ISO format. A date-only value like 2026-06-15 means due by the end of that day. Pass empty string to clear.
statusNo
todo_idYesUUID of the todo to update
agent_idYesStable identifier for the calling agent.
priorityNo
descriptionNo
assigned_to_agent_idNoPass empty string to unassign

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. Pass empty string to clear.",
+  "type": "string"
+}
  2. Addedv0.1.5

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare idempotent=true, destructive=false, readOnly=false, so the safety profile is covered. The description adds that agent_id is required for attribution and implies partial-update semantics by listing fields with 'or', but never states explicitly that unmentioned fields are untouched or what the call returns. Adequate, not rich.

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 short sentences, front-loaded with the fields being mutated, then the usage trigger, then the required-param note. No filler; only a mild redundancy between the field list and the kanban-column parenthetical.

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?

For an 8-parameter mutation tool with no output schema, the description covers fields and triggers but omits return behavior and partial-update guarantees. Annotations carry the safety signal, so the gaps are moderate rather than disqualifying.

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 only 50% (title, status, priority, description are undescribed), and the description compensates by enumerating every mutable field and mapping status values to kanban columns. It also explains agent_id's purpose (attribution), which the schema only labels as a 'stable identifier'. It does not repeat the schema's documented empty-string clearing behavior for due_at/assignee.

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 (update) and resource (todo) and enumerates the mutable fields, so an agent immediately knows the operation. It does not distinguish itself from siblings that also change status (complete_todo, drop_todo), which is a missed opportunity given status='done'/'dropped' are valid here.

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 concrete triggers: scope changes, ownership shifts, or moving between kanban columns. However it never says when NOT to use it — e.g. whether marking work done should go through complete_todo instead of update_todo with status='done' — leaving a real routing ambiguity with siblings.

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