Skip to main content
Glama
deenesjakoruzh
jalehman

MCP Sage

by jalehman
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

mcp-sage

Сервер MCP (Model Context Protocol), который предоставляет инструменты для отправки запросов либо в модель O3 OpenAI, либо в Gemini 2.5 Pro от Google на основе количества токенов. Инструменты встраивают все указанные пути к файлам (рекурсивно для папок) в запрос. Это полезно для получения вторых мнений или подробных обзоров кода из модели, которая может точно обрабатывать множество контекстов.

Обоснование

Я активно использую Claude Code. Это отличный продукт, который хорошо подходит для моего рабочего процесса. Новые модели с большим объемом контекста кажутся действительно полезными для работы с более сложными кодовыми базами, где требуется больше контекста. Это позволяет мне продолжать использовать Claude Code в качестве инструмента разработки, одновременно используя возможности большого контекста O3 и Gemini 2.5 Pro для расширения ограниченного контекста Claude Code.

Related MCP server: Claude Code Review MCP

Выбор модели

Сервер автоматически выбирает подходящую модель на основе количества токенов и доступных ключей API:

  • Для меньших контекстов (≤ 200 тыс. токенов): использует модель O3 OpenAI (если установлен OPENAI_API_KEY)

  • Для больших контекстов (> 200 тыс. и ≤ 1 млн токенов): использует Gemini 2.5 Pro от Google (если установлен GEMINI_API_KEY)

  • Если содержимое превышает 1 млн токенов: возвращает информационную ошибку.

Резервное поведение:

  • Резервный ключ API :

    • Если OPENAI_API_KEY отсутствует, Gemini будет использоваться для всех контекстов в пределах лимита в 1 млн токенов.

    • Если GEMINI_API_KEY отсутствует, с помощью O3 можно обрабатывать только меньшие контексты (≤ 200 тыс. токенов)

    • Если оба ключа API отсутствуют, возвращается информационная ошибка.

  • Резервное сетевое подключение :

    • Если API OpenAI недоступен (ошибка сети), система автоматически возвращается к Gemini.

    • Это обеспечивает устойчивость к временным сбоям в работе сети у одного провайдера.

    • Для работы резервного варианта требуется установить GEMINI_API_KEY

Вдохновение

Этот проект черпает вдохновение из двух других проектов с открытым исходным кодом:

Обзор

В этом проекте реализован сервер MCP, предоставляющий три инструмента:

sage-opinion

  1. Принимает в качестве входных данных приглашение и список путей к файлам/каталогам.

  2. Упаковывает файлы в структурированный формат XML

  3. Измеряет количество токенов и выбирает подходящую модель:

    • O3 для ≤ 200 тыс. токенов

    • Gemini 2.5 Pro для > 200 тыс. и ≤ 1 млн токенов

  4. Отправляет объединенную подсказку + контекст в выбранную модель

  5. Возвращает ответ модели

sage-review

  1. Принимает в качестве входных данных инструкцию по изменению кода и список путей к файлам/каталогам.

  2. Упаковывает файлы в структурированный формат XML

  3. Измеряет количество токенов и выбирает подходящую модель:

    • O3 для ≤ 200 тыс. токенов

    • Gemini 2.5 Pro для > 200 тыс. и ≤ 1 млн токенов

  4. Создает специализированную подсказку, указывающую модели форматировать ответы с использованием блоков ПОИСК/ЗАМЕНА

  5. Отправляет объединенный контекст + инструкцию выбранной модели

  6. Возвращает предложения по редактированию, отформатированные как блоки ПОИСК/ЗАМЕНА для легкой реализации

sage-plan

  1. Принимает в качестве входных данных запрос на план внедрения и список путей к файлам/каталогам.

  2. Упаковывает файлы в структурированный формат XML

  3. Организует многомодельные дебаты для разработки высококачественного плана внедрения

  4. Модели критикуют и совершенствуют планы друг друга в ходе нескольких раундов.

  5. Возвращает выигрышный план внедрения с подробными шагами

sage-plan - Многомодельные и самостоятельные рабочие процессы

