Skip to main content
Glama
amenalahassa

bugcap

by amenalahassa
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Attach files to a report

attach_file

Attach files like logs, stack traces, or HAR captures to a bug report as supporting evidence. Copies each into the local store and appends to the report; one bad source won't stop others.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
idYesNumeric report id, as returned by list_reports (e.g. 12).
labelsNoOptional short names, one per entry in `sources` and in the same order; use null to leave one unlabeled. A label lets notes refer to the item as @label.
sourcesYes1 to 20 files to add: local file paths, glob patterns (e.g. 'logs/*.txt') or http(s) URLs to download.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.7.2
    • addedInput schema / properties / id / description
      Added value: +"Numeric report id, as returned by list_reports (e.g. 12)."
    • addedInput schema / properties / labels / description
      Added value: +"Optional short names, one per entry in `sources` and in the same order; use null to leave one unlabeled. A label lets notes refer to the item as @label."
    • addedInput schema / properties / sources / description
      Added value: +"1 to 20 files to add: local file paths, glob patterns (e.g. 'logs/*.txt') or http(s) URLs to download."
  2. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing that files are copied into a local store, URLs are downloaded, existing media is preserved, and nothing is uploaded to GitHub — important context given openWorldHint=true. It also documents partial-failure semantics ('one bad source does not stop the others'), which annotations never convey.

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-loads purpose and the sibling exclusion, then layers behavior. Dense but nearly every clause earns its place; the return-shape sentence partially duplicates the output schema, a minor redundancy.

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?

With an output schema present and annotations covering safety profile, the description supplies the remaining essentials: storage behavior, GitHub exclusion, and partial-success handling. An agent has everything needed to call it correctly.

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 adds meaning beyond the schema by explaining that labels let notes refer to items as @label and that failures are reported per source. It doesn't restate the 1-to-20 source limit or glob syntax, which the schema already covers.

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+resource ('Add files ... to a bug report as supporting evidence') and enumerates the file types accepted. It explicitly distinguishes itself from the sibling attach_image and its output target (get_report).

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

Usage Guidelines5/5

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

Gives an explicit routing rule: use attach_image for pictures so they are returned as images by get_report, implying this tool for everything else. The @d<n>/@label referencing note also tells the agent how attachments are consumed downstream.

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