Skip to main content
Glama
Sign In
dpesch

MantisBT MCP Server

by dpesch
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Get Issue Enum Values

get_issue_enums
Read-onlyIdempotent

Retrieve valid IDs and names for MantisBT issue enum fields to select correct severity, status, priority, resolution, and reproducibility values before creating or updating issues.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.14.0
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Addedv1.10.4
  3. Removed
  4. First observedv1.5.6

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: discloses the deprecation lifecycle and removal version, shows concrete return shapes for both English and localized installs, and explains the non-obvious installation-level customization case where 'name' itself is localized and no 'label' is present. It also states how each field is consumed downstream (create_issue vs update_issue).

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?

Front-loaded with the deprecation notice, which is exactly right. The two full example responses overlap heavily — the localized example could have been reduced to just the 'status' fragment it already is — so a little length is spent on illustration that a one-line explanation would cover.

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?

There is no output schema, so the description carries return-value explanation entirely, and it does: sample payloads, per-field meaning, localization caveat, and downstream consumption guidance. Nothing an agent needs to call or interpret this zero-arg tool is missing.

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?

Zero parameters, so the baseline is 4; the schema is empty and needs no compensation. The description's value-format notes ('pass the canonical English name, the localized name, or the label') apply to sibling tools rather than this one's inputs, but they usefully document the output fields.

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 and resource — 'Return valid ID, name, and (if available) localized label for all issue enum fields' — and immediately names the sibling that supersedes it (get_issue_schema). An agent can distinguish it from get_issue_schema, get_issue_fields, and get_metadata without opening any schema.

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?

Gives explicit timing ('use this tool before creating or updating issues') and names lookup targets (severity, status, priority, resolution, reproducibility), plus a deprecation redirect to get_issue_schema. The one gap is the mild tension between 'Deprecated: use get_issue_schema instead' and 'Use this tool before creating or updating issues' — the agent isn't told which wins when both are available.

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