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_draftsB | List current daily draft versions, optionally filtered by date, timezone, or status. |
| update_daily_draftC | 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_publicationB | Preview Work Logs and explicitly selected Tasks for one approved draft version. This performs no Notion writes. |
| publish_to_notionB | 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_statusC | 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 resource+action, and the Notion and Calendar tracks are cleanly mirrored (validate, preview, publish, status) so they never collide. The only potentially overlapping group — save_daily_draft, update_daily_draft, approve_daily_draft — is sharply differentiated by descriptions (persist vs. new immutable revision vs. approve exact version). get_daily_draft vs. list_daily_drafts is the standard singular/plural split and reads clearly.
Nearly all tools follow a verb_noun pattern (get_daily_activity, save_daily_draft, preview_notion_publication), and the two publication tracks are named in strict parallel. Minor deviations: 'ping' is a bare verb and 'publish_to_notion/publish_to_calendar' use a 'verb_to_noun' form, but these remain predictable and readable.
At 15 tools it sits at the top of the well-scoped band but every tool earns its place: a draft lifecycle plus symmetric preview/publish/status triads for two external targets. No redundant or vestigial tools are apparent.
The lifecycle is well covered end-to-end: activity ingestion, draft save/get/list/update/approve, then validate/preview/publish/status for both Notion and Calendar. Minor gaps: no delete/archive for drafts and no explicit retry tool despite status reporting 'retry status,' which agents may need to work around.