MantisBT MCP Server

Retrieve a single MantisBT issue by its numeric ID. Returns all issue fields including notes, attachments, and relationships. Notes are always included — no separate list_notes call needed.

Retrieve multiple MantisBT issues by their numeric IDs in a single MCP call. Requests run in parallel (max 5 concurrent). Missing or inaccessible IDs return null at their array position — the call never fails due to individual missing IDs. Response includes "requested", "found", and "failed" counters for quick validation.

List MantisBT issues with optional filtering. Returns a paginated list of issues. Use the "select" parameter to limit returned fields and reduce response size significantly.

Note: "assigned_to", "reporter_id", "status", and date filters are applied client-side (the MantisBT REST API does not support these as server-side filters). When any of these filters are active the tool automatically fetches multiple pages internally until enough matching results are found (up to 500 issues scanned). The "page" and "page_size" parameters refer to the resulting filtered list.

Tip for date queries: fetching with select="id,updated_at,created_at" plus a date filter is very compact and efficient.

Create a new MantisBT issue. Returns the created issue including its assigned ID.

Update one or more fields of an existing MantisBT issue using a partial PATCH.

The "fields" object accepts any combination of:

• summary (string)

• description (string)

• steps_to_reproduce (string)

• additional_information (string)

• status: { name: "new"|"feedback"|"acknowledged"|"confirmed"|"assigned"|"resolved"|"closed" }

• resolution: { id: 20 } (20 = fixed/resolved)

• handler: { id: <user_id> } or { name: "" }

• priority: { name: "<priority_name>" }

• severity: { name: "<severity_name>" }

• reproducibility: { name: "<reproducibility_name>" }

• category: { name: "<category_name>" }

• version: { name: "<version_name>" } (affected version)

• target_version: { name: "<version_name>" }

• fixed_in_version: { name: "<version_name>" }

• view_state: { name: "public"|"private" }

Important: when resolving an issue, always set BOTH status and resolution to avoid leaving resolution as "open".

Permanently delete a MantisBT issue. This action is irreversible.

List all notes (comments) attached to a MantisBT issue. Note: get_issue already includes notes in its response — use list_notes only when you need notes without fetching the full issue.

Add a note (comment) to an existing MantisBT issue. Full UTF-8 text is supported.

Permanently delete a note from a MantisBT issue. This action is irreversible.

List all file attachments of a MantisBT issue.

Upload a file as an attachment to a MantisBT issue via multipart/form-data.

Two input modes (exactly one must be provided):

• file_path: absolute path to a local file — filename is derived from the path automatically

• content: Base64-encoded file content — filename must be supplied explicitly via the filename parameter

The optional content_type parameter sets the MIME type (e.g. "image/png"). If omitted, "application/octet-stream" is used.

Add a relationship between two MantisBT issues.

Relationship types — use either type_id (numeric) or type_name (string):

• 0 / "duplicate_of" — this issue is a duplicate of target

• 1 / "related_to" — this issue is related to target

• 2 / "parent_of" — this issue depends on target (target must be done first); alias: "depends_on"

