Which integrations are available for this server?

Provides containerized deployment options for both development and production environments Used for environment variable management, allowing configuration of Backlog API credentials through .env files Referenced as a resource for setting up the Windsurf application with MCP capabilities

How do I use Backlog MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Backlog MCP Server search for open issues in PROJECT1" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

en es ja ko zh

Backlog MCP Server

by jootsuki

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Backlog MCP Server

This is an MCP server that connects to Backlog's API. It provides the functionality to search, retrieve, and update issues.

function

Search for issues
Get an issue
Update an issue

Related MCP server: Backlog MCP Server

set up

MCP Configuration

Add the following to ~/Library/Application Support/Code/User/globalStorage/rooveterinaryinc.roo-cline/settings/cline_mcp_settings.json :

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

Note: Replace cwd with the actual project path.

Docker environment

Development environment

If you use Docker containers for development and testing:

# .envファイルを作成
cp .env.example .env
# 必要な環境変数を設定
BACKLOG_SPACE_URL=https://your-space.backlog.com
BACKLOG_API_KEY=your_api_key

# 開発モードでビルドと起動
NODE_ENV=development docker compose up -d --build

In development mode it will watch for changes in the source code and restart automatically.

Production

If you use Docker containers for production:

# .envファイルを作成
cp .env.example .env
# 必要な環境変数を設定
BACKLOG_SPACE_URL=https://your-space.backlog.com
BACKLOG_API_KEY=your_api_key

# 本番モードでビルドと起動
docker compose up -d --build

Use as an MCP server

To run an MCP server using a Docker container, set the following in the configuration file of the app you are using. Example for Cline and RooCline: cline_mcp_settings.json

{
  "mcpServers": {
    "backlog": {
      "command": "docker",
      "args": ["exec", "-i", "backlog-mcp-server", "node", "build/index.js"],
      "env": {
        "BACKLOG_SPACE_URL": "https://your-space.backlog.com",
        "BACKLOG_API_KEY": "your_api_key"
      }
    }
  }
}

Other app settings methods

Claude Desktop: https://ainow.jp/claude-mcp-guide/

Windsurf: https://zenn.dev/y16ra/articles/3ed3e2ae734fa4

Cursor: https://note.com/shuzon \_\_/n/na2aafacf7324 →[Set Notion MCP Server as Cursor]

Example prompt

# 課題の検索
・バックログのPROJECT1-100の課題を説明して
・バックログのPROJECT1のプロジェクトで処理中の課題を教えて

# 課題の更新
・PROJECT1-100の課題のステータスを完了にして
・PROJECT1-100の課題に「〜〜〜」とコメントして

Available Tools

4 tools

getIssueC

特定のBacklog課題を取得します

ParametersJSON Schema

Name	Required	Description	Default
`issueId`	Yes	課題のID（例: PROJECT-1）

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves a specific issue but doesn't mention whether this is a read-only operation, what permissions are required, how errors are handled (e.g., invalid issue IDs), or the format of the return data. For a retrieval tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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, efficient sentence in Japanese that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse. Every part of the sentence contributes to understanding the tool's function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and output schema, the description is incomplete for a tool that retrieves data. It doesn't explain what information is returned (e.g., issue details, status, comments) or how to interpret the output. For a retrieval tool with no structured output documentation, this leaves the agent guessing about the result format and usability.

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 input schema has 100% description coverage, with the 'issueId' parameter clearly documented as the issue ID (e.g., 'PROJECT-1'). The description doesn't add any additional meaning beyond this, such as explaining ID formats or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('取得します' - get/retrieve) and resource ('特定のBacklog課題' - specific Backlog issue), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'searchIssues' (which likely searches multiple issues) or 'getProjects' (which retrieves projects rather than issues), so it doesn't reach the highest score.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'searchIssues' or 'updateIssue'. It doesn't mention prerequisites, such as needing a valid issue ID, or contextual factors like whether this is for single-issue retrieval versus bulk operations. The agent must infer usage from the tool name and description alone.

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

