Skip to main content
Glama

Get MantisBT Version

get_mantis_version
Read-onlyIdempotent

Check the current MantisBT version and optionally compare it with the latest GitHub release to verify if your installation is up to date.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
check_latestNoWhether to fetch the latest release from GitHub and compare (default: true)

Implementation Reference

  • The `get_mantis_version` tool is registered and implemented within `registerVersionTools` in `src/tools/version.ts`. It handles retrieving the MantisBT version and optionally compares it against the latest GitHub release.
      server.registerTool(
        'get_mantis_version',
        {
          title: 'Get MantisBT Version',
          description: `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.`,
          inputSchema: z.object({
            check_latest: z.preprocess(coerceBool, z.boolean()).default(true).describe(
              'Whether to fetch the latest release from GitHub and compare (default: true)'
            ),
          }),
          annotations: {
            readOnlyHint: true,
            destructiveHint: false,
            idempotentHint: true,
          },
        },
        async ({ check_latest }) => {
          try {
            const installedRaw = await client.getVersion();
            const result: Record<string, unknown> = { installed_version: installedRaw };
    
            if (check_latest) {
              versionHint.triggerLatestVersionFetch();
              const latestRaw = await versionHint.waitForLatestVersion(5000);
    
              result.latest_version = latestRaw;
    
              if (latestRaw === null) {
                result.status = 'unknown';
                result.github_note = 'Could not fetch latest version from GitHub (timeout or network error).';
              } else {
                const installed = parseVersion(installedRaw);
                const latest = parseVersion(latestRaw);
                if (installed && latest) {
                  const cmp = compareVersions(installed, latest);
                  result.status = cmp === 0
                    ? 'up-to-date'
                    : cmp > 0
                      ? 'newer-than-release'
                      : 'update-available';
                } else {
                  result.status = 'unknown';
                }
              }
            }
    
            return {
              content: [{ type: 'text', text: JSON.stringify(result, null, 2) }],
            };
          } catch (error) {
            const msg = error instanceof Error ? error.message : String(error);
            return { content: [{ type: 'text', text: `Error: ${msg}` }], isError: true };
          }
        }
      );
Behavior4/5

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

While annotations declare readOnlyHint=true and destructiveHint=false, the description adds valuable behavioral context: it reveals the version is sourced from the X-Mantis-Version response header (implementation detail) and explicitly discloses that the comparison feature triggers an external HTTPS request to GitHub (network dependency/latency implications). This goes beyond the safety profile provided by annotations.

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 well-structured with the primary purpose front-loaded in the first sentence. Implementation details (header source, GitHub API requirement) follow logically. Every sentence earns its place by providing transparency into data sources or external dependencies, though the header detail is somewhat granular for a high-level description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-parameter read-only tool, the description adequately covers functionality, optional behaviors, and data sources. However, lacking an output schema, it could benefit from a brief description of what the return value contains (e.g., version string format, comparison result structure) to be fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the baseline is 3. The description mentions 'optionally compares it against the latest official release on GitHub,' which aligns with the check_latest parameter's schema description but does not add significant additional semantic detail, examples, or validation rules beyond what the schema already provides.

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?

The description clearly states it 'Returns the version of the connected MantisBT installation' with specific verb and resource. It also mentions the optional GitHub comparison. However, it does not explicitly distinguish from sibling 'get_mcp_version' (which likely returns the server version, not the MantisBT installation version), though the tool name makes this distinction reasonably clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the optional comparison behavior and notes that the GitHub check requires an outbound HTTPS request, providing implicit context for when to use the check_latest parameter. However, it lacks explicit guidance on when to use this tool versus alternatives like get_config, or when to enable/disable the comparison feature.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dpesch/mantisbt-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server