Инструмент sage-plan не запрашивает план у одной модели. Вместо этого он организует структурированные дебаты , которые длятся один или несколько раундов, а затем просит отдельную модель-судью (или ту же модель в режиме CoRT) выбрать победителя.

1. Многомодельный поток дебатов

flowchart TD
  S0[Start Debate] -->|determine models, judge, budgets| R1

  subgraph R1["Round 1"]
    direction TB
    R1GEN["Generation Phase<br/>*ALL models run in parallel*"]
    R1GEN --> R1CRIT["Critique Phase<br/>*ALL models critique others in parallel*"]
  end

  subgraph RN["Rounds 2 to N"]
    direction TB
    SYNTH["Synthesis Phase<br/>*every model refines own plan*"]
    SYNTH --> CONS[Consensus Check]
    CONS -->|Consensus reached| JUDGE
    CONS -->|No consensus & round < N| CRIT["Critique Phase<br/>*models critique in parallel*"]
    CRIT --> SYNTH
  end

  R1 --> RN
  JUDGE[Judgment Phase<br/>*judge model selects/merges plan*]
  JUDGE --> FP[Final Plan]

  classDef round fill:#e2eafe,stroke:#4169E1;
  class R1GEN,R1CRIT,SYNTH,CRIT round;
  style FP fill:#D0F0D7,stroke:#2F855A,stroke-width:2px
  style JUDGE fill:#E8E8FF,stroke:#555,stroke-width:1px

Ключевые этапы дискуссии о мультимоделях:

Фаза настройки

  • Система определяет доступные модели, выбирает судью и распределяет бюджеты токенов.

Раунд 1

  • Фаза генерации — каждая доступная модель (A, B, C и т. д.) параллельно пишет свой собственный план внедрения.

  • Фаза критики — каждая модель рассматривает все другие планы (но не свои собственные) и параллельно выдает структурированную критику.

Округляет от 2 до N (N по умолчанию равно 3)

  1. Фаза синтеза — каждая модель улучшает свой предыдущий план, используя полученные критические замечания (модели работают параллельно).

  2. Проверка консенсуса — модель судьи оценивает сходство между всеми текущими планами.

    • Если оценка ≥ 0,9, дебаты прекращаются раньше времени и переходят к суждению.

  3. Фаза критики — если консенсус не достигнут И мы не в финальном раунде, каждая модель снова критикует все остальные планы (параллельно)

Фаза суждения

  • После завершения всех раундов (или достижения раннего консенсуса) модель судьи (по умолчанию O3):

    • Выбирает один лучший план ИЛИ объединяет несколько планов в один лучший

    • Предоставляет оценку достоверности для своего выбора/синтеза

2. Поток самообсуждения — доступна одна модель

flowchart TD
  SD0[Start Self-Debate] --> R1

  subgraph R1["Round 1 - Initial Plans"]
    direction TB
    P1[Generate Plan 1] --> P2[Generate Plan 2<br/>*different approach*]
    P2 --> P3[Generate Plan 3<br/>*different approach*]
  end

  subgraph RN["Rounds 2 to N"]
    direction TB
    REF[Generate Improved Plan<br/>*addresses weaknesses in all previous plans*]
    DEC{More rounds left?}
    REF --> DEC
    DEC -->|Yes| REF
  end

  R1 --> RN
  DEC -->|No| FP[Final Plan = last plan generated]

  style FP fill:#D0F0D7,stroke:#2F855A,stroke-width:2px

Когда доступна только одна модель, используется подход «Цепочка рекурсивных мыслей» (CoRT) :

  1. Начальный всплеск — модель генерирует три отдельных плана, каждый из которых использует свой подход.

  2. Раунды уточнения — для каждого последующего раунда (от 2 до N, по умолчанию N=3):

    • Модель рассматривает все предыдущие планы

    • Он критикует их изнутри, выявляя сильные и слабые стороны.

    • Создает один новый улучшенный план, который устраняет ограничения более ранних планов.

  3. Окончательный выбор — последний сформированный план становится окончательным планом реализации.

Что на самом деле происходит в коде (краткая справка)

Фаза/Функциональность

Расположение кода

Примечания

Генерация подсказок

