GTD MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DATABRICKS_HOST | No | Databricks workspace URL. Injected by Databricks Apps in deployment. | |
| GTD_DELTA_TABLE | No | Fully qualified name of the Delta table (e.g., gtd_mcp.app.gtd_mcp_records). Required for delta backend. | |
| GTD_SQLITE_PATH | No | Path to the SQLite database file (used only for sqlite backend). | .local/gtd.sqlite3 |
| DATABRICKS_APP_NAME | No | Name of the Databricks App. When present and GTD_STORAGE_BACKEND is unset, server assumes delta backend. | |
| GTD_STORAGE_BACKEND | No | Storage backend type. Defaults to 'sqlite' if not set and DATABRICKS_APP_NAME is absent. | sqlite |
| DATABRICKS_WAREHOUSE_ID | No | ID of the SQL warehouse to use. Required for delta backend. |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| healthA | Check server health and selected storage backend. |
| get_statsB | Get task, project, priority, and attention-needed statistics. |
| capture_taskB | Capture raw text to the GTD inbox. |
| get_inboxB | Return all raw inbox captures. |
| create_taskC | Create a structured actionable task. |
| update_taskC | Update task fields by ID. |
| get_taskA | Get full task details by ID. |
| list_tasksA | List tasks with optional filters by status, priority, project, context, or tag. |
| delete_taskC | Delete a task by ID. |
| create_projectC | Create a project to group related tasks. |
| get_projectC | Get project details and task IDs. |
| list_projectsA | List projects, filtered by active/completed/paused or all. |
| update_projectC | Update project fields by ID. |
| delete_projectB | Delete a project and unassign its tasks. |
| get_next_actionsC | Get high-priority actionable tasks to work on next. |
| start_taskC | Mark a task as in progress. |
| complete_taskC | Mark a task as completed. |
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 17 tools
Each tool has a distinct and clearly defined purpose, with no overlapping functionality. For example, capture_task is for raw inbox items while create_task is for structured actionable tasks, and specialized tools like get_next_actions, get_inbox, and get_stats serve unique aggregation roles.
All tool names follow a consistent verb_noun pattern using lowercase snake_case (e.g., capture_task, get_next_actions, delete_project). This predictability aids agent comprehension and selection.
With 17 tools, the set is well-scoped for a GTD methodology server. Each tool addresses a specific operation in the GTD workflow without redundancy or bloat, balancing coverage with conciseness.
The tool surface covers core GTD operations: capture, creation, update, deletion, status tracking, and listing for both tasks and projects. Minor gaps exist, such as lack of batch operations or explicit 'review' tools, but core workflows are fully supported.