Skip to main content
Glama
yuka-sakamaki777

bgl-mcp-server

by yuka-sakamaki777
OverviewSchemaRelated ServersScoreDiscussions
TypeScript

bgl-mcp-server

bgl CLIをラップしたMCPサーバーです。

VSCode + GitHub Copilot や Claude Desktop から、直接Backlogの課題を参照・コメント追加ができるようになります。

前提条件

  • Node.js v20以上

  • bgl がインストール済み＆ログイン済み

# bglのインストール（まだの場合）
brew tap dannygim/tap
brew install bgl

# Backlogにログイン
bgl auth login

Related MCP server: Backlog MCP Server

インストール

# リポジトリをクローン
git clone <this-repo>
cd bgl-mcp-server

# 依存関係インストール
npm install

# ビルド
npm run build

VSCode + GitHub Copilot での設定

プロジェクトの .vscode/mcp.json を作成：

{
  "servers": {
    "backlog": {
      "command": "node",
      "args": ["/path/to/bgl-mcp-server/dist/index.js"]
    }
  }
}

または、グローバル設定 ~/.vscode/mcp.json に追加。

Claude Desktop での設定

~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "backlog": {
      "command": "node",
      "args": ["/path/to/bgl-mcp-server/dist/index.js"]
    }
  }
}

利用可能なツール

ツール名

説明

backlog_get_issue

課題の内容を取得

backlog_get_comments

課題のコメント一覧を取得

backlog_add_comment

課題にコメントを追加

使い方の例

Copilot Chatで以下のように話しかけるだけ：

EBC_101-25956 の課題内容を確認して
この課題の原因を分析して、修正方針を検討して
検討した修正方針をBacklogにコメントとして投稿して

ライセンス

MIT

Available Tools

3 tools
backlog_add_commentA

Backlogの課題にコメントを追加します。作業計画やPR作成報告などに使用できます。

ParametersJSON Schema
NameRequiredDescriptionDefault
messageYes投稿するコメント内容
issueKeyYes課題キー（例: EBC_101-25956）

TDQS

A3.6/5.0
Behavior2/5

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

No annotations provided, so description carries full burden. It only states 'adds a comment' without disclosing behavioral traits like permissions, notifications, or idempotency. Lacks depth for a mutation tool.

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 sentences, front-loaded with main action, no wasted words. Highly concise.

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 simple 2-param tool with no output schema, the description is fairly complete. It explains purpose and usage scenarios. Could mention error cases, but acceptable.

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 coverage is 100% with descriptions for both parameters. Description adds no extra meaning beyond schema, so baseline 3 is appropriate.

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 tool adds a comment to a Backlog issue (specific verb+resource). It distinguishes from siblings like backlog_get_issue and backlog_get_comments.

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 provides usage examples (work plans, PR creation reports) but does not explicitly state when not to use or mention alternatives. Implied usage only.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

backlog_get_commentsA

Backlogの課題に対するコメント一覧を取得します。

ParametersJSON Schema
NameRequiredDescriptionDefault
issueKeyYes課題キー（例: EBC_101-25956）

TDQS

A3.6/5.0
Behavior2/5

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

No annotations are provided, so the description must convey behavioral traits. It only states that it retrieves comments, with no mention of read-only behavior, pagination, ordering, or authentication needs. For a read operation, minimal behavioral info is disclosed.

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?

The description is a single, terse sentence that directly states the tool's function. No extraneous words, perfectly sized for a simple tool.

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 tool's simplicity (one required parameter, no output schema), the description is nearly complete. However, it lacks mention of potential pagination or ordering of comments, which might be relevant for an agent to know. Still, for a basic list retrieval, it is adequate.

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?

The schema description coverage is 100% for the single required parameter 'issueKey'. The tool description does not add any additional meaning beyond the schema's parameter description. Thus, baseline 3 is appropriate.

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 tool retrieves a list of comments for a specific issue, using the verb '取得' (retrieve) and the resource 'コメント一覧' (comment list). It differentiates from sibling tools like backlog_get_issue (issue details) and backlog_add_comment (add comment).

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 does not provide explicit guidance on when to use this tool versus alternatives. While the purpose is clear, it does not state that the tool is only for reading comments or when not to use it (e.g., for adding comments). Usage is implied but not articulated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

backlog_get_issueA

Backlogの課題(Issue)を取得します。課題キー（例: EBC_101-25956）を指定してください。

ParametersJSON Schema
NameRequiredDescriptionDefault
issueKeyYes課題キー（例: EBC_101-25956, PRJ-123）

TDQS

A4.1/5.0
Behavior3/5

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

No annotations provided. Description indicates a read operation ('gets') but lacks details on authentication, error handling, or rate limits. Adequate for a simple tool.

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 sentences, no fluff. Information is front-loaded and efficient.

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?

Given the tool's simplicity (one parameter, no output schema), the description is complete: it explains what the tool does and what input is required.

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% (parameter documented). The description adds no extra meaning beyond the schema, so baseline 3 is appropriate.

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 it retrieves a Backlog issue using the issue key. It distinguishes from sibling tools (comments) by focusing on the issue entity.

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?

Provides clear context: use to get an issue by key. No explicit when-not-to or alternatives, but sibling tools are comment-related, so usage is implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 3 tool updatesv1.0.0
    • First observedbacklog_add_comment
    • First observedbacklog_get_comments
    • First observedbacklog_get_issue
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: retrieving an issue, listing comments, and adding a comment. No overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent 'backlog_verb_noun' pattern using snake_case (get_issue, get_comments, add_comment).

Tool Count4/5

Three tools is slightly low but still reasonable for a focused Backlog integration covering basic issue and comment operations.

Completeness3/5

The set covers reading an issue, reading comments, and adding a comment, but lacks update/delete operations and listing issues, which are notable gaps.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Backlog MCP Server

    bachduc782
    F
    license
    Not graded
    quality
    C
    maintenance
    Exposes Backlog project management as tools for Claude Desktop, enabling search and management of issues, comments, wiki pages, milestones, custom fields, notifications, and more.
    -

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/yuka-sakamaki777/bgl-mcp-server'

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