Skip to main content
Glama

get_bug

Retrieve a bug by ID from a specified provider. Optionally fetch only metadata to skip comments and tasks.

Instructions

Fetch a bug by ID from the given provider.

Set metadata_only to True to skip fetching comments and tasks.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bug_idYes
provider_nameYes
metadata_onlyNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The get_bug tool handler function. It fetches a bug by ID from the given provider using the singleton QueryService, and converts the result to a dictionary via _bug_record_to_dict. Registered as an MCP tool via @mcp.tool() decorator.
    @mcp.tool()
    def get_bug(
        bug_id: str,
        provider_name: str,
        metadata_only: bool = False,
    ) -> dict | None:
        """Fetch a bug by ID from the given provider.
    
        Set metadata_only to True to skip fetching comments and tasks.
        """
        svc = get_service()
        try:
            record = svc.get_bug(
                bug_id=bug_id,
                provider_name=provider_name,
                metadata_only=metadata_only,
            )
        except ValueError as exc:
            return {"error": str(exc)}
    
        if record is None:
            return None
    
        return _bug_record_to_dict(record)
  • Helper that converts a BugRecord into a plain dict for JSON serialization. Defines the output schema (shape) of the get_bug tool result.
    def _bug_record_to_dict(record) -> dict:
        return {
            "provider_name": record.provider_name,
            "id": record.id,
            "title": record.title,
            "description": record.description,
            "tags": record.tags,
            "created_at": _fmt_dt(record.created_at),
            "updated_at": _fmt_dt(record.updated_at),
            "last_message_at": _fmt_dt(record.last_message_at),
            "owner": _user_to_dict(record.owner),
            "assignee": _user_to_dict(record.assignee),
            "bug_tasks": [_task_to_dict(t) for t in record.bug_tasks],
            "comments": [_comment_to_dict(c) for c in record.comments],
        }
    
    
    def _task_to_dict(task) -> dict:
        return {
            "title": task.title,
            "target": task.target,
            "importance": task.importance,
            "status": task.status,
            "milestone": task.milestone,
            "owner": _user_to_dict(task.owner),
            "assignee": _user_to_dict(task.assignee),
        }
    
    
    def _comment_to_dict(comment) -> dict:
        return {
            "author": _user_to_dict(comment.author),
            "content": comment.content,
            "created_at": _fmt_dt(comment.created_at),
            "edited_at": _fmt_dt(comment.edited_at),
        }
    
    
    def _user_to_dict(user) -> dict | None:
        if user is None:
            return None
        return {
            "username": user.username,
            "display_name": user.display_name,
            "profile_url": user.profile_url,
        }
    
    
    def _fmt_dt(dt: datetime | None) -> str | None:
        return dt.isoformat() if dt else None
    
    
    def _parse_datetime(value: str | None) -> datetime | None:
        if value is None:
            return None
        return datetime.fromisoformat(value)
  • The get_bug function is registered as an MCP tool via the @mcp.tool() decorator on the FastMCP instance 'mcp' (line 16).
    @mcp.tool()
    def get_bug(
  • Helper used by _bug_record_to_dict to serialize UserRecord objects.
    def _user_to_dict(user) -> dict | None:
        if user is None:
            return None
        return {
            "username": user.username,
            "display_name": user.display_name,
            "profile_url": user.profile_url,
        }
Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses the 'metadata_only' flag behavior (skipping comments/tasks), but lacks details on authentication, error handling, rate limits, or effects of missing IDs. Adequate but not comprehensive.

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?

Two short sentences, no redundant words. Purpose and a key parameter option are conveyed efficiently. Every sentence earns its place.

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?

Given the presence of an output schema (declared via context signals), the description need not detail return values. Parameter semantics are mostly covered. Missing usage guidelines and some behavioral details, but adequate for a simple fetch tool.

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?

Input schema has 3 parameters with 0% coverage, so description must compensate. It explains 'metadata_only' clearly. 'bug_id' and 'provider_name' are implied in the action phrase, but format or valid values are not specified. Overall adds meaningful context beyond schema.

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?

The description clearly states the verb 'fetch', resource 'bug', and specifies retrieval by ID from a given provider. It effectively distinguishes from sibling tools like 'search_bugs' (which searches) and 'list_bug_providers' (which lists providers).

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 implies usage when you have a bug ID and provider name, but it does not explicitly state when to use this tool versus alternatives like 'search_bugs' or 'submit_bug'. No guidance on when not to use it or prerequisites.

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/lvoytek/ubuntu-mcp'

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