Taiga MCP Server

Copy the translated translation# Taiga MCP Server

Model Context Protocol (MCP) server for Taiga project management — написан на TypeScript и построен на Model Context Protocol SDK поверх транспорта stdio (с опциональным потоковым HTTP-транспортом для удалённых и веб-клиентов). Он подключает LLM-клиентов к инстансам Taiga для просмотра и управления проектами, рабочими элементами (тикетами, пользовательскими историями, задачаима, эпиками), спринтами, комментариями, вложениями и wiki-страницами.

Сервер объединяет все возможности в 6 инструментов с диспетчеризацией операций, рассчитанных на минимальную нагрузку на токены и на получение плотных текстовых ответов, читаемых как человеком, так и LLM.

Содержание

• Возможности · Требования и конфигурация · Быстрый старт · Локальная копия репозитория · HTTP-транспортировка и веб-клиенты · Контейнеры

• Установка: Claude Code · Claude Desktop · VS Code / Copilot · Cursor · Windsurf · Cline / Roo / Kilo · Continue.dev · Zed · JetBrains · Gemini CLI · Codex CLI · opencode · Amp · Pi · Oh My Pi

• Инструменты: Соглашения · Почему шесть инструментов · Справочник инструментов: projects · work · sprints · comments · attachments · wiki

• Эксплуатация: Надёжность · Безопасность · FAQ · Устранение неполадок · Разработка · Вклад в проект · Журнал изменений · Лицензия

Related MCP server: @illodev/taiga-mcp

Возможности

• Шесть инструментов, двадцать восемь операций : проекты, рабочие элементы, спринты, комментарии, вложения и wiki-страницы — весь полезный выход tools/list не превышает ~10 493 символов (~2 800 токенов).

• Понятные человеку идентификаторы: проекты — по ID или slug; рабочие элементы — по ID в базе данных или #reference; участники — по ID, имени пользователя, полному имени или "me"; статусы, приоритеты, серьёзности, типы задач и имена спринтов разрешаются на стороне сервера.

• Плотный текстовый вывод: одна строка на запись в списках, чистые представления в виде «ключ-значение»; пустые коллекции сообщаются как данные, а не как ошибки.

• Пакетное создание до 20 рабочих элементов за один вызов; удаления намеренно выполняются только по отдельности.

• Средства надёжности: повторные попытки при ограничении частоты с учётом Retry-After, таймауты HTTP 30 секунд, кэш метаданных на 60 секунд и отсутствие автоматических повторов при 5xx (мутирующие запросы могли быть применены).

• Безопасность вложений: загрузки с привязкой к имени хоста, ограничение 10 & МБ, защита от перезаписи и отсутствие туманов ключей аундинизации при обращении к хостяам, отдающим медиа.

• Два транспорта: по умолчанию stdio; потоковый HTTP на адрес замыкания, если задан TAIGA_HTTP_PORT.

Требования и конфигурация

• Node.js >= 20.11

• Учётная запись Taiga на taiga.io или собственный экземпляр Taiga

• Настройте три переменные окружения:

Дополнительные переменные для транспорта:

Быстрый старт

Быстрее всего запустить Claude Desktop через npx (без клонирования репозитория):

{
  "mcpServers": {
    "taiga": {
      "command": "npx",
      "args": ["-y", "mcp-taiga"],
      "env": {
        "TAIGA_USERNAME": "your_username",
        "TAIGA_PASSWORD": "your_password"
      }
    }
  }
}

Все приведённые ниже конфигурации построены по этой схеме; отличаются только расположение файла и синтаксис обёртки.

Учётные данные и .env: локальная копия репозитория автоматически загружает .env из его корня (см. .env.example). При установке через npx этого не происходит: dotenv вычисляет путь относительно места установки пакета в npm-кэше, поэтому учтные данные, передаваемые через npx, ОБЯЗАТЕЛЬНО должны быть заданы в блоке env каждой клиентской конфигурации, как показано выше.

Запуск из локальной копии репозитория

git clone https://github.com/negoro26/mcp-taiga.git
cd mcp-taiga && npm ci && npm run build
cp .env.example .env   # fill in TAIGA_USERNAME / TAIGA_PASSWORD

Затем укажите любому клиенту путь к собранной точке входа вместо npx:

