genai-solutions-mcp

Сервер MCP, который предоставляет курируемую базу данных инструментов генеративного ИИ — 1 197 записей, которые я веду в Notion с 2023 года — в виде четырех инструментов, к которым ИИ-ассистент может обращаться напрямую.

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

> Which open-source tools in here run locally and have a CLI?
> Compare Firecrawl and the other scraping options.

Install

npm install
npm run build
npm start

Без API-ключа, без сети, без базы данных. Набор данных поставляется вместе с репозиторием.

Зарегистрируйте его в MCP-клиенте (здесь показан Claude Desktop):

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

Related MCP server: disvr

Tools

Design decisions

Зафиксированный снимок, а не живой прокси Notion. Очевидное решение — вызывать Notion API при каждом вызове инструмента. Это также делает репозиторий бесполезным для всех, кроме меня: вам понадобится мой токен и моя база данных. Вместо этого scripts/sync-notion.ts экспортирует Notion в data/solutions.json, который здесь версионируется, и сервер читает только этот файл. Компромисс — свежесть (данные актуальны на момент последней синхронизации) против сервера, который любой может клонировать и запустить за пятнадцать секунд, без учетных данных, без сетевой зависимости во время вызова и без ограничения скорости. Базовые данные меняются не чаще раза в неделю, поэтому свежесть — это то, чем легче пожертвовать.

Поиск подстрок, а не эмбеддинги. ~1100 записей — это субмиллисекундное линейное сканирование. Векторный индекс добавил бы этап эмбеддинга в синхронизацию, зависимость от модели, недетерминированные результаты и индекс, который нужно поддерживать согласованным со снимком — в обмен на семантический recall на корпусе, где полезные запросы в основном состоят из имен и категорий. Если набор данных вырастет на порядок или сводки станут длиннее, это первое, что нужно пересмотреть.

Поиск возвращает проекцию, а не полные записи. search_solutions возвращает только id, name, type и url. Возвращение полных записей для запроса из 20 результатов потратило бы большой объем контекста агента на поля, которые обычно не нужны; get_solution существует для тех случаев, когда они нужны.

Белый список свойств в синхронизации, а не черный. База данных Notion содержит внутреннее состояние рабочего процесса и вложения, которым не место в публичном доступе. scripts/sync-notion.ts перечисляет свойства, которые экспортирует, так что добавление приватного столбца в Notion впоследствии не сможет незаметно утечь сюда.

Known limitations

• Type в Notion — это одиночный выбор, поэтому каждый инструмент имеет ровно одну категорию, даже если подошли бы две.

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

• Нет ранжирования по релевантности, кроме взвешенного по полям поиска подстрок.

• Маркировка атрибутов неравномерна. Local и Open Source применялись в разные периоды с разными привычками, и они пересекаются только в одной записи, хотя многие инструменты подходят для обоих. Фильтры честно отражают то, что помечено, а не то, что верно — свойство, которое этот набор данных разделяет с большинством реальных внутренних баз данных.

• Разрешение Node зависит от среды хоста. Было замечено, что сервер запускается под двумя разными установками Node на одной машине в зависимости от контекста запуска. Закрепите путь к среде выполнения в конфигурации клиента, если это для вас важно.

Syncing (maintainer only)

NOTION_TOKEN=… NOTION_DATABASE_ID=… npm run sync
git diff data/solutions.json   # read it before committing

License

MIT