worklog-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| WORKLOG_URL | No | If set, POST events here instead of writing to a file. Endpoint is <WORKLOG_URL>/api/agent/events. | |
| WORKLOG_FILE | No | Where to append events when no receiver is set (i.e., no WORKLOG_URL). Defaults to .worklog/events.jsonl. | .worklog/events.jsonl |
| WORKLOG_API_KEY | No | Bearer token. Required when WORKLOG_URL is set. |
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 |
|---|---|
| log_workA | Log a unit of work when you finish something meaningful. Capture the WHY and any open loops — git already has the diff. |
| record_decisionA | Record an architecturally consequential decision (ADR-style). Only call when a real choice was made. |
| report_test_runB | Report the outcome of a test/verify run (counts, not full logs). |
| link_prC | Link a pull request to this project's work log. |
| update_progressB | Upsert the current status of a work item (feature/task). Overwrites the item's status; also records the change. |
| sync_docA | Sync a long-form project document (plan/spec/progress/runbook/research) as rendered markdown. Upserts by (kind, key); the version bumps each sync. Use for docs an agent maintains in-repo, so the log carries their current state. |
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 6 tools
Most tools target distinct actions (logging work, recording decisions, reporting test runs, linking PRs, updating progress, syncing docs). However, log_work and update_progress could be confused since both deal with work item status, though descriptions help clarify boundaries.
All tool names follow a consistent verb_noun snake_case pattern (log_work, record_decision, report_test_run, link_pr, update_progress, sync_doc). The naming is predictable and uniform, making it easy to infer function from name.
With 6 tools, the set is well-scoped for a worklog server. Each tool covers a distinct aspect of work logging without redundancy or excessive granularity, fitting comfortably within the ideal 3-15 range.
The tool set is heavily write-oriented (log, record, report, link, update, sync) but lacks any retrieval or query tools. There is no way to read/list/export the work log, which is a significant gap for a server whose purpose is to capture work history. This will likely cause agent failures when attempting to review or summarize logged work.