Skip to main content
Glama
olgasafonova

productplan-mcp-server

by olgasafonova

bulk_update_bars

Destructive

Update multiple roadmap bars in one call—recolor, move lanes, retag, reschedule, or set progress. Validates all changes before writing, with dry-run support.

Instructions

Update many bars in one call: recolor, move lanes, retag, reschedule, set progress.

USE WHEN: "Color all these bars Committed", "Move these 12 bars to the Backend lane", "Set percent_done on every Q3 bar" For a single bar, use manage_bar instead. Put values shared by every bar in set (e.g. set:{"legend":"Committed"}) and per-bar values in items; an item's own fields override set. Up to 100 items; each bar_id may appear once. Every item is validated before anything is written: legend, lane, custom field labels, and dropdown values are checked against each bar's roadmap (one roadmap fetch per distinct roadmap; pass roadmap_id to skip looking up each bar's roadmap). One invalid item means nothing is sent, and the error lists every problem with the valid options. dry_run:true returns the exact PATCH payload per bar without writing. Writes run 4 at a time under the client's rate limiter. Returns per-item {index, bar_id, ok, error} and a summary like "Updated 28 of 30 bars; 2 failed". The result is an error only when no bar was updated. A partial failure is a normal result whose summary counts the failures; retry only the failed items. FAILS WHEN: items empty or over 100, a bar_id missing or repeated, a name not on the roadmap, legend_id or effort passed (see manage_bar).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
setNoFields applied to every item unless the item sets them itself, e.g. {"legend":"Committed"}. Same fields as items
itemsYesBars to update: [{bar_id, ...fields}]. Fields are the same as manage_bar update: name, lane, lane_id, legend, clear_legend, starts_on, ends_on, description, percent_done, is_container, container_bar_id, parked, strategic_value, notes, tags, custom_text_fields, custom_dropdown_fields. Optional per-item roadmap_id.
dry_runNoTrue to validate and return the payloads without writing
roadmap_idNoRoadmap all bars are on; skips one bar lookup per item when names need validating

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv6.0.0

TDQS

A4.9/5.0
Behavior5/5

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

The description reveals behaviors beyond annotations (which only signal destructiveHint=true): validation before any write ('One invalid item means nothing is sent'), dry_run returning exact payloads without writing, 4-at-a-time writes under the client's rate limiter, per-item result format, and the nuance that an error only occurs when no bar is updated (partial failures are normal results with retry guidance). It also flags unsupported fields (legend_id, effort) routed to manage_bar. This is comprehensive behavioral disclosure.

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 longer than typical but front-loads the purpose and use cases before the detailed operation semantics. Every sentence contributes to operational correctness — override logic, validation, dry run, rate limiting, failure handling. It is dense but not padded; slightly tighter could be achieved without losing value, but the length is justified by the bulk-write 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?

The description covers usage, validation, error semantics, retry behavior, dry run, concurrency, capacity limits, and return format. With no output schema present, it explicitly states the per-item result structure and summary format. It also addresses rate limiting and the optimization via roadmap_id. No critical gap remains for an agent to invoke the tool correctly.

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

Parameters5/5

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

Though the schema documents all 4 parameters (100% coverage), the description adds critical semantics: set vs items override behavior ('an item's own fields override set'), the capacity limit (up to 100 items) and uniqueness constraint (each bar_id may appear once), and how roadmap_id skips per-bar roadmap lookups. It also clarifies dry_run and the per-item roadmap_id field. These are material additions beyond the schema descriptions.

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 ('Update many bars in one call') with concrete operation examples (recolor, move lanes, retag, reschedule, set progress). It explicitly distinguishes itself from the single-bar sibling manage_bar and from other bulk tools in the sibling list. The purpose is unambiguous and uniquely identifiable.

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?

It includes a 'USE WHEN' block with example user phrases and explicitly routes single-bar cases to manage_bar. It also enumerates 'FAILS WHEN' conditions, giving clear operational boundaries. This is explicit when-to-use, when-not-to-use, and alternative tool guidance.

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