Skip to main content
Glama
deenesjakoruzh
jalehman

MCP Sage

by jalehman
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

mcp-sage

Un servidor MCP (Protocolo de Contexto de Modelo) que proporciona herramientas para enviar solicitudes al modelo O3 de OpenAI o a Gemini 2.5 Pro de Google, según el número de tokens. Las herramientas integran todas las rutas de archivo referenciadas (de forma recursiva para las carpetas) en la solicitud. Esto resulta útil para obtener segundas opiniones o revisiones de código detalladas de un modelo capaz de gestionar gran cantidad de contexto con precisión.

Razón fundamental

Uso Claude Code con frecuencia. Es un producto excelente que se adapta bien a mi flujo de trabajo. Sin embargo, los modelos más recientes con gran cantidad de contexto parecen muy útiles para trabajar con bases de código más complejas donde se necesita más contexto. Esto me permite seguir usando Claude Code como herramienta de desarrollo y, al mismo tiempo, aprovechar las amplias capacidades de contexto de O3 y Gemini 2.5 Pro para ampliar el contexto limitado de Claude Code.

Related MCP server: Claude Code Review MCP

Selección de modelos

El servidor selecciona automáticamente el modelo apropiado según el recuento de tokens y las claves API disponibles:

  • Para contextos más pequeños (≤ 200 000 tokens): utiliza el modelo O3 de OpenAI (si OPENAI_API_KEY está configurado)

  • Para contextos más grandes (> 200 000 y ≤ 1 000 000 de tokens): utiliza Gemini 2.5 Pro de Google (si GEMINI_API_KEY está configurado)

  • Si el contenido supera 1 millón de tokens: devuelve un error informativo

Comportamiento de respaldo:

  • Clave API de respaldo :

    • Si falta OPENAI_API_KEY, se utilizará Gemini para todos los contextos dentro de su límite de tokens de 1 millón

    • Si falta GEMINI_API_KEY, solo se pueden procesar contextos más pequeños (≤ 200K tokens) con O3

    • Si faltan ambas claves API, se devuelve un error informativo

  • Conectividad de red alternativa :

    • Si la API de OpenAI no está disponible (error de red), el sistema recurre automáticamente a Gemini.

    • Esto proporciona resiliencia frente a problemas de red temporales con un proveedor.

    • Requiere que GEMINI_API_KEY esté configurado para que la opción de respaldo funcione

Inspiración

Este proyecto se inspira en otros dos proyectos de código abierto:

Descripción general

Este proyecto implementa un servidor MCP que expone tres herramientas:

sage-opinion

  1. Toma un mensaje y una lista de rutas de archivos/directorios como entrada

  2. Empaqueta los archivos en un formato XML estructurado

  3. Mide el número de tokens y selecciona el modelo apropiado:

    • O3 para ≤ 200K tokens

    • Gemini 2.5 Pro para más de 200 000 y menos de 1 000 tokens

  4. Envía el mensaje combinado + contexto al modelo seleccionado

  5. Devuelve la respuesta del modelo.

sage-review

  1. Toma una instrucción para cambios de código y una lista de rutas de archivos/directorios como entrada

  2. Empaqueta los archivos en un formato XML estructurado

  3. Mide el número de tokens y selecciona el modelo apropiado:

    • O3 para ≤ 200K tokens

    • Gemini 2.5 Pro para más de 200 000 y menos de 1 000 tokens

  4. Crea un mensaje especializado que indica al modelo cómo formatear las respuestas usando bloques BUSCAR/REEMPLAZAR

  5. Envía el contexto + instrucción combinado al modelo seleccionado

  6. Devuelve sugerencias de edición formateadas como bloques de BÚSQUEDA/REEMPLAZAR para una fácil implementación

sage-plan

  1. Toma un mensaje solicitando un plan de implementación y una lista de rutas de archivos/directorios como entrada

  2. Empaqueta los archivos en un formato XML estructurado

  3. Orquesta un debate multimodelo para generar un plan de implementación de alta calidad

  4. Los modelos critican y refinan los planes de los demás a través de múltiples rondas.

  5. Devuelve el plan de implementación ganador con pasos detallados.

sage-plan - Flujos de trabajo multimodelo y de autodebate

