Skip to main content
Glama
Sign In
idea-base-mcp-server

idea-base-mcp-server

Official
by IDEAManagement
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

set_sprint_cadence

Configure a product's sprint rhythm by setting sprint length, start weekday, automatic sprint creation, and carry-over of unfinished work; changes apply from the next sprint opened.

Instructions

Set a product's sprint rhythm. "Mon-Sun weekly" is length_days 7 + start_weekday 1; a Wednesday fortnight is 14 + 3. Changing it does not move sprints that already exist — it applies from the next sprint opened. Setting a cadence is also what opts a product into having sprints opened and closed on the schedule.

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": {
      "product_id": "<product_id>"
    },
    "name": "set_sprint_cadence"
  }
}

Input Schema

NameRequiredDescriptionDefault
enabledNoWhether the schedule touches this product at all. Default true.
product_idYesThe product to configure
auto_createNoOpen the next sprint unattended on the schedule. Default true.
length_daysNoSprint length in days, 1-90. Default 7.
start_weekdayNo0 = Sunday through 6 = Saturday. Default 1 (Monday). Only decides the FIRST sprint; later ones follow the previous sprint's end.
carry_over_unfinishedNoMove unfinished work into the next sprint on close. Default true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.7.0

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the load and does well: it discloses the non-retroactive behavior ('does not move sprints that already exist') and the opt-in side effect of enabling scheduled open/close. It omits permissions requirements and whether the call is idempotent or returns the resulting cadence.

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?

Three tight sentences, front-loaded with purpose, then concrete encoding examples, then the behavioral caveat. The examples earn their space by disambiguating weekday numbering; nothing is redundant.

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?

For a mutation tool with no annotations and no output schema, the description covers the most important behavioral caveats, but it leaves the return value, permission prerequisites, and the effect of enabled=false versus not calling at all unstated. Adequate, not complete.

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

Parameters3/5

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

Schema coverage is 100%, so the schema already documents all six parameters including defaults and ranges. The description adds a genuine interpretive example (7 + 1 = Mon-Sun weekly; 14 + 3 = Wednesday fortnight) that helps an agent reason about length_days and start_weekday together, but it doesn't touch enabled, auto_create, or carry_over_unfinished.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence gives a specific verb+resource ('Set a product's sprint rhythm') and the rest clarifies what cadence means concretely. It stops short of naming the sibling get_sprint_cadence as the read counterpart, so differentiation relies on the reader inferring it.

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 explains the operational consequence of calling it — the cadence applies from the next sprint opened and is what opts a product into auto open/close — which tells an agent when this is the right lever. It doesn't explicitly state when not to use it (e.g. to edit an existing sprint, use update_sprint/close_sprint), so a small gap remains.

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