jira-worklog-mcp

by luizeduul

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a clear, distinct operation: auth check, issue search, single issue fetch, comment addition, single worklog entry, batch worklog entry, and worklog listing. Even the two worklog-logging tools are cleanly separated by singular vs. batch usage.
Naming Consistency5/5
All tools follow a consistent jira_ + verb_noun pattern (search_issues, get_issue, add_comment, log_work, log_work_batch, get_worklogs). The only slight exception is jira_whoami, but it is a standard command-style name and does not break the overall consistency.
Tool Count5/5
With 7 tools, the server is well-scoped for a Jira worklog-focused MCP. It provides all necessary supporting operations (auth, issue lookup, comments) without bloat, and every tool earns its place.
Completeness3/5
The core worklog operations of logging (single and batch) and retrieving are covered, along with issue search and comments. However, there are no tools to update or delete existing worklogs, which is a notable gap in the full lifecycle for a worklog management server.
Average 4.2/5 across 7 of 7 tools scored.
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
- Last stable release on June 15, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It adds that the output is a 'compact view' and lists the fields, which is useful. However, it does not mention error handling, authentication requirements, or whether it returns full or partial data beyond the listed fields. For a simple read-only tool this is adequate but not comprehensive.
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 concise sentence with a clear list of output fields. It is front-loaded with the core action and avoids any redundant wording or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one well-documented parameter and an existing output schema, the description is complete. It accurately conveys what the tool returns and in what format (compact view with specified fields), which is sufficient for an LLM to select and invoke it correctly.
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 100% for the single parameter 'issue_key', with an example. The description itself does not add additional parameter semantics beyond listing 'key' in the output. Baseline 3 applies because the schema fully documents the parameter.
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 clearly states the tool's function with a specific verb ('Returns') and resource ('one issue'), and enumerates the exact fields included. This distinguished it from siblings like jira_search_issues (which returns multiple issues) and jira_add_comment (which writes).
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: you need an issue key to fetch a single issue. However, it does not explicitly state when to use this tool versus alternatives, such as 'use this when you have a known issue key; use jira_search_issues to find issues by query.' Thus, usage context is implied but no exclusions or alternatives are mentioned.
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, the description carries the full burden. It indicates a read-only operation by saying 'lists', and it discloses the filtering behavior of mine_only. However, it doesn't mention any side effects or limitations beyond that, such as authentication requirements or potential errors for invalid issue keys. This is minimal but adequate for a simple read operation.
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 short sentences, front-loaded with the core purpose. Every word is useful, and it clearly explains the mine_only parameter in a natural way. Perfectly concise.
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 simple 2-parameter tool with an output schema, the description is adequately complete. It clarifies the primary scope (single issue) and the optional filter. It doesn't explain return values, but the output schema covers that. It could potentially mention that it's a read-only operation, but 'lists' conveys that implicitly.
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?
The input schema already provides descriptions for both parameters ('Issue key.' and 'Only my worklogs.'), so the description adds little extra. The phrase 'from one issue' adds a bit of semantic context to issue_key, but overall it doesn't go beyond the schema. With 100% schema coverage, the baseline is 3.
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 clearly states it lists worklogs from a single issue, distinguishing it from sibling tools like jira_get_issue (which retrieves issue details) and jira_search_issues (which searches across issues). The verb 'lists' and resource 'worklogs' are specific and unambiguous.
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 implies the use case: retrieving worklogs for a specific issue. It doesn't explicitly mention alternatives or when not to use it, but the scope ('from one issue') provides clear context. There are no exclusions stated, but the purpose is self-evident.
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 behavioral disclosure burden. It discloses that plain text is converted to Jira ADF, which is a meaningful behavior beyond the schema. However, it does not mention potential side effects, permissions, or idempotency, leaving some gaps for a mutation 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 two short sentences, front-loaded with the primary action. Every word serves a purpose with no wasted text. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two required parameters, both documented in the schema. The description covers the core function and adds a key behavioral detail (ADF conversion). An output schema exists to handle return values, so the description does not need to explain them. The context is complete for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers both parameters with examples and descriptions (100% coverage). The description adds value by specifying that the 'comment' parameter expects plain text, which will be converted to ADF. This clarifies the input format beyond what the schema states.
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 clearly states the tool's function: 'Adds a comment to an issue.' It uses a specific verb ('adds') and resource ('comment to an issue'), and the mention of plain text converting to Jira ADF adds a distinctive detail that differentiates it from sibling tools like jira_log_work or jira_get_issue.
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 its usage context: use when you need to add a comment to a Jira issue. However, it does not explicitly state when to use it versus alternatives or provide any exclusions. There are no sibling tools for adding comments, so the usage is fairly clear but not explicitly guided.
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 burden. It discloses important behavioral details: accepted time_spent formats, started defaulting to now, and the special 'daily' behavior. However, it does not mention side effects, return values, or error handling, leaving gaps for a mutation 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?
Three sentences with no fluff. It leads with the core action, then clarifies key parameter formats, then the special daily mode. Every sentence earns its place.
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?
Given the moderate complexity and presence of an output schema (not shown but noted as present), the description covers purpose, formats, and special behavior well. It omits permissions or error cases, but for a single-worklog editor, the provided context is sufficient for selection and basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds valuable semantics beyond the schema: concrete examples for time_spent ('2:40', '1h 30m'), explicit 'empty = now' for started, and the special issue_key='daily' meaning. This genuinely helps the agent invoke correctly.
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?
Description opens with a specific verb+resource: 'Logs one worklog.' It clearly distinguishes from sibling jira_log_work_batch by emphasizing 'one', and also describes a special mode for issue_key='daily'. The purpose is unambiguous.
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 implicitly differentiates from jira_log_work_batch by saying 'one worklog', and explains when to use the daily bucket. However, it does not explicitly state when to use this tool versus the batch sibling, so some inference is required.
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 full burden. It states the core behavior (checks auth) and adds the nuance that identity is returned only 'when available.' However, it does not disclose what happens on failure (e.g., error behavior) or the exact nature of the return value beyond identity, leaving some uncertainty.
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, front-loaded sentence with no filler words. It conveys exactly what the tool does without waste, perfectly sized for such a simple operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters, an output schema, and a simple one-sentence description, the tool is fully contextualized. There is no missing information that would prevent an agent from selecting and invoking it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, so the schema is trivially complete. The baseline for no parameters is 4, and the description adds no parameter-specific meaning because none exist. This is appropriate.
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?
Description uses a specific verb ('Checks') with a specific resource (Jira authentication) and states the output (returns identity). This clearly distinguishes it from sibling tools focused on searching issues, comments, and worklogs.
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 clearly indicates the tool's purpose as verifying authentication, which implies when to use it (before authenticated operations). It does not explicitly mention when not to use it or name alternatives, but no alternatives exist among siblings, so the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behaviors: skipping duplicates by default and returning them for confirmation, plus the 'daily' bucket mapping. It doesn't state whether it's a mutating operation, but 'Logs' clearly implies a write, and the disclosure of duplicate skipping is valuable context.
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 concise (three sentences) and front-loads the core purpose. Each sentence adds necessary detail: purpose, entry format with optional fields, special 'daily' handling, and default duplicate behavior. No wasted words.
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?
An output schema exists, so return format need not be explained. The description covers the main operational aspects: batching, duplicate handling, special bucket, and per-row reporting. It doesn't discuss edge cases like partial failures, but the provided details are adequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters well (100% coverage), but the description adds meaning beyond the schema by explaining the default skip behavior and the 'daily' sentinel for issue_key. This extra detail helps the agent understand the exact semantics of entries and skip_duplicates.
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 clearly states 'Logs multiple worklogs' with a specific verb and resource, and distinguishes itself from the sibling jira_log_work by emphasizing batch operation. The special 'daily' bucket behavior further clarifies its unique 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 implies use for multiple worklogs and explains the 'daily' special case, providing clear context. It doesn't explicitly contrast with jira_log_work, but the batch vs single distinction is implicit and sufficient for an agent to select appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
In the absence of annotations, the description discloses key behavioral details: the default behavior with no args, that query becomes a text search, and that jql overrides query. It does not mention authentication or rate limits, but for a search tool these are less critical and the output schema covers return structure.
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 short sentences, front-loaded with the core purpose, no redundancy. Every sentence adds meaningful information about the tool's behavior.
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?
The description covers the tool's main modes and dependencies, and with an output schema present, the absence of return-value details is acceptable. It lacks context on max_results default and pagination, but these are in the schema and not essential for tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all three parameters with descriptions, meeting the 100% coverage baseline. The description adds the default 'no args' behavior (current user's open issues), which is not in the schema, and the priority relationship is reinforced.
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 states a specific verb ('Finds') and resource ('Jira issues'), and clarifies three invocation modes (no args, query, jql). This distinguishes it from sibling jira_get_issue, which retrieves a single issue.
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 clearly explains the meaning of no arguments, the query parameter, and the jql parameter, including precedence. However, it does not explicitly mention when to prefer this over jira_get_issue or other siblings, leaving some ambiguity for an agent deciding between search and direct issue retrieval.
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:

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

Score Badge

Copy to your README.md:

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

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/luizeduul/mcp-worklog-reg'

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