{
  "mcpServers": {
    "taiga": {
      "command": "node",
      "args": ["/absolute/path/to/mcp-taiga/dist/src/index.js"]
    }
  }
}

Здесь блок env не нужен: сервер сам загрузит .env из корня репозитория. В репозитории также содержится готовый .mcp.json, поэтому разработчики, работающие в копии проекта, могут сразу использовать локальную сборку.

Установка и конфигурация

Настройка для каждого клиента с использованием опубликованного npm-пакета. В каждом сниппете учётные данные передаются встроенно; подставьте собственные значения.

Claude Code

Область проекта (проверена в репозиторий, доступна команде):

// .mcp.json at repository root
{
  "mcpServers": {
    "taiga": {
      "command": "npx",
      "args": ["-y", "mcp-taiga"],
      "env": {
        "TAIGA_USERNAME": "your_username",
        "TAIGA_PASSWORD": "your_password"
      }
    }
  }
}

Или добавьте из CLI (область пользователя задаётся флагом -s user, локальная — по умолчанию):

claude mcp add taiga \
  -e TAIGA_USERNAME=your_username \
  -e TAIGA_PASSWORD=your_password \
  -- npx -y mcp-taiga

Проверьте с помощью claude mcp list или /mcp в сессии.

Claude Desktop

Отредактируйте файл конфигурации — claude_desktop_config.json через Claude Desktop -> Settings -> Developer -> Edit Config, расположенный в %APPDATA%\Claude\claude_desktop_config.json на Windows или ~/Library/Application Support/Claude/claude_desktop_config.json на macOS, и перезапустите настольное приложение:

{
  "mcpServers": {
    "taiga": {
      "command": "npx",
      "args": ["-y", "mcp-taiga"],
      "env": {
        "TAIGA_USERNAME": "your_username",
        "TAIGA_PASSWORD": "your_password"
      }
    }
  }
}

На Windows, если прямой вызов npx не сработает, используйте cmd /c: "command": "cmd", "args": ["/c", "npx", "-y", "mcp-taiga"].

VS Code и GitHub Copilot

VS Code поддерживает MCP-серверы нативно (1.99+); Copilot Chat подхватывает их автоматически.

// .vscode/mcp.json (workspace) or use Command Palette: "MCP: Add Server"
{
  "servers": {
    "taiga": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "mcp-taiga"],
      "env": {
        "TAIGA_USERNAME": "your_username",
        "TAIGA_PASSWORD": "your_password"
      }
    }
  }
}

Запустите сервер из представления Extensions (mcp.json отображает кнопку Start) или выполните MCP: List Servers в панели команд. Входные данные могут ссылаться на секреты через поле "inputs" вместо жёстко заданных паролей.

Cursor

Через CLI (интерфейс повторяет Claude Code):

cursor mcp add taiga -e TAIGA_USERNAME=your_username -e TAIGA_PASSWORD=your_password -- npx -y mcp-taiga

Или отредактируйте ~/.cursor/mcp.json (глобально):

{
  "mcpServers": {
    "taiga": {
      "command": "npx",
      "args": ["-y", "mcp-taiga"],
      "env": {
        "TAIGA_USERNAME": "your_username",
        "TAIGA_PASSWORD": "your_password"
      }
    }
  }
}

Включите сервер в Cursor Settings -> MCP & Integrations, если он не активировался сразу.

Windsurf

Отредактируйте ~/.codeium/windsurf/mcp_config.json (или **Windsurf Settings -> Cascade -> MCP Servers -> Manage MCP -> View Raw Config (Показать исходный конфиг) **) и обновите панель MCP после этого:

{
  "mcpServers": {
    "taiga": {
      "command": "npx",
      "args": ["-y", "mcp-taiga"],
      "env": {
        "TAIGA_USERNAME": "your_username",
        "TAIGA_PASSWORD": "your_password"
      }
    }
  }
}

Cline, Roo Code и Kilo Code

Все три расширения VS Code читают одинаковый JSON-файл настроек, который можно редактировать через панель MCP Servers каждого расширения (значок карандаша открывает исходный файл):

Добавьте сервер внутрь корневого объекта "mcpServers":

{
  "mcpServers": {
    "taiga": {
      "disabled": false,
      "timeout": 60,
      "command": "npx",
      "args": ["-y", "mcp-taiga"],
      "env": {
        "TAIGA_USERNAME": "your_username",
        "TAIGA_PASSWORD": "your_password"
      }
    }
  }
}