prompts/debatePrompts.generatePrompt

Добавляет заголовок «# План внедрения (Модель X)»

Критические подсказки

prompts/debatePrompts.critiquePrompt

Использует разделы «## Критика плана {ID}»

Подсказки по синтезу

prompts/debatePrompts.synthesizePrompt

Модель пересматривает свой план

Проверка консенсуса

дебатыOrchestrator.checkКонсенсус

Модель судьи возвращает JSON с consensusScore

Суждение

prompts/debatePrompts.judgePrompt

Судья возвращает "# Окончательный план реализации" + уверенность

Самостоятельная дискуссия

подсказки/debatePrompts.selfDebatePrompt

Цикл «Цепочка рекурсивных мыслей»

Соображения производительности и стоимости

⚠️ Важно: инструмент sage-plan может:

  • Выполнение займет значительное время (5–10 минут для нескольких моделей)

  • Потребление значительных токенов API из-за многочисленных раундов дебатов

  • Более высокие затраты, чем при подходах с одной моделью

Типичное использование ресурсов:

  • Многомодельные дебаты: в 2–4 раза больше токенов, чем при подходе с одной моделью

  • Время обработки: 5-10 минут в зависимости от сложности и доступности модели.

  • Стоимость API: 0,30–1,50 долл. США за генерацию плана (зависит от используемых моделей и сложности плана)

Предпосылки

  • Node.js (v18 или более поздняя версия)

  • Ключ API Google Gemini (для более масштабных контекстов)

  • Ключ API OpenAI (для меньших контекстов)

Установка

# Clone the repository
git clone https://github.com/your-username/mcp-sage.git
cd mcp-sage

# Install dependencies
npm install

# Build the project
npm run build

Переменные среды

Установите следующие переменные среды:

  • OPENAI_API_KEY : ваш ключ OpenAI API (для модели O3).

  • GEMINI_API_KEY : Ваш ключ API Google Gemini (для Gemini 2.5 Pro)

Использование

После сборки с помощью npm run build добавьте в конфигурацию MCP следующее:

OPENAI_API_KEY=your_openai_key GEMINI_API_KEY=your_gemini_key node /path/to/this/repo/dist/index.js

Вы также можете использовать переменные окружения, заданные в другом месте, например, в профиле оболочки.

Подсказка

Чтобы получить второе мнение по какому-либо вопросу, просто попросите высказать второе мнение.

Чтобы получить обзор кода, попросите провести обзор кода или экспертную оценку.

Оба варианта выигрывают от предоставления путей к файлам, которые вы хотите включить в контекст, но если они не указаны, то хост-LLM, вероятно, сам определит, что именно следует включить.

Отладка и мониторинг

Сервер предоставляет подробную информацию о мониторинге через возможность ведения журнала MCP. Эти журналы включают:

  • Статистика использования токенов и выбор модели

  • Количество файлов и документов, включенных в запрос

  • Метрики времени обработки запроса

  • Информация об ошибке при превышении лимита токенов

Журналы отправляются с помощью метода notifications/message протокола MCP, что гарантирует, что они не будут мешать коммуникации JSON-RPC. Клиенты MCP с поддержкой журналирования будут отображать эти журналы соответствующим образом.

Примеры записей журнала:

Token usage: 1,234 tokens. Selected model: o3-2025-04-16 (limit: 200,000 tokens)
Files included: 3, Document count: 3
Sending request to OpenAI o3-2025-04-16 with 1,234 tokens...
Received response from o3-2025-04-16 in 982ms
Token usage: 235,678 tokens. Selected model: gemini-2.5-pro-preview-03-25 (limit: 1,000,000 tokens)
Files included: 25, Document count: 18
Sending request to Gemini with 235,678 tokens...
Received response from gemini-2.5-pro-preview-03-25 in 3240ms

Использование инструментов

мудрец-мнение Инструмент

Инструмент sage-opinion принимает следующие параметры:

  • prompt (строка, обязательно): запрос для отправки выбранной модели.

  • paths (массив строк, обязательно): список путей к файлам для включения в качестве контекста

