worklog-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness2/5
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.
Average 3.4/5 across 6 of 6 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose what 'link' means operationally—whether it creates a log entry, updates a PR, or has side effects like sending notifications. There is no mention of required permissions, reversibility, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one terse sentence with no redundant wording, which is efficient. However, it is almost too sparse, lacking any structural breakdown that would help an agent parse requirements. Still, for conciseness it earns a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, 4 required, no output schema, and no annotations, a single sentence is insufficient. It does not explain what constitutes a successful link, what happens if the PR doesn't exist, or how the work log is affected. The description is markedly incomplete for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (17%), and the description adds no parameter explanations. The schema itself provides limited context (e.g., provider enum, repo format), but the description does not clarify how parameters like url, prNumber, or status should be used or relate to the linking operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('link') and resource ('pull request') with a specific destination ('this project's work log'). It is unambiguous and identifies the core purpose, though it does not explicitly distinguish itself from sibling tools like log_work or record_decision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no context on when to use this tool versus alternatives, nor any exclusions or prerequisites. It only states what it does, leaving the agent without guidance on appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the disclosure burden. It adds 'counts, not full logs,' which clarifies the output type, but it omits whether the tool mutates state, requires permissions, or returns confirmation. The tool appears to be a reporting action but side effects are not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the purpose and adds one clarifying parenthetical. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and no annotations, the description is too sparse. It doesn't explain parameter relationships, required fields beyond the schema, or what the tool returns. The parenthetical about counts helps but is insufficient for complete operational guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 14% of parameters have schema descriptions, and the description does not elaborate on individual parameters. It hints that passed/failed/skipped are counts, but doesn't explain suite, durationMs, or failureSummary beyond what parameter names imply. The schema's enum for result is clear, but no additional meaning is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports test/verify outcomes and restricts scope to counts rather than logs. This distinguishes it from sibling tools like log_work, though it doesn't explicitly name alternatives. The verb 'Report' and resource 'outcome of a test/verify run' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a test/verify run has completed and you need to submit its outcome. It does not explicitly state when to use this tool over alternatives like log_work or update_progress, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the operation overwrites the existing status and records the change, which is useful. However, it does not mention idempotency, reversibility, permission requirements, or behavior when the work item does not exist (despite the 'upsert' implication).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, immediately states the core purpose, and adds a critical behavioral note about overwriting and recording. It wastes no words and is well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, is a mutation, lacks annotations and output schema, yet the description does not explain return values, error cases, or the meaning of several parameters. The 'upsert' semantics and defaulting of workItemKey to the session are only hinted in the schema, not described. For a write operation, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only workItemKey has a description). The tool description adds minimal parameter meaning beyond the schema: it clarifies 'status' as the main thing being updated, but leaves 'summary', 'blockers', and 'nextSteps' without semantic explanation. Since schema coverage is low, the description should compensate, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Upsert') and resource ('current status of a work item'), and clarifies it overwrites status and records the change. It is distinct enough from siblings like 'log_work' or 'record_decision' because it focuses on status updates, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating a work item's status, but it does not explicitly state when to use it versus alternatives, nor does it provide exclusions or prerequisites. The sibling tools are not referenced, so the agent must infer the tool's niche from its name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains what the tool does but does not describe side effects, return values, idempotency, or how supersedesId affects existing decisions. This is a significant gap for a decision-recording tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, front-loading the core purpose and a usage condition. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, a one-sentence description is insufficient. It omits details about the ADR format, expected field contents, and the supersede mechanism, leaving the agent to infer too much.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the tool description adds no parameter information. The schema describes 'decision' and 'supersedesId' but leaves title, context, alternatives, and consequences undocumented. The description does not compensate for this low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Record an architecturally consequential decision (ADR-style)') that clearly distinguishes it from sibling tools like log_work or link_pr. The qualifier 'architecturally consequential' adds precision about the intended scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Only call when a real choice was made', providing a clear condition for when to use the tool. However, it does not mention alternatives or when not to use it, so it falls short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds useful context beyond annotations (none provided): 'git already has the diff' implies the tool is for metadata/context, not code changes. However, it doesn't disclose whether this is a persistent write operation, auth requirements, or what happens on invocation. Since annotations are absent, the description carries the burden and only partially fulfills it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences. Every word earns its place, delivering the core purpose and a key design philosophy without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple logging tool with no output schema, the description gives the essential purpose and mindset but omits parameter details (especially commitSha and filesTouched) and any behavioral specifics. It's minimally viable but leaves gaps for optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (intent and summary have descriptions; commitSha and filesTouched do not). The description adds guidance by stating to capture the WHY (intent) and open loops (likely in summary), and 'git already has the diff' hints that diff-related fields (commitSha/filesTouched) may be redundant. But it doesn't explain the un-documented parameters explicitly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Log a unit of work') and the resource (a unit of work), with context ('when you finish something meaningful'). It doesn't explicitly differentiate from siblings like 'update_progress' or 'record_decision', but the resource and phrasing are distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear usage context: use when you finish something meaningful. However, it doesn't mention alternatives or exclusions, such as when to use 'update_progress' or 'record_decision' instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It does reveal non-obvious behavior: upsert semantics by (kind, key) and version bumping per sync, plus the markdown format. However, it does not disclose overwrite/retention details, required permissions, or side effects beyond versioning.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly written sentences: front-loaded verb/resource, immediately followed by identity/version semantics and a clear use case. Every clause earns its place without repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter tool with no output schema, the description adequately covers purpose, identity, version behavior, doc kinds, and intended usage. It is slightly light on return value/response behavior and explicit differentiation from siblings, but it is sufficient for correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 60%, so the description adds some value. It clarifies that kind+key form the identity ('Upserts by (kind, key)'), and 'rendered markdown' explains the body format. Yet title and status are not semantically elaborated, and the enum values are already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Sync') and identifies the resource ('long-form project document') with enumerations of doc kinds (plan/spec/progress/runbook/research). It also distinguishes from sibling tools by noting 'docs an agent maintains in-repo', clearly separating this from logging or progress-update tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool: 'Use for docs an agent maintains in-repo, so the log carries their current state.' This gives clear context, but it does not name alternative tools or provide explicit when-not-to-use guidance, keeping it just below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![worklog-mcp MCP server](https://glama.ai/mcp/servers/aadityakushwaha/worklog-mcp/badges/card.svg)](https://glama.ai/mcp/servers/aadityakushwaha/worklog-mcp)

Score Badge

Copy to your README.md:

[![worklog-mcp MCP server](https://glama.ai/mcp/servers/aadityakushwaha/worklog-mcp/badges/score.svg)](https://glama.ai/mcp/servers/aadityakushwaha/worklog-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/aadityakushwaha/worklog-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server