• 3 / "child_of" — this issue blocks target (target can't proceed until this is done); alias: "blocks"

• 4 / "has_duplicate" — this issue has target as a duplicate

Directionality note: "A child_of B" means A blocks B. "A parent_of B" means A depends on B.

Dash variants (e.g. "related-to") are also accepted for type_name.

Remove a relationship from a MantisBT issue.

Use get_issue first to retrieve the relationship IDs. The relationship_id is the numeric id field of a relationship object in the issue's relationships array (not the type ID).

Add a user as a monitor (watcher) of a MantisBT issue. Monitors receive email notifications for issue updates.

Remove a user from the monitor list of a MantisBT issue. The user will no longer receive email notifications for updates to this issue.

List all MantisBT projects accessible to the current API user.

List all users with access to a specific MantisBT project.

List all versions defined for a MantisBT project.

List all categories available for a MantisBT project.

Note: The MantisBT API returns global (cross-project) categories with a "[All Projects] " prefix. This tool strips that prefix so the returned names can be used directly when creating issues.

Search for users with access to a MantisBT project by name, display name, or email.

Returns up to limit matching users (default: 10, max: 100). Matching is case-insensitive substring search across name, real_name, and email fields. Omit query to list the first limit users.

Data is served from the local metadata cache when fresh; falls back to a live API call otherwise.

Retrieve the profile of the user associated with the current API key.

List all saved MantisBT issue filters accessible to the current user. Filter IDs can be used with list_issues.

Retrieve one or more MantisBT configuration options.

Common option names:

• "status_enum_string" — issue status values and their IDs

• "priority_enum_string" — priority values

• "severity_enum_string" — severity values

• "resolution_enum_string" — resolution values

• "reproducibility_enum_string" — reproducibility values

• "view_state_enum_string" — view state values

• "access_levels_enum_string" — access level values

Return valid ID, name, and (if available) localized label for all issue enum fields.

Use this tool before creating or updating issues to look up the correct value for severity, status, priority, resolution, or reproducibility.

Example response (English installation): { "severity": [{"id": 10, "name": "feature"}, {"id": 50, "name": "minor"}, ...], "status": [{"id": 10, "name": "new"}, {"id": 20, "name": "feedback"}, ...], "priority": [{"id": 10, "name": "none"}, {"id": 30, "name": "normal"}, ...], "resolution": [{"id": 10, "name": "open"}, {"id": 20, "name": "fixed"}, ...], "reproducibility": [{"id": 10, "name": "always"}, {"id": 70, "name": "have not tried"}, ...] }

Example response (localized installation, e.g. German): { "status": [ {"id": 10, "name": "new", "label": "Neu"}, {"id": 20, "name": "feedback", "label": "Feedback"}, {"id": 30, "name": "acknowledged", "label": "Bestätigt"}, ... ], ... }

Fields:

• "id" — numeric ID accepted by the API

• "name" — localized or canonical name from the MantisBT database

• "label" — UI display label (only present when it differs from "name")

• "canonical_name" — English canonical name (only present on localized installs)

For create_issue (severity, priority, reproducibility): pass the canonical English name, the localized "name", or the "label" — all are accepted. The server resolves them to the correct ID.

For update_issue: pass either "id" or "name" in the field reference object.

Note: on some installations enum values are customized at the database level. In that case "name" itself may be localized (e.g. "kleinerer Fehler" instead of "minor") and no "label" will be present because there is no separate English original.

List all languages supported by the MantisBT installation.

List all tags defined in the MantisBT installation.

The MantisBT REST API exposes a GET /tags endpoint on some installations. If that endpoint is not available, this tool falls back to the local metadata cache populated by sync_metadata.

Fetch all projects and their associated users, versions, categories, and tags from MantisBT and store them in the local metadata cache.

Tags are fetched via the dedicated GET /tags endpoint when available. On installations where that endpoint is missing (MantisBT < 2.26), tags are collected by scanning all issues across all projects.

This is useful for getting a complete overview of your MantisBT installation. The cache is valid for 24 hours by default (configurable via MANTIS_CACHE_TTL env var). Use this tool to refresh stale data.

Return a compact summary of cached MantisBT metadata: project count, tag count, and per-project counts of users, versions, and categories.

If the cache does not exist or has expired (default TTL: 24 hours), it will automatically sync first. Use sync_metadata to force a refresh. For full lists use: list_projects (projects), get_project_users / get_project_versions / get_project_categories (per-project data), list_tags (tags).

Return the complete raw MantisBT metadata cache: all projects with full fields, and per-project lists of users, versions, categories, plus all tags.

If the cache does not exist or has expired (default TTL: 24 hours), it will automatically sync first. Use sync_metadata to force a refresh. For a lightweight overview use get_metadata instead.

Return all field names that are valid for the "select" parameter of list_issues and get_issue.

Fields are discovered by fetching a sample issue from MantisBT (which reflects the server's active configuration — e.g. whether eta, projection, or profile fields are enabled) and merging the result with fields that MantisBT omits when empty (notes, attachments, relationships, etc.). The result is cached with the same TTL as the metadata cache.

Use this tool before constructing a "select" string to ensure you only request fields that exist on this server.

Attach one or more tags to a MantisBT issue.

Each tag can be specified either by ID or by name. If a tag name is provided that does not exist yet, MantisBT will create it automatically (requires tag_create_threshold permission, default: REPORTER).

Requires tag_attach_threshold permission (default: REPORTER).

Remove a tag from a MantisBT issue.

Requires tag_detach_own_threshold (default: REPORTER) for own tags, or tag_detach_threshold (default: DEVELOPER) for tags attached by others.

Returns the version of this mantisbt-mcp-server instance.

Returns the version of the connected MantisBT installation and optionally compares it against the latest official release on GitHub.

The version is read from the X-Mantis-Version response header sent by every API call. The GitHub comparison requires an outbound HTTPS request to the GitHub API.