Инструменты MCP

Готово

Быстро найдите нужный MCP tool, обязательные поля и рабочую форму запроса.

Типизированные tools для поиска задач и безопасного исполнения workflow

Discovery-tools помогают получить projects, tasks, boards, teams, comments, analytics и markdown-документы.

Execution-tools закрывают ready discovery, проверку контекста, claim, смену статуса, progress, artifacts, handoff, recovery и convergence.

Большинство мутаций пакета требуют свежий snapshot packet context перед вызовом.

Раздел

Tools для discovery и context

list_projects, get_project, list_tasks, get_task, list_comments, get_comment.
create_project и create_task создают реальные project/task сущности для IDE-driven intake flow.
list_ready_packets, get_task_work_packet_context, get_task_context, get_task_dependencies, get_related_docs.
Перед рискованной мутацией вызывайте validate_task_readiness и validate_boundary_safety.

Раздел

Tools для мутаций

move_task_to_final_stage физически переносит карточку в board stage, помеченный как final; это не то же самое, что update_task_status.
claim_work_packet, renew_claim, update_packet_status, release_work_packet.
append_progress_comment, attach_artifact, append_handoff_packet, open_recovery_wave, run_convergence_gate.
propose_work_packets создаёт reviewable proposals вместо тихого коммита нового ready work.

Payload для claim_work_packet

{
  "projectId": "project_1",
  "packetId": "pkt_123",
  "expectedPacketRevision": 7,
  "expectedTaskRevision": 19,
  "expectedContractVersion": 2,
  "contextToken": "ctx_abc",
  "idempotencyKey": "claim-20260509-1",
  "leaseDurationSeconds": 900,
  "runId": "run_14",
  "waveId": "wave_14"
}

Раздел

Ведение разработки — протокол «Яйцехват»

Это рабочий маршрут для реальной разработки: сначала оформляем задачу, потом переводим её в исполнимые пакеты, затем берём пакет в работу, показываем прогресс и в конце закрываем задачу.

Сначала задача должна стать понятной и проверяемой, а не просто “что-то надо сделать”.
Потом работа делится на пакеты, чтобы каждый кусок можно было взять отдельно и не потерять контекст.
После этого пакет проходит ready gate, claim, progress, artifact и handoff так, чтобы результат было легко проверить.
create_detailed_task / enrich_task_to_proposal — делают задачу не сырой, а пригодной для работы.
create_work_packets_from_plan — делит план на понятные пакеты, чтобы каждый шаг можно было брать отдельно.
approve_packet_ready — ставит пакет в состояние “можно брать в работу”.
claim_work_packet — фиксирует, что конкретный пакет уже взяли в исполнение.
append_progress_comment / attach_artifact — показывают ход работы и прикладывают доказательства.
release_work_packet / move_task_to_final_stage — закрывают пакет и переводят задачу в финал.

Диаграмма

Как идёт Яйцехват

Это не магия и не один большой вызов. Это несколько маленьких шагов, у каждого есть свой смысл.

intake / plan

create_detailed_task или enrich_task_to_proposal

create_work_packets_from_plan

approve_packet_ready

claim_work_packet

append_progress_comment / attach_artifact

release_work_packet

move_task_to_final_stage

Как это понимать без лишней теории

Если по-простому: сначала мы оформляем смысл, потом делаем маленькие исполнимые куски, потом показываем ход работы, а не тащим всё одной большой и непонятной мутацией.

Как выглядит запрос на входе

Нужно починить browser back внутри /app. Сначала понять причину, потом оформить пакет, потом только менять код.

Раздел

Обязательные CAS-поля

expectedPacketRevision
expectedTaskRevision
expectedContractVersion
contextToken
idempotencyKey
claimToken, если packet уже находится в claim

Следующие материалы

Связанные страницы

Справочник MCP resources

Готово

URI-шаблоны и resource-поверхности MCP Treker Zadachek: task context, ready queue, proposals, packets, runs и waves.

Справочник MCP prompts

Готово

Prompt-поверхности MCP Treker Zadachek для task brief, readiness, progress, декомпозиции, handoff и convergence.

Workflow work packet

Готово

Поймите жизненный цикл work packet в Treker Zadachek: от proposal и ready gate до claim, progress, artifact, handoff, recovery и convergence.

Ошибки и troubleshooting

Готово

Типовые ошибки Treker Zadachek MCP и API: проблемы auth, отказы доступа, stale context и packet authorization denial.

Коротко

О чём эта страница

MCP Treker Zadachek

MCP Treker Zadachek — stdio-мост: отдаёт discovery, исполнение work packet, resources и prompts в supervised runtime агента, сохраняя backend scope и семантику отказов.

FAQ

Когда выбирать MCP вместо REST API?

Выбирайте MCP, когда вызывающая сторона - агент или supervised runtime, которому нужны tools, resources, prompts и workflow-safe мутации packet. REST нужен, когда достаточно прямого HTTP-контракта.

Почему MCP Treker Zadachek требует revision и context token?

Эти CAS-поля предотвращают stale write, делают retry явным и держат исполнение packet согласованным с последним состоянием backend.

Источники

README MCP server

mcp-server/README.md

Главное публичное описание MCP-контракта и ожиданий к оператору.

Контракт OpenAPI

docs/openapi/external-statistics-v1.yaml

Machine-readable reference для tooling и генерации клиентов.

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

Справочник MCP resources