What can you do with this server?

The MCP Backlog Server is a Model Context Protocol server for managing work items and tasks with structured workflows and multi-project support. Core Capabilities: Backlog Item Management - Create, read, update, and archive backlog items with topics, descriptions, and priorities (high/medium/low). Items are automatically versioned when amended and support tracking item age. Status Workflow - Move items through a defined lifecycle: new → ready → review → done, with specialized operations like submit, approve, reopen, and wontfix. Items can be completed with optional summary notes. Todo Management - Create, read, and update todos within backlog items with content, status (pending/in_progress/completed/cancelled), batch organization, and dependency tracking. Mark todos complete with automatic dependency validation to ensure prerequisites are met. Filtering & Listing - Filter backlog items by status, priority, or topic. Filter todos by status, batch, or associated backlog item topic. List completed items separately. Storage & Organization - Uses XDG-compliant, human-readable markdown files with frontmatter. Supports isolated storage per project (git-aware), custom storage locations via environment variables (e.g., MCP_BACKLOG_DIR), and separate archive directory structure. Archive Maintenance - Prune or clear old completed/archived items with configurable age thresholds (olderThanDays) and dry-run previews. Configuration Flexibility - Supports global installation, NPX/Bunx execution, and environment variable customization for different deployment scenarios.

How do I use MCP Backlog 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., "@MCP Backlog Server create a high priority item for implementing user authentication" 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.

MCP Backlog Server

by rwese

Overview Schema Related Servers Score Discussions

TypeScript

Local

MCP Backlog Server

A Model Context Protocol (MCP) server for managing backlog items and todos. This server provides a structured way to track work items, their status, and associated tasks.

Features

Backlog Management: Create, read, update, and archive backlog items
Todo Tracking: Manage todos within backlog items with dependencies
Status Workflow: Track items through states: new → ready → review → done
Priority Levels: Organize items by high, medium, or low priority
Versioning: Automatic versioning when amending backlog items
Markdown Storage: Human-readable markdown files with frontmatter
Prune/Clear: Remove old completed items to keep your archive clean

Related MCP server: Backlog MCP Server

Installation

Quick Start (Zero Install)

Using NPX (Node.js):

npx -y github:rwese/mcp-backlog

Using Bunx (Bun - Faster):

bunx --bun github:rwese/mcp-backlog

Global Installation

With Bun (Recommended):

# From GitHub (latest)
bun add -g github:rwese/mcp-backlog

# From NPM (when published)
bun add -g @rwese/mcp-backlog

With NPM:

# From GitHub
npm install -g github:rwese/mcp-backlog

# From NPM (when published)
npm install -g @rwese/mcp-backlog

From Source

git clone https://github.com/rwese/mcp-backlog.git
cd mcp-backlog
bun install  # or npm install
bun run build  # or npm run build

Usage

In your MCP client configuration

Add to your MCP client's configuration file:

Using NPX from GitHub (Recommended):

{
  "mcpServers": {
    "backlog": {
      "command": "npx",
      "args": ["-y", "github:rwese/mcp-backlog"]
    }
  }
}

Using Bunx (Faster):

{
  "mcpServers": {
    "backlog": {
      "command": "bunx",
      "args": ["--bun", "github:rwese/mcp-backlog"]
    }
  }
}

Using global install:

{
  "mcpServers": {
    "backlog": {
      "command": "mcp-backlog"
    }
  }
}

Using NPX:

{
  "mcpServers": {
    "backlog": {
      "command": "npx",
      "args": ["@rwese/mcp-backlog"]
    }
  }
}

Using local build:

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

Tools

backlog-read

List and filter backlog items.

Arguments:

status (optional): Filter by status (new, ready, review, done, reopen, wontfix)
priority (optional): Filter by priority (high, medium, low)

backlog-write

Create and manage backlog items.

Arguments:

action: Operation to perform (create, list, amend, approve, submit, reopen, wontfix)
topic: Topic name for the backlog item
description: Description of the work item
priority (optional): Priority level (default: medium)
status (optional): Status for amend operation

Examples:

// Create a new backlog item
{
  "action": "create",
  "topic": "Add user authentication",
  "description": "Implement JWT-based authentication",
  "priority": "high"
}

// Amend an existing item
{
  "action": "amend",
  "topic": "Add user authentication",
  "status": "ready"
}

backlog-done

Mark backlog items as complete.

Arguments:

action: done or list
topic: Topic name to mark as done
summary (optional): Completion summary

ticket-read

List todos for a backlog item.

Arguments:

topic: Backlog item topic (required)
status (optional): Filter by status
batch (optional): Filter by batch

ticket-write

Create and update todos within backlog items.

Arguments:

action: create, update, or list
topic: Backlog item topic (required)
todoId: Todo ID (for update)
content: Todo content
status: Todo status (pending, in_progress, completed, cancelled)
dependencies: Array of todo IDs that must complete first
batch: Batch identifier

ticket-done

Mark todos as complete with dependency validation.

Arguments:

action: done or list
topic: Backlog item topic (required)
todoId: Todo ID to mark as done

prune

Remove old completed/archived backlog items from COMPLETED_Backlog.

Arguments:

action: Operation to perform (list, prune, clear) - default: list
olderThanDays (optional): For prune action, delete items older than this many days (default: 30)
dryRun (optional): Preview what would be deleted without actually deleting (default: false)

Examples:

// List all completed items with their age
{
  "action": "list"
}

// Preview what would be deleted (items older than 7 days)
{
  "action": "prune",
  "olderThanDays": 7,
  "dryRun": true
}

// Actually delete items older than 30 days
{
  "action": "prune",
  "olderThanDays": 30
}

// Clear all completed items (with preview first)
{
  "action": "clear",
  "dryRun": true
}

Directory Structure

Default Location (XDG-compliant)

By default, the server stores backlog data in XDG-compliant directories with multi-project isolation:

~/.local/share/mcp-backlog/
└── projects/
    └── <project-name>/
        ├── Backlog/
        │   └── <topic-name>/
        │       ├── item.md       # Backlog item details
        │       └── todos.json    # Associated todos
        └── COMPLETED_Backlog/
            ├── DONE_<topic>-v1.md
            └── WONTFIX_<topic>.md

Multi-Project Support

Each project gets its own isolated directory:

Git repositories: Uses the repository root directory name as project identifier
Non-git projects: Uses directory name + hash for uniqueness

This allows you to use the same MCP server across multiple projects without conflicts.

Legacy Support

For backward compatibility, if you have an existing .agent/ directory in your current working directory, it will be used instead of the XDG directory.

Custom Locations

You can override the default location using environment variables:

Option 1: Set a custom backlog directory

export MCP_BACKLOG_DIR="/path/to/your/backlog"

Option 2: Set XDG_DATA_HOME (affects all XDG-compliant apps)

export XDG_DATA_HOME="/path/to/data"
# Backlog will be stored at: /path/to/data/mcp-backlog/

Add these to your MCP client configuration:

{
  "mcpServers": {
    "backlog": {
      "command": "mcp-backlog",
      "env": {
        "MCP_BACKLOG_DIR": "/custom/path"
      }
    }
  }
}

Configuration

See CONFIGURATION.md for detailed information about:

XDG Base Directory support
Multi-project isolation
Environment variables
Custom storage locations
Platform-specific defaults

Development

Run tests

bun test

Build

bun run build

Workflow

Create a backlog item with status "new"
Submit to move it to "ready" (ready for work)
Amend to update status to "review" when work is done
Approve to move from "review" to "done"
Done to archive the completed item

Or use reopen to send items back for more work, or wontfix to archive without completing.

License

MIT

Available Tools

7 tools

doneC

Mark backlog items as complete with optional summary - done operation and list

ParametersJSON Schema

