Which integrations are available for this server?

Allows logging work on GitHub issues and pull requests, plus task search and comments. Allows logging and checking worklogs on Jira Cloud issues, including searching tasks, adding comments, and logging work time. Allows logging and checking worklogs on Redmine issues, including task search, comments, and time entries.

How do I use jira-worklog-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@jira-worklog-mcp log 2 hours on PROJ-123" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

jira-worklog-mcp

by luizeduul

Overview Schema Related Servers Score Discussions

Python

Local

worklog-mcp

English documentation comes first because GitHub commonly presents repository content in English. A Portuguese version is available below.

English

worklog-mcp is an MCP (Model Context Protocol) server for logging and checking worklogs from multiple task management providers (Jira Cloud, Redmine, GitHub, Artia) using AI agents such as Claude Code, Claude Desktop, Cursor, or any MCP client that supports stdio.

The main workflow is simple: paste time-sheet rows into your agent, review the preview, and let the agent call this server to log each work item in the right issue on your preferred provider.

How It Works

MCP client -> stdio JSON-RPC -> worklog-mcp -> HTTPS -> Task Provider API
                                              (Jira Cloud, Redmine, GitHub, Artia)

Transport: local stdio. No HTTP server and no open port.
Providers: select your task management system via WORK_PROVIDER env variable (default: jira).
Auth: provider-specific credentials from environment variables or .env.
Config: loaded from .env (optional) or from the MCP client environment.
Layers: client modules (src/jira_client.py, src/redmine_client.py, etc.) handle provider-specific API calls; src/providers/ adapts them behind a common TaskProvider interface; src/tools/ exposes FastMCP tools; src/server.py wires them together. The root server.py is a thin launcher.

Tools

This server exposes exactly seven tools. Availability and behavior depend on the selected provider and its capabilities. By design, all tools are read/append only (least privilege) — no ability to create, edit, transition, assign, or delete issues, comments, or worklogs.

Tool	Purpose	Notes
`whoami`	Validates authentication and returns the current identity when the provider allows it.	Available on all providers.
`search_tasks`	Searches tasks. No args returns your open/assigned tasks; `query` does text search; `native_query` runs provider-specific syntax (JQL for Jira, etc.).	Available on all providers.
`get_task`	Returns a compact view of one task (key, summary, status, type, assignee, priority, labels, description text).	Available on all providers.
`add_comment`	Adds a comment to a task. Plain text is converted to provider-specific format (ADF for Jira, markdown for GitHub, etc.).	Depends on provider capabilities.
`log_work`	Logs one worklog. `time_spent` accepts `2:40` or `1h 30m`. Provider-specific extras like `issue_key="daily"` (Jira) may apply.	Depends on provider capabilities.
`log_work_batch`	Logs multiple worklogs in one call. Skips entries already logged at the same date/time and returns them for confirmation.	Depends on provider capabilities.
`get_worklogs`	Lists worklogs from a task. `mine_only` filters your entries when identity is available.	Depends on provider capabilities.

Requirements

uv, recommended for Python and dependency management.
An account on your chosen provider (Jira Cloud, Redmine, GitHub, or Artia) with permission to log work on target tasks.
API token or credentials for your provider (varies by provider).

Install uv on Windows:

powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

Supported Providers

Jira Cloud (jira): Log work on Jira issues. Supports daily bucket feature via JQL template.
Redmine (redmine): Log work on Redmine issues.
GitHub (github): Log work on GitHub issues and pull requests.
Artia (artia): Log work on Artia tasks.

Installation

git clone https://github.com/luizeduul/mcp-worklog-reg.git
cd worklog-mcp
cp .env.example .env
uv sync

Edit .env with credentials for your selected provider.

Do not commit .env. It is already ignored by .gitignore.

Provider-Specific Setup

Jira Cloud

Create a Jira API token at: https://id.atlassian.com/manage-profile/security/api-tokens
Store the token in JIRA_API_TOKEN env variable or .env file.
Set WORK_PROVIDER=jira and configure JIRA_BASE_URL, JIRA_EMAIL.

Redmine

