MCP: подключить клиентского агента и спросить свои данные

По шагам

1. 1. Определите, что даёт подключение и что оно не меняет

   MCP-сервер открывает клиентскому агенту контекст вашего продукта: стратегию, цели, гипотезы, допущения, решения, артефакты и sizing. Агент задаёт вопрос обычным языком и получает ответ, собранный из этого контекста, с цитатами на узлы-источники и отметкой их актуальности. Это вторая поверхность того же механизма, который отвечает на вопросы внутри интерфейса TaskTreker, — не отдельный продукт и не чат вместо интерфейса. Продуктовая граница при этом не сдвигается. TaskTreker не превращается в трекер задач, чат или файловый менеджер: задачи остаются в трекере, которым уже пользуется команда, а продуктовая аналитика остаётся в инструменте, который команда уже читает. Если обещания про MCP-сервер нет в этом гайде, считайте его неподтверждённым.

2. 2. Подготовьте контекст до подключения агента

   Ответы собираются из хранилища контекста — структурированной версионируемой памяти вашего продукта, — а не из открытого интернета. Значит, качество ответа решается задолго до подключения агента: зафиксированными и подтверждёнными решениями, гипотезами, допущениями и артефактами, которые вы внесли. Отсюда два правила, которые стоит проверить заранее. Первое: извлечённое не является контекстом — всё, что слой capture вытащил из встречи или документа, приходит со статусом «не проверено» и не попадает в ответы, пока человек это не подтвердит. Второе: модель не принимает решения о доступе и не заполняет пробелы — если в контексте нет ответа, правильный результат — прямое «не знаю» с предложением создать запись о решении, а не правдоподобный абзац. Если подключить агента к пустому пространству, честный ответ будет таким: данных, из которых отвечать, нет.

3. 3. Подключите сервер в клиентском агенте и авторизуйтесь своей учётной записью

   Добавьте MCP-сервер TaskTreker в конфигурацию MCP вашего клиентского агента — Claude Code или Cursor — и авторизуйте подключение своей учётной записью в рабочем пространстве. Учётная запись здесь решает всё: доступ выдаётся конкретному человеку, а данные компании изолированы, поэтому агент, подключённый участником одной компании, не видит контекст другой. Подключение от имени всей компании или общее подключение между коллегами без раздельных учётных записей эту изоляцию ломает и не является поддерживаемым сценарием. Права и подключения управляются в настройках компании, где администратор видит пользователей, их роли, подключённые сервисы и биллинг. Если агент отвечает данными, которые не ваши, остановитесь и переавторизуйтесь, прежде чем задавать что-то ещё: такой симптом — это сбой изоляции, а не вопрос к вашим данным.

4. 4. Проверьте режим доступа и оставьте его на чтении

   По умолчанию действует режим «только чтение», и продукт считает это правилом, а не рекомендацией. Читать контекст и отвечать на вопросы по нему можно. Менять узел контекста нельзя: при попытке записи запрос отклоняется и попадает в журнал аудита. Запись возможна только там, где она явно разрешена в настройках, и решение о разрешении принимает человек с соответствующими правами — языковая модель не выдаёт доступ себе сама. Пока вы осваиваетесь в настройке, оставьте режим чтения: большинство вопросов закрывается тем, что уже зафиксировано, а непреднамеренную запись проще не допустить, чем заметить постфактум. Если запись для конкретного случая всё-таки включена, имейте в виду, что изменение действует на то подключение, которое вы настроили, и после этого посмотрите журнал аудита, чтобы увидеть, что именно изменилось.

5. 5. Задайте первый вопрос о своём контексте

   Спросите так, как спросили бы коллегу, который был на встрече: «почему мы решили сделать именно так», «на каком допущении стоит эта гипотеза», «что мы обещали клиенту по этому», «что изменилось в этом релизе». Вопрос проходит через тот же механизм, что и поиск внутри интерфейса, а ответ приходит с цитатами на использованные узлы контекста и с отметкой их свежести: когда создан источник и не устарел ли он. Начните с решения, которое действительно зафиксировано, — это и есть сценарий, вокруг которого построен продукт: цепочка допущение → гипотеза → решение → следствие, со ссылкой на источник на каждом шаге. Первый вопрос держите узким. Широкий вопрос даёт широкий ответ, и отличить слабый ответ от бедного контекста труднее, чем понять, какого узла не хватает.