La herramienta sage-plan no le pide a un solo modelo un plan. En cambio, organiza un debate estructurado que se desarrolla en una o más rondas y luego le pide a un modelo de juez independiente (o al mismo modelo en modo CoRT) que elija al ganador.

1. Flujo de debate multimodelo

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

Fases clave en el debate multimodelo:

Fase de configuración

  • El sistema determina los modelos disponibles, selecciona un juez y asigna presupuestos de tokens.

Ronda 1

  • Fase de generación : cada modelo disponible (A, B, C, etc.) escribe su propio plan de implementación en paralelo

  • Fase de crítica : cada modelo revisa todos los demás planes (nunca el suyo propio) y produce críticas estructuradas en paralelo.

Rondas 2 a N (N por defecto es 3)

  1. Fase de síntesis : cada modelo mejora su plan anterior utilizando las críticas que recibió (los modelos trabajan en paralelo)

  2. Comprobación de consenso : el modelo del juez evalúa la similitud entre todos los planes actuales

    • Si la puntuación es ≥ 0,9, el debate se detiene antes de tiempo y pasa al Juicio.

  3. Fase de crítica : si no se llega a un consenso Y no estamos en la ronda final, cada modelo vuelve a criticar todos los demás planes (en paralelo).

Fase de juicio

  • Después de completar todas las rondas (o alcanzar un consenso temprano), el modelo de juez (O3 por defecto):

    • Selecciona el mejor plan único O fusiona varios planes en uno superior

    • Proporciona una puntuación de confianza para su selección/síntesis

2. Flujo de autodebate: modelo único disponible

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

Cuando solo hay un modelo disponible, se utiliza un enfoque de cadena de pensamientos recursivos (CoRT) :

  1. Explosión inicial : el modelo genera tres planes distintos, cada uno con un enfoque diferente

  2. Rondas de refinamiento : para cada ronda subsiguiente (2 a N, predeterminado N=3):

    • El modelo revisa todos los planes anteriores

    • Los critica internamente, identificando fortalezas y debilidades.

    • Produce un nuevo plan mejorado que aborda las limitaciones de los planes anteriores.

  3. Selección final : el último plan generado se convierte en el plan de implementación final

Qué sucede realmente en el código (referencia rápida)

Fase / Funcionalidad

Ubicación del código

Notas

Avisos de generación

indicaciones/debatePrompts.generatePrompt

Añade el encabezado "# Plan de Implementación (Modelo X)"

Indicaciones de crítica

indicaciones/debatePrompts.critiquePrompt

Utiliza las secciones "## Crítica del plan {ID}"

Indicaciones de síntesis

indicaciones/debatePrompts.synthesizePrompt

Modelo revisa su propio plan

Comprobación de consenso

debateOrchestrator.checkConsensus

El modelo Judge devuelve JSON con consensusScore

Juicio

indicaciones/debatePrompts.judgePrompt

Juez devuelve "#PlanDefinitivoDeImplementación" + confianza

Indicación de autodebate

indicaciones/debatePrompts.selfDebatePrompt

Bucle de cadena de pensamientos recursivos

Consideraciones sobre rendimiento y costos

⚠️ Importante: La herramienta sage-plan puede:

  • Toma una cantidad significativa de tiempo completarlo (5 a 10 minutos con varios modelos)

  • Consumir una cantidad sustancial de tokens API debido a múltiples rondas de debate

  • Incurren en costos más altos que los enfoques de modelo único

Uso típico de recursos:

  • Debate multimodelo: 2-4 veces más tokens que con un enfoque de modelo único

  • Tiempo de procesamiento: 5-10 minutos dependiendo de la complejidad y disponibilidad del modelo.

  • Costos de API: $0,30 a $1,50 por generación de plan (varía según los modelos utilizados y la complejidad del plan)

Prerrequisitos

  • Node.js (v18 o posterior)

  • Una clave API de Google Gemini (para contextos más amplios)

  • Una clave API de OpenAI (para contextos más pequeños)

Instalación

# 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

Variables de entorno

Establezca las siguientes variables de entorno:

  • OPENAI_API_KEY : Su clave API de OpenAI (para el modelo O3)

  • GEMINI_API_KEY : Su clave API de Google Gemini (para Gemini 2.5 Pro)

