Skip to main content
Glama

list_ready

List tasks ready to build now—open, settled, all dependencies done—ranked by priority and roadmap standing. Excludes in-progress work, so you can dispatch directly from the list.

Instructions

The tasks ready to build right now: open, settled, every dependency done — RANKED, best first, by (blocks + 1) x the task's priority x the standing of the ROADMAP TARGET it serves, so reach and urgency combine at both altitudes rather than one overriding the rest. A task whose target still waits on an unshipped target sorts below every task whose roadmap row is clear. Each row carries the roadmap standing that ranked it. The rank is a starting order, not a decision. A task a worker has marked in progress (start_task) is NOT listed, so this is safe to dispatch straight from.

claims reports every claim the project holds — one row per in-progress task, each with its stale_for_minutes (whole minutes since the last heartbeat). It is an age, not a verdict: a healthy build shows a small number and a worker that died still holding a task shows a growing one, so a console displays the age and a dispatcher sweeps the quiet ones with claims.filter((c) => c.stale_for_minutes >= claimStaleMinutes) (default 15). A claim is never auto-released — release one deliberately with edit_task { spec: "replan" }.

scope draws a LANE: only tasks whose folders touch it are listed, so two dispatchers can run side by side without ever writing the same files. Folder containment counts either way (src covers src/orders), a task with no scope is in every lane, and no filter means everything. Each row also carries overlap: the ids of tasks being worked right now whose scope touches that row's, computed across ALL lanes, because a claim in another lane is exactly what a lane filter would otherwise hide. Normally empty; non-empty means dispatching it would put two workers over the same folders.

tags carries the row's plain GitHub labels, so a dispatcher can branch on the KIND of work without a second call. spike is the one this flow reads: a spike ticket's deliverable is a drafted ticket, not merged code, so it is briefed differently. Labels are adopted from the issue on every pull, so one added in the web UI reaches the dispatcher.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scopeNoFolders that draw this dispatcher's lane. Omit for every ready task.
branchNoBranch to scope to (optional; the backend decides its use).
projectNoThe project id — an opaque, supplied string, never derived. Omit to use the server's --project-id default.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idsYes
tasksYes
claimsYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.21.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden, and it delivers richly: it explains the ranking formula, why in-progress tasks are excluded, how scope containment works, how overlap across lanes is computed, that claims are never auto-released, and how stale claim ages behave. This is far beyond a minimal 'lists ready tasks' statement and gives an agent the behavioral detail needed to interpret and act on the response safely.

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 description is long but structured with front-loaded purpose and clear field-by-field paragraphs. Most sentences earn their place by explaining decision-relevant behavior, though some explanatory asides like the full dispatcher sweep example and edit_task release path could be trimmed without losing core meaning.

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?

The description covers the tool's selection criteria, ranking logic, response fields, scoping behavior, overlap semantics, labels, and claim staleness handling. With no annotations and a rich output contract, this level of detail gives an agent everything needed to call the tool correctly and interpret its results without additional lookups.

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, but the description adds meaningful semantics for the `scope` parameter: folder containment rules, no-scope means every lane, and the connection to lane-based dispatching. It does not add extra meaning for `branch` or `project`, but those are already clearly described in the schema, so the added scope detail justifies above baseline.

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 opens with a specific verb+resource: it lists tasks that are ready to build, defined as open, settled, and with all dependencies done. It clearly differentiates from siblings by focusing on ready-to-dispatch work rather than general task listing or planning. The ranking behavior and exclusion of in-progress tasks further pin down its unique purpose.

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?

The description provides clear context for when to use the tool: when a dispatcher needs tasks that are safe to build immediately, and when scoping to a lane to avoid overlapping workers. It does not explicitly name sibling tools or say 'use list_tasks for all tasks,' but the ready-to-build framing and dispatch-oriented examples make the intended usage clear.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/outputty/tasks-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server