Name	Required	Description
`action`	No	Operation to perform (default: done)
`topic`	No	Topic name (required for done)
`summary`	No	Optional completion summary describing what was accomplished, lessons learned, or final notes
`status`	No	Status filter for list operation
`priority`	No	Priority filter for list operation

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as destructive potential, permissions required, or side effects. It only mentions the basic action and optional summary, lacking depth for safe invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short (one sentence), but the fragment 'done operation and list' is awkward and somewhat unclear. It could be more structured, but it is not overly verbose. Mixed effectiveness.

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?

The tool has 5 parameters and 3 enums but no output schema. The description does not explain return values, error handling, or how the list operation behaves. Given the dual functionality, more context is needed for completeness.

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% coverage with descriptions for all 5 parameters. The description adds no additional meaning beyond what the schema already provides, such as clarifying the relationship between 'done' and 'list' operations. Baseline 3 is appropriate.

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 states the tool marks backlog items as complete and mentions an optional summary, clearly indicating the primary action. However, the phrase 'done operation and list' is ambiguous and could be interpreted as two separate operations, which reduces clarity.

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 its siblings (prune, read, ticket-done, etc.). There are no explicit when-to-use or when-not-to-use instructions, leaving the agent to infer context.

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

pruneC

Prune completed/done backlog items - remove old archived items from COMPLETED_Backlog

ParametersJSON Schema

Name	Required	Description
`action`	No	Operation: prune (by age), clear (all), or list completed items (default: list)
`olderThanDays`	No	For prune action: delete items older than this many days (default: 30)
`dryRun`	No	Preview what would be deleted without actually deleting (default: false)

TDQS

C2.8/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 disclose all behavior. It highlights pruning but omits the 'clear' and 'list' actions. No mention of side effects, permissions, or reversibility, which is critical for a potentially destructive tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise (one sentence) and front-loaded, but it omits key actions and lacks structure. It could be improved to include all operations in a clear, organized manner.

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 no annotations, no output schema, and three parameters with multiple actions, the description should provide more context, such as the effect of each action and the purpose of 'COMPLETED_Backlog'. It is insufficient for an agent to fully understand the tool's capabilities.

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% coverage with descriptions for all three parameters. The description adds no extra meaning beyond what the schema provides, so baseline score of 3 is appropriate.

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 states the tool is for pruning completed/done backlog items, targeting a specific 'COMPLETED_Backlog'. However, it fails to mention that the tool also supports 'clear' and 'list' actions, which reduces clarity. It distinguishes from siblings by specifying a unique backlog context.

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 on when to use this tool versus alternatives like 'done' or 'ticket-done'. The description implies a use case for maintenance of completed items but does not specify when to choose prune over other actions or tools.

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

readA

Read-only access to backlog items - list and view backlog work items

ParametersJSON Schema

Name	Required	Description
`topic`	No	Topic name to fetch a single backlog item with full content
`status`	No	Status filter for list operation
`priority`	No	Priority filter for list operation
`showAge`	No	Include age information (default: true)

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations, the description must convey behavioral traits. It states 'Read-only access' but lacks details on return format, pagination, idempotency, or side effects. The agent gets minimal safety info.

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 sentence that is front-loaded with 'Read-only access'. It is concise, though 'list and view backlog work items' slightly repeats 'backlog items'.

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?

Without an output schema, the description should clarify return values. It only says 'list and view' but does not specify whether the response is a list or single item, or any structural details.

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%, so each parameter has descriptions. The tool description adds no extra meaning beyond the schema, meeting the baseline for this dimension.

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 provides 'Read-only access to backlog items' for 'list and view' operations. It distinguishes from sibling tools like ticket-read which are for tickets, so the resource and action are specific.

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?

The description implies usage for backlog items vs. siblings with 'ticket' prefix, providing clear context. However, it does not explicitly state when not to use this tool or mention alternatives.

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

ticket-doneC

Mark backlog tickets as complete with dependency validation

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Operation to perform
`topic`	Yes	Topic name (required)
`todoId`	No	Ticket ID (required for done)
`status`	No	Filter by status (for list)
`batch`	No	Filter by batch (for list)

TDQS

C2.8/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It mentions 'dependency validation', implying a check before marking complete, but fails to disclose other mutation details like side effects or permissions.

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?