Uso

Después de compilar con npm run build , agregue lo siguiente a su configuración de MCP:

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

También puedes utilizar variables de entorno configuradas en otro lugar, como en tu perfil de shell.

Incitación

Para obtener una segunda opinión sobre algo, simplemente solicite una segunda opinión.

Para obtener una revisión de código, solicite una revisión de código o una revisión de un experto.

Ambos se benefician al proporcionar rutas de archivos que desea que se incluyan en el contexto, pero si se omiten, el LLM del host probablemente inferirá qué incluir.

Depuración y monitorización

El servidor proporciona información de monitorización detallada mediante la función de registro de MCP. Estos registros incluyen:

  • Estadísticas de uso de tokens y selección de modelos

  • Número de archivos y documentos incluidos en la solicitud

  • Métricas del tiempo de procesamiento de solicitudes

  • Información de error cuando se superan los límites de tokens

Los registros se envían mediante el método notifications/message del protocolo MCP, lo que garantiza que no interfieran con la comunicación JSON-RPC. Los clientes MCP compatibles con el registro mostrarán estos registros correctamente.

Ejemplos de entradas de registro:

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

Usando las herramientas

Herramienta de opinión de sabios

La herramienta sage-opinion acepta los siguientes parámetros:

  • prompt (cadena, obligatorio): el mensaje que se enviará al modelo seleccionado

  • paths (matriz de cadenas, obligatoria): lista de rutas de archivos para incluir como contexto

Ejemplo de llamada a la herramienta MCP (usando 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"]
    }
  }
}

Herramienta de revisión de sage

La herramienta sage-review acepta los siguientes parámetros:

  • instruction (cadena, obligatoria): Los cambios o mejoras específicos necesarios

  • paths (matriz de cadenas, obligatoria): lista de rutas de archivos para incluir como contexto

Ejemplo de llamada a la herramienta MCP (usando 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"]
    }
  }
}

La respuesta contendrá bloques BUSCAR/REEMPLAZAR que puedes usar para implementar los cambios sugeridos:

<<<<<<< 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

Herramienta de planificación de salvia

La herramienta sage-plan acepta los siguientes parámetros:

  • prompt (cadena, obligatorio): Descripción de lo que necesita un plan de implementación para

  • paths (matriz de cadenas, obligatoria): lista de rutas de archivos para incluir como contexto

Ejemplo de llamada a la herramienta MCP (usando 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/"]
    }
  }
}

La respuesta contiene un plan de implementación detallado con:

  1. Descripción general de la arquitectura de alto nivel

  2. Pasos de implementación específicos

  3. Se necesitan cambios de archivo

  4. Estrategia de prueba

  5. Posibles desafíos y mitigaciones

Este plan se beneficia de la inteligencia colectiva de múltiples modelos de IA (o de una autoevaluación exhaustiva por parte de un solo modelo) y generalmente contiene recomendaciones más sólidas, reflexivas y detalladas que un enfoque de una sola pasada.

Ejecución de las pruebas

Para probar las herramientas:

# 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

Nota : La prueba del plan sabio puede tardar entre 5 y 15 minutos en ejecutarse, ya que organiza un debate de múltiples modelos.

Estructura del proyecto

  • src/index.ts : La implementación principal del servidor MCP con definiciones de herramientas

  • src/pack.ts : Herramienta para empaquetar archivos en un formato XML estructurado

  • src/tokenCounter.ts : Utilidades para contar tokens en un mensaje

  • src/gemini.ts : Implementación del cliente API de Gemini

  • src/openai.ts : Implementación del cliente de API de OpenAI para el modelo O3

  • src/debateOrchestrator.ts : Orquestación de debates multimodelo para sage-plan

  • src/prompts/debatePrompts.ts : Plantillas para indicaciones e instrucciones de debate

  • test/run-test.js : Prueba para la herramienta sage-opinion

  • test/test-expert.js : Prueba para la herramienta sage-review

  • test/run-sage-plan.js : Prueba para la herramienta sage-plan

  • test/test-o3.js : Prueba de la lógica de selección del modelo

Licencia

ISC

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