Local DevLog MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LOCAL_DEVLOG_DATA_DIR | No | Overrides the data directory (useful for isolated testing). By default, configuration, events, and drafts are stored at ~/Library/Application Support/local-devlog-mcp/. |
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
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| pingB | Check MCP connectivity |
| get_daily_activityA | Read Git pre-push attempts for a local calendar date. Results are attempts, not proof that pushes succeeded. |
| save_daily_draftB | Persist an AI-proposed daily draft. This does not approve or publish it. |
| get_daily_draftB | Read a daily draft and all of its immutable revisions. |
| list_daily_draftsA | List current daily draft versions, optionally filtered by date, timezone, or status. |
| update_daily_draftB | Create a new immutable revision after checking the current version. Use REJECTED to reject and PENDING to edit or reopen. |
| approve_daily_draftA | Approve one exact persisted draft version after explicit human confirmation. This does not publish externally. |
| validate_notion_connectionA | Read Notion authentication, Database, Data Source, and property schemas without modifying Notion. |
| preview_notion_publicationA | Preview Work Logs and explicitly selected Tasks for one approved draft version. This performs no Notion writes. |
| publish_to_notionA | Publish an exact, previously previewed approved draft version after explicit user confirmation. |
| get_notion_publication_statusB | Read local per-item Notion publication and retry status for one draft version. |
| validate_calendar_connectionA | Inspect Apple Calendar permission and configured target. Set requestPermission only when the user wants the macOS full-access prompt. |
| preview_calendar_publicationA | Preview one all-day Apple Calendar event for an exact approved draft version. This performs no Calendar write. |
| publish_to_calendarA | Publish an exact, previously previewed approved draft version to Apple Calendar after explicit user confirmation. |
| get_calendar_publication_statusB | Read local Apple Calendar publication state and verify the event when Calendar access is available. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Daily draft review | Interactive review, editing, rejection, reopening, and approval for local daily drafts. |
TDQS
Scored across 15 tools
Each tool targets a distinct action and resource: draft lifecycle, Notion publication, Calendar publication, and connectivity. The parallel Notion and Calendar tools are clearly separated by platform, and draft read/list/save/update/approve/preview/publish boundaries are explicit.
Nearly all tools follow a predictable snake_case verb_noun pattern, with parallel naming for Notion and Calendar workflows. The only outlier is the simple connectivity tool `ping`, which is conventional and does not disrupt the pattern.
Fifteen tools are well scoped for a local devlog workflow involving draft revisions, approval, Notion publication, and Calendar publication. Each tool appears to earn its place by covering a distinct lifecycle step or integration check.
The surface covers the core daily-draft lifecycle and mirrors publication pipelines for both Notion and Calendar with validation, preview, publish, and status tools. A minor gap is the lack of explicit task selection/discovery tools despite preview referencing selected Tasks, and retry handling is only implied through status.