Пример вызова инструмента MCP (с использованием JSON-RPC 2.0):

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "sage-opinion",
    "arguments": {
      "prompt": "Explain how this code works",
      "paths": ["path/to/file1.js", "path/to/file2.js"]
    }
  }
}

Инструмент sage-review

Инструмент sage-review принимает следующие параметры:

  • instruction (строка, обязательно): Конкретные необходимые изменения или улучшения.

  • paths (массив строк, обязательно): список путей к файлам для включения в качестве контекста

Пример вызова инструмента MCP (с использованием JSON-RPC 2.0):

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "sage-review",
    "arguments": {
      "instruction": "Add error handling to the function",
      "paths": ["path/to/file1.js", "path/to/file2.js"]
    }
  }
}

Ответ будет содержать блоки SEARCH/REPLACE, которые вы можете использовать для реализации предлагаемых изменений:

<<<<<<< SEARCH
function getData() {
  return fetch('/api/data')
    .then(res => res.json());
}
=======
function getData() {
  return fetch('/api/data')
    .then(res => {
      if (!res.ok) {
        throw new Error(`HTTP error! Status: ${res.status}`);
      }
      return res.json();
    })
    .catch(error => {
      console.error('Error fetching data:', error);
      throw error;
    });
}
>>>>>>> REPLACE

Инструмент мудреца-плана

Инструмент sage-plan принимает следующие параметры:

  • prompt (строка, обязательно): Описание того, для чего вам нужен план внедрения

  • paths (массив строк, обязательно): список путей к файлам для включения в качестве контекста

Пример вызова инструмента MCP (с использованием JSON-RPC 2.0):

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "sage-plan",
    "arguments": {
      "prompt": "Create an implementation plan for adding user authentication to this application",
      "paths": ["src/index.js", "src/models/", "src/routes/"]
    }
  }
}

Ответ содержит подробный план реализации, включающий:

  1. Обзор архитектуры высокого уровня

  2. Конкретные шаги по внедрению

  3. Необходимы изменения в файле

  4. Стратегия тестирования

  5. Потенциальные проблемы и пути их смягчения

Этот план использует коллективный интеллект нескольких моделей ИИ (или тщательную самопроверку одной моделью) и обычно содержит более надежные, продуманные и подробные рекомендации, чем подход с одним проходом.

Проведение тестов

Для тестирования инструментов:

# Test the sage-opinion tool
OPENAI_API_KEY=your_openai_key GEMINI_API_KEY=your_gemini_key node test/run-test.js

# Test the sage-review tool
OPENAI_API_KEY=your_openai_key GEMINI_API_KEY=your_gemini_key node test/test-expert.js

# Test the sage-plan tool
OPENAI_API_KEY=your_openai_key GEMINI_API_KEY=your_gemini_key node test/run-sage-plan.js

# Test the model selection logic specifically
OPENAI_API_KEY=your_openai_key GEMINI_API_KEY=your_gemini_key node test/test-o3.js

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

Структура проекта

  • src/index.ts : Основная реализация сервера MCP с определениями инструментов

  • src/pack.ts : Инструмент для упаковки файлов в структурированный формат XML

  • src/tokenCounter.ts : Утилиты для подсчета токенов в приглашении

  • src/gemini.ts : Реализация клиента API Gemini

  • src/openai.ts : Реализация клиента API OpenAI для модели O3

  • src/debateOrchestrator.ts : Многомодельная оркестровка дебатов для sage-plan

  • src/prompts/debatePrompts.ts : Шаблоны для подсказок и инструкций по дебатам

  • test/run-test.js : Тест для инструмента sage-opinion

  • test/test-expert.js : Тест для инструмента sage-review

  • test/run-sage-plan.js : Тест для инструмента sage-plan

  • test/test-o3.js : Тест логики выбора модели

Лицензия

МСК

Available Tools

3 tools
sage-opinionA

Send a prompt to sage-like model for its opinion on a matter.

Include the paths to all relevant files and/or directories that are pertinent to the matter.

IMPORTANT: All paths must be absolute paths (e.g., /home/user/project/src), not relative paths.

