Skip to main content
Glama
valentil

FeatureBoard MCP Server

by valentil

Next wave of work (fill every lane)

next_wave
Read-only

Get the next wave of tickets as file-disjoint lanes for concurrent sub-agents, pass occupied tickets to refill free lanes efficiently.

Instructions

The PLURAL of next_task: return the whole dispatchable set at once, already partitioned into file-disjoint lanes, so every sub-agent lane can be filled in ONE call instead of N sequential next_task round-trips. Use this — not repeated next_task — whenever you are working a board with more than one open ticket. lanes[] are mutually file-disjoint and safe to run as CONCURRENT sub-agents; tickets WITHIN a lane share files and must run serially in the order given. sequential[] holds orchestrator-only tickets (fable) that run inline. Each ticket carries its own dispatch block ({subAgent, model, cap, parallelizable, instruction}) so no second lookup is needed. Pass occupied with the tickets your sub-agents are still working and call it again to REFILL just the lanes that freed up — lanes containing a running ticket come back under busyLanes and are never re-served. stopCondition is the authority on whether the loop is over: an empty wave is a steer_project event, NOT a stop.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNoall
projectYes
maxLanesNoCap concurrent lanes returned. Omit to saturate — the default is every lane the board can safely run.
occupiedNoTicket ids currently being worked by a sub-agent — excluded from the wave, and their lanes withheld.
laneDepthNoCap tickets returned per lane. Omit for the full serial list.
Behavior5/5

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

Annotations already indicate read-only; description adds rich behavioral context: lane disjointness, concurrent sub-agent safety, busyLanes mechanics, stopCondition semantics, and dispatch block contents—all beyond what annotations provide.

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

Conciseness5/5

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

Every sentence adds value; well-structured with purpose, usage, lane details, and parameter behavior. Efficient for the complexity.

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?

With no output schema, description fully explains return structure (lanes, sequential, busyLanes, dispatch tickets) and usage loop (occupied, stopCondition). Complete for correct agent invocation.

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?

Description adds meaningful usage context for 'occupied' (exclusion/refill logic) and 'maxLanes' (concurrency cap) beyond schema. 'type' and 'project' are not elaborated but covered by schema (required, enum). Compensates for 60% schema coverage.

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 clearly states the tool returns multiple tickets partitioned into lanes for concurrent execution ("return the whole dispatchable set at once") and explicitly distinguishes it from next_task, making the purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit guidance on when to use (board with more than one open ticket) and not to use (repeated next_task), plus details on lane concurrency and the occupied parameter behavior.

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

Install Server

Other Tools

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/valentil/featureboard-mcp'

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