Redbooth MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| REDBOOTH_CLIENT_ID | No | Client ID for your own Redbooth OAuth app, used directly and bypassing the broker. | |
| REDBOOTH_READ_ONLY | No | Set to true to disable all write tools. | |
| REDBOOTH_TOKEN_PATH | No | Custom token file location. Defaults to ~/.config/redbooth-mcp/tokens.json. | |
| REDBOOTH_ACCESS_TOKEN | No | Use a static Redbooth access token. | |
| REDBOOTH_CLIENT_SECRET | No | Client secret for your own Redbooth OAuth app, used directly and bypassing the broker. | |
| REDBOOTH_AUTH_BROKER_URL | No | Point to your own Cloudflare Worker OAuth broker. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| loginA | Sign in to your Redbooth account in the browser. Zero configuration required – opens your browser to Redbooth's authorization screen and waits for you to click Allow. |
| logoutA | Disconnect the current Redbooth account and remove locally stored OAuth tokens. |
| get_meA | Get the authenticated Redbooth user (useful to find your own user ID). |
| list_organizationsB | List Redbooth organizations the current user belongs to. |
| list_usersA | List Redbooth users visible to you. Use this to find user IDs for assigning tasks. Optionally filter by organization or project. |
| list_projectsA | List Redbooth projects (workspaces) you have access to. |
| get_projectB | Get details of a single Redbooth project. |
| create_projectC | Create a new Redbooth project in an organization. |
| list_task_listsB | List the task lists in a Redbooth project. A task must belong to a task list. |
| create_task_listC | Create a new task list in a Redbooth project. |
| list_tasksA | List Redbooth tasks. Filter by project, task list, assignee and/or status. Without filters returns tasks across all your projects. |
| get_taskA | Get full details of a single Redbooth task. |
| create_taskA | Create a Redbooth task. Requires a project_id and a task_list_id (use list_task_lists to find one). |
| update_taskA | Update fields on an existing Redbooth task. Only the provided fields are changed. |
| complete_taskB | Mark a Redbooth task as resolved (done). |
| list_subtasksB | List the subtasks (checklist items) of a Redbooth task. |
| create_subtaskB | Add a subtask (checklist item) to a Redbooth task. |
| update_subtaskB | Rename a subtask and/or mark it resolved/unresolved. |
| list_commentsC | List comments on a Redbooth task. |
| add_commentC | Post a comment on a Redbooth task. |
| redbooth_api_getA | Escape hatch: perform a read-only GET against any Redbooth API v3 path (e.g. path '/notes' with query {"project_id": 1}). Use only when no dedicated tool fits. Returns the raw JSON. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 21 tools
Each tool targets a distinct resource+action (projects, tasks, subtasks, comments, users), so selection is mostly clear. The only mild overlap is complete_task vs update_task, but the description explicitly distinguishes the resolved-state shortcut.
Nearly all tools follow a consistent snake_case verb_noun pattern (list_tasks, create_task, update_subtask). Minor deviations are login/logout (verb-only) and redbooth_api_get, which reverses the order and prefixes the domain.
21 tools is on the heavier side but justified for a full project-management surface spanning auth, orgs, users, projects, task lists, tasks, subtasks, and comments. No obvious filler tools.
Core create/read/update flows exist for tasks, subtasks, and comments, but the surface lacks delete operations (tasks, subtasks, projects, comments) and update_project/update_task_list, leaving notable lifecycle gaps. The read-only escape hatch helps but cannot cover writes.