Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
PORTNoPort for HTTP mode3000
TRANSPORTNoTransport mode: stdio or httpstdio
MCP_HTTP_HOSTNoBind address for HTTP mode. Set to 0.0.0.0 for Docker or remote access.127.0.0.1
MANTIS_API_KEYYesAPI token for authentication
MCP_HTTP_TOKENNoWhen set, the /mcp endpoint requires Authorization: Bearer <token>.
MANTIS_BASE_URLYesBase URL of the MantisBT REST API
MANTIS_CACHE_DIRNoDirectory for the metadata cache~/.cache/mantisbt-mcp
MANTIS_CACHE_TTLNoCache lifetime in seconds3600
MANTIS_SEARCH_DIRNoDirectory for the search index (defaults to {MANTIS_CACHE_DIR}/search)
MANTIS_UPLOAD_DIRNoRestrict upload_file to files within this directory to prevent path traversal.
MANTIS_SEARCH_MODELNoEmbedding model name (downloaded once on first use, ~80 MB)Xenova/paraphrase-multilingual-MiniLM-L12-v2
MANTIS_SEARCH_BACKENDNoVector store backend: vectra (pure JS) or sqlite-vec (requires manual install)vectra
MANTIS_SEARCH_ENABLEDNoSet to true to enable semantic searchfalse
MANTIS_SEARCH_THREADSNoNumber of ONNX intra-op threads for the embedding model.1

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}
prompts
{
  "listChanged": true
}
resources
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
get_issueA

Retrieve one MantisBT issue by "id", or several by "ids" (1–50). Pass exactly one of the two.

With "id": returns the issue with all fields including notes (each with view_url), attachments and relationships, unless "select" is given. With "ids": returns { issues, requested, found, failed } — requests run in parallel (max 5 concurrent); missing or inaccessible IDs give null at their position instead of failing the call.

Use "select" to fetch only some fields, e.g. select: "notes" for just the notes or select: "attachments" for just the file attachments of an issue.

get_issuesA

Deprecated: use get_issue with ids instead — get_issues will be removed in 2.0.0.

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_issuesA

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); if that limit ends the search before the page is full, the response contains "truncated": true. 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.

For overviews use "group_by" ("status", "handler", "priority" or "category"): the server counts all matching issues itself and returns { group_by, total, groups: [{ id, name, label?, count }] } instead of an issue list — far fewer tokens than listing issues and counting them. All filters still apply. If the scan stops at its limit (50,000 issues), the response contains "truncated": true.

create_issueA

Create a new MantisBT issue. Returns the full created issue object including the assigned id, summary, status, priority, severity, category, reporter, created_at, and view_url.

Required fields: summary, description, project_id, category. All other fields are optional with sensible defaults (priority: "normal", severity: "minor").

Recommended workflow:

  1. Call get_project with include: ["categories"] to obtain a valid category name

  2. Optionally add "versions" to include to obtain version names

  3. Optionally call get_project with member_query to resolve the assignee's username

Both priority and severity accept canonical English names or localized labels from the connected MantisBT instance — call get_issue_schema to see all available values.

For the handler, prefer the username field (resolved server-side) over handler_id when working interactively.

