Skip to main content
Glama
Sign In
dpesch

MantisBT MCP Server

by dpesch
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Release Version

release_version

Mark a version as released and set its release date, optionally creating a follow-up version in the same step.

Instructions

Deprecated: use update_version with released=true, timestamp and (optionally) next_version instead — release_version will be removed in 2.0.0.

Mark a version as released and set its date (default: now). Optionally create a follow-up version in the same step.

The follow-up version is only created when next_version is given; its name is used as-is — no automatic numbering.

Returns { released: } plus either next_version: or next_version_error: . The two steps are separate API calls: if creating the follow-up version fails, the release itself stays in effect and the error is reported in next_version_error.

The version must belong to project_id itself: versions inherited from a parent project can only be changed via the parent's project_id (otherwise MantisBT answers "Version not found"). get_project with include: ["versions"] and without inherit lists the project's own versions.

Requires the manage_project_threshold access level in the project (MantisBT default: manager).

Input Schema

NameRequiredDescriptionDefault
timestampNoRelease date as ISO 8601 string. Default: now.
project_idYesNumeric ID of the project the version belongs to — use list_projects to discover project IDs
version_idYesNumeric version ID — use get_project with include: ["versions"] to discover version IDs
next_versionNoName of a follow-up version to create as unreleased placeholder, e.g. "1.2.1". Omit to only release.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.15.0
    • changedInput schema / properties / version_id / description
      Previous value: -"Numeric version ID — use get_project_versions to discover version IDs"New value: +"Numeric version ID — use get_project with include: [\"versions\"] to discover version IDs"
  2. Addedv1.14.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations describe it as a non-readonly, non-idempotent operation, and the description adds substantial behavioral context: default timestamp, follow-up version naming behavior, non-atomic two-call behavior, partial-failure semantics, inherited-version restrictions, and required access level.

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?

The deprecation notice and replacement path are front-loaded, followed by the core behavior and then caveats. Despite its length, each paragraph contributes necessary operational detail and there is no redundant filler.

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?

No output schema exists, and the description still documents the return shape, including next_version_error on partial failure. It also covers permission requirements, inherited-version handling, and how to discover relevant IDs.

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 the baseline is 3. The description still adds meaning beyond the schema by explaining that next_version is used as-is without automatic numbering and that it is created as a separate API call whose failure does not roll back the release.

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 names a specific action and resource: mark a version as released and set its date, with an optional follow-up version. It also explicitly identifies itself as deprecated and points to update_version, which clearly distinguishes it from the sibling tool.

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 gives explicit alternatives (use update_version with released=true, timestamp, and optionally next_version), explains when next_version is created, and states that inherited versions must be changed via the parent project. Access requirements and discovery paths are also provided.

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