Skip to main content
Glama
Sign In
UnClick MCP Server

UnClick MCP Server

by malamutemayhem
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

List actionable Boardroom todos

list_actionable_todos
Read-onlyIdempotent

Retrieve highest-priority unassigned open todos so an agent can select and claim the next available job from the shared work queue.

Instructions

Returns the highest-priority unassigned open todos, ranked so an agent can pull the next best chip without relying on prose handoffs. This is the canonical pull lane of the Jobs board, the fleet's shared work queue (humans watch the same todos at /admin/jobs). When you take a chip, claim it with update_todo (assign yourself, status in_progress) so the board shows one owner per job, and close it with complete_todo or a 'Closes UnClick todo: ' line in the merged PR body. agent_id required.

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": {
      "agent_id": "<agent_id>"
    },
    "name": "list_actionable_todos"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
agent_idYes
include_descriptionNoInclude compact job descriptions so runners can keep the source brief while routing.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.5

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile is covered; the description adds genuinely new context — the human-visible board at /admin/jobs, the one-owner-per-job invariant, and the two closure paths. Pagination/ordering ties (limit behavior) beyond 'highest-priority' are not disclosed.

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?

The core scope and ranking is front-loaded in the first clause, followed by workflow guidance. It is slightly padded by flavor text ('without relying on prose handoffs'), but nearly every sentence carries operational meaning.

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?

There is no output schema, so the description should help an agent anticipate what a 'chip' contains (id, lane, priority fields) and how ranking/limit interact; it does neither. The claim/close workflow and shared-queue semantics are covered well, leaving the return shape as the main gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 33%: include_description is documented in the schema, but limit and agent_id are not. The description merely repeats 'agent_id required' (already in the schema's required list) without explaining what the identity is used for, and never mentions what limit controls.

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?

The description states a specific verb and resource with a precise scope: 'highest-priority unassigned open todos' that are 'ranked.' The phrasing 'canonical pull lane of the Jobs board' distinguishes it sharply from list_todos and other board siblings, so an agent can pick it without opening sibling schemas.

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?

It clearly states the use case (pull the next best chip from the shared queue) and prescribes the surrounding workflow: claim via update_todo, close via complete_todo or a PR body line. It does not explicitly say when to prefer list_todos instead, so the exclusion is implied rather than stated.

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