update_issueA

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" }

  • custom_fields: [{field: {id|name}, value: ""}] (only the listed custom fields are changed, others stay untouched; use get_issue_schema to discover fields)

  • notes: [{ id: <note_id>, text?: "", view_state?: "public"|"private" }] (edits existing notes; note IDs come from get_issue. An omitted view_state keeps the note's current visibility. To add a new note use the "note" parameter or add_note.)

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

Use the optional "note" parameter to append a note in the same call (e.g. the reason for a status change) — no separate add_note call needed. For a note without field changes use add_note.

Use "add_monitors" / "remove_monitors" (lists of MantisBT login names) to change who watches the issue — "fields" may be omitted then. The response contains "monitors" with added/removed/not_monitoring and the current monitor list. Adding or removing other users requires the monitor_add_others_bug_threshold / monitor_delete_others_bug_threshold access level.

Steps run in order: fields, monitors, note. Once one step succeeded, a later failure is reported inline ("notes_error" when a note edit was not applied, "monitors_error", "note_error") instead of failing the call — do not retry the steps that went through. Only if every requested step failed is the call an error.

delete_issueB

Permanently delete a MantisBT issue. This action is irreversible.

list_notesA

Deprecated: use get_issue with select: "notes" instead — list_notes will be removed in 2.0.0.

List all notes (comments) attached to a MantisBT issue.

add_noteA

Add a note (comment) to an existing MantisBT issue. Returns the created note object including id, created_at, reporter, text, view_state, and a view_url linking directly to the note in the MantisBT web UI.

Full UTF-8 text is supported. Markdown syntax is stored as-is — rendering depends on the MantisBT instance's configured text renderer.

Use view_state="private" to restrict the note to users with reporter-level access or higher; public notes are visible to all users who can view the issue.

Prerequisites: obtain issue_id from list_issues, get_issue, or search_issues.

delete_noteA

Permanently delete a note from a MantisBT issue. This action is irreversible — deleted notes cannot be recovered.

Returns a plain-text confirmation message on success. Returns an error if the note does not exist or the current user lacks permission to delete it (MantisBT enforces access control: users can typically only delete their own notes unless they have manager-level access or higher).

Prerequisites: obtain note_id from get_issue (notes[].id).

list_issue_filesA

Deprecated: use get_issue with select: "attachments" instead — list_issue_files will be removed in 2.0.0.

List all file attachments of a MantisBT issue. Returns an array of attachment objects, each containing id, filename, size in bytes, content_type, and download_url. Returns an empty array if the issue has no attachments.

upload_fileA

Upload a file as an attachment to a MantisBT issue. Adds the file to the issue without modifying any issue fields or status. Returns the created attachment metadata on success.

Provide exactly one of the two input modes:

  • file_path (preferred): absolute path to a local file — use this whenever the file exists on disk; the server reads and encodes it automatically; filename is derived from the path. Note: file_path reads from the server's filesystem and is disabled over the HTTP transport unless MANTIS_UPLOAD_DIR is configured — HTTP clients should use content instead.

  • content: Base64-encoded file content — only use this when the file is not accessible via a path (e.g. in-memory data); filename must be supplied explicitly via the filename parameter

The optional content_type sets the MIME type (e.g. "image/png"); defaults to "application/octet-stream". Use the optional description to annotate the attachment.

Use this tool to attach files such as logs, screenshots, or patches to an existing issue. To list existing attachments, use get_issue with select: "attachments".

add_relationshipA

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_relationshipA

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_monitorA

Deprecated: use update_issue with add_monitors instead — add_monitor will be removed in 2.0.0.

Add a user as a monitor (watcher) of a MantisBT issue. Monitors receive email notifications whenever the issue is updated. Returns { success, monitors } — "monitors" lists the login names now monitoring the issue.

Use it to subscribe team members to issue updates without assigning them as the handler.

Adding a user who is already a monitor is a no-op — the operation succeeds without creating duplicates.

Prerequisites: obtain issue_id from list_issues or get_issue; use get_project with member_query to look up valid MantisBT login names.

remove_monitorA

Deprecated: use update_issue with remove_monitors instead — remove_monitor will be removed in 2.0.0.

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

Returns { success, removed, monitors } — "monitors" lists the login names still monitoring the issue. If the user was not a monitor, the call succeeds with removed=false and nothing is changed.

Removing another user requires the monitor_delete_others_bug_threshold access level; without it the call returns an error.

get_projectA

Get one MantisBT project: its master data (id, name, description, status, enabled, view_state, access_level, subprojects) and, on request, its categories, users and versions in the same call.

  • include: any of "categories", "users", "versions" (default: none — master data only).

  • categories: names come without the "[All Projects] " prefix, ready for create_issue / update_issue.

  • users: id, name (login name), real_name, email, access_level. access_level returns only users at or above that level (10=viewer, 25=reporter, 40=updater, 55=developer, 70=manager, 90=administrator) and implies include "users".

  • member_query: case-insensitive substring search in login name, real name and email; returns all matching users. Implies include "users".

  • versions: id, name, released, obsolete, timestamp. obsolete=true adds obsolete versions, inherit=true adds versions of parent projects; either implies include "versions".

Users come from the local metadata cache when it is fresh and no access_level is given. Prerequisites: obtain project_id from list_projects.

list_projectsA

List all MantisBT projects accessible to the current API user.

get_project_usersA

Deprecated: use get_project with include: ["users"] instead — get_project_users will be removed in 2.0.0.

List all users with access to a specific MantisBT project. Returns an array of user objects, each containing id, name (login name), real_name, email, and access_level fields.

Access level IDs: 10=viewer, 25=reporter, 40=updater, 55=developer, 70=manager, 90=administrator.

Prerequisites: obtain project_id from list_projects.

get_project_versionsA

Deprecated: use get_project with include: ["versions"] instead — get_project_versions will be removed in 2.0.0.

List all versions defined for a MantisBT project. Returns an array of version objects, each containing id, name, released (boolean), obsolete (boolean), and timestamp (version date). To create, change, release or delete versions use create_version, update_version, release_version and delete_version.

Use the returned version names directly when creating or updating issues via create_issue and update_issue (version, target_version, fixed_in_version fields).

By default, obsolete and inherited parent-project versions are excluded. Set obsolete=true to include deprecated versions; set inherit=true to also return versions from parent projects.

Prerequisites: obtain project_id from list_projects.

get_project_categoriesA

Deprecated: use get_project with include: ["categories"] instead — get_project_categories will be removed in 2.0.0.

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.

find_project_memberA

Deprecated: use get_project with member_query instead — find_project_member will be removed in 2.0.0.

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.

create_versionA

Create a new version in a MantisBT project. Returns the created version object (id, name, description, released, obsolete, timestamp).

Version names must be unique within the project. Without timestamp, MantisBT uses the current date.

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

update_versionA

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).