Do not worry about context limits; feel free to include as much as you think is relevant. If you include too much it will error and tell you, and then you can include less. Err on the side of including more context.
ParametersJSON Schema
NameRequiredDescriptionDefault
pathsYesPaths to include as context. MUST be absolute paths (e.g., /home/user/project/src). Including directories will include all files contained within recursively.
promptYesThe prompt to send to the external model.

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: the tool sends a prompt to an external model, handles file paths as context, uses absolute paths, and may error if too much context is included. However, it lacks details on rate limits, authentication needs, or what the 'sage-like model' entails (e.g., model type, limitations). The description doesn't contradict annotations since none exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded, with the core purpose stated first. It uses bullet-like formatting for key points (paths, absolute paths, context limits), but includes some redundancy (e.g., repeating absolute path requirement). Most sentences earn their place by clarifying usage, though it could be slightly more streamlined.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is somewhat complete but has gaps. It covers the basic operation and constraints, but lacks details on the model's behavior, error handling specifics, or output expectations. Without annotations or an output schema, more context on what 'opinion' entails would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters ('paths' and 'prompt') with descriptions. The description adds minimal value beyond the schema: it reiterates the need for absolute paths and context inclusion but doesn't provide additional syntax, format details, or examples. Baseline 3 is appropriate as the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Send a prompt to sage-like model for its opinion on a matter.' It specifies the verb ('send'), resource ('sage-like model'), and action ('for its opinion'). However, it doesn't explicitly differentiate from sibling tools like 'sage-plan' or 'sage-review' beyond the 'opinion' focus, which is implied but not contrasted.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context: 'Include the paths to all relevant files and/or directories that are pertinent to the matter' and advises on absolute paths and context limits. It implicitly suggests using this tool for opinion-seeking tasks, but it doesn't explicitly state when to choose this over siblings like 'sage-plan' or 'sage-review', nor does it list exclusions or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sage-planA

Generate an implementation plan via multi-model debate.

This tool leverages multiple AI models to debate, critique, and refine implementation plans.

Models will generate initial plans, critique each other's work, refine their plans based on critiques,
and finally produce a consensus plan that combines the best ideas.

IMPORTANT: All paths must be absolute paths (e.g., /home/user/project/src), not relative paths.

The process creates detailed, well-thought-out implementation plans that benefit from
diverse model perspectives and iterative refinement.

When the optional outputPath parameter is provided, the final plan will be saved to that file path,
and a complete transcript of the debate will be saved to a companion file with "-full-transcript"
added to the filename. This is strongly recommended for preserving the expensive results of the debate.
ParametersJSON Schema
NameRequiredDescriptionDefault
maxTokensNoMaximum token budget for the debate
outputPathNoMarkdown file path to save the final plan. Will also save a full transcript to a '-full-transcript.md' suffixed file.
pathsYesPaths to include as context. MUST be absolute paths (e.g., /home/user/project/src). Including directories will include all files contained within recursively.
promptYesThe task to create an implementation plan for
roundsNoNumber of debate rounds (default: 3)

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the multi-model debate process (generation, critique, refinement, consensus), the creation of detailed plans, and file-saving behavior when outputPath is provided. It also notes the expense of the debate, which is useful context. However, it lacks details on error handling or performance expectations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded, starting with the core purpose. Most sentences add value, such as explaining the debate process and file-saving behavior. However, some redundancy exists (e.g., reiterating absolute paths), and the structure could be slightly tighter by integrating the IMPORTANT note more seamlessly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a 5-parameter tool with no annotations and no output schema, the description does a good job of covering the tool's behavior and key usage aspects. It explains the debate process and file outputs, but it could be more complete by detailing the format of the output (e.g., Markdown structure) or potential limitations, which would help set clearer expectations for the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds some value by emphasizing the importance of absolute paths for the 'paths' parameter and explaining the file-saving behavior for 'outputPath', but it does not provide additional semantic context beyond what the schema offers, such as typical use cases for parameters like 'maxTokens' or 'rounds'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Generate an implementation plan via multi-model debate.' It specifies the verb ('generate') and resource ('implementation plan'), and distinguishes it from siblings by detailing the unique multi-model debate process, which is not implied by the sibling names 'sage-opinion' and 'sage-review'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool: for creating detailed, well-thought-out implementation plans through iterative debate. However, it does not explicitly state when not to use it or mention alternatives like the sibling tools, which could help differentiate use cases more precisely.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sage-reviewA

