This server provides MCP tools to interact with Jira Server/Data Center and Tempo (Timesheets & Planner), authenticated via a personal access token.
Issue Management
Retrieve issues by key, search with JQL, add comments, create issues (epic, task, story, sub-task) with custom fields, and list available issue types per project. Create/comment are write operations and require explicit user confirmation.
Project & Role Discovery
List all visible projects, get a single project by key or ID, and view project roles with their members (users and groups).
User & Group Lookup
List all Jira users, search users by name/username/email, and find groups by name substring.
Worklog Reporting & Logging (Tempo Timesheets)
Retrieve logged hours for a single user, multiple users, or an entire Tempo team over a date range, with optional breakdowns by day, project, issue, or account—and the option to exclude absences.
Log time entries on issues using Jira duration syntax, with optional start time and comment. Write operations require explicit user request.
Tempo Team Management
List all Tempo teams, find a team by name, and get team members along with their roles and membership periods.
Tempo Planner
View planned allocations for a user or group of users over a period, showing which projects and how many hours per day, while respecting working calendars.
Allows interaction with Jira Server/Data Center, providing tools for managing issues (get, search, add comments) and retrieving worklog data from Tempo Timesheets.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@jira-mcp find issue 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.
MCP-сервер для доступа к Jira Server / Data Center (и, опционально, к
Confluence Server / DC) через
atlassian-python-api.
Аутентификация — Personal Access Token (Bearer). Транспорт — stdio.
Python ≥ 3.11 (в разработке используется 3.13)
Related MCP server: MCP Atlassian Node Server
Сервер ставится и запускается прямо из репозитория через uvx — клонировать
исходники и указывать путь до них не нужно. uvx скачает пакет, соберёт его в
изолированном окружении и запустит точку входа:
uvx --from git+https://github.com/nsleader/jira-mcp.git jira-mcpЧтобы зафиксировать версию, можно указать тег или коммит:
uvx --from git+https://github.com/nsleader/jira-mcp.git@v0.1.0 jira-mcpКреды передаются как переменные окружения в конфигурации подключения MCP-сервера
(блок env), а не через .env файл.
Переменная | Обязательна | По умолчанию | Описание |
| да | — | Базовый URL Jira, напр. |
| да | — | Personal Access Token (Bearer) |
| нет |
| Проверка TLS-сертификата |
| нет |
| Таймаут запроса, сек |
| для Confluence | — | Базовый URL Confluence, напр. |
| нет |
| Отдельный PAT Confluence |
| нет | как у Jira | Проверка TLS-сертификата |
| нет | как у Jira | Таймаут запроса, сек |
PAT создаётся в Jira: Profile → Personal Access Tokens; в Confluence — там же
в своём профиле. Confluence — отдельное приложение со своим адресом и, как
правило, своим токеном, поэтому CONFLUENCE_URL из JIRA_URL не выводится.
Без него сервер работает как обычно, а confluence-инструменты возвращают
понятную ошибку о ненастроенном подключении.
Сервер общается по stdio и запускается MCP-клиентом. Для локальной проверки можно задать переменные вручную:
JIRA_URL=https://jira.example.com JIRA_PERSONAL_TOKEN=xxxx \
uvx --from git+https://github.com/nsleader/jira-mcp.git jira-mcpclaude mcp add jira \
-e JIRA_URL=https://jira.example.com \
-e JIRA_PERSONAL_TOKEN=your-personal-access-token \
-- uvx --from git+https://github.com/nsleader/jira-mcp.git jira-mcpЧтобы включить инструменты Confluence, добавьте туда же
-e CONFLUENCE_URL=https://wiki.example.com и (если токен отдельный)
-e CONFLUENCE_PERSONAL_TOKEN=your-confluence-token.
Пошаговая инструкция для чистого Mac и пользователя без опыта разработки —
docs/install-macos-claude-desktop.md.
Короткий вариант — в claude_desktop_config.json:
{
"mcpServers": {
"jira": {
"command": "uvx",
"args": ["--refresh", "--from", "git+https://github.com/nsleader/jira-mcp.git", "jira-mcp"],
"env": {
"JIRA_URL": "https://jira.example.com",
"JIRA_PERSONAL_TOKEN": "your-personal-access-token"
}
}
}
}Claude Desktop запускает MCP-серверы с урезанным PATH, поэтому "command": "uvx"
у многих не находится (spawn uvx ENOENT). В этом случае укажите абсолютный путь,
например /Users/<пользователь>/.local/bin/uvx или /opt/homebrew/bin/uvx.
--refresh заставляет uvx перечитать HEAD репозитория на каждом старте: иначе
сборка берётся из кэша и установка остаётся на том коммите, на котором была
поставлена. Стоит это меньше секунды, но требует доступа к GitHub при запуске.
Инструмент | Описание |
| Получить задачу по ключу ( |
| Поиск задач по JQL |
| Добавить комментарий к задаче |
| Типы задач инстанса или конкретного проекта (что можно передать в |
| Создать эпик / задачу / подзадачу — вызывается строго по явной просьбе пользователя |
| Куда задачу можно перевести из текущего статуса (и какие поля обязательны) |
| Сменить статус задачи — вызывается строго по явной просьбе пользователя |
| Залогировать время на задачу — вызывается строго по явной просьбе пользователя |
| Список всех проектов, видимых пользователю |
| Один проект по ключу или id |
| Роли проекта и их состав (пользователи и группы) — где искать реального РП |
| Поиск пользователей по логину, имени или email (подстрока) |
| Все пользователи Jira — объединение групп, дающих доступ к Jira |
| Найти группы Jira по названию → узнать нужную для |
| Часы одного пользователя за период (Tempo Timesheets) |
| Часы по списку пользователей за период, с разбивкой по каждому |
| Часы всех участников команды Tempo ( |
| Список всех команд Tempo (id, название, лид) |
| Найти команды Tempo по названию (подстрока) → получить |
| Все участники команды Tempo (ключ, имя, роль, период членства) |
| Планы Tempo Planner: на какие проекты и на сколько часов в день запланирован пользователь |
| Планы Tempo Planner по списку пользователей за один запрос, с разбивкой по каждому |
| Поиск страниц Confluence: текст, пространство, метка (CQL под капотом) |
| Прочитать страницу по id / ссылке / |
| Дочерние страницы — обход дерева пространства вниз |
| Список пространств Confluence (ключи для поиска) |
src/jira_mcp/
├── config.py # настройки из окружения (pydantic-settings)
├── client.py # фабрики Jira- и Confluence-клиентов (кеш)
├── identity.py # логин ↔ ключ пользователя: чем ловится «0 часов»
├── server.py # FastMCP + main()
└── tools/
├── issues.py # инструменты по задачам + create_issue, transition_issue
├── projects.py # проекты и роли проекта (get_project_roles)
├── worklogs.py # отчёты по времени (Tempo Timesheets) + add_worklog
├── tempo.py # Tempo Planner: планирование (get_user_plan)
└── confluence.py # поиск и чтение статей Confluenceget_issue и search_issues отдают ответ Jira как есть, с одной правкой:
customfield_* получают человеческие имена, а пустые выбрасываются. Jira
возвращает каждое кастомное поле, заведённое на инстансе, — на одной задаче это
под сотню записей customfield_11704: null, среди которых пара заполненных
ничем не отличается от остального.
Читающему модель это ломает: она видит description: null и отвечает, что
описания нет, — а текст лежит в «Описании пресейла». Поэтому
"Описание пресейла (customfield_12001)": "{*}Контекст сделки{*}: ..."Id остаётся в ключе: писать в поля всё равно приходится по id — extra_fields
у create_issue, экраны переходов у transition_issue. Каталог полей читается
раз на сессию, тем же запросом, которым ищутся agile-поля.
create_issue создаёт issue через rest/api/2/issue от имени владельца токена.
Иерархия Jira Server/DC не лежит в обычных полях, поэтому сервер сам разбирается
с agile-полями Greenhopper (их id различаются от инстанса к инстансу и находятся
по типу схемы в rest/api/2/field):
issue_type="Epic" → в обязательное поле Epic Name пишется epic_name,
а если он не задан — summary
обычный тип + parent="PROJ-1" → ключ эпика пишется в Epic Link
подзадача (subtask: true) + parent="PROJ-2" → поле parent; без parent
вызов отклоняется до похода в Jira
Тип задачи резолвится по имени (регистронезависимо) или id заранее: если такого
типа нет, ошибка перечисляет доступные, а не возвращает голый HTTP 400. Имена
типов на инстансах переименовывают и локализуют — при сомнениях сначала
get_issue_types(project_key).
Остальные поля — description, assignee (логин Server/DC), priority,
labels, components, due_date; всё, что не покрыто сигнатурой (story points,
обязательные кастомные поля), передаётся через extra_fields, например
{"customfield_10004": 3}.
Как и add_worklog, инструмент пишущий и в описании помечен как вызываемый
строго по просьбе пользователя: удалить созданную задачу сервер не умеет.
Статус в Jira Server/DC нельзя присвоить напрямую — он результат перехода
workflow, а набор переходов зависит от текущего статуса, схемы проекта и прав
владельца токена. Поэтому transition_issue сначала читает
rest/api/2/issue/{key}/transitions, а потом постит найденный переход.
target — имя целевого статуса (Ready For Test), имя перехода
(Start Progress) или числовой id перехода; сравнение регистронезависимое,
приоритет у целевого статуса (кнопка и её результат в workflow нередко
называются по-разному)
если такого перехода нет, ошибка перечисляет доступные из текущего статуса — вместо голого HTTP 400
задача уже в нужном статусе → changed: false, без запроса на запись
comment уходит в update (добавление комментария в рамках перехода),
resolution — в поля закрывающего перехода, всё остальное для экранов
перехода передаётся через fields по id поля (см. required_fields в
get_transitions)
Инструмент пишущий и помечен как вызываемый строго по просьбе пользователя: переход виден всей команде (доски, уведомления, автоматизации), а обратного перехода в workflow может не быть.
add_worklog пишет worklog через core-API Jira
(rest/api/2/issue/{key}/worklog) от имени владельца токена; Tempo на Server/DC
читает те же worklog'и, поэтому списанное время видно в отчётах выше.
time_spent — синтаксис Jira: 2h, 90m, 2h 30m, 1d 4h
started — YYYY-MM-DD (привязывается к 09:00 локального времени, чтобы
worklog не уехал на предыдущий день в восточных таймзонах), YYYY-MM-DDTHH:MM
или метка времени со смещением; по умолчанию — сейчас
В описании инструмента явно указано, что он вызывается строго по просьбе пользователя: это единственный инструмент, пишущий время, и отменить запись из сервера нельзя.
У человека в Jira два имени: логин (acutina, меняется при смене фамилии)
и ключ (JIRAUSER18613, не меняется никогда). До Jira 6.0 ключ совпадал с
логином, поэтому у старых сотрудников разницы не видно — у всех, кого завели
позже, она есть.
Две части Tempo расходятся в том, какое из имён им нужно:
API | Фильтр | Принимает |
Tempo Timesheets (часы) |
| ключ |
Tempo Planner (планы, календарь) |
| логин |
Ни одна из них не ругается на чужое имя: фильтр просто ни с кем не совпадает, и ответ приходит пустой. Отчёт от этого не ломается — он врёт: «Кутина за неделю залогировала 0 часов» выглядит как факт.
Поэтому инструменты принимают любое из двух имён и приводят его к нужному
сами (identity.py, кеш на время жизни процесса, поиск через rest/api/2/user).
get_user_worklog возвращает разрешённый worker_key, get_user_plan —
login, а by_user в групповых отчётах ключуется ключом и несёт display с
человеческим именем. Имя человека («Кутина») именем пользователя не является —
его сначала ищут через search_users.
get_user_plan читает раздел планирования через rest/tempo-planning/1/allocation
и рабочий календарь пользователя (rest/tempo-core/1/user/schedule), поэтому
разбивка по дням не учитывает выходные и праздники — так же, как сам Tempo.
На Server/DC это плагин Jira: работает тот же JIRA_URL и PAT, отдельный
Tempo-токен не нужен.
Четыре инструмента только на чтение: найти статью и прочитать её.
Поиск. search_confluence собирает CQL из обычных аргументов —
query (полнотекстовый text ~), space, label, content_type — и по
умолчанию сортирует по релевантности; newest_first=true переключает на
«что менялось недавно». Для запросов, которые сигнатурой не выразить
(creator = jsmith AND lastmodified > -7d), есть параметр cql — он идёт на
сервер как есть. Маркеры подсветки совпадений (@@@hl@@@), которые Server
подмешивает в заголовок и excerpt, вычищаются. В ответе total — общее число
совпадений, а не размер выданной страницы результатов.
Чтение. get_confluence_page принимает id, любую ссылку на страницу
(?pageId=123, /pages/123/Title, /display/SPACE/Title) либо пару
space + title. Тело берётся из отрендеренного body.view (макросы уже
раскрыты) и конвертируется в Markdown: заголовки, списки, таблицы и блоки кода
сохраняются, разметка макросов — нет; относительные ссылки достраиваются до
абсолютных. Другие варианты — format="text", "html" и "storage"
(исходный XHTML, нужен только чтобы где-то отредактировать страницу).
Длинные статьи режутся по max_chars (по умолчанию 20000), чтобы не забивать
контекст: в ответе есть content_chars, truncated и next_offset —
следующий кусок читается тем же инструментом с offset.
Рядом с текстом возвращается контекст статьи: пространство, версия, кто и когда
менял, метки и хлебные крошки ancestors. Вниз по дереву —
get_confluence_page_children; ключи пространств — get_confluence_spaces
(персональные ~user скрыты, если не попросить include_personal).
uv run ruff check
uv run pytestAdd a comment to a Jira issue.
Args:
issue_key: The issue key, e.g. PROJ-123.
comment: The comment body (plain text / Jira wiki markup).
| Name | Required | Description | Default |
|---|---|---|---|
| comment | Yes | ||
| issue_key | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the basic action without mentioning permissions, whether the comment is appended or replaces, or any side effects. The output schema existence is not leveraged to describe return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences plus an Args section). However, the Args section uses non-standard formatting (adapted from docstring) rather than a clean prose description. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 covers parameter semantics but omits behavioral details like whether the comment is added to the issue's existing comments or replaces them, or any authorization requirements. Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema: 'issue_key' is explained with an example ('PROJ-123') and 'comment' is described as 'plain text / Jira wiki markup'. Given 0% schema coverage, this significantly aids understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a comment to a Jira issue' using a specific verb ('Add') and resource ('comment' with target 'Jira issue'). This distinguishes it from siblings like 'create_issue' or 'add_worklog'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as when to add a comment versus update an issue or add a worklog. The description lacks any contextual advice on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Log time on a Jira issue, as the user who owns the API token.
CALL THIS TOOL STRICTLY ON THE USER'S EXPLICIT REQUEST. It is the only tool here that writes: it creates a real worklog under the user's name and cannot be undone from this server. Never call it on your own initiative — not after finishing a task, not to "correct" hours seen in a report, not as a step inferred from some other request. If the user has not asked to log time, ask them first.
Args:
issue_key: The issue to log against, e.g. PROJ-123.
time_spent: Duration in Jira syntax — 2h, 90m, 2h 30m,
1d 4h (w/d/h/m). Jira converts it using the instance's
working day/week, so 1d is usually 8h, not 24h.
started: When the work happened. YYYY-MM-DD (anchored at 09:00
local time), YYYY-MM-DDTHH:MM, or a timestamp with an
offset. Defaults to now — pass the date explicitly when logging
for a past day.
comment: Optional worklog comment (plain text / Jira wiki markup).
Returns the created worklog: id, time_spent, started,
author and a browse link to the issue.
| Name | Required | Description | Default |
|---|---|---|---|
| comment | No | ||
| started | No | ||
| issue_key | Yes | ||
| time_spent | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden: it discloses that the tool creates a real worklog under the user's name, cannot be undone, and is the only write tool—providing essential behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-structured with a critical warning front-loaded, followed by clear arg definitions. Every sentence adds value, though the overall length could be slightly trimmed while retaining clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and the tool's write nature, the description is complete: it covers purpose, usage rules, behavior, all parameters with examples, and mentions return value (even with an output schema). No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description thoroughly explains all parameters: 'issue_key' format, 'time_spent' Jira syntax with examples, 'started' formats and defaults, and 'comment' optionality. This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it logs time on a Jira issue and uniquely identifies itself as the only write tool among siblings, effectively distinguishing it from read-only tools like 'get_user_worklog'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call only on user's explicit request and warns against calling on its own initiative, providing clear when-to-use and when-not-to-use guidance. Siblings are implicitly contrasted as read-only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Jira issue — epic, task, story or sub-task.
CALL THIS TOOL STRICTLY ON THE USER'S EXPLICIT REQUEST. It writes a real issue into the project under the token owner's name and this server cannot delete it afterwards. Never create issues on your own initiative (not to "track" work you are doing, not as an inferred step of another request). When several issues are described at once, confirm the list with the user before creating them.
Args:
project_key: Target project key, e.g. PROJ.
summary: Single-line title of the issue.
issue_type: Type name as it appears in Jira — Task (default),
Epic, Story, Bug, Sub-task… Call
get_issue_types when unsure; names are instance-specific and
may be localised.
description: Body text (plain text / Jira wiki markup).
parent: Key of the parent issue. For a sub-task this is its parent
task (required). For any other type this is the epic it
belongs to — it is written to the Epic Link field.
epic_name: Short board label for an epic. Epics only; defaults to
summary when omitted.
assignee: Username (Server/DC login) to assign the issue to.
priority: Priority name, e.g. Major.
labels: Labels to set.
components: Component names to set.
due_date: Due date, YYYY-MM-DD.
extra_fields: Raw field overrides merged in last, for anything this
signature does not cover — e.g. story points or a required
custom field: {"customfield_10004": 3}.
Returns the created issue: key, id, url and the resolved
type/parent, so the key can be reused directly (e.g. as parent for
the epic's children).
| Name | Required | Description | Default |
|---|---|---|---|
| labels | No | ||
| parent | No | ||
| summary | Yes | ||
| assignee | No | ||
| due_date | No | ||
| priority | No | ||
| epic_name | No | ||
| components | No | ||
| issue_type | No | Task | |
| description | No | ||
| project_key | Yes | ||
| extra_fields | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: it writes a real issue, cannot be deleted, runs under the token owner's name, and returns the created issue's key/id/url. No contradictions with missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with headers and bullet points, front-loading the core purpose and usage guidelines. While slightly verbose, every sentence adds value, earning a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, 2 required, output schema present), the description covers all parameters, usage guidelines, and return values comprehensively, leaving no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full burden. It explains each parameter in detail with examples, defaults, and relationships (e.g., parent for sub-task vs epic), far exceeding what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a Jira issue — epic, task, story or sub-task.' It uses a specific verb and resource, and distinguishes from siblings by listing the supported issue types, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'CALL THIS TOOL STRICTLY ON THE USER'S EXPLICIT REQUEST' and warns against creating issues on its own initiative. It also advises confirming a list of issues with the user, providing clear when-not and usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find Jira groups by name — use it to discover the license group name.
Handy when you don't know which group holds all users. Search e.g.
users to find candidates like jira-users / jira-software-users,
then pass the right one to get_all_users.
Args:
query: Substring to match against group names (default users).
limit: Maximum number of groups to return (default 20).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | users |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 describes a read-only search operation with substring matching, but does not disclose additional behavioral traits such as authentication requirements or side effects. The existence of an output schema covers return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is structured into three paragraphs: purpose, usage example, and parameter list. Information is front-loaded and each sentence adds value. Could be slightly more concise, but overall well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional params, output schema present), the description is complete. It covers purpose, usage context with an example, parameter defaults, and links to a related sibling tool. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clearly explains both parameters: 'query' is a substring match defaulting to 'users', and 'limit' is the max number of groups defaulting to 20. This adds meaningful context beyond the schema's titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Find Jira groups by name' and specifies the use case of discovering the license group name. It distinguishes from siblings like 'get_all_users' by explaining the tool is for finding groups when you don't know which group holds all users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for when to use this tool: 'when you don't know which group holds all users' and suggests passing results to 'get_all_users'. It gives usage examples but does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find Tempo teams whose name contains query (case-insensitive).
Tempo has no server-side team search, so this lists every team and
filters locally. Handy to turn a team name into the teamId that
get_team_worklog needs.
Args:
query: Substring to match against the team name.
expand: Optional comma-separated Tempo expand fields
(e.g. lead,program).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| expand | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses local filtering behavior and case-insensitivity. No annotations provided, so description carries full burden — it reveals the underlying implementation (no server-side search) without contradicting any metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Five lines with clear structure: purpose first, then behavioral context, then usage hint, then parameter details. Every sentence adds value and no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, behavior, parameter semantics, and use case. Could mention handling no results or errors, but given output schema exists and tool is simple, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are described in args: 'query' as substring match to team name, 'expand' as optional comma-separated expand fields with example. Schema had 0% coverage, so description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States 'Find Tempo teams whose name contains query (case-insensitive)' — specific verb, resource, and matching rule. Distinguishes from siblings like get_all_teams (lists all without filtering) and search_users/search_groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains that no server-side search exists, so tool lists all teams and filters locally. Provides a concrete use case: converting team name to teamId for get_team_worklog. Lacks explicit 'when not to use' but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Jira projects visible to the authenticated user.
Args:
include_archived: Include archived projects in the result.
expand: Optional comma-separated list of fields to expand
(e.g. description,lead,url).
| Name | Required | Description | Default |
|---|---|---|---|
| expand | No | ||
| include_archived | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 that results are based on authenticated user visibility and includes parameters for including archived projects and expanding fields. It does not mention pagination or performance, but for a simple listing tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, and uses a bullet list for arguments. Every sentence adds value with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 optional parameters, no nested objects) and the presence of an output schema, the description covers purpose, parameters, and visibility context completely. No return value explanation needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully explains both parameters: 'include_archived' as a boolean for including archived projects, and 'expand' as an optional comma-separated list with examples (description,lead,url). This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all Jira projects visible to the authenticated user,' specifying the verb (List) and resource (all projects). This distinguishes it from siblings like 'get_project' which retrieves a single project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing projects but does not explicitly indicate when to use this tool versus alternatives like 'get_project' or other list tools. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every Tempo team (id, name, lead, …).
Use this to discover a team's numeric teamId for
get_team_worklog. To look one up by name, prefer find_team.
Args:
expand: Optional comma-separated Tempo expand fields
(e.g. lead,program).
| Name | Required | Description | Default |
|---|---|---|---|
| expand | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the action and parameter but does not disclose permissions, pagination, or limits; however, being read-only is implied, and the expand parameter is explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise with front-loaded main purpose, then usage note, then parameter definition. Every sentence adds value with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values need not be detailed. The description covers purpose, usage, and parameter adequately, but lacks mention of authentication or potential limitations given no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage with no descriptions. The description adds meaning by explaining expand as optional comma-separated expand fields with examples, exceeding baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List every Tempo team' with specific fields (id, name, lead) and explicitly differentiates from sibling find_team, providing strong purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (discover teamId for get_team_worklog) and when to prefer alternative (find_team for name lookup), offering clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Jira users (union of the groups that grant Jira access).
Jira Server/DC has no single "all users" endpoint — users are enumerated
through group membership. By default this reads every group that grants
Jira Software access on this instance and de-duplicates the members.
Pass groups to target specific group(s) instead.
Args:
groups: Group names to read. Defaults to the instance's Jira Software
license groups.
status: Which users to return by account state — active (default,
enabled users only), inactive (deactivated / blocked / former
employees, active=false), or all.
| Name | Required | Description | Default |
|---|---|---|---|
| groups | No | ||
| status | No | active |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the de-duplication process, default groups for Jira Server/DC limitations, and status filtering. It does not cover performance or permission requirements, but it is still substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening sentence and bulleted args. It is slightly verbose but each sentence adds value. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two simple parameters and an output schema is available, the description sufficiently covers the tool's behavior. It explains the unique need for the tool in Jira Server/DC environments.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description fully covers both parameters: `groups` defaults to license groups, and `status` defaults to 'active' with clear definitions for values 'active', 'inactive', and 'all'. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List all Jira users' and explains the unique mechanism of enumerating group memberships for Jira Server/DC, clearly distinguishing the tool's purpose from sibling tools like search_users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It describes when to use the default behavior (union of Jira Software license groups) and how to target specific groups via the `groups` parameter. However, it does not explicitly state when not to use this tool or point to alternatives like search_users for name-based searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single Jira issue by key (e.g. PROJ-123).
Args:
issue_key: The issue key, e.g. PROJ-123.
fields: Optional comma-separated list of fields to return
(e.g. summary,status,assignee). Defaults to all fields.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | ||
| issue_key | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. 'Get' implies a read-only operation without side effects, but it does not explicitly state that it requires read permissions, is safe, or that no modifications occur. Lacks disclosure of rate limits or auth needs beyond typical Jira API expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with a clear structure: purpose statement followed by parameter documentation. No fluff, example provided, and critical information is front-loaded. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with two parameters and an output schema, the description is complete. It covers input details and scope. Output behavior is handled by the existing output schema, so no need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, description compensates fully. It explains issue_key format with a concrete example and clarifies the fields parameter as an optional comma-separated list defaulting to all fields, adding significant meaning beyond bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get a single Jira issue by key', specifying verb, resource, and method. Example with key format (PROJ-123) reinforces exact usage. Distinguishes from siblings like search_issues (multiple issues) and create_issue (creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when you have a specific issue key, but does not explicitly contrast with alternatives like search_issues for batch retrieval or get_project for project details. No when-not-to-use guidance, though the narrow scope is inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the issue types available for create_issue.
Call this first when unsure what issue_type a project accepts —
instances rename and translate types (Task/Задача, Story,
Sub-task), so guessing produces a 400.
Args: project_key: Optional project key to restrict to the types actually enabled in that project's scheme. Without it, every type on the instance is returned.
| Name | Required | Description | Default |
|---|---|---|---|
| project_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses that types can be renamed/translated and that omitting project_key returns all types. Indicates read-only behavior and error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a clear intro, usage guidance, and an Args section. Every sentence provides essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the tool is simple (1 parameter), the description covers purpose, usage, and parameter semantics completely. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% but description provides detailed meaning for the project_key parameter, explaining its purpose and effect. Adds significant value beyond schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists issue types for create_issue, with specific verb and resource. It distinguishes itself from sibling tools by focusing on issue types, not projects or users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to call this first when unsure about issue_type to avoid 400 errors. Explains when to use the optional project_key parameter and the consequence of omitting it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single Jira project by its key or id.
Args:
project_key: The project key or id, e.g. PROJ or 10001.
expand: Optional comma-separated list of fields to expand
(e.g. description,lead,url).
| Name | Required | Description | Default |
|---|---|---|---|
| expand | No | ||
| project_key | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It only states that it gets a project, with no mention of permissions, rate limits, error handling, or read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences for purpose and a clear list for parameters. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose and parameters well. Missing details on error handling (e.g., project not found) and permission requirements, but output schema handles return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant meaning beyond schema: explains project_key accepts key or id with examples, and expand is a comma-separated list with examples. Schema coverage 0%, so description carries full parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves a single Jira project by key or id. Distinguishes from sibling 'get_all_projects' which lists all projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Implies use for one project but does not say when not to use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all members of a Tempo team.
Reads rest/tempo-teams/2/team/{team_id}/member/. Each member's
key is the same value the Tempo worklog worker field carries — so
it's what you pass on to per-user worklog tools. Note this is the Tempo
team roster, not a Jira user group (see get_all_users for groups).
Args:
team_id: Tempo team id (e.g. 79).
raw: Return Tempo's untouched membership objects instead of the
flattened key / display_name / role / membership-window
shape. Use when you need fields not surfaced by default.
| Name | Required | Description | Default |
|---|---|---|---|
| raw | No | ||
| team_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description carries burden. Discloses default flattened output shape and raw parameter effect. Mentions key is same as worker field. Does not address pagination or idempotence, but for a read-only list tool, the provided details are sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with clear sections. Includes URL, parameter explanations, and usage notes. Could be slightly more concise (e.g., floating the URL), but overall efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return value details are not needed. Description covers default vs raw output and key mapping. Given sibling tools context, it provides enough information. Could mention pagination, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description fully compensates. Explains team_id with data type and example (79). Explains raw parameter with its purpose and when to use it ('when you need fields not surfaced by default'). Adds meaning beyond raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List all members of a Tempo team' with specific verb and resource. Distinguishes from 'get_all_users' by noting Tempo team vs Jira user group. References exact API endpoint: rest/tempo-teams/2/team/{team_id}/member/.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use this tool ('List all members of a Tempo team') and when not ('not a Jira user group'), with alternative tool named ('see get_all_users for groups'). Additionally explains that the output 'key' field is used in per-user worklog tools, providing integration guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hours every member of a Tempo team logged in a date range, per worker.
Reproduces Tempo's "Logged Time" report grouped by worker (the
Tempo.jspa#/reports/logged-time?teamId=…&groupBy=worker view): one
worklog search filtered by teamId covers the whole team for
[date_from, date_to] (both inclusive). The team roster is fetched
separately so members who logged nothing still appear with 0 hours.
Args:
team_id: Tempo team id (the teamId from the report URL, e.g. 79).
date_from: Start date, inclusive, YYYY-MM-DD.
date_to: End date, inclusive, YYYY-MM-DD.
include_subtasks: Include worklogs on subtasks (the report's
includeSubtasks toggle). Defaults to Tempo's own default.
breakdown: Optional per-worker grouping — day, project,
issue, both (=project+issue), all, or a comma combo
like day,project. Each requested dimension appears as
by_day / by_project / by_issue inside every worker's
entry (e.g. day → hours-per-day per worker, the whole
timesheet matrix, in ONE call — never call this once per user).
only_active: Keep only current employees on an open team membership
(default). Set False to include people who left the company or
moved off the team — a team's roster accumulates them for years,
so the default keeps the report to the people working now.
exclude_absence: Drop vacation / sick-leave worklogs, which Tempo
logs against a dedicated Absence account. Off by default so
totals match Tempo's own report; turn it on to read the numbers
as actual workload — otherwise a week of vacation looks
identical to a week of work (8h/day either way).
| Name | Required | Description | Default |
|---|---|---|---|
| date_to | Yes | ||
| team_id | Yes | ||
| breakdown | No | ||
| date_from | Yes | ||
| only_active | No | ||
| exclude_absence | No | ||
| include_subtasks | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully discloses behavior: output includes per-worker entries with optional breakdowns (day, project, etc.), members with zero hours appear, and effects of include_subtasks, only_active, and exclude_absence parameters are detailed. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with an Args section and parameter descriptions. Front-loaded purpose. Slightly verbose but every sentence adds value; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters (all explained), output schema exists (so return format not needed), and annotations absent, the description covers all necessary context: usage, behavior, parameter semantics, and edge cases (zero-hour members, absence handling). Complete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description compensates thoroughly: explains team_id source, date format and inclusivity, breakdown options and their output structure, only_active rationale (team roster accumulation), and exclude_absence impact (vacation vs work). Adds significant meaning beyond bare schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the exact resource (Tempo team worklog), action (get hours per member), and scope (date range, per worker). It distinguishes from siblings like get_user_worklog and get_users_worklog by focusing on team-level aggregation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states this tool covers the whole team in one call, recommending against per-user calls. Provides context by referencing the Tempo report and explaining how the team roster is handled. Implicitly suggests alternatives by contrasting with single-user tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What a user is planned for in Tempo Planner over a date range.
Answers "which projects is this person allocated to, for how many hours
per day": fetches the user's plan allocations and expands them into
planned hours within [date_from, date_to] (both inclusive), using
the user's Tempo working-day calendar so weekends and public holidays
are excluded exactly as Tempo itself does.
Args:
username: Jira username / login (Tempo assignee key).
date_from: Start date, inclusive, YYYY-MM-DD.
date_to: End date, inclusive, YYYY-MM-DD.
breakdown: Pass day to add by_day — planned hours for each
date in the range, split by project inside each day. Omit for
the compact view (plans + per-project totals only).
Returns plans (each allocation with its hours_per_day, period
and target project/issue), by_project totals for the range, and
optionally by_day.
| Name | Required | Description | Default |
|---|---|---|---|
| date_to | Yes | ||
| username | Yes | ||
| breakdown | No | ||
| date_from | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses important behavioral traits: the date range is inclusive, weekends and holidays are excluded using Tempo's calendar, and the breakdown parameter controls output detail. It does not mention read-only nature or authentication, but the core behavior is well-explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an introductory sentence, a bullet list for arguments, and a note on return structure. It is efficient but slightly longer than necessary; however, every sentence adds value. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (date range, calendar, breakdown), the description covers all functional aspects. An output schema exists, and the description provides a high-level overview of return fields (plans, by_project, optionally by_day). No obvious gaps for an agent to misuse the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate fully. It provides detailed semantics for all four parameters: username (Jira login), date_from and date_to (inclusive YYYY-MM-DD format), and breakdown (pass 'day' for daily breakdown). This adds essential meaning beyond the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a user's plan allocations over a date range, answering a specific question. It distinguishes from the sibling tool 'get_users_plan' by focusing on a single user, and the verb 'get' combined with the resource 'user_plan' is precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly explains when to use the tool (to retrieve a user's planned hours for projects within a range) but does not explicitly mention when not to use it or when alternatives like 'get_users_plan' might be better. Usage context is clear but lacks exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What a group of users is planned for in Tempo Planner, per user.
One allocation request covers every user in usernames for
[date_from, date_to] (both inclusive) — never call this once per
user. Each user's plans are then expanded against their own
working-day calendar (calendars differ: part-time, regional holidays),
so weekends and public holidays are excluded exactly as Tempo does.
Args:
usernames: Jira usernames / logins (Tempo assignee keys).
date_from: Start date, inclusive, YYYY-MM-DD.
date_to: End date, inclusive, YYYY-MM-DD.
breakdown: Pass day to add by_day inside every user's
entry — planned hours for each date, split by project within
each day. Omit for the compact view.
Returns by_user (each user's plans, by_project totals and
optionally by_day, users sorted by planned hours desc; users with
no plans appear with 0) and cross-user by_project totals.
| Name | Required | Description | Default |
|---|---|---|---|
| date_to | Yes | ||
| breakdown | No | ||
| date_from | Yes | ||
| usernames | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 explains calendar expansion per user, exclusion of weekends and holidays, and the effect of the breakdown parameter. It also describes the return structure including sorting and zero-plans handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It starts with the purpose, then a critical usage note, followed by parameter details in a list format. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, 0% schema coverage, no annotations, and an existing output schema, the description provides complete context. It explains parameters, behavior, and return structure (by_user and by_project totals). The output schema may cover return values, but the description adds clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. It explains usernames as Jira logins, date format as YYYY-MM-DD inclusive, breakdown as 'day' for detailed output, and the return structure. This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves planned allocations for a group of users in Tempo Planner, per user. It uses specific verbs ('get') and resource ('users plan'), and the context of sibling tools (e.g., get_user_plan for a single user) helps distinguish it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises against calling per user: 'never call this once per user'. It explains that a single request covers all users in usernames for a date range. It could be improved by mentioning when to use the single-user alternative, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Total hours a group of users logged in a date range, per user.
Uses the Tempo Timesheets API: one search covers every user in
usernames for [date_from, date_to] (both inclusive) — a single
request, regardless of team size or breakdown. by_user always lists
each worker's total; breakdown nests that worker's own day/project/
issue split inside their entry (still one request — never call this once
per user).
Args:
usernames: Tempo workers (Jira usernames / keys).
date_from: Start date, inclusive, YYYY-MM-DD.
date_to: End date, inclusive, YYYY-MM-DD.
project: Optional project key to restrict to (e.g. PROJ).
breakdown: Optional per-worker grouping — day, project,
issue, both (=project+issue), all, or a comma combo
like day,project. Each requested dimension appears as
by_day / by_project / by_issue inside every user's
entry (e.g. day → hours-per-day per worker in one call).
| Name | Required | Description | Default |
|---|---|---|---|
| date_to | Yes | ||
| project | No | ||
| breakdown | No | ||
| date_from | Yes | ||
| usernames | Yes | ||
| exclude_absence | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden. It explains the single-request behavior, inclusive date range, and breakdown nesting. While it lacks details on authentication, rate limits, or error handling, the core behavioral traits are adequately covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a brief summary, behavioral explanation, and parameter list. Every sentence adds value, and the format is easy to parse. No redundancy or unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no annotations, output schema exists), the description covers most aspects: core function, comparison with siblings, and parameter details. The missing 'exclude_absence' parameter and lack of response structure summary (though output schema exists) prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains 5 of 6 parameters with added context (e.g., breakdown options, date format). However, it omits the 'exclude_absence' parameter, which is present in the schema but undocumented. Despite this gap, the description adds significant meaning beyond the schema's property titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving total hours logged by a group of users within a date range, per user. It distinguishes from siblings like get_user_worklog (singular) and get_team_worklog by emphasizing it handles multiple users in a single request, eliminating ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when to use this tool (e.g., for multiple users) and warns against common misuse (e.g., 'never call this once per user'). It also implicitly suggests alternatives for single users or teams, providing clear context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Total hours a user logged in a date range, optionally broken down.
Uses the Tempo Timesheets API: one search returns all of the user's
worklogs in [date_from, date_to] (both inclusive), filtered
server-side.
Args:
username: Tempo worker (Jira username / key).
date_from: Start date, inclusive, YYYY-MM-DD.
date_to: End date, inclusive, YYYY-MM-DD.
project: Optional project key to restrict to (e.g. PROJ).
breakdown: Optional grouping — day, project, issue,
account, both (=project+issue), all, or a
comma-separated combo like day,project. When day is
combined with project/issue the project/issue hours are
nested inside each day; otherwise they are flat for the period.
exclude_absence: Drop vacation / sick-leave worklogs (Tempo's
Absence account). Off by default so totals match Tempo.
| Name | Required | Description | Default |
|---|---|---|---|
| date_to | Yes | ||
| project | No | ||
| username | Yes | ||
| breakdown | No | ||
| date_from | Yes | ||
| exclude_absence | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains server-side filtering, breakdown behavior, and default for exclude_absence. However, it does not mention authentication requirements or rate limits, which is acceptable given no annotations but lacks full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative and well-structured with a clear parameter section. It is slightly verbose but each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no annotations, and an output schema, the description covers all necessary details (parameter formats, optionality, behavior) and references the API source.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All six parameters are thoroughly explained with format, optionality, and behavior (e.g., breakdown options, exclusion default). This adds significant value beyond the empty schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns total hours logged by a user in a date range, optionally broken down. It uses specific verbs and resource identification, distinguishing it from siblings like get_users_worklog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for single-user worklog retrieval but does not explicitly state when to use this tool over alternatives like get_users_worklog or provide conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search issues with a JQL query.
Args:
jql: A JQL query, e.g. project = PROJ AND status = "In Progress".
limit: Maximum number of issues to return (default 50).
| Name | Required | Description | Default |
|---|---|---|---|
| jql | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. Only mentions default limit, but omits pagination, rate limits, authorization needs, or query timeout. Incomplete for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise with an Args section. The first line is clear and front-loaded. Each sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, return values are not required in description. However, missing usage guidelines and behavioral transparency make the description incomplete for a tool with moderate complexity (2 params, search operation).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning: jql has an example ('project = PROJ AND status = "In Progress"') and limit specifies 'Maximum number of issues to return (default 50)'. Compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search issues with a JQL query', specifying the verb (search), resource (issues), and method (JQL). This distinguishes it from sibling tools like 'get_issue' (single issue by ID) and 'search_users'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., get_issue for single issue retrieval). Usage is implied but no when-not-to-use or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Jira users by name, username or email fragment.
Args: query: Substring to match against username, display name or email. limit: Maximum number of users to return (default 50). include_inactive: Include deactivated users in the result.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| include_inactive | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It describes the search function and parameters but does not explicitly state read-only safety, pagination behavior, or authentication requirements. The search nature implies it is safe, but explicit disclosure is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one introductory sentence followed by a bulleted list of parameters with clear explanations. Every sentence adds value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with an output schema (not required to describe returns), the description covers parameters and behavior well. It could mention edge cases (e.g., empty results) but overall is adequately complete given tool simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description provides all parameter meaning: query as substring match, limit as max results (default 50), include_inactive for deactivated users. This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches Jira users by name, username, or email fragment. It specifies a concrete verb ('Search'), resource ('Jira users'), and search criteria, distinguishing it from siblings like get_all_users (which returns all users) and search_issues (which searches issues).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for substring-based user searches but does not explicitly compare to alternatives like get_all_users for unfiltered retrieval or provide when-not-to-use guidance. No context on when to prefer search_users over other user-listing tools is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct resource and action. For example, get_project vs get_all_projects, search_users vs get_all_users, and the three worklog tools (get_user_worklog, get_users_worklog, get_team_worklog) have clear scopes (single user, group, team) with no overlap.
Tool names follow a consistent verb_noun pattern: get_* for retrieval, search_* for search, add_* for creation, create_issue, and find_* for lookup. No mixed conventions or vague verbs.
19 tools is well-scoped for a Jira/Tempo integration covering projects, issues, users, teams, worklogs, and plans. Each tool serves a clear purpose without being too few or too many.
The tool set covers core workflows: project/issue retrieval, user/team discovery, worklog and plan queries, and limited write operations (add_worklog, create_issue, add_comment). Missing update/delete operations for issues, but the primary focus on reporting is well-supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP Server for JFrog, providing tools for development and artifact management.
An MCP server that provides access to Testiny projects, test cases and test runs
MCP server providing attendance data queries via the CloudTime API.
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/nsleader/jira-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