Когда расширение запросит разрешение на использование инструментов сервера, подтвердите его; автоподтверждение для отдельных инструментов настраивается там же.

Continue.dev

Continue читает MCP-серверы либо из блоков mcpServers: в своей конфигурации, либо из отдельных YAML-файлов в .continue/mcpServers/ (она такжепринимает JSON-конфигурации Claude/Cursor/Cline, помещённые в этот каталог без изменений):

# ~/.continue/config.yaml (or .continue/mcpServers/taiga.yaml with
# name/version/schema metadata fields added)
name: Assistant
version: 1.0.0
schema: v1
mcpServers:
  - name: Taiga
    type: stdio
    command: npx
    args:
      - -y
      - mcp-taiga
    env:
      TAIGA_USERNAME: your_username
      TAIGA_PASSWORD: your_password

Инструменты MCP доступны в режиме агента.

Zed

Добавьте пользовательский сервер контекста в settings.json (zed: open settings):

{
  "context_servers": {
    "taiga": {
      "command": {
        "path": "npx",
        "args": ["-y", "mcp-taiga"],
        "env": {
          "TAIGA_USERNAME": "your_username",
          "TAIGA_PASSWORD": "your_password"
        }
      }
    }
  }
}

JetBrains IDE

Откройте Settings -> Tools -> AI Assistant -> MCP (или отдельную страницу настроек MCP в новых версиях), нажмите Add, выберите As JSON и вставьте:

{
  "mcpServers": {
    "taiga": {
      "command": "npx",
      "args": ["-y", "mcp-taiga"],
      "env": {
        "TAIGA_USERNAME": "your_username",
        "TAIGA_PASSWORD": "your_password"
      }
    }
  }
}

Требуется плагин AI Assistant с включённой поддержкой MCP.

Gemini CLI

Отредактируйте ~/.gemini/settings.json и перезапустите CLI. Инструменты требуют подтверждения на каждый вызов, если вы не внесёте их в список разрешённых:

{
  "mcpServers": {
    "taiga": {
      "command": "npx",
      "args": ["-y", "mcp-taiga"],
      "env": {
        "TAIGA_USERNAME": "your_username",
        "TAIGA_PASSWORD": "your_password"
      },
      "includeTools": ["projects", "work", "sprints", "comments", "attachments", "wiki"]
    }
  }
}

Проверьте регистрацию командой /mcp list в CLI.

Codex CLI

Добавьте таблицу серверов в конфиг ~/.codex/config.toml:

[mcp_servers.taiga]
command = "npx"
args = ["-y", "mcp-taiga"]

[mcp_servers.taiga.env]
TAIGA_USERNAME = "your_username"
TAIGA_PASSWORD = "your_password"

Проверьте с помощью codex mcp list; инструменты появляются как taiga_* внутри сессий.

opencode

Добавьте в opencode.json (в корень проекта или ~/.config/opencode/opencode.json):

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "taiga": {
      "type": "local",
      "command": ["npx", "-y", "mcp-taiga"],
      "environment": {
        "TAIGA_USERNAME": "your_username",
        "TAIGA_PASSWORD": "your_password"
      },
      "enabled": true
    }
  }
}

Обратите внимание на ключ environment в единственном числе и форму command в виде массива — они отличаются от схемы в стиле Claude.

Amp

Для серверов уровня пользователя предпочтительно использовать CLI:

amp mcp add taiga -- npx -y mcp-taiga

Или объявите amp.mcpServers в ~/.config/amp/settings.json (варианты в рабочей области .amp/settings.json требуют сначала выполнить amp mcp approve taiga):

{
  "amp.mcpServers": {
    "taiga": {
      "command": "npx",
      "args": ["-y", "mcp-taiga"],
      "env": {
        "TAIGA_USERNAME": "your_username",
        "TAIGA_PASSWORD": "your_password"
      }
    }
  }
}

Pi

Pi читает MCP-конфиг в стиле Claude из двух областей: ~/.pi/agent/mcp.json (пользователь) и .mcp.json или mcp.json в рабочей области (проект). Отредактируйте пользовательский файл:

{
  "mcpServers": {
    "taiga": {
      "command": "npx",
      "args": ["-y", "mcp-taiga"],
      "env": {
        "TAIGA_USERNAME": "your_username",
        "TAIGA_PASSWORD": "your_password"
      }
    }
  }
}

Удалённые серверы используют "url" и "transport": "http". Управление серверами через /mcp в сессии (/mcp add, /mcp list, включение/выключение для каждого сервера).

В этом репозитории есть собственный .mcp.json, так что при запуске pi в локальной копии автоматически используется локальная сборка (учётные данные там не нужны — сервер сам загрузит .env репозитория).

Oh My Pi

omp использует ядро агента pi, но со своим корнем конфигурации. Отредактируйте ~/.omp/agent/mcp.json:

{
  "mcpServers": {
    "taiga": {
      "command": "npx",
      "args": ["-y", "mcp-taiga"],
      "env": {
        "TAIGA_USERNAME": "your_username",
        "TAIGA_PASSWORD": "your_password"
      }
    }
  }
}

MCP-серверы подключаются при создании сессии — после редактирования перезапустите omp. Инструменты отображаются как taiga_*; конфигурации уровня проекта определяются по логике pi (включая .mcp.json из этого репозитория).

Удалённые и веб-клиенты (HTTP-транспортировка)

Задайте TAIGA_HTTP_PORT, чтобы те же шесть инструментов были доступны по потоковому HTTP вместо stdio — это удобно для клиентов, которые не могут запускать локальные процессы, или для одного общего экземпляра:

TAIGA_HTTP_PORT=3000 npx -y mcp-taiga
# serves http://127.0.0.1:3000/mcp

Свойства: режим без состояния (без session-заголовков); привязка к 127.0.0.1, если не задан TAIGA_HTTP_HOST (не-loopback адреса привязки выводит в stderr предупреждение о обычном HTTP); для объявляемого хоста включена защита от DNS-rebinding; повреждённый JSON отклоняется с -32700; на /mcp обрабатываются только POST (405 для остальных методов).

Клиенты подключаются по URL, а не по команде:

{
  "mcpServers": {
    "taiga": {
      "url": "http://127.0.0.1:3000/mcp"
    }
  }
}

Аналоги для Continue.dev: type: streamable-http с полем url:; для opencode: type: "remote" с полем url:. Поскольку процесс запускается вручную, а не клиентом, экспортируйте TAIGA_USERNAME/TAIGA_PASSWORD в этой оболочке (или используйте systemd unit, контейнер и т. п.).

Контейнеры

Входящий в набор двухстадийный Dockerfile использует Node 22 Alpine с непривилегированным пользователем node. Стадия сборки компилирует TypeScript, стадия запуска включает только собранный результат в каталоге dist/src и production-зависимости.

Соберите образ контейнера:

docker build -t mcp-taiga .

Запустите контейнер, подклучаясь к стандартному вводу-выводу:

docker run --rm -i --env-file .env mcp-taiga

Podman работает с прямой заменой: замените docker на podman.

Укажите MCP-клиенту контейнер, запускаемый через этот раннер:

{
  "mcpServers": {
    "taiga": {
      "command": "docker",
      "args": ["run", "--rm", "-i", "--env-file", "/absolute/path/to/.env", "mcp-taiga"]
    }
  }
}

При HTTP-развёртывании опубликуйте пост

Намеренно не существует compose-файла. MCP stdio-сервер должен запускаться с прямым подключением к потокам stdin и stdout своего клиента и завершаться, когда этот поток stdin закрывается. Супервизоры процессов или compose-окружения, пытающиеся поддерживать фоновые сервисы в живых, вызывают бесконечные циклы перезапуска и конфликты имён контейнеров.

Соглашения

• Проекты: проектные аргументы принимают числовой идентификатор проекта (например, 19) или слаг (например, "acme-web").

• Рабочие элементы: рабочие элементы принимают числовой идентификатор в БД (например, 1888) или ссылку с префиксом # (например, "#70"). Обозначение #reference требует аргумент project для разрешения.

• Люди: аргументы участников принимают числовой идентификатор пользователя, имя пользователя (например, "jdoe"), полное имя (например, "Jane Doe") или буквленное "me".