getProjectsB

Backlogのプロジェクト一覧を取得します

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/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 states this retrieves project lists but doesn't disclose any behavioral traits: no information about pagination, sorting, filtering capabilities, authentication requirements, rate limits, or what format the data returns. For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.

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, efficient Japanese sentence that directly states the tool's purpose. There's zero wasted language or unnecessary elaboration. It's appropriately sized for a simple list-retrieval tool and front-loads the essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no output schema and no annotations, the description is insufficiently complete. It doesn't explain what the return data looks like (project objects, IDs, names, metadata), whether there are limitations on the listing, or how results are structured. For a data retrieval tool with no structured output documentation, the description should provide more context about the response format.

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?

The tool has zero parameters with 100% schema description coverage (empty schema). The description doesn't need to explain any parameters since none exist. It appropriately focuses on the tool's purpose rather than parameter details. Baseline for zero parameters is 4, as there's nothing to compensate for.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('取得します' - get/retrieve) and resource ('プロジェクト一覧' - project list) in Japanese. It specifies this tool retrieves project lists from Backlog, which distinguishes it from sibling tools that handle issues. However, it doesn't explicitly differentiate from potential sibling project tools (though none are listed).

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention whether this is for listing all projects, filtered projects, or specific use cases. With sibling tools focused on issues (getIssue, searchIssues, updateIssue), there's no comparison or context about when project listing is appropriate versus issue operations.

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

searchIssuesC

Backlogの課題を検索します

ParametersJSON Schema

Name	Required	Description
`projectId`	Yes	プロジェクトID（数値）
`keyword`	No	検索キーワード
`status`	No	ステータス（未対応、処理中、処理済み、完了）

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only states the action without disclosing behavioral traits. It doesn't mention whether this is a read-only operation, potential side effects, authentication requirements, rate limits, or response format. For a search tool with zero annotation coverage, this is a significant gap in transparency.

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?

The description is a single, efficient sentence in Japanese, front-loaded with the core action. It's appropriately sized for a basic tool, with no wasted words, though it could benefit from more detail given the lack of annotations and output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (search tool with 3 parameters), no annotations, and no output schema, the description is incomplete. It doesn't cover return values, error handling, or how search results are structured, leaving the agent with insufficient context for effective use.

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 the input schema fully documents parameters (projectId, keyword, status). The description adds no meaning beyond the schema, as it doesn't explain parameter interactions, default behaviors, or search semantics. Baseline 3 is appropriate since the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Backlogの課題を検索します' (Searches Backlog issues) states the basic action and resource (issues in Backlog), but it's vague about scope and doesn't distinguish from sibling tools like getIssue or updateIssue. It specifies the verb 'search' and target 'issues', but lacks detail on what 'search' entails versus 'get'.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives such as getIssue (which might retrieve a single issue) or updateIssue. The description implies searching multiple issues but doesn't clarify contexts like filtering needs or prerequisites, leaving the agent to infer usage from parameter names alone.

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

updateIssueC

Backlog課題を更新します

ParametersJSON Schema