Very concise single sentence with no redundancy. However, omission of the 'list' action reduces clarity.

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?

Description is insufficient for a tool with 5 parameters and two actions. No mention of list functionality, required parameters, or return values. Lacks output schema.

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%, and description adds no extra meaning beyond field names. Baseline score applies.

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?

Description states it marks tickets as complete with dependency validation, but neglects the 'list' operation available in the action enum. It also doesn't differentiate from sibling tool 'done'.

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 on when to use this tool versus siblings like 'done', 'ticket-read', or 'ticket-write'. Lacks context for appropriate usage.

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

ticket-readA

Read-only access to backlog tickets - list and filter tickets for a backlog item

ParametersJSON Schema

Name	Required	Description
`topic`	Yes	Topic name (required)
`status`	No	Filter by status
`batch`	No	Filter by batch

TDQS

A3.5/5.0

Behavior2/5

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

The description mentions 'read-only', indicating no side effects, but lacks details on behavioral traits such as pagination, ordering, rate limits, or authentication requirements. Since no annotations are present, the description carries the full burden but falls short.

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 exceptionally concise, using a single sentence of about 10 words. It is front-loaded with the key qualifier 'Read-only access' and every word adds value without redundancy.

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

Completeness3/5

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

For a list/filter tool with no output schema, the description does not explain the return format or structure. However, it covers the core functionality. Given the low complexity (3 parameters), it is minimally 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?

All three parameters have descriptions in the input schema (100% coverage), and the description adds no additional meaning beyond 'list and filter'. Baseline 3 is appropriate as the schema already documents the parameters sufficiently.

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 identifies the tool as providing read-only access to backlog tickets with list and filter capabilities. It specifies the resource (backlog tickets) and action (list and filter), and distinguishes from sibling tools like ticket-write.

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 for viewing tickets by stating 'Read-only access', but does not explicitly state when to use this tool over alternatives like 'read' or 'ticket-done'. No exclusions or alternative recommendations are provided.

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

ticket-writeC

Write access to backlog tickets - create and update tickets for backlog items

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Operation to perform
`topic`	Yes	Topic name (required)
`todoId`	No	Ticket ID (required for update)
`content`	No	Ticket content
`status`	No	Ticket status
`dependencies`	No	Ticket dependencies (array of ticket IDs)
`batch`	No	Batch identifier

TDQS

C2.5/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 disclose behavioral traits. It claims 'write access' yet includes a 'list' action (a read operation), creating an internal contradiction. No side effects, permissions, or idempotence details are given.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence, but it omits the 'list' operation and does not fully reflect the input schema. It is concise but incomplete.

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 no annotations, no output schema, and 7 parameters, the description fails to explain the 'list' action, batch usage, or return values. It is insufficient for an agent to fully understand the tool's behavior.

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?

Input schema has 100% description coverage for all 7 parameters. The description adds no new meaning beyond the schema, meeting the baseline for a tool with full schema coverage.

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 states 'create and update' for backlog tickets, but the input schema includes a 'list' action, which is not mentioned. This inconsistency reduces clarity about the tool's full purpose.

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 siblings like 'ticket-read' or 'read'. There are no explicit when-to-use or when-not-to-use instructions.

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

writeC

Write access to backlog management - create, amend, and list backlog work items

ParametersJSON Schema

Name	Required	Description
`action`	No	Operation to perform (default: create)
`topic`	No	Topic name (required for create/amend)
`description`	No	Description (required for create, optional for amend)
`priority`	No	Priority level for create/amend operations (default: medium)
`status`	No	Status for amend operation or filter for list operation

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description must fully disclose behaviors. It only states 'Write access' implying mutation but includes 'list' (read-only), and fails to mention side effects, permissions, or response behavior for actions like approve or amend.

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?

Single concise sentence capturing the core purpose. However, by omitting several actions, it sacrifices completeness for brevity.

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?

Description lacks behavioral details and action-specific guidance. With 5 parameters and no output schema, it should explain key actions and their typical use cases, which it does not.

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 covers 100% of parameters with descriptions, so baseline is 3. Description adds no extra parameter context or usage examples, but does not need to given coverage.

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?

