This server lets you manage GitHub Projects v2 boards as a personal kanban board, creating and organizing draft activities without linking to real issues.
List your GitHub Projects v2 boards.
Create new boards with default Status (Todo/In Progress/Done) and Priority (Urgent/High/Medium/Low) fields.
List activities/draft items in a board, filtered by status or priority.
Create activities with title, description, and optional status/priority.
Move activities to a different status and optionally set priority.
Update an activity's title and/or description.
Delete activities permanently.
Archive and unarchive activities to hide/restore them (per README; not in the supplied schema).
Provides tools for managing GitHub Projects v2 boards as a personal kanban system, including creating, moving, updating, and deleting activities (draft items) and filtering by status and priority.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@gh-board-mcp Add a new activity called 'Write specs' with priority High"
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 server for managing GitHub Projects v2 as a personal kanban board. Create activities (draft items), move them between columns, track priority — without linking to real issues.
Node.js >= 18
A GitHub Personal Access Token with the project scope (fine-grained: Projects read/write)
Related MCP server: GitHub Project MCP Server
The package is published on npm — any MCP client can launch it with npx gh-board-mcp:
GITHUB_TOKEN=ghp_xxx npx -y gh-board-mcpRegister it globally (available in all projects):
claude mcp add gh-board-mcp -s user -e GITHUB_TOKEN=ghp_xxx -- npx -y gh-board-mcp-s user → global config (all projects); use -s project to scope it to a single repo.
-e GITHUB_TOKEN=... sets the token env var; the -- separates the server command.
Verify with claude mcp list → gh-board-mcp should show Connected.
Add it to the global config at ~/.config/opencode/opencode.json (or .jsonc):
{
"mcp": {
"gh-board-mcp": {
"type": "local",
"command": ["npx", "-y", "gh-board-mcp"],
"enabled": true,
"environment": {
"GITHUB_TOKEN": "ghp_xxx"
}
}
}
}Verify with opencode mcp list → gh-board-mcp should show connected.
Tool | Description |
| List your GitHub Projects v2 boards |
| Create a new board (default Status + Priority fields, opens with a board view) |
| List activities (draft items), filter by status/priority |
| Create an activity with optional status/priority |
| Move an activity to another status (and set priority) |
| Edit an activity's title/description |
| Delete an activity (permanent) |
| Archive an activity (hidden from lists, reversible) |
| Restore an archived activity |
create_project creates a new board with Status = Todo / In Progress / Done, Priority = Urgent / High / Medium / Low, and a board (kanban) view as its default view.
Boards created from a GitHub template keep their own Status/Priority options — pass values that exist on the board. create_activity, move_activity, and list_activities report the valid options when given an unknown value.
Custom columns are not supported via the API (configure them in the GitHub UI).
Read cap: list_activities and list_projects read up to 100 items / projects in one call; larger boards are truncated.
Archive ≠ delete: archive_activity hides an item from list_activities but keeps it (restorable via unarchive_activity); delete_activity removes it permanently.
Eventual consistency: GitHub Projects v2 writes can take a moment to appear in reads — a list_activities immediately after create_activity may briefly miss the new item.
Create is not atomic: create_activity validates the status/priority options before creating, so a bad option leaves nothing behind; a transient network error mid-create can still leave a draft without its field values.
npm install
npm test
npm run build
npm run devMIT
Create a new activity (draft item) in a board. Optionally set an initial status and priority.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Title of the activity | |
| status | No | Initial status. Valid values depend on the project (new boards: Todo, In Progress, Done / Urgent, High, Medium, Low). | |
| priority | No | Initial priority. Valid values depend on the project (new boards: Todo, In Progress, Done / Urgent, High, Medium, Low). | |
| description | No | Notes/body for the activity | |
| projectNumber | Yes | Number of the GitHub Project board |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses that the tool creates a draft item (not final) and that status/priority values are project-dependent, which is helpful. However, it does not mention side effects (e.g., whether it triggers notifications), permission requirements, or what happens on failure (e.g., draft vs. committed?).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that covers the core purpose and key optional features. Every word earns its place – no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, no nested objects, no output schema) and the fact that the input schema is well-documented (100% coverage, required fields listed), the description is adequate. It would benefit from mentioning that 'projectNumber' is required and must exist, but overall it provides sufficient context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds that status and priority can be set initially, but the schema already describes their valid values. The description does not clarify the relationship between project and valid status/priority values beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('create') and resource ('activity (draft item) in a board'), clearly distinguishing it from siblings like 'list_projects', 'update_activity', or 'delete_activity'. The addition of 'optionally set an initial status and priority' further specifies what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies basic usage (creating a draft with optional status/priority) but provides no guidance on when to use this tool versus alternatives like 'update_activity' for modifying existing items, or prerequisites such as needing a valid 'projectNumber'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new GitHub Project v2 board with default Status (Todo/In Progress/Done) and Priority (Urgent/High/Medium/Low) fields.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the new board/project |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. While it mentions the default fields, it omits whether the operation is destructive (overwriting existing projects?), requires authentication, or has side effects (e.g., creating a repository or webhook). A mutation tool should disclose 'creates a new board beyond existing ones' and usage limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, front-loaded sentence with no fluff. Every word serves the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 1 parameter, the description is mostly adequate. However, without an output schema or annotations, it would benefit from stating what the response looks like (e.g., 'Returns the created board's ID and URL') and any prerequisites (e.g., 'Requires admin access to the repository or organization').
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds context about default fields ('Status' and 'Priority'), but the sole parameter 'name' is already explained in the schema. The description does not add meaning beyond what the schema already provides, but it does not need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create'), the target ('GitHub Project v2 board'), and what default fields come with it ('Status' and 'Priority'). This distinguishes it from siblings like 'list_projects' (list) or 'create_activity' (creates a different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for creating boards with a specific structure, which differentiates it from siblings like 'list_projects' (read) or other activity-level tools. However, it does not explicitly say when to use an alternative or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an activity (draft item) from a board.
| Name | Required | Description | Default |
|---|---|---|---|
| itemId | Yes | Item id of the activity (from list_activities) | |
| projectNumber | Yes | Number of the GitHub Project board |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully communicate behavioral traits. It states the tool deletes an activity but does not disclose whether the deletion is permanent, reversible, or if it requires special permissions. For a destructive operation, this lack of transparency is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous words. Every word is essential, delivering the core purpose efficiently. It is appropriately sized for a simple deletion tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only two parameters and no output schema, the description covers the basic purpose but omits crucial context like return behavior (e.g., success/failure signals) and error dependencies. It is minimally adequate but leaves gaps that could confuse an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have schema descriptions (100% coverage) that explain their meaning (itemId from list_activities, projectNumber as board number). The description does not add further detail nor clarify relationships between parameters, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete'), the resource ('activity (draft item)'), and the location ('from a board'). This directly differentiates it from sibling tools (e.g., create_activity, move_activity, update_activity) which perform other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 does not mention prerequisites (e.g., the activity must exist), conditions where deletion is inappropriate, or suggest fallback tools like update_activity for archival. Lacking this context, an agent might misuse it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List activities (draft items) in a board. Filter by status and/or priority. Valid values depend on the project (new boards: Todo, In Progress, Done / Urgent, High, Medium, Low).
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Status filter. Valid values depend on the project (new boards: Todo, In Progress, Done / Urgent, High, Medium, Low). | |
| priority | No | Priority filter. Valid values depend on the project (new boards: Todo, In Progress, Done / Urgent, High, Medium, Low). | |
| projectNumber | Yes | Number of the GitHub Project board |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must communicate behavioral traits. The verb 'list' implies a read operation, but the description does not explicitly state that it is read-only, safe, or idempotent. It also omits any mentions of authentication requirements or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and efficiently adds filtering details. Every sentence contributes value without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately explains what the tool does and how to filter, but it does not describe the return format or output structure. Since there is no output schema, the description should provide some context about what fields are returned, which is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description adds no new parameter-level meaning beyond restating the valid values note already present in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('activities (draft items)'), and the scope ('in a board'). It also mentions filtering by status and/or priority, which distinguishes it from sibling tools like list_projects or create_activity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use the tool (listing activities with optional filters) and gives valid values for status/priority. However, it does not explicitly state when not to use it or mention alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all GitHub Projects v2 boards owned by the authenticated user.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility. It correctly implies a read-only operation (list) and specifies the data scope (user's own projects). However, it does not mention pagination, error scenarios, or whether the list includes all boards or only active ones. The simplicity of the tool (no parameters) makes the transparency adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, front-loaded with the verb 'List'. Every word carries meaning; there is no redundancy or filler. It is maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no parameters, no output schema, no annotations). The description covers the primary action and scope. However, it does not describe the return format (e.g., fields included, pagination behavior), which would help an agent interpret results. Given the lack of an output schema, a slightly richer description (like 'returns project id and title') would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is 100% trivially. The description does not need to add parameter information. Following the baseline guideline of 4 for 0-parameter tools, this score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list), the resource (GitHub Projects v2 boards), and the scope (owned by the authenticated user). This verb+resource+scope pattern distinguishes it from sibling tools like create_project or list_activities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., list_activities for project items). There is no mention of prerequisites, context, or situations where this tool should be avoided. The description only states what it does, not when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move an activity to a different status and optionally set its priority. Valid values depend on the project (new boards: Todo, In Progress, Done / Urgent, High, Medium, Low).
| Name | Required | Description | Default |
|---|---|---|---|
| itemId | Yes | Item id of the activity (from list_activities) | |
| status | Yes | Target status. Valid values depend on the project (new boards: Todo, In Progress, Done / Urgent, High, Medium, Low). | |
| priority | No | Target priority. Valid values depend on the project (new boards: Todo, In Progress, Done / Urgent, High, Medium, Low). | |
| projectNumber | Yes | Number of the GitHub Project board |
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 notes that valid values depend on the project but does not reveal side effects, idempotency, required permissions, or what the tool returns. This is insufficient for an agent to understand the full impact of invoking the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action. Every word serves a purpose, with no fluff or repetition. It is appropriately concise for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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. It omits what the tool returns after the move, how to discover valid status/priority values for a project, and any error conditions. The agent cannot fully understand the contract without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description repeats the valid-values note already present in the status and priority parameter descriptions, adding no new semantic information beyond what the schema already provides. It does not elaborate on 'itemId' or 'projectNumber' further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Move an activity to a different status and optionally set its priority') with a specific verb and resource. It distinguishes the tool from siblings like 'update_activity' (which could update other fields) and 'create_activity', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., 'update_activity' might also change status). The description does not specify prerequisites, when not to use it, or how to determine valid status/priority values, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit the title and/or description of an activity (draft item).
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | New title | |
| itemId | Yes | Item id of the activity (from list_activities) | |
| description | No | New description/body | |
| projectNumber | Yes | Number of the GitHub Project board |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states 'Edit' without explaining mutability, idempotency, authorization requirements, or what happens if the activity is not in a draft state. This is a significant gap 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of 12 words. Every word is necessary, and it communicates the core action without filler. It is highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple update tool, but it lacks context about what constitutes a 'draft item', how to obtain the itemId (though schema references list_activities), and whether both title and description can be updated simultaneously. Given the lack of output schema and annotations, more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter's purpose. The description adds no new meaning beyond confirming that title and/or description can be edited. With high coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Edit' and identifies the resource as 'an activity (draft item)'. It clearly distinguishes from siblings like create_activity, move_activity, and delete_activity by focusing on modifying existing content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need to change the title or description of an existing activity. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites or exclude scenarios (e.g., when the activity is not a draft).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0create_activitycreate_projectdelete_activitylist_activitieslist_projectsmove_activityupdate_activityScored across 7 tools
Each tool targets a distinct resource or action: projects (list/create) vs activities (create/list/move/update/delete). No two tools have overlapping purposes, and descriptions clearly differentiate them.
All tools follow a consistent verb_noun pattern where listing uses plural nouns (list_projects, list_activities) and other actions use singular nouns (create_project, create_activity, move_activity, update_activity, delete_activity).
With 7 tools, the server covers the essential operations for GitHub Projects v2 board management without being bloated or minimal. Each tool serves a clear and necessary purpose.
Core CRUD on activities is mostly covered, but missing operations like updating or deleting a project are notable omissions. There is no tool to retrieve a single activity by ID, though list_activities with filters partially compensates.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Create and drive KanbanThing kanban boards. No account, no API key, board link required.
Capture, organize, and work your GTD board: inbox capture, next actions, projects, waiting-for.
Read and manage your EasyKanban kanban boards: to-do summaries, create, update, and move cards.
Task management for people and AI agents, with scoped OAuth access to issues, projects, and docs.