Name	Required	Description
`issueId`	Yes	課題のID（例: PROJECT-1）
`status`	No	新しいステータス
`description`	No	課題の説明
`comment`	No	更新時のコメント

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool updates an issue, implying a mutation, but doesn't disclose any behavioral traits like required permissions, whether changes are reversible, rate limits, or what the response looks like. This is a significant gap for a mutation tool with zero annotation coverage.

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, efficient sentence ('Backlog課題を更新します') that is appropriately sized and front-loaded, with zero waste. It directly states the tool's purpose without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain the return values, error conditions, or behavioral context, leaving the agent with insufficient information to use the tool effectively beyond basic parameter input.

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 input schema has 100% description coverage, with all parameters documented in the schema itself (e.g., 'issueId' as the issue ID, 'status' as new status). The description adds no additional meaning beyond what the schema provides, such as explaining how parameters interact or providing examples beyond the schema's '例: PROJECT-1'. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Backlog課題を更新します' (Updates a Backlog issue) clearly states the verb ('更新します' - updates) and resource ('Backlog課題' - Backlog issue), providing a basic purpose. However, it doesn't distinguish this from potential sibling tools like 'getIssue' or 'searchIssues' beyond the update action, making it somewhat vague in differentiation.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'getIssue' or 'searchIssues'. It lacks any mention of prerequisites, such as needing an existing issue ID, or exclusions, leaving the agent to infer usage from the tool name alone.

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 tool updatev1.0.0Jan 3, 2026
- ChangedgetProjects1 field changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
4 tool updatesSep 24, 2025
- First observedgetIssue
- First observedgetProjects
- First observedsearchIssues
- First observedupdateIssue

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.9/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: getIssue retrieves a specific issue, getProjects lists projects, searchIssues finds issues based on criteria, and updateIssue modifies an issue. There is no overlap or ambiguity between these functions.

Naming Consistency4/5

The naming follows a consistent verb_noun pattern (e.g., getIssue, getProjects, searchIssues, updateIssue), with all tools using camelCase. The only minor deviation is that 'getProjects' uses a plural noun while others use singular, but this is still readable and predictable.

Tool Count3/5

With only 4 tools, the set feels thin for a Backlog server, as it lacks essential operations like creating issues or projects, deleting resources, or managing comments. While the tools cover basic retrieval and update, the scope is incomplete for typical issue-tracking workflows.

Completeness2/5

There are significant gaps in the tool surface for a Backlog server. Missing operations include create_issue, delete_issue, create_project, and update_project, which are core to issue lifecycle management. This will likely cause agent failures when trying to perform full CRUD operations.

Resources

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

mcpOAuth
com.bullpenstrategygroup.rotunda
An MCP server that provides congressional transcripts
Government Data Search Open Data
2
Airweave SearchOAuth
io.github.airweave-ai
MCP server for searching Airweave collections with natural language queries.
Search Art & Culture Open Data
25,729
Danushkumar-V-mcp-discordOAuth
ai.smithery
An MCP server that integrates with Discord to provide AI-powered features.
Communication Social Media App Automation
2
neverinfamous-memory-journal-mcp
ai.smithery
A MCP server built for developers enabling Git based project management with project and personal…
Version Control Developer Tools Project Management
320

Related MCP Servers

Backlog MCP Server
Project Management Developer Tools
fleagne
A
license
B
quality
Not graded
maintenance
An MCP server implementation that integrates with Backlog API, enabling project management operations including issues, projects, and wikis through natural language interactions.
Updated a year ago (2025-05-25 03:48 UTC)
12
7,341
3
-
Backlog MCP Server
Project Management Version Control Developer Tools
duytnb79
A
license
B
quality
D
maintenance
A read-only MCP server that enables users to retrieve and interact with Backlog projects, issues, pull requests, and notifications. It provides a secure way to query Backlog data through natural language using tools like Claude Desktop.
Updated 5 months ago (2026-04-02 09:17 UTC)
10
15
MIT
Jira MCP Server
Project Management Developer Tools
AlexVulaj
A
license
Not graded
quality
D
maintenance
An MCP server for integrating with Jira Server instances, enabling natural language interactions to create, update, search, and manage issues and comments.
Updated a year ago (2025-09-12 14:27 UTC)
98
1
MIT
backlog-mcp
Project Management Developer Tools
cuongph-dev-work
A
license
A
quality
D
maintenance
An MCP server providing AI agents with read access to Backlog issues, comments, and attachments via API Key authentication.
Updated 4 months ago (2026-04-28 17:56 UTC)
12
16
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/jootsuki/backlog-mcp-server'

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