Skip to main content
Glama
Sign In
dpesch

MantisBT MCP Server

by dpesch
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Update Version

update_version
Idempotent

Updates an existing MantisBT project version, changing only specified fields and optionally releasing it while creating a follow-up version.

Instructions

Update an existing version of a MantisBT project. Only the fields you pass are changed. Returns the updated version object.

Renaming a version also rewrites the version, target_version and fixed_in_version fields of all issues that reference it (including subprojects if versions are inherited).

Setting released=true does not change the version date — pass timestamp as well (e.g. the release date).

To release a version: released=true, timestamp=, and optionally next_version= to create the follow-up version in the same call. With next_version the response is { version: , next_version: } — or next_version_error: if creating the follow-up failed (the update itself stays in effect). Without next_version the response is the updated version object.

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
nameNoNew version name (must be unique within the project)
obsoleteNoObsolete flag
releasedNoReleased flag
timestampNoVersion date as ISO 8601 string, e.g. "2026-09-27" or "2026-09-27T10:00:00+02:00". Determines the order in roadmap and changelog.
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
descriptionNoNew version description
next_versionNoOnly with released=true: name of a follow-up version to create as unreleased placeholder, e.g. "1.2.1". Used as-is — no automatic numbering.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.15.0
    • addedInput schema / properties / next_version
      Added value: +{
+  "description": "Only with released=true: name of a follow-up version to create as unreleased placeholder, e.g. \"1.2.1\". Used as-is — no automatic numbering.",
+  "minLength": 1,
+  "type": "string"
+}
    • 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.5/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: renaming rewrites issue version fields including subprojects, released=true does not update the version date, next_version has distinct response and error behavior, and inherited versions are rejected with 'Version not found'. It also discloses the required access threshold. No contradiction with readOnlyHint=false, idempotentHint=true, or destructiveHint=false is apparent.

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 front-loaded with the core action and then organized around side effects, release workflow, response shapes, project scoping, and permissions. It is appropriately detailed for a mutation tool with side effects, but it is somewhat dense and repeats the normal return shape after already stating it in the opening sentence.

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?

Given the eight parameters, side effects, access requirement, and absence of an output schema, the description is complete enough to call the tool correctly. It covers discovery, inheritance restrictions, release behavior, follow-up version creation, error behavior for next_version, and return object shapes.

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?

Although schema coverage is already 100%, the description adds meaningful cross-parameter semantics: timestamp must be passed with released=true to set the release date, next_version is only valid with released=true, and next_version changes the response shape. It also explains that project_id must be the owning project rather than a parent whose inherited version is being referenced.

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?

States a specific verb and resource: update an existing MantisBT project version, with partial-update semantics and return shape. It is clear overall, but it overlaps with the sibling release_version tool by explaining release behavior without naming release_version or disambiguating when to use it instead.

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?

Provides strong operational guidance: only passed fields change, releasing requires released=true plus timestamp, next_version creates a follow-up, inherited versions must be changed via the parent project, and manage_project_threshold access is required. It also points to get_project for discovering a project's own versions. The main gap is that it does not explicitly compare with sibling tools such as release_version, create_version, or delete_version.

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