Log in to Redmine and go to your Account settings.
Generate or copy your API key from the right sidebar.
Store in REDMINE_API_KEY and configure REDMINE_URL.
Set WORK_PROVIDER=redmine.

GitHub

Create a personal access token at: https://github.com/settings/tokens
Grant permissions: repo, user scopes.
Store in GITHUB_TOKEN env variable.
Set WORK_PROVIDER=github.

Artia

Generate integration keys in Artia (ClientId + Secret).
Store in ARTIA_CLIENT_ID and ARTIA_SECRET.
Configure ARTIA_API_URL (optional; default is https://api.artia.com/graphql).
Set ARTIA_ACCOUNT_ID (required) and optionally ARTIA_FOLDER_ID.
Set WORK_PROVIDER=artia.

Local Test

Start the server directly:

uv run server.py

For a quick auth check on the active provider:

uv run python -c "from src.services.provider_registry import registry; print(registry.get().whoami())"

To test a different provider, set WORK_PROVIDER:

$env:WORK_PROVIDER = "redmine"
uv run python -c "from src.services.provider_registry import registry; print(registry.get().whoami())"

MCP Client Registration

Keep machine-specific paths outside Git. Define them as environment variables in your shell, OS profile, or MCP client environment:

$env:UV_PATH = "C:/path/to/uv.exe"
$env:MCP_PROJECT_DIR = "C:/path/to/worklog-mcp"
$env:WORK_PROVIDER = "jira"  # or redmine, github, artia

Example: Register with Jira provider via Claude Code

claude mcp add worklog --scope user `
  -e WORK_PROVIDER=jira `
  -e JIRA_BASE_URL=https://your-company.atlassian.net `
  -e JIRA_EMAIL=you@example.com `
  -e JIRA_API_TOKEN=your-token `
  -- $env:UV_PATH --directory $env:MCP_PROJECT_DIR run server.py

Example: Register with Redmine provider

claude mcp add worklog --scope user `
  -e WORK_PROVIDER=redmine `
  -e REDMINE_URL=https://redmine.example.com `
  -e REDMINE_API_KEY=your-key `
  -- $env:UV_PATH --directory $env:MCP_PROJECT_DIR run server.py

Claude Desktop, Cursor, or another stdio MCP client configuration

Create or edit %APPDATA%\Claude\claude_desktop_config.json (on Windows):

{
  "mcpServers": {
    "worklog": {
      "command": "powershell",
      "args": [
        "-NoProfile",
        "-ExecutionPolicy",
        "Bypass",
        "-Command",
        "& $env:UV_PATH --directory $env:MCP_PROJECT_DIR run server.py"
      ],
      "env": {
        "WORK_PROVIDER": "jira",
        "JIRA_BASE_URL": "https://your-company.atlassian.net",
        "JIRA_EMAIL": "you@example.com",
        "JIRA_API_TOKEN": "your-token"
      }
    }
  }
}

Alternatively, use .env file in the repository root instead of passing credentials via environment.

Time-Sheet Workflow

The agent translates your pasted time-sheet block into tool calls. The server only exposes the primitives.

Use the reference date you provide. If none is provided, the agent should ask.
Classify each row:
- Starts with a task key like PROJ-123: log work to that task.
- Has no task key: find it first with search_tasks, or skip it and report it in the preview.
Show a preview with task key, duration, start time, and comment.
After confirmation, call log_work_batch. Entries that already have a worklog at the same date/time are skipped and returned under skipped_duplicates; decide per entry whether to log them anyway with log_work.

Note: Provider-specific features like Jira's issue_key="daily" are handled automatically by the server.

Environment Variables

Provider Selection

Variable	Default	Description
`WORK_PROVIDER`	`jira`	Active provider: `jira`, `redmine`, `github`, or `artia`.

Jira Cloud (when `WORK_PROVIDER=jira`)

Variable	Required	Description
`JIRA_BASE_URL`	yes	Jira Cloud URL, must be HTTPS and a `*.atlassian.net` host, for example `https://your-company.atlassian.net`.
`JIRA_EMAIL`	yes	Atlassian account email.
`JIRA_API_TOKEN`	yes	Jira API token.
`JIRA_DAILY_JQL`	no	JQL that resolves `issue_key="daily"` to a recurring monthly bucket issue. Use `{month}` (Portuguese month name) and `{year}`, filled from the worklog date, e.g. `project = MYPROJ AND summary ~ "Timesheet {month} de {year}" ORDER BY created DESC`. Unset disables the feature.

Redmine (when `WORK_PROVIDER=redmine`)

Variable	Required	Description
`REDMINE_URL`	yes	Redmine base URL, e.g. `https://redmine.example.com`.
`REDMINE_API_KEY`	yes	Redmine API key.

GitHub (when `WORK_PROVIDER=github`)

Variable	Required	Description
`GITHUB_TOKEN`	yes	GitHub personal access token (PAT).

Artia (when `WORK_PROVIDER=artia`)

Variable	Required	Description
`ARTIA_API_URL`	no	Artia GraphQL URL. Default: `https://api.artia.com/graphql`.
`ARTIA_CLIENT_ID`	yes	Artia integration ClientId.
`ARTIA_SECRET`	yes	Artia integration Secret.
`ARTIA_ACCOUNT_ID`	yes	Account/workspace id used for get_task/worklogs.
`ARTIA_FOLDER_ID`	no	Default folder id for `search_tasks`.
`ARTIA_WORKLOG_STATUS_ID`	no	Optional status id sent when creating a time entry.

The required variables for your chosen provider are read from .env (optional) or from the MCP client environment. No .env file is required.

Security

Least privilege: the server is read/append only. It cannot create, edit, transition, assign, or delete tasks, comments, or worklogs. No tool maps to a destructive endpoint.
Provider URLs validated: Only HTTPS URLs are accepted. Provider URLs (Jira, Redmine, etc.) are validated for correctness.
Credentials not stored in code: They come from environment variables; .env is optional and ignored by Git.
One shared, pooled HTTP client with fixed timeout and connection limits per provider instance.
Local machine paths should stay in environment variables such as UV_PATH and MCP_PROJECT_DIR.
Local stdio transport: the server does not open an inbound network port.

Development

uv run pytest -q

Tests use respx to mock HTTP calls to various providers. They do not call real provider APIs.

Project layout:

worklog-mcp/
  pyproject.toml
  .env.example
  server.py                      # thin launcher -> src/server.py
  src/
    server.py                    # FastMCP app, registers tools
    config.py                    # loads .env, selects provider
    jira_client.py               # Jira REST v3 HTTP client
    redmine_client.py            # Redmine API client
    github_client.py             # GitHub REST API client
    artia_client.py              # Artia API client
    utils.py
    models/                      # Task, Comment, Worklog, ProviderCapabilities
    providers/
      base.py                    # TaskProvider protocol and BaseProvider
      jira_provider.py           # Jira Cloud provider
      redmine_provider.py        # Redmine provider
      github_provider.py         # GitHub provider
      artia_provider.py          # Artia provider
    services/
      provider_registry.py       # lazily-built provider instances
    tools/                       # one module per MCP tool
  tests/

Architecture

Provider interface (src/providers/base.py): TaskProvider protocol defines the contract. Each provider implements required methods (whoami, search_tasks, get_task) and optional ones gated by capabilities (add_comment, log_work, get_worklogs).
Provider registry (src/services/provider_registry.py): Lazily instantiates and caches provider instances based on WORK_PROVIDER env variable.
Tools (src/tools/): Seven FastMCP tools that call the active provider through the registry.

Troubleshooting

The MCP client shows the server as failed.

Run uv run server.py from the repository and check the error. Common causes are missing environment variables, uv not available to the launcher, or an incorrect MCP_PROJECT_DIR.

Authentication fails with invalid credentials error.

Check that you are using the correct provider and that the credentials are valid:

For Jira: JIRA_BASE_URL, JIRA_EMAIL, JIRA_API_TOKEN.
For Redmine: REDMINE_URL, REDMINE_API_KEY.
For GitHub: GITHUB_TOKEN.
For Artia: ARTIA_CLIENT_ID, ARTIA_SECRET, ARTIA_ACCOUNT_ID.

Generate a new token if needed.

Worklog was created on one provider but I expected another.

Check the WORK_PROVIDER environment variable. Default is jira. Set it explicitly if needed.

A worklog was created but does not appear in the company timesheet.

Your company may use a separate timesheet app (e.g., Tempo Timesheets for Jira, etc.). This server writes native provider worklogs.

Related MCP server: Tempo MCP Server

Português

worklog-mcp é um servidor MCP (Model Context Protocol) para lançar e conferir horas em múltiplos provedores de gestão de tarefas (Jira Cloud, Redmine, GitHub, Artia) a partir de agentes de IA como Claude Code, Claude Desktop, Cursor ou qualquer cliente MCP via stdio.

O fluxo principal é simples: cole as linhas da sua planilha de horas no agente, confira o preview, e deixe o agente chamar este servidor para registrar cada item na ferramenta correta.

Como Funciona

Cliente MCP -> stdio JSON-RPC -> worklog-mcp -> HTTPS -> API do Provedor
                                            (Jira Cloud, Redmine, GitHub, Artia)

Transporte: stdio local. Sem servidor HTTP e sem porta aberta.
Provedores: selecione sua ferramenta via variável WORK_PROVIDER (padrão: jira).
Autenticação: credenciais específicas do provedor de variáveis de ambiente ou .env.
Configuração: vem de variáveis de ambiente, lidas do .env (opcional) ou passadas pelo cliente MCP.
Camadas: módulos de cliente (src/jira_client.py, src/redmine_client.py, etc.) conversam com APIs específicas; src/providers/ adapta para uma interface comum TaskProvider; src/tools/ expõe as tools FastMCP; src/server.py liga tudo. O server.py da raiz é só um launcher.

Tools

Este servidor expõe exatamente sete tools. A disponibilidade e comportamento dependem do provedor selecionado e suas capacidades. Por design, todas as tools são somente leitura/append (menor privilégio) — não conseguem criar, editar, transicionar, atribuir nem apagar tarefas, comentários ou worklogs.

Tool	Finalidade	Notas
`whoami`	Valida a autenticação e retorna a identidade atual quando o provedor permite.	Disponível em todos os provedores.
`search_tasks`	Busca tarefas. Sem args retorna suas abertas/atribuídas; `query` faz busca textual; `native_query` executa sintaxe específica do provedor (JQL para Jira, etc.).	Disponível em todos os provedores.
`get_task`	Retorna uma visão compacta de uma tarefa (chave, resumo, status, tipo, responsável, prioridade, labels, texto da descrição).	Disponível em todos os provedores.
`add_comment`	Adiciona um comentário a uma tarefa. Texto simples é convertido para formato específico do provedor (ADF para Jira, markdown para GitHub, etc.).	Depende das capacidades do provedor.
`log_work`	Lança um worklog. `time_spent` aceita `2:40` ou `1h 30m`. Extras específicos do provedor como `issue_key="daily"` (Jira) podem ser aplicados.	Depende das capacidades do provedor.
`log_work_batch`	Lança vários worklogs em uma chamada. Pula lançamentos já existentes no mesmo dia/horário e os devolve para confirmação.	Depende das capacidades do provedor.
`get_worklogs`	Lista worklogs de uma tarefa. `mine_only` filtra os seus quando a identidade está disponível.	Depende das capacidades do provedor.

Pré-Requisitos

uv, recomendado para gerenciar Python e dependências.
Conta em seu provedor escolhido (Jira Cloud, Redmine, GitHub ou Artia) com permissão para lançar horas nas tarefas.
API token ou credenciais para seu provedor (varia por provedor).

Instale o uv no Windows:

powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

Provedores Suportados

Jira Cloud (jira): Lança horas em issues do Jira. Suporta feature de tarefa-balde diária via template JQL.
Redmine (redmine): Lança horas em issues do Redmine.
GitHub (github): Lança horas em issues e pull requests do GitHub.
Artia (artia): Lança horas em tarefas do Artia.

Instalação

git clone https://github.com/luizeduul/mcp-worklog-reg.git
cd worklog-mcp
cp .env.example .env
uv sync

Edite o .env com as credenciais do provedor selecionado.

Não commite o .env. Ele já está no .gitignore.

Setup Específico Do Provedor

Jira Cloud

Crie um token API do Jira em: https://id.atlassian.com/manage-profile/security/api-tokens
Guarde o token em JIRA_API_TOKEN ou no arquivo .env.
Configure WORK_PROVIDER=jira e defina JIRA_BASE_URL, JIRA_EMAIL.

Redmine

Faça login no Redmine e vá para Configurações da Conta.
Gere ou copie sua chave API da barra lateral direita.
Guarde em REDMINE_API_KEY e configure REDMINE_URL.
Configure WORK_PROVIDER=redmine.

GitHub

Crie um token de acesso pessoal em: https://github.com/settings/tokens
Conceda permissões: escopos repo e user.
Guarde em GITHUB_TOKEN.
Configure WORK_PROVIDER=github.

Artia

Gere chaves de integração no Artia (ClientId + Secret).
Guarde em ARTIA_CLIENT_ID e ARTIA_SECRET.
Configure ARTIA_API_URL (opcional; padrão https://api.artia.com/graphql).
Defina ARTIA_ACCOUNT_ID (obrigatório) e opcionalmente ARTIA_FOLDER_ID.
Configure WORK_PROVIDER=artia.

Teste Local

Suba o servidor diretamente:

uv run server.py

Para testar autenticação rapidamente no provedor ativo:

uv run python -c "from src.services.provider_registry import registry; print(registry.get().whoami())"

Para testar um provedor diferente, configure WORK_PROVIDER:

$env:WORK_PROVIDER = "redmine"
uv run python -c "from src.services.provider_registry import registry; print(registry.get().whoami())"

Registro Em Cliente MCP

Mantenha caminhos específicos da sua máquina fora do Git. Defina-os como variáveis de ambiente no shell, no perfil do sistema ou no ambiente do cliente MCP:

$env:UV_PATH = "C:/caminho/para/uv.exe"
$env:MCP_PROJECT_DIR = "C:/caminho/para/worklog-mcp"
$env:WORK_PROVIDER = "jira"  # ou redmine, github, artia

Exemplo: Registrar com provedor Jira via Claude Code

claude mcp add worklog --scope user `
  -e WORK_PROVIDER=jira `
  -e JIRA_BASE_URL=https://sua-empresa.atlassian.net `
  -e JIRA_EMAIL=voce@example.com `
  -e JIRA_API_TOKEN=seu-token `
  -- $env:UV_PATH --directory $env:MCP_PROJECT_DIR run server.py

Exemplo: Registrar com provedor Redmine

claude mcp add worklog --scope user `
  -e WORK_PROVIDER=redmine `
  -e REDMINE_URL=https://redmine.example.com `
  -e REDMINE_API_KEY=sua-chave `
  -- $env:UV_PATH --directory $env:MCP_PROJECT_DIR run server.py

Claude Desktop, Cursor ou outro cliente MCP via stdio

Edite %APPDATA%\Claude\claude_desktop_config.json (no Windows):

{
  "mcpServers": {
    "worklog": {
      "command": "powershell",
      "args": [
        "-NoProfile",
        "-ExecutionPolicy",
        "Bypass",
        "-Command",
        "& $env:UV_PATH --directory $env:MCP_PROJECT_DIR run server.py"
      ],
      "env": {
        "WORK_PROVIDER": "jira",
        "JIRA_BASE_URL": "https://sua-empresa.atlassian.net",
        "JIRA_EMAIL": "voce@example.com",
        "JIRA_API_TOKEN": "seu-token"
      }
    }
  }
}

Alternativamente, use arquivo .env na raiz do repositório em vez de passar credenciais via ambiente.

Fluxo Da Planilha

O agente traduz o bloco colado da planilha em chamadas de tools. O servidor apenas expõe as primitivas.

Usa a data de referência que você informar. Se não informar, o agente deve perguntar.
Classifica cada linha:
- Começa com chave de tarefa, como PROJ-123: lança na tarefa.
- Não tem chave: acha a tarefa antes com search_tasks, ou pula e mostra no preview.
Mostra preview com tarefa, duração, início e comentário.
Depois da confirmação, chama log_work_batch. Lançamentos já existentes no mesmo dia/horário são pulados e devolvidos em skipped_duplicates; você decide por linha se quer lançar mesmo assim via log_work.

Nota: Recursos específicos do provedor como issue_key="daily" do Jira são manipulados automaticamente pelo servidor.

Variáveis De Ambiente

Seleção De Provedor

Variável	Padrão	Descrição
`WORK_PROVIDER`	`jira`	Provedor ativo: `jira`, `redmine`, `github` ou `artia`.

Jira Cloud (quando `WORK_PROVIDER=jira`)

Variável	Obrigatória	Descrição
`JIRA_BASE_URL`	sim	URL do Jira Cloud, precisa ser HTTPS e um host `*.atlassian.net`, por exemplo `https://sua-empresa.atlassian.net`.
`JIRA_EMAIL`	sim	Email da conta Atlassian.
`JIRA_API_TOKEN`	sim	API token do Jira.
`JIRA_DAILY_JQL`	não	JQL que resolve `issue_key="daily"` para a tarefa-balde mensal. Use `{month}` (nome do mês em PT) e `{year}`, preenchidos pela data do worklog, ex. `project = MYPROJ AND summary ~ "Timesheet {month} de {year}" ORDER BY created DESC`. Vazio desliga o recurso.

Redmine (quando `WORK_PROVIDER=redmine`)

Variável	Obrigatória	Descrição
`REDMINE_URL`	sim	URL base do Redmine, ex. `https://redmine.example.com`.
`REDMINE_API_KEY`	sim	Chave API do Redmine.

GitHub (quando `WORK_PROVIDER=github`)

Variável	Obrigatória	Descrição
`GITHUB_TOKEN`	sim	Token de acesso pessoal (PAT) do GitHub.

Artia (quando `WORK_PROVIDER=artia`)

Variável	Obrigatória	Descrição
`ARTIA_API_URL`	não	URL GraphQL do Artia. Padrão: `https://api.artia.com/graphql`.
`ARTIA_CLIENT_ID`	sim	ClientId da integração Artia.
`ARTIA_SECRET`	sim	Secret da integração Artia.
`ARTIA_ACCOUNT_ID`	sim	ID da conta/workspace usado em get_task/worklogs.
`ARTIA_FOLDER_ID`	não	ID da pasta padrão para `search_tasks`.
`ARTIA_WORKLOG_STATUS_ID`	não	ID de status opcional enviado ao criar apontamento.

As variáveis obrigatórias para seu provedor escolhido são lidas do .env (opcional) ou do ambiente do cliente MCP. Nenhum arquivo .env é obrigatório.

Segurança

Menor privilégio: o servidor é somente leitura/append. Não cria, edita, transiciona, atribui nem apaga tarefas, comentários ou worklogs. Nenhuma tool aponta para um endpoint destrutivo.
URLs dos provedores validadas: Apenas HTTPS. URLs dos provedores (Jira, Redmine, etc.) são validadas.
Credenciais não ficam no código: Vêm de variáveis de ambiente; .env é opcional e ignorado pelo Git.
Um único httpx.Client compartilhado com pool, timeout fixo e limites de conexão por instância de provedor.
Caminhos locais da máquina devem ficar em variáveis como UV_PATH e MCP_PROJECT_DIR.
Transporte stdio local: não abre porta de rede.

Desenvolvimento

uv run pytest -q

Os testes usam respx para mockar chamadas HTTP em vários provedores. Eles não chamam APIs reais.

Estrutura:

worklog-mcp/
  pyproject.toml
  .env.example
  server.py                      # launcher fino -> src/server.py
  src/
    server.py                    # app FastMCP, registra as tools
    config.py                    # carrega .env, seleciona o provedor
    jira_client.py               # cliente HTTP da REST v3 do Jira
    redmine_client.py            # cliente API do Redmine
    github_client.py             # cliente REST API do GitHub
    artia_client.py              # cliente API do Artia
    utils.py
    models/                      # Task, Comment, Worklog, ProviderCapabilities
    providers/
      base.py                    # protocolo TaskProvider e BaseProvider
      jira_provider.py           # provedor Jira Cloud
      redmine_provider.py        # provedor Redmine
      github_provider.py         # provedor GitHub
      artia_provider.py          # provedor Artia
    services/
      provider_registry.py       # instâncias de provedores lazy-loaded
    tools/                       # um módulo por tool MCP
  tests/

Arquitetura

Interface de provedor (src/providers/base.py): protocolo TaskProvider define o contrato. Cada provedor implementa métodos obrigatórios (whoami, search_tasks, get_task) e opcionais controlados por capabilities (add_comment, log_work, get_worklogs).
Registry de provedor (src/services/provider_registry.py): instancia e cacheia preguiçosamente os provedores baseado na variável WORK_PROVIDER.
Tools (src/tools/): Sete tools FastMCP que chamam o provedor ativo através do registry.

Troubleshooting

O cliente MCP mostra o servidor como failed.

Rode uv run server.py no repositório e veja o erro. Causas comuns: variáveis de ambiente ausentes, uv indisponível para o launcher ou MCP_PROJECT_DIR incorreto.

Autenticação falha com erro de credenciais inválidas.

Confira que você está usando o provedor correto e que as credenciais são válidas:

Para Jira: JIRA_BASE_URL, JIRA_EMAIL, JIRA_API_TOKEN.
Para Redmine: REDMINE_URL, REDMINE_API_KEY.
Para GitHub: GITHUB_TOKEN.
Para Artia: ARTIA_CLIENT_ID, ARTIA_SECRET, ARTIA_ACCOUNT_ID.

Gere um token novo se necessário.

Worklog foi lançada em um provedor mas eu esperava outro.

Confira a variável de ambiente WORK_PROVIDER. O padrão é jira. Configure explicitamente se necessário.

A hora foi lançada mas não aparece no timesheet da empresa.

Sua empresa pode usar um app separado (ex. Tempo Timesheets para Jira, etc.). Este servidor grava worklogs nativos do provedor.

Available Tools

7 tools

jira_add_commentA

Adds a comment to an issue. Plain text is converted to Jira ADF.

ParametersJSON Schema

Name	Required	Description	Default
`comment`	Yes	Comment text.
`issue_key`	Yes	Issue key, for example PROJ-123.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.1/5.0

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.

jira_get_issueA

Returns a compact view of one issue: key, summary, status, type, assignee, priority, labels, and description text.

ParametersJSON Schema

Name	Required	Description	Default
`issue_key`	Yes	Issue key, for example PROJ-123.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

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.

jira_get_worklogsA

Lists worklogs from one issue. mine_only filters current user's worklogs.

ParametersJSON Schema

Name	Required	Description	Default
`issue_key`	Yes	Issue key.
`mine_only`	No	Only my worklogs.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

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.

jira_log_workA

Logs one worklog. time_spent accepts 'H:MM' (for example '2:40') or '1h 30m'. started: 'YYYY-MM-DD' or 'YYYY-MM-DD HH:MM' (empty = now). Set issue_key='daily' to log into the configured monthly bucket (JIRA_DAILY_JQL) instead of guessing the key.

ParametersJSON Schema

Name	Required	Description
`comment`	No	Worklog comment.
`started`	No	Start: 'YYYY-MM-DD HH:MM'. Empty = now.
`issue_key`	Yes	Issue key (e.g. PROJ-123), or 'daily' for the monthly bucket.
`time_spent`	Yes	Duration: 'H:MM' or '1h 30m'.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

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.

jira_log_work_batchA

Logs multiple worklogs. entries: list of {issue_key, time_spent, started?, comment?}. issue_key may be 'daily' to log into the configured monthly bucket (JIRA_DAILY_JQL). By default, entries that already have a worklog at the same date/time are skipped and returned for confirmation. Reports each row result.

ParametersJSON Schema

Name	Required	Description	Default
`entries`	Yes	List of {issue_key, time_spent, started?, comment?}. issue_key may be 'daily'.
`skip_duplicates`	No	Skip entries already logged at the same date/time.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

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.

jira_search_issuesA

Finds Jira issues. No args: current user's open issues. 'query': free text. 'jql': raw JQL.

ParametersJSON Schema

Name	Required	Description
`jql`	No	Raw JQL. Takes priority over query.
`query`	No	Free text. Becomes: text ~ "<query>".
`max_results`	No	Maximum returned issues.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

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.

jira_whoamiA

Checks whether Jira authentication works and returns identity when available.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

7 tool updatesv0.1.0Aug 9, 2026
- First observedjira_add_comment
- First observedjira_get_issue
- First observedjira_get_worklogs
- First observedjira_log_work
- First observedjira_log_work_batch
- First observedjira_search_issues
- First observedjira_whoami

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.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.

Maintenance

ActivityStale

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp-serverOAuth
io.klokin
MCP server exposing klokin time-tracking operations (employees, time entries, stores) to AI clients.
Workplace & Productivity Project Management
2
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
server B
io.cycloid.mcp
An MCP server that let you interact with Cycloid.io Internal Development Portal and Platform
Developer Tools CI/CD & DevOps Cloud Platforms
62

Related MCP Servers

mcp-jira-stdio
Developer Tools Project Management
freema
A
license
A
quality
A
maintenance
MCP server for Jira integration with stdio transport. Enables reading, writing, and managing Jira issues and projects directly from Claude Desktop. Supports issue creation, updates, comments, JQL search, and project management.
Updated a month ago (2026-08-10 13:58 UTC)
23
587
14
MIT
Tempo MCP Server
Project Management Workplace & Productivity Developer Tools
ivelin-web
A
license
C
quality
B
maintenance
An MCP server for managing Tempo worklogs in Jira, allowing users to track time, retrieve logs, and perform bulk operations via natural language. It integrates with the Tempo API to support creating, editing, and deleting work entries through MCP-compatible clients like Claude and Cursor.
Updated 2 months ago (2026-07-03 13:54 UTC)
7
1,607
43
MIT
jira-cli-mcp
Project Management Developer Tools
choplin
A
license
Not graded
quality
C
maintenance
MCP server that wraps the jira-cli command-line tool to enable AI assistants to interact with Jira.
Updated a year ago (2025-06-09 01:05 UTC)
29
9
MIT
jira-mcp-server
Project Management Developer Tools
pursuitanand
A
license
Not graded
quality
C
maintenance
A lightweight MCP server that exposes Jira issue operations (get, search, create) as tools for AI clients like Claude.
Updated 2 months ago (2026-07-01 02:05 UTC)
98
ISC

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

worklog-mcp

English

How It Works

Tools

Requirements

Supported Providers

Installation

Provider-Specific Setup

Jira Cloud

Redmine

GitHub

Artia

Local Test

MCP Client Registration

Time-Sheet Workflow

Environment Variables

Provider Selection

Jira Cloud (when WORK_PROVIDER=jira)

Redmine (when WORK_PROVIDER=redmine)

GitHub (when WORK_PROVIDER=github)

Artia (when WORK_PROVIDER=artia)

Security

Development

Architecture

Troubleshooting

Português

Como Funciona

Tools

Pré-Requisitos

Provedores Suportados

Instalação

Setup Específico Do Provedor

Jira Cloud

Redmine

GitHub

Artia

Teste Local

Registro Em Cliente MCP

Fluxo Da Planilha

Variáveis De Ambiente

Seleção De Provedor

Jira Cloud (quando WORK_PROVIDER=jira)

Redmine (quando WORK_PROVIDER=redmine)

GitHub (quando WORK_PROVIDER=github)

Artia (quando WORK_PROVIDER=artia)

Segurança

Desenvolvimento

Arquitetura

Troubleshooting

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Jira Cloud (when `WORK_PROVIDER=jira`)

Redmine (when `WORK_PROVIDER=redmine`)

GitHub (when `WORK_PROVIDER=github`)

Artia (when `WORK_PROVIDER=artia`)

Jira Cloud (quando `WORK_PROVIDER=jira`)

Redmine (quando `WORK_PROVIDER=redmine`)

GitHub (quando `WORK_PROVIDER=github`)

Artia (quando `WORK_PROVIDER=artia`)