Skip to main content
Glama
amenalahassa

bugcap

by amenalahassa
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Import GitHub issues

pull_issues
Idempotent

Import open GitHub issues into bugcap as reports so agents can read them and attach screenshots. Re-running refreshes titles and bodies without overwriting notes, tags, or status.

Instructions

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 gh login. Safe to repeat: an issue that is already imported only has its title and body refreshed, never its notes, tags or status. Returns {"created", "updated", "unchanged"} counts, or {"error": ...} when no repo is given or configured, or gh is not signed in.

Input Schema

NameRequiredDescriptionDefault
repoNoGitHub repo as 'owner/name'. Defaults to the repo configured in .bugcap.toml.
limitNoMaximum number of issues to fetch (default 30).
labelsNoOnly import issues carrying all of these labels, e.g. ['bug'].

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.7.2
    • addedInput schema / properties / labels / description
      Added value: +"Only import issues carrying all of these labels, e.g. ['bug']."
    • addedInput schema / properties / limit / description
      Added value: +"Maximum number of issues to fetch (default 30)."
    • addedInput schema / properties / repo / description
      Added value: +"GitHub repo as 'owner/name'. Defaults to the repo configured in .bugcap.toml."
  2. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses the auth dependency (GitHub API via the user's `gh` login), the precise idempotency semantics (existing imports refresh only title and body, never notes/tags/status), and the return/error shape including the no-repo and not-signed-in failure modes. The idempotentHint is confirmed and fleshed out rather than repeated.

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-loads the action and scope in the first clause, then layers the when-to-use, auth mechanism, idempotency guarantee, and return shape in a tight sequence with no filler sentences.

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?

Covers purpose, prerequisites (gh auth, repo config), repeat-safety, and error conditions; an output schema exists but the description still summarizes the count/error shape, which is sufficient for correct invocation.

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?

Schema description coverage is 100%, so repo fallback to .bugcap.toml, the limit default, and label AND-filtering are already documented in the schema. The description adds only the repo-default behavior, which is duplicative; limit and labels go unmentioned. Baseline 3 applies.

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 ("Import open GitHub issues into bugcap as reports") and immediately clarifies the resulting object type is readable via get_report, distinguishing it from the read-only siblings like list_reports and 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 selection condition: "Use this when the bug you need lives in GitHub rather than in bugcap yet," plus the follow-on path (read imported issues with get_report, attach screenshots to them). That routes the agent between this importer and the report-reading siblings without inference.

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