Skip to main content
Glama

List Releases

list_releases
Read-only

Browse and filter a project's releases (milestones) by type, status, completion, parent release, or name search to find the ones you need.

Instructions

Browse releases (milestones) for a project. Supports filtering by type, completion status, parent release, and free-text search on name. Pass parentReleaseId to get only the direct children of a release (releases nest up to 3 levels deep). Default page size is 25 (max 200).

Input Schema

NameRequiredDescriptionDefault
pageNo
typeNoRelease type. Default options (lowercased on save so the UI badge color matches): "release", "version", "sprint", "iteration", "plan", "cycle", "feature". Display labels ("Sprint", "Iteration", …) are accepted and normalized. Projects can customize this list via Project Settings → Release Types, so other values may be valid for a given project.
limitNoDefault 25
searchNoMatch by name
sortByNo
statusNoRelease status (project-specific)
projectIdYesProject ID
sortOrderNo
isCompletedNo
parentReleaseIdNoFilter to direct children of a release

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed13 schema fields changedv2.2.0
    • addedInput schema / $schema
      Added value: +"http://json-schema.org/draft-07/schema#"
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / limit / description
      Previous value: -"Default 25 (max 200)."New value: +"Default 25"
    • addedInput schema / properties / limit / maximum
      Added value: +200
    • addedInput schema / properties / limit / minimum
      Added value: +1
    • changedInput schema / properties / limit / type
      Previous value: -"number"New value: +"integer"
    • addedInput schema / properties / page / minimum
      Added value: +1
    • changedInput schema / properties / page / type
      Previous value: -"number"New value: +"integer"
    • changedInput schema / properties / parentReleaseId / description
      Previous value: -"Direct children of this release."New value: +"Filter to direct children of a release"
    • changedInput schema / properties / projectId / description
      Previous value: -"Project ID (required)."New value: +"Project ID"
    • changedInput schema / properties / search / description
      Previous value: -"Match by release name."New value: +"Match by name"
    • changedInput schema / properties / status / description
      Previous value: -"Release status (project-specific)."New value: +"Release status (project-specific)"
    • changedInput schema / properties / type / description
      Previous value: -"Release type. Either canonical ('iteration', 'major') or display ('Iteration', 'Major') form — server normalizes to lowercase so UI badge color matches."New value: +"Release type. Default options (lowercased on save so the UI badge color matches): \"release\", \"version\", \"sprint\", \"iteration\", \"plan\", \"cycle\", \"feature\". Display labels (\"Sprint\", \"Iteration\", …) are accepted and normalized. Projects can customize this list via Project Settings → Release Types, so other values may be valid for a given project."
  2. Addedv1.0.10

TDQS

A4/5.0
Behavior3/5

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

Annotation readOnlyHint=true already establishes safe read behavior. Description adds the 3-level nesting depth constraint and pagination defaults (25/200), which is useful behavioral context beyond the annotation. But doesn't mention pagination mechanics or ordering guarantees.

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?

Four tight sentences, front-loaded with purpose, then filters, then the key nesting semantic, then pagination limits. No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Complete enough for a 10-param list tool: purpose, main filters, nesting semantics, and pagination defaults all covered. Minor gap: no output schema, so an agent gets no hint about returned release fields.

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 60%, and description compensates by naming what filters do (type, completion status, parent release, search on name) and explaining parentReleaseId semantic (direct children, 3 levels). Adds meaning over the terse schema descriptions for several params.

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?

States a specific verb (Browse/List) and resource (releases/milestones) with clear scope for a project. Distinguished from siblings like get_release (single) and create_release through the explicit 'list' framing.

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

Usage Guidelines3/5

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

Implied usage as a discovery/list tool, with some filtering context. But no explicit when-to-use vs get_release or when to prefer search over parentReleaseId filtering. No exclusions stated.

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