KiraHub MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| KIRAHUB_API_KEY | Yes | API key for authentication with KiraHub | |
| KIRAHUB_API_URL | No | URL of the KiraHub instance | http://localhost |
| PLAN_EDITOR_API_URL | No | URL of the Plan Editor API (optional, for plan wiki integration) |
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_next_taskC | Get the next task from the queue based on priority and dependencies |
| claim_taskC | Claim a task to work on it |
| complete_taskA | Mark a task as completed. This will trigger validation questions based on project knowledge. If validation questions are returned, you must answer them by calling this tool again with the answer in the message parameter. |
| create_taskC | Create a new task |
| update_taskC | Update task details |
| get_task_detailsA | Get detailed information about a task including dependencies and notes |
| list_epicsB | List all epics for a project |
| get_epicB | Get epic details with all tasks |
| create_epicC | Create a new epic |
| update_epicC | Update epic details |
| add_working_noteA | Add a working note to a task (todo, bug, edge case, optimization, plan, or information). Plan notes auto-resolve previous plans. Priority defaults to informational for plan/information types. |
| resolve_working_noteB | Mark a working note as resolved |
| escalate_working_noteB | Escalate a working note to a new task |
| get_task_notesA | Get all working notes for a task |
| sync_planA | Sync an implementation plan to the currently claimed task as a working note. Uses the current task context automatically - no task_id needed. Previous plan notes are auto-resolved. Call this after exiting plan mode. |
| add_task_dependencyB | Add a blocking dependency between tasks (blocked_task waits for blocking_task to complete) |
| remove_task_dependencyA | Remove a blocking dependency between tasks |
| get_project_knowledgeA | Search project knowledge base (architecture, best practices, specs) |
| add_project_knowledgeB | Add a new knowledge entry to the project |
| post_activityA | Post an activity event to track what the agent is doing. You MUST call this proactively throughout your work — do not wait to be asked. Specifically:
|
| get_activityB | Get recent activity events for a project or task |
| get_shared_contextC | Get shared context for a project (contracts, utilities, decisions, config) |
| set_shared_contextA | Set a shared context item so other agents can see your work. You SHOULD call this when:
|
| delete_shared_contextC | Delete a shared context item |
| get_plan_overviewA | Fetch the overview, manifest, and epic metadata from the PlanCreator wiki for a given project |
| list_plan_tasksA | List tasks from the PlanCreator wiki along with metadata to understand available plan steps |
| get_plan_task_detailsA | Retrieve the full markdown content and metadata for a specific plan task from the PlanCreator wiki |
| search_plan_tasksA | Search plan tasks in PlanCreator by title, description, tags, or content to find relevant context |
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 28 tools
Most tools have clearly distinct purposes: task management, epics, notes, dependencies, knowledge, activity, shared context, and plan wiki. A few pairs like add_project_knowledge vs set_shared_context and get_task_details vs get_task_notes could be confused, but their descriptions provide enough clarification.
Tool names follow a consistent verb_noun pattern in lowercase snake_case (e.g., get_next_task, create_epic, add_working_note, resolve_working_note, post_activity). All verbs clearly indicate the action, and there are no mixed conventions or vague names.
With 28 tools, the server exceeds the 25+ threshold that indicates a heavy, oversized toolset. While each tool serves a distinct function, the sheer number may overwhelm agents and suggests a need for consolidation or sub-servers.
The toolset covers a broad lifecycle: task and epic CRUD (though missing delete), notes, dependencies, knowledge, activity, shared context, and plan wiki. Notable gaps include no direct list_tasks tool (only via epics) and no deletion capabilities for tasks or epics, which agents may need.