Почему свой MCP-сервер для CRM полезнее встроенного

У крупных CRM появились MCP-серверы. Почти у всех. И меня каждую неделю спрашивают: что осталось строить? Отвечаю.

Встроенный MCP-сервер отвечает на вопросы про CRM. Это весь его потолок. А проблемы, которые реально стоят денег, живут не внутри одной системы, а в стыках между ними.

Задача, которая затихла. Клиент, которому я не писал девять дней. Открытый счёт, привязанный к этому же клиенту. По отдельности каждый факт — пустяк. Вместе они сигнал: решение, о котором я не знал, что должен его принять. Ни одна система не хранит все три данных. Значит, ни один односторонний MCP-сервер не покажет их рядом.

Соединить домены, а не подсказывать

Поэтому я собрал Founders OS. Это не новый инструмент, это один проход через CRM, учёт и историю решений одновременно. Сервер не говорит, что делать. Он показывает связь: счёт, тишина и зависшая задача оказываются в одном ответе. Решение остаётся за мной.

Я не хочу иметь дело с системой, которая притворяется, что у неё есть суждение о моём бизнесе. Полезная версия скромнее и честнее: покажи то, о чём я сам не догадался бы спросить.

Технически это выглядит так: сервер читает живые записи через типизированные инструменты и соединяет их за один проход. Спрашиваешь про клиента — получаешь карточку, что выставлено, что оплачено, что осталось открытым, и все связанные переговоры и решения. Один вопрос, один ответ, три домена. Когда данные меняются каждый час, это принципиально: нет индекса, который успевает устареть.

Где живут данные

В собственном Postgres. Сервер работает через stdio, разворачивается самостоятельно, лицензия MIT. Это осознанный выбор, а не слоган. Данные бизнеса — категория, в которой решение о хранении я хочу оставлять за собой. И если я передумаю, мне не придётся участвовать в миграции. Развернул, указал на базу, готово.

При этом сервер работает с любым MCP-клиентом. Я использую его и в Claude, и в Cursor против одной и той же базы. Контекст следует за работой, а не за приложением.

Встроенный или свой: сравнение

Честные ограничения

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

Второе ограничение — сервер работает настолько хорошо, насколько наполнена база. Пустая база — бесполезные ответы. Это верно для любой системы учёта, и здесь не исключение.

Что стоит взять на вооружение

Если вы тоже думаете о собственном MCP-сервере, вот принципы, которые я вынес из этой затеи:

• Не просите сервер думать за вас. Пусть показывает отношения, а решение принимаете вы.
• Читайте живые данные, а не индекс. Когда информация меняется каждый час, любой кэш врёт.
• Соединяйте домены в одном проходе. Один вопрос — один ответ — несколько систем.
• Храните данные у себя. Решение о хранении и миграции должно оставаться вашим.
• Используйте любой MCP-клиент. Один сервер одинаково хорошо работает и в Claude, и в Cursor.

Встроенный MCP-сервер полезен, когда вопрос живёт внутри CRM. Мои вопросы живут на стыках, поэтому я собрал свой. Если ваша работа тоже не умещается в одну систему — возможно, такая же архитектура пригодится и вам.