release_versionA

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).

delete_versionA

Permanently delete a version of a MantisBT project. This action is irreversible.

MantisBT clears the version, target_version and fixed_in_version fields of all issues that reference the deleted version (including subprojects if versions are inherited). To retire a version without touching issues, set obsolete=true via update_version instead.

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).

get_current_userA

Retrieve the profile of the user associated with the current API key: id, name (login name), real_name, email, language, timezone, access_level, created_at and the accessible projects.

"language" is the MantisBT language of this user (e.g. "german", "english") — use it as the hint for which language to write issue texts and notes in, and expect localized enum labels in that language.

list_filtersA

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

get_configA

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

get_issue_enumsA

Deprecated: use get_issue_schema instead — get_issue_enums will be removed in 2.0.0.

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_languagesA

Deprecated: use get_current_user (field "language") instead — list_languages will be removed in 2.0.0.

Despite its name, MantisBT's GET /lang returns only the language of the current user ({ strings, language }), not a list of all languages.

list_tagsA

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 get_metadata.

sync_metadataA

Deprecated: use get_metadata with refresh: true instead — sync_metadata will be removed in 2.0.0.

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.

get_metadataA

Return the cached MantisBT metadata (projects with their users, versions and categories, plus all tags).

  • detail: "summary" (default) — compact counts: project count, tag count, per-project counts of users, versions and categories, cached_at, ttl_seconds.

  • detail: "full" — the complete raw cache with all lists (large; minified JSON).

  • refresh: true — re-fetch everything from MantisBT before answering (otherwise the cache is used and only synced when missing or expired; default TTL 24 hours).

When semantic search is enabled, the response also contains "search_index": how many issues are indexed vs. the total, and the time of the last sync.

For lists of a single project use get_project with include; for tags use list_tags.

get_metadata_fullA

Deprecated: use get_metadata with detail: "full" instead — get_metadata_full will be removed in 2.0.0.

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 get_metadata with refresh: true to force a refresh.