Description clearly identifies the tool as managing backlog work items with actions like create, amend, and list. However, it omits other actions from the schema (approve, submit, reopen, wontfix) and includes 'list' which is a read operation in a tool named 'write', slightly blurring clarity.

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 on when to use this tool versus siblings like 'read' or 'done'. Does not state when to avoid using it, nor alternative tools.

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.

7 tool updatesv1.1.0May 2, 2026
- Addedprune
- Addedticket-done
- Addedticket-read
- Addedticket-write
- Removedtodo-done
- Removedtodo-read
- Removedtodo-write
6 tool updatesDec 28, 2025
- First observeddone
- First observedread
- First observedtodo-done
- First observedtodo-read
- First observedtodo-write
- First observedwrite

Install Server

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

TDQS

B3.2/5.0

Disambiguation4/5

Tools are mostly distinct, but 'done' and 'ticket-done' could confuse an agent as both mark items complete; similarly 'read' vs 'ticket-read' and 'write' vs 'ticket-write' are pairs with overlapping purposes, though descriptions clarify the backlog vs ticket context.

Naming Consistency3/5

Naming is inconsistent: plain verbs (done, prune, read, write) and noun-verb with hyphen (ticket-done, ticket-read, ticket-write) mix styles. The verb placement also varies (verb-first vs noun-first).

Tool Count5/5

Seven tools is a reasonable number for managing backlog items and tickets, covering necessary operations without excess or deficiency.

Completeness4/5

The tool set covers core CRUD-like operations for both backlog items and tickets, including creation, reading, updating, completing, and pruning. Minor gaps include lack of explicit delete for backlog items or tickets (beyond pruning), but these are not severe.

Maintenance

ActivityInactive

ResponsivenessResponsive

Resources

GitHub Repository

Need Help?

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

shortcut
com.mcparmory
Track stories, organize sprints, and manage project workflows across your team
Project Management Developer Tools Workplace & Productivity
2
FrameOn
com.frameonlab
Shared project memory for teams: read projects and tasks, write updates and wiki decisions.
Knowledge & Memory Project Management Workplace & Productivity
1
Done Bear A
com.donebear
Local-first task manager: create, edit, and complete tasks, projects, and checklists via MCP.
Project Management App Automation
151
Plate AOAuth
to.plate
Minimal project management for teams and AI agents.
Project Management App Automation
282

Related MCP Servers

Tasks.md MCP Server
Project Management Developer Tools File Systems
context-you-keep
F
license
Not graded
quality
Not graded
maintenance
Enables AI-native task management using plain markdown files to create, update, query, and organize Epics, Stories, Tasks, and Milestones without requiring a database.
Updated 10 months ago (2025-11-19 04:44 UTC)
-
Backlog MCP Server
Project Management File Systems Developer Tools
gkoreli
A
license
B
quality
A
maintenance
Enables managing a minimal task backlog with operations to create, list, update, and retrieve tasks with different statuses (open, in progress, blocked, done, cancelled). Tasks are stored in a local JSON file with atomic writes.
Updated 2 months ago (2026-07-20 19:05 UTC)
28
81
5
MIT
Agile Planner MCP Server
Project Management Developer Tools Autonomous Agents
cyberlife-coder
A
license
Not graded
quality
D
maintenance
Automatically generates structured agile backlogs including epics, features, and user stories from natural language descriptions within AI-powered IDEs. It streamlines project management by creating AI-optimized markdown files and directory structures to guide step-by-step implementation.
Updated 7 months ago (2026-01-23 18:44 UTC)
31
3
MIT
Headquarter
Project Management CRM
axeldotdev
A
license
A
quality
C
maintenance
An AI-first business and project management tool that stores data locally in Markdown and JSON files, exposed via the Model Context Protocol (MCP). Enables project, issue, client, contact, and note management through natural language.
Updated 8 months ago (2026-01-16 03:09 UTC)
25
MIT

Appeared in Searches

A tool for sharing files, task lists, and a kanban board

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

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