6. 6. Прочитайте ответ: цитаты, свежесть и честные пробелы

   В правильном ответе видны четыре вещи, и они одинаковы для ответа из интерфейса и из агента. Каждое фактическое утверждение сопровождается ссылкой на узел контекста, из которого оно взято. У источников видна дата, а устаревший источник помечается, а не используется молча. Числа без источника помечаются как оценка и не выдаются за факт. И когда в контексте нет ответа, вы получаете прямое «не знаю» с предложением создать запись о решении. Отсюда два следствия для вашей практики. «Не знаю» — это информация: оно указывает на пробел в контексте, который стоит закрыть, а не на дефект агента. А когда две версии одного утверждения противоречат друг другу, ответ показывает обе с их датами, а не выбирает одну молча — контекст ваш, и решать за вас агент не вправе.

7. 7. Проверьте журнал аудита и журнал прогонов после первого сеанса

   Каждый вызов через MCP-сервер попадает в два места. Журнал аудита фиксирует, кто, что и когда вызвал, — это след, к которому вы обращаетесь, если возникает вопрос о доступе. Журнал прогонов фиксирует вход, выход, статус и стоимость прогона — так же, как прогоны внутри продукта. Прочитайте оба после первого сеанса: так быстрее всего понять, что агент на самом деле запрашивал и что на самом деле получил. Стоит завести две привычки. Первая: открывать журнал аудита каждый раз, когда подключаете нового агента или меняете, кто авторизован. Вторая: использовать журнал прогонов как место, где позже проверяется свежесть ответа: ответ, полученный из источника, который был актуален в прошлом месяце, — это не то же утверждение, что ответ, полученный сегодня, и журнал показывает эту разницу.

8. 8. Подключите источники и оставьте открытый выход

   MCP-сервер отвечает из контекста, а контекст наполняется из систем, где ваша работа уже происходит. Двенадцать интеграций входят в целевое состояние v1: Linear, Jira, GitHub, Notion, Confluence, Slack, Google Docs и Drive, Figma, Amplitude и Mixpanel, HubSpot и amoCRM, почта и сам MCP-сервер. Каждая из них — отдельное подключение со своими правами: что читаем, что не читаем, что уходит в модель. У любого коннектора выполняются два свойства: его можно выключить, не сломав продукт, и данные можно выгрузить без потери. Универсальный путь — импорт и экспорт в Markdown, JSON и CSV — закрывает стеки без отдельного коннектора, так что редкий инструмент не становится причиной ждать. После подключения проверьте выход: выгрузите контекст и убедитесь, что выгрузка полна, — прежде чем чему-то доверять настолько, чтобы было страшно потерять.

Если не работает

Агент отвечает, но ответ — «не знаю».

Это ожидаемое поведение, когда в контексте нет ничего подтверждённого по теме. Ответ собирается из хранилища контекста, а извлечённое, которое никто не подтвердил, в него не попадает. Зафиксируйте решение или подтвердите извлечённый узел и повторите вопрос. Если вопрос возвращает тот же ответ, не хватает узла в вашем контексте, и предложение создать запись о решении — это ровно то, с чего стоит начать.

Агент показывает данные, которые не наши.

Относитесь к этому как к сбою изоляции, а не как к любопытству. Отзовите подключение в клиентском агенте, авторизуйтесь заново своей учётной записью и проверьте в настройках компании, какие подключения активны сейчас. Доступ выдаётся конкретному человеку, а компании разделены, поэтому агент, ответивший контекстом другой компании, настроен или авторизован неверно. До проверки авторизации не задавайте агенту больше ничего.

Агент попытался изменить узел или записать задачу.

«Только чтение» — режим по умолчанию, поэтому отклонённая запись — это работа системы по назначению: запрос отклонён и попал в журнал аудита. Посмотрите журнал, чтобы понять, что агент собирался сделать. Если запись была действительно нужна, разрешите её явно для этого подключения в настройках — и помните, что решение о доступе принимает человек, а не модель. После этого перечитайте журнал аудита и убедитесь, что изменилось ровно то, что вы ожидали.

Мы отключили коннектор, и часть контекста стала недоступна.

Любую интеграцию можно выключить, не сломав продукт, а данные остаются выгружаемыми без потери — это требование к коннекторам, а не вежливость. Подключите сервис заново, если он нужен в работе, или возьмите выгруженную копию и работайте с ней через универсальный путь: импорт и экспорт в Markdown, JSON и CSV. Если отключение действительно убрало данные, которые вы не выгружали, считайте это дефектом и сообщите о нём: выгрузка — это и есть страховка, которую продукт обещает.

Агент и интерфейс дают разные ответы на один и тот же вопрос.

Так происходить не должно, и это стоит зафиксировать: ответы агента и ответы в интерфейсе используют один и тот же механизм цитат и «не знаю», а расхождение между ними — дефект, а не возможность. Перед сообщением запишите оба ответа, сам вопрос, дату и версию контекста, на которой каждый из них построен: журнал прогонов хранит вход, выход и статус, а журнал аудита — сам вызов. С этими данными причину можно установить, а не угадать.