get_issue_fieldsA

Deprecated: use get_issue_schema instead — get_issue_fields will be removed in 2.0.0.

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.

get_issue_schemaA

Return what is valid for issues on this MantisBT server, in one response:

  • fields: all field names valid for the "select" parameter of get_issue, list_issues and search_issues. Discovered from a sample issue (reflects the server's active configuration) plus fields MantisBT omits when empty (notes, attachments, relationships, …); cached with the metadata TTL. fields_source tells where they came from: "cache", "live" or "static".

  • enums: ID, name and (if available) localized label for severity, status, priority, resolution and reproducibility. "name" or "id" is what create_issue / update_issue accept; "canonical_name" appears on localized installations.

Call it before building a "select" string or before setting enum fields.

attach_tagsA

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).

detach_tagA

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.

get_versionA

Return the version of this mantisbt-mcp-server and of the connected MantisBT installation in one response: { mcp_server: { version }, mantis: { installed_version, latest_version?, status?, github_note? } }

The MantisBT version is read from the X-Mantis-Version response header. With check_latest (default: true) it is compared against the latest MantisBT release on GitHub (outbound HTTPS request, up to 5 seconds); status is "up-to-date", "update-available", "newer-than-release" or "unknown". If MantisBT cannot be reached, mantis contains "error" instead and mcp_server is still returned.

get_mcp_versionA

Deprecated: use get_version instead — get_mcp_version will be removed in 2.0.0.

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

get_mantis_versionA

Deprecated: use get_version instead — get_mantis_version will be removed in 2.0.0.

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

Prompts

Interactive templates invoked by user choice

NameDescription
create-bug-reportGuide the creation of a complete bug report in MantisBT. Project, category, summary, and description are required.
create-feature-requestGuide the creation of a feature request in MantisBT. Project, category, summary, and description are required.
summarize-issueFetch a MantisBT issue and provide a concise summary of its status, details, and recent activity.
project-statusGenerate a status overview of open issues for a MantisBT project, grouped by severity.

Resources

Contextual data attached and managed by the client

NameDescription
current-userProfile of the user associated with the configured API key.
projectsAll MantisBT projects accessible to the current API user. Served from local cache when fresh; falls back to live fetch. Refresh via get_metadata with refresh: true.
issue-enumsValid values for issue enum fields: severity, priority, status, resolution, and reproducibility. Use these to look up IDs or names before creating or updating issues.

TDQS

A3.7/5.0

Scored across 41 tools

Disambiguation2/5

A large fraction of the surface is deprecated aliases whose functionality is already covered by newer tools: get_issues vs get_issue, list_notes/list_issue_files vs get_issue select, add_monitor/remove_monitor vs update_issue, get_project_users/versions/categories/find_project_member vs get_project, get_issue_enums/get_issue_fields vs get_issue_schema, and get_mcp_version/get_mantis_version vs get_version. The deprecation notes prevent outright confusion, but an agent must still choose between multiple tools that do the same thing, which is exactly the overlap this dimension penalizes.

Naming Consistency4/5

Nearly all tools follow a predictable snake_case verb_noun pattern (get_issue, create_issue, list_projects, add_note, delete_version). Minor deviations exist in the version tools (get_version alongside get_mcp_version/get_mantis_version) and a few noun-first resource names like list_issue_files, but the convention remains readable throughout.

Tool Count2/5

41 tools is well above the 25-tool threshold for a heavy surface, and a significant portion (roughly a dozen) are deprecated shims that duplicate newer tools. The effective useful surface is much smaller than 41, making the count poorly scoped for the server's purpose.

Completeness4/5

Core issue lifecycle is well covered: list/get/create/update/delete issues, notes, attachments, monitors, relationships, tags, versions CRUD, projects, schema, config, and metadata. Remaining gaps are minor—no attachment deletion, no project/category/tag create-update-delete tools—but agents can work around these, and the deprecated aliases still provide coverage for older clients.

Maintenance

ActivityMaintained
ResponsivenessNo issues