Send code to the sage model for expert review and get specific edit suggestions as SEARCH/REPLACE blocks.

Use this tool any time the user asks for a "sage review" or "code review" or "expert review".

This tool includes the full content of all files in the specified paths and instructs the model to return edit suggestions in a specific format with search and replace blocks.

IMPORTANT: All paths must be absolute paths (e.g., /home/user/project/src), not relative paths.

If the user hasn't provided specific paths, use as many paths to files or directories as you're aware of that are useful in the context of the prompt.
ParametersJSON Schema
NameRequiredDescriptionDefault
instructionYesThe specific changes or improvements needed.
pathsYesPaths to include as context. MUST be absolute paths (e.g., /home/user/project/src). Including directories will include all files contained within recursively.

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the tool includes 'full content of all files in the specified paths' and returns 'edit suggestions in a specific format with search and replace blocks', which adds useful context beyond basic functionality. However, it doesn't cover potential limitations like rate limits, authentication needs, or error conditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and appropriately sized, with key information front-loaded. However, the second paragraph could be more concise, and the 'IMPORTANT' section repeats path information already stated elsewhere, slightly reducing efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (code review with file processing) and lack of annotations/output schema, the description is moderately complete. It explains the core behavior and format of suggestions but doesn't detail what happens with invalid paths, how large files are handled, or the structure of the returned edit blocks, leaving some gaps for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description reinforces that paths 'must be absolute paths' and mentions directory recursion, but this is already covered in the schema. It adds minimal value beyond what the structured schema provides, meeting the baseline for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('send code', 'get specific edit suggestions') and resources ('sage model', 'SEARCH/REPLACE blocks'). It distinguishes from sibling tools by specifying this is for 'expert review' with edit suggestions, unlike 'sage-opinion' or 'sage-plan' which likely serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidelines: 'Use this tool any time the user asks for a "sage review" or "code review" or "expert review"'. It also includes alternative handling when paths aren't specified ('use as many paths... as you're aware of'), giving clear context for when and how to invoke the tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv1.0.0
    • First observedsage-opinion
    • First observedsage-plan
    • First observedsage-review
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: sage-opinion provides opinions on matters, sage-plan generates implementation plans through debate, and sage-review offers code review with edit suggestions. There is no overlap in functionality, and the descriptions clearly differentiate their roles.

Naming Consistency5/5

All tool names follow a consistent 'sage-' prefix with a descriptive suffix (opinion, plan, review), using kebab-case throughout. This pattern is predictable and enhances readability, making it easy to identify the tool's function at a glance.

Tool Count4/5

With 3 tools, the count is appropriate for a server focused on AI-assisted development tasks, as it covers key areas like opinion generation, planning, and code review. It is slightly lean but reasonable, as each tool serves a distinct and valuable purpose without redundancy.

Completeness4/5

The tool set covers core AI-assisted development workflows: opinion generation, planning, and code review. Minor gaps exist, such as the lack of tools for executing plans or managing project states, but agents can work around these by combining tools or using external methods.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Yellhorn MCP

    msnidal
    F
    license
    A
    quality
    D
    maintenance
    An MCP server that connects Gemini 2.5 Pro to Claude Code, enabling users to generate detailed implementation plans based on their codebase and receive feedback on code changes.
    5
    14
    -

  • gpal

    tobert
    A
    license
    A
    quality
    D
    maintenance
    An MCP server that gives your IDE or agent access to Google Gemini with autonomous codebase exploration, enabling deep code analysis, architectural reviews, and bug hunting.
    20
    10
    MIT

  • Gemini Code Assist MCP

    VinnyVanGogh
    A
    license
    Not graded
    quality
    C
    maintenance
    An MCP server that integrates Google Gemini CLI with Claude Code for AI-powered development assistance, enabling code review, bug analysis, feature planning, and code explanation without requiring an API key.
    8
    MIT