bugcap
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BUGCAP_HOME | No | Overrides the per-OS data/config directory where bugcap stores its SQLite index and images |
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
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_reportsA | List bug reports stored by bugcap, newest first. Use this to find a report id; it returns only summaries (id, title, status, tags, repo, created_at, linked GitHub issue) and no notes or images, so call get_report for the full report. Read-only and local: no network access. Returns a JSON array, empty when nothing matches. |
| get_reportA | Read one bug report in full: title, body, notes, status, tags, linked GitHub issue and the
list of attached media, followed by every screenshot as image content so you can see it.
Use this after list_reports to understand a bug before fixing it. Notes refer to media as
@i1, @d1 or @label; |
| request_screenshotA | Ask the human at the machine to take a screenshot (for example to show a bug, or to check a
fix) and attach it to a report. Use this when you need visual evidence you cannot produce
yourself; to attach an image file that already exists, use attach_image. Opens the user's
capture tool and blocks until they finish, cancel or |
| pull_issuesA | Import open GitHub issues into bugcap as reports, so you can read them with get_report and
attach screenshots to them. Use this when the bug you need lives in GitHub rather than in
bugcap yet. Calls the GitHub API through the user's |
| attach_imageA | Add existing images (PNG, JPEG, GIF or WebP) to a bug report, for example a screenshot you saved or a diagram from a URL. Use attach_file instead for logs, videos or other non-image files, and request_screenshot when the user has to take the picture. Copies each image into bugcap's local store (URLs are downloaded) and appends it to the report; existing media is kept. Notes can then refer to it as @i or @label. Returns {"added": [{index, label, kind, size_bytes, source}], "rejected": [{source, reason}]}: one bad source does not stop the others. |
| attach_fileA | Add files of any type (logs, stack traces, HAR captures, videos, configs) to a bug report as supporting evidence. Use attach_image for pictures so they are returned as images by get_report. Copies each file into bugcap's local store (URLs are downloaded) and appends it to the report; existing media is kept. Attached files are never uploaded to GitHub. Notes can then refer to a file as @d or @label. Returns {"added": [...], "rejected": [{source, reason}]}: one bad source does not stop the others. |
| update_notesA | Overwrite a bug report's notes with new text, for example to record a diagnosis, steps to
reproduce or what a fix changed. The previous notes are replaced, not appended to: read
them with get_report first and include whatever should be kept. Every @ reference must
match media attached to the report; an unknown one is rejected with an error and nothing
is saved. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Each tool targets a distinct resource+action: listing vs reading reports, importing issues, requesting a screenshot, attaching images vs files, and updating notes. The only potentially confusable pair (attach_image/attach_file) is explicitly cross-referenced in both descriptions, and request_screenshot is clearly differentiated by requiring human action.
All seven tools follow a consistent verb_noun snake_case pattern: list_reports, get_report, request_screenshot, pull_issues, attach_image, attach_file, update_notes. No deviations in style or casing.
Seven tools is well-scoped for a bug-report capture server, and each tool earns its place in a distinct workflow step (browse, read, import, capture, attach, annotate). No redundant or filler tools.
Core read/import/attach/annotate flow is covered, but status and tags are surfaced in list/get yet no tool can set them, and there is no delete/remove-media operation nor an explicit create_report (only implicitly via request_screenshot). These triage gaps are notable dead ends for a bug-tracking domain.