nirvana-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| NIRVANA_AUTH_TOKEN | Yes | Nirvana authentication token obtained via the login command |
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 |
|---|---|
| get_inboxA | Returns tasks in the Nirvana Inbox (state=0) — unprocessed items the user hasn't categorized yet. |
| get_next_actionsA | Returns tasks marked as Next Actions in Nirvana (state=1) — concrete, actionable next steps the user has committed to. |
| get_waiting_forA | Returns tasks the user is Waiting on someone else for in Nirvana (state=2). Often blocked on a contact's response or delivery. |
| get_scheduledA | Returns Scheduled tasks in Nirvana (state=3) — tasks deferred to a specific future start date. |
| get_somedayA | Returns tasks parked in Nirvana's Someday list (state=4) — things to revisit later but not actionable now. |
| get_logbookA | Returns completed tasks logged in Nirvana (state=7). Use this to review what the user finished. |
| get_focusA | Returns tasks the user has flagged for Focus in Nirvana (seqt > 0), excluding completed or trashed items. These are what the user is actively prioritizing right now. |
| list_projectsA | Returns the user's active projects in Nirvana (state=11). Projects are containers that group related tasks under a shared outcome. |
| get_projectA | Returns a single project and all of its direct child items (tasks and sub-projects). Identify the project by its exact |
| list_areasA | Returns the user's Areas in Nirvana — high-level life domains (e.g. 'work', 'personal') that group projects and tasks. Areas are the top-level organizing dimension. |
| list_tagsA | Returns the user's labels in Nirvana — plain tags, GTD contexts (e.g. @phone, @home), and contacts (people the user waits on). Each entry has a |
| search_tasksA | Search the user's Nirvana tasks with any combination of filters. At least one filter is required. Trashed and deleted tasks are always excluded. Completed (logged) tasks are excluded unless |
| get_laterA | Returns tasks in Nirvana's Later list (state=5) — things the user will definitely do, but not in the immediate Next queue. Sits between Next and Someday. |
| get_trashA | Returns tasks the user has thrown into Trash (state=6). These are soft-deleted but recoverable — useful for finding something the user trashed but might want back. |
| get_recurringA | Returns the user's recurring task templates in Nirvana (state=9). These are the rules that spawn task instances on a schedule, not individual occurrences. |
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 15 tools
Each tool targets a specific Nirvana task state or entity (focus, inbox, later, logbook, next actions, project, recurring, scheduled, someday, trash, waiting for, areas, projects, tags, search). The descriptions clearly differentiate overlapping concepts like focus vs. next actions, making selection unambiguous.
All tool names follow a consistent verb_noun pattern using snake_case: get_*, list_*, search_*. No mixing of conventions or vague verbs. The naming is predictable and discoverable.
With 15 tools, the count is at the upper boundary of the ideal range. It covers many task states and organizational entities, which is reasonable for a full-featured GTD app. Slightly high but still well-scoped.
The tool set covers all retrieval needs for task states, projects, areas, and tags, but completely lacks mutation tools (create, update, delete for tasks or projects). This is a significant gap, as agents cannot modify the user's task system, limiting practical usage.