Skip to main content
Glama
olgasafonova

productplan-mcp-server

by olgasafonova

bulk_create_bars

Create up to 100 roadmap bars in one call, validating every item before anything is written. Use dry-run to preview payloads, and on partial failure retry only the failed bars to avoid duplicates.

Instructions

Create many bars on one roadmap in one call.

USE WHEN: "Add these 20 features to the roadmap", "Import this list as bars", "Create a bar per epic" For a single bar, use manage_bar instead. Each item needs name and a lane (lane name or lane_id), from the item or from set. Put shared values in set (e.g. set:{"lane":"Backend","legend":"Exploring"}). Up to 100 items. All items are validated against the roadmap before anything is written; one invalid item means nothing is sent. dry_run:true returns the exact POST payloads without writing. Parking follows manage_bar: a bar given starts_on and ends_on and no parked lands on the timeline (parked:false); an undated bar is parked by ProductPlan's default; a nested bar inherits its container's parked state. Writes run 4 at a time under the client's rate limiter. Returns per-item {index, bar_id, name, ok, error} and a summary like "Created 18 of 20 bars; 2 failed". The result is an error only when no bar was created. On a partial failure, retry only the failed items: resending the whole call would duplicate the bars that were created. FAILS WHEN: roadmap_id missing, items empty or over 100, an item without name or lane, a name not on the roadmap.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
setNoFields applied to every item unless the item sets them itself
itemsYesBars to create: [{name, lane or lane_id, ...fields}]. Fields are the same as manage_bar create.
dry_runNoTrue to validate and return the payloads without writing
roadmap_idYesRoadmap to create the bars on

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv6.0.0

TDQS

A4.8/5.0
Behavior5/5

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

Even though annotations exist, the description adds substantial behavior beyond them: atomic all-or-nothing validation ("one invalid item means nothing is sent"), dry_run semantics, parking inheritance rules, rate limiting ("Writes run 4 at a time"), partial-failure error semantics, and explicit retry guidance with the duplicate-warning. No contradiction with annotations — readOnlyHint=false and idempotentHint=false align with the warning that resending the whole call duplicates created bars.

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 every block earns its place: USE WHEN, single-bar alternative, item requirements, set semantics, atomicity, dry_run, parking, rate limits, return format, retry guidance, and FAILS WHEN. Clear structural markers make it scannable, and the core purpose is front-loaded in the first sentence. Slightly dense, but no wasted words.

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?

For a complex bulk-write tool with nested objects, no output schema, and 4 parameters, the description is remarkably complete. It covers the return value explicitly (per-item result objects and summary string) since there is no output schema, plus error semantics, validation behavior, retry strategy, and failure conditions. Nothing an agent needs to call this safely and correctly is missing.

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 baseline is 3, but the description adds real meaning: it clarifies the lane resolution rule (lane from the item OR from set, and by name or lane_id), gives a concrete set example, states the 100-item cap, and cross-references fields to manage_bar create. The dry_run parameter gains precision ("returns the exact POST payloads") beyond the schema's wording.

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 first sentence states a specific verb, resource, and scope: "Create many bars on one roadmap in one call." It names the sibling it is routing away from (manage_bar) and is unmistakably distinct from the other sibling alternatives (bulk_update_bars, bulk_delete_bars). An agent can tell exactly what this tool does without opening the schema.

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?

The description provides an explicit USE WHEN block with concrete natural-language triggers ("Add these 20 features to the roadmap", "Import this list as bars") and a direct exclusion: "For a single bar, use manage_bar instead." It also implies when NOT to use it vs. the update/delete bulk siblings by naming the operation as create-only. Routing guidance is fully explicit.

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