• Таксионимии: названия статусов, приоритетов, уровней серьёзности, типов заявок и спринтов принимаются в человекочитаемом виде и преобразуются в числовые идентификаторы на стороне сервера.

• Пользовательские истории с несколькими исполнителями: истории Taiga поддерживают нескольких исполнителей через поле assigned_users. Фильтрация по assignee в work list type:story находит и соисполнителей, а в списках показываются все исполнители, а не только основной.

• Плотные текстовые результаты: результаты — обычный текст, в котором каждая запись выводится плотной строкой, а подробные представления оформлены аккуратными блоками «ключ — значение». Ни один потребитель не читает structuredContent, поэтому результаты содержат только текст. Пустая коллекция сообщается как <items> in <project>: 0, а не как ошибка.

• Полный список: перечневые endpoints возвращают полные коллекции, потому что клиент отправляет заголовок запроса `x-disable-pagination: true» — это исключает многократные полнопереходные раундттрипы.

Почему шесть инструментов

Множество инструментов одного назначения создаёт серьёзные издержки на контекстное окно ещё до вызова любого из них. Объединение функциональности в 6 инструментов с диспетчеризацией операций удерживает размер полезной нагрузки tools/list на уровне примерно 10 493 символов (~2 800 токенов).

Схемы вывода намеренно отсутствуют в реестру инструментов: мосты MCP-клиентов объединяют текстовый контент и игнорируют outputSchema и structuredContent, поэтому отсутствие выходных схем убирает лишние потери токенов при старте сессии.

Справочник инструментов

Сервер предоставляет 6 инструментов, охватывающих 28 операций.

1. projects

Перечисление и просмотр проектов Taiga, проверка учётных данных.

2. work

Управление заявками, пользовательскими историями, задачами и эпиками (type: issue, story, task, epic).

3. sprints

Управление спринтами (вехами) и проверка статистики хода работ.

Удаление спринтов осознанно не выставлено наружу: удаление вехи отвязывает каждую историю и задачу, превращая операцию в правку уровня всей доски, которую следует выполнять в интерфейсе Taiga.

4. comments

Просмотр, добавление, изменение или удаление комментариев к рабочим элементам и вики-страницам (type: issue, story, task, epic, wiki).

5. attachments

Управление файловыми вложениями в рабочих элементахки и вики-страницах (type: issue, story, task, epic, wiki).

6. wiki

Управление вики-страницами и подпиской на них внутри проекта.

Надёжность и безопасность

Надёжность и безопасность

• Ограничение частоты запросов (429): Сервер повторяет HTTP-запросы при ответе 429 не более двух раз, учитывая заголовок Retry-After сервера. Если необходимое ожидание превышает 5-секундный лимит (MAX_THROTTLE_WAIT_MS), он немедленно выбрасывает исключение с сообщением о повторной попытке, а не ждёт.

• Ошибки 5xx никогда не повторяются: Ответы 5xx никогда не повторяются автоматически, потому что изменяющие запросы (например, POST) могли уже быть применены на сервере; повторение создаёт риск появления дублирующихся записей.

• Кэш метаданных: Метаданные проекта (поиск по slug, членство пользователей и таксономические списки для статусов, приоритетов, уровней критичности и типов задач) кэшируются на 60 секунд (METADATA_TTL_MS) через getMetadata. Рабочие элементы, комментарии и вложения никогда не кэшируются.

• Таймауты: Для HTTP-запросов установлено 30-секундное время ожидания (REQUEST_TIMEOUT_MS).

• Принудительное использование HTTPS: Сервер выводит предупреждение в stderr, если TAIGA_API_URL использует незашифрованный HTTP для обращения к хосту, отличному от loopback.

• Ограничения на скачивание вложений: Скачивание вложений строго ограничено настроенным именем хоста Taiga, перенаправления запрещены (maxRedirects: 0), максимальный размер файла — 10 МБ (MAX_ATTACHMENT_BYTES). При скачивании сборщик не передаёт bearer-токен Taiga на медиахосты.

• Защита от перезаписи файлов: Скачивание вложения с savePath отказывается перезаписывать существующий локальный файл.

• Удаление одного объекта за раз: Операции удаления принимают ровно один объект за один раз. Пакетные операции поддерживают только создание (до 20 элементов), что предотвращает случайное удаление по всей доске.

Вопросы безопасности

• Учётные данные передаются через переменные окружения или файлы конфигурации клиентского окружения, никогда — через аргументы командной строки (доступные из списков процессов) и никогда через репозиторий. Не храните файлы конфигурации клиентского окружения с паролями в системе контроля версий; .gitignore уже исключает .env*, кроме .env.example.

• Опциональный HTTP-транспорт по умолчанию привязывается к loopback и включает защиту от DNS-rebinding; привязка к маршрутизируемому адресу выводит предупреждение, потому что трафик не шифруется.

• Скачивание вложений никогда не уводит ваш bearer-токен за пределы хоста Taiga, запрещает перенаправления, ограничивает размер файла и не перезаписывает существующие файлы.

• Удаление спроектировано работающим с одним объектом за раз; пакетного удаления нет.

FAQ

Какие MCP-клиенты могут его использовать? Любой клиент, работающий через stdio MCP, — руководство по установке описывает семнадцать из них с готовыми конфигурациями — а также клиенты на основе URL через HTTP-транспорт.

Работает ли он с self-hosted Taiga? Да. Укажите в TAIGA_API_URL адрес вашего экземпляра, включая суффикс /api/v1 (например, https://taiga.example.com/api/v1). Всё вызнать аналогично; если запросы возвращают 404, см. раздел Устранение неполадок.

Можно ли подключить более одной учётной записи или экземпляра Taiga? Не в рамках одного процесса — внутри него существует ровно один набор учётных данных, считываемый окружением при старте. Зарегистрируйте дополнительные записи в mcpServers (например, "taiga-work") со своими значениями переменных окружения; каждая станет независимым пространством имён, например mcp__taiga-work__work.

Куда попадает мой пароль? Из вашего блока env в память, а оттуда — только на настроенный экземпляр Taiga при обмене входа. Он никогда не попадает в командную строку (которая процичивается через списки процессов), в журналы, результаты инструментов или на серверы скачивания вложений. См. раздел Вопросы безопасности.

Он только для чтения? Нет: поддержку полное создание, обновление, связывание/отвязку и удаление рабочих элементов, спринтов, обсуждений, вложений и вики-страниц. Удаление спринтов и пакетное удаление намеренно отсутствует — см. Надёжность и безопасность.

Почему только шесть инструментов, когда другие MCP-серверы используют десятки? Экономия контекстного окна: каждое объявление инструмента стоит занимает место при каждом старте сессии. См. Почему шесть инструментов.

Что-то сломалось — с чего начать? Устранение неполадок описывает типовые проблемы; если это не помогает, создайте issue на GitHub с описанием упавшего вызова и содержимым stderr сервера.

Устранение неполадок

• Сбои аутентификации — запустите инструмент projects с параметром op: whoami; он точно укажет, какой шаг обмена учётными данными не сработал. Проверьте лишние пробелы в значениях окружения и работу учётной записи в веб-интерфейсе Taiga.

• Self-hosted экземпляр возвращает 404 — в TAIGA_API_URL должен быть указан суффикс /api/v1, например https://taiga.example.com/api/v1.

• Сервер запускается, но npx-клиент не видит инструментов — убедитесь, что в окружении клиента выполняется Node.js >= 20.11; графические оболочки часто наследуют другой PATH, нежели ваш шелл.

• Учётные данные игнорируются при запуске через npx — установки npx не читают .env; помещайте учётные данные в блок env конфигурации клиента (только локальные копии автоматически подгружают .env).

• Конфликт портов в HTTP-режиме — порт занят другим процессом; выберите другой значение TAIGA_HTTP_PORT. Сервер завершает работу с ошибкой прослушивании и кодом возврата, отличным от нуля, а не натравит.

• Пустые результаты — списки выводят <items> in <project>: 0; это успешный ответ, а не ошибка.

• Сервер Cursor/Windsurf присутствует, но не активен — после изменения конфигурационных файлов включите переключатель сервера в панели настроек соответствующего приложения; оба приложения кэшировать состояние до обновления.

Разработка

Расположение файлов

src/index.ts            # Entrypoint: createServer() factory, stdio vs HTTP transport selection
src/http.ts             # Streamable HTTP transport (node:http, stateless, DNS-rebinding protected)
src/api.ts              # Authenticated axios transport, generic HTTP helpers (get, post, patch, del), token management, retry policy, metadata cache
src/taiga.ts            # Domain helpers: resolution (projects, items, members, taxonomies, sprints) and optimistic concurrency patch
src/types.ts            # Taiga payload interfaces, tool definitions, and type contracts
src/format.ts           # Dense pipe-separated single-line renderers and detail views
src/utils.ts            # MCP response builders (createSuccessResponse, createErrorResponse, guard) and formatting helpers
src/constants.ts        # Endpoints, limits (batch size, attachment size), status labels, error messages
src/tools/index.ts      # Tool registry aggregating all tools and registering with McpServer
src/tools/projects.ts   # projects tool (list, get, whoami)
src/tools/work.ts       # work tool (list, get, create, update, link, unlink, delete across issues, stories, tasks, epics)
src/tools/sprints.ts    # sprints tool (list, get, create, stats)
src/tools/comments.ts   # comments tool (list, add, edit, delete)
src/tools/attachments.ts # attachments tool (list, upload, download, delete)
src/tools/wiki.ts       # wiki tool (list, get, create, update, delete, watch)
test/unitTest.ts        # Offline unit tests for pure helpers, formatting functions, response builders, and tool invariants
test/protocolTest.ts    # Protocol tests verifying MCP stdio handshake, server capabilities, tool count, and tools/list budget
test/httpTest.ts        # Transport tests verifying the streamable HTTP endpoint: handshake, tools/list, routing rejections
test/apiContractTest.ts # Contract tests driving every tool op against an in-process mock Taiga HTTP server, asserting outgoing HTTP requests
test/integration.ts     # Live integration smoke test against a real Taiga instance (read-only, skips without credentials)

NPM-скрипты

• npm run build: Компилирует TypeScript из src/ и test/ в dist/ через tsc.

• npm run check: Проверяет типы TypeScript без генерации выходных файлов (tsc --noEmit).

• npm run lint: Запускает oxlint по каталогам src/ и test/.

• npm start: Запускает собранный сервер (node dist/src/index.js).

• npm test: Компилирует и запускает последовательно наборы unit-, protocol-, contract- и HTTP-транспортных тестов.

• npm run test:unit: Компилирует и выполняет автономные модульные тесты.

• npm run test:protocol: Компилирует и запускает тесты протокола MCP через stdio.

• npm run test:http: Компилирует и запускает тесты потокового HTTP-транспорта.

• npm run test:contract: Компилирует и запускает контрактные тесты API против мок-сервера Taiga.

• npm run test:integration: Компилирует и запускает живые интеграционные тесты с реальным экземпляром.

• npm run prepublishOnly: Выполняет проверку типов, линтер и полный набор тестов перед публикацией.

Тестовые наборы

1. Unit-тесты (test/unitTest.ts): Автономные модульные тесты проверяют чистые функции форматирования, строители ответов, помощники разрешения идентификаторов и инварианты определения инструментов без сети и учётных данных.

2. Протокольные тесты (test/protocolTest.ts): Протокольные тесты проверяют реальное stdio-рукопожатие MCP, версию и возможности сервера, схемы инструментов и бюджет символов tools/list на порождаемом серверном процессе.

3. HTTP-тесты (test/httpTest.ts): Запускает скомпилированный сервер с TAIGA_HTTP_PORT и проверяет реальное рукопожатие потокового HTTP, эхо версии протокола, отсутствие сохранения состояния между запросами, содержимое tools/list и отклонения маршрутов с кодами 400/404/405 на локальных хостах.

4. Контрактные тесты (test/apiContractTest.ts): Контрактные тесты проверяют, что каждый инструмент и операция отправляют ожидаемые исходящие HTTP-запросы (метод, конечную точку, параметры запроса, заголовки и тело) и корректно обрабатывают ответы внутрипроцессного мокового HTTP-сервера Taiga.

5. Интеграционные тесты (test/integration.ts): Живые интеграционные smoke-тесты, проверяющие операции инструмента в режиме только чтения на реальном экземпляре Taiga через stdio (пропускаются, если учётные данные не заданы).

Участие в разработке

Пулл-реквесты отправляются в ветку dev; см. CONTRIBUTING.md о модели веток (dev → staging → main), рекомендациях к коммитам и процессе релиза.

Журнал изменений

См. CHANGELOG.md.

Лицензия

MIT