Skip to main content
Glama
Sign In
dpesch

MantisBT MCP Server

by dpesch
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Get Cached Metadata

get_metadata
Read-onlyIdempotent

Retrieve cached MantisBT metadata including projects, users, versions, categories, and tags; choose summary counts or full details, and refresh to re-fetch from the server.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
detailNo"summary" (default): counts only; "full": the complete raw cachesummary
refreshNoRe-fetch all metadata from MantisBT first (default: false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.15.0
    • addedInput schema / properties / detail
      Added value: +{
+  "default": "summary",
+  "description": "\"summary\" (default): counts only; \"full\": the complete raw cache",
+  "enum": [
+    "summary",
+    "full"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / refresh
      Added value: +{
+  "default": false,
+  "description": "Re-fetch all metadata from MantisBT first (default: false)",
+  "type": "boolean"
+}
  2. Changed1 schema field changedv1.14.0
    • removedInput schema / additionalProperties
      Removed value: -false
  3. Addedv1.10.4
  4. Removed
  5. First observedv1.5.6

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real behavioral context beyond them: cache-vs-live behavior, the default 24-hour TTL, that the full view is large minified JSON, and that a search_index block appears when semantic search is enabled. Since there is no output schema, this return-shape disclosure carries the load well.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded one-line purpose followed by compact bullets for detail and refresh, then the conditional search_index note and the hand-offs to siblings. Every sentence carries information an agent needs; nothing is padding.

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 zero-required-param, read-only cache reader with no output schema, the description covers return shape, size trade-off, staleness rules, and alternatives — enough to call it correctly. Completeness only suffers from the unaddressed overlap with get_metadata_full and sync_metadata.

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?

Schema coverage is 100%, so the baseline is 3, but the description genuinely adds meaning: 'summary' yields concrete fields (cached_at, ttl_seconds, per-project counts) while 'full' is flagged as large minified JSON, and 'refresh' is tied to cache invalidation rather than just 're-fetch'. Slight redundancy with the schema keeps it below 5.

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 — return the cached MantisBT metadata — and enumerates its contents (projects with users, versions, categories, plus tags). It clearly routes away from get_project and list_tags, but says nothing about the identically-purposed sibling get_metadata_full, so an agent cannot fully resolve which one to call from the purpose statement alone.

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?

Explicitly tells the agent which alternative to use for two cases: single-project lists via get_project with include, and tags via list_tags. It also explains when to set refresh vs. rely on the cache (synced only when missing or expired, 24h TTL). The gap is that it never explains when to prefer this tool over get_metadata_full or sync_metadata, both of which overlap the 'detail: full' option and the 'refresh: true' behavior.

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