Skip to main content
Glama
deenesjakoruzh
jalehman

MCP Sage

by jalehman
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

mcp-sage

An MCP (Model Context Protocol) server that provides tools for sending prompts to OpenAI's GPT-5, GPT-4.1, Google's Gemini 2.5 Pro, or Anthropic's Claude Opus 4.1 based on token count and configuration. The tools embed all referenced filepaths (recursively for folders) in the prompt. This is useful for getting second opinions or detailed code reviews from models that can handle large amounts of context accurately.

Rationale

I make heavy use of Claude Code. It's a great product that works well for my workflow. Newer models with large amounts of context seem really useful though for dealing with more complex codebases where more context is needed. This lets me continue to use Claude Code as a development tool while leveraging the large context capabilities of GPT-5, Gemini 2.5 Pro, and other models to augment Claude Code's limited context.

Related MCP server: Claude Code Review MCP

Model Selection

The server automatically selects the appropriate model based on token count, with configuration defined in models.yaml:

  • For smaller contexts (≤ 400K tokens): Uses OpenAI's GPT-5 (if OPENAI_API_KEY is set)

  • For medium contexts (≤ 1M tokens): Uses Google's Gemini 2.5 Pro (if GEMINI_API_KEY is set)

  • For fallback (≤ 1M tokens): Uses OpenAI's GPT-4.1

  • If the content exceeds 1M tokens: Returns an informative error

Fallback behavior:

  • API Key Fallback:

    • If OPENAI_API_KEY is missing, Gemini will be used for all contexts within its 1M token limit

    • If GEMINI_API_KEY is missing, only smaller contexts can be processed with OpenAI models

    • If required API keys are missing, an informative error is returned

Inspiration

This project draws inspiration from two other open source projects:

Overview

This project implements an MCP server that exposes two primary tools:

sage-opinion

  1. Takes a prompt and a list of file/dir paths as input

  2. Packs the files into a structured XML format

  3. Measures the token count and selects the appropriate model:

    • GPT-5 for ≤ 400K tokens

    • Gemini 2.5 Pro for > 400K and ≤ 1M tokens

    • GPT-4.1 as fallback for ≤ 1M tokens

  4. Sends the combined prompt + context to the selected model

  5. Returns the model's response

sage-review

  1. Takes an instruction for code changes and a list of file/dir paths as input

  2. Packs the files into a structured XML format

  3. Measures the token count and selects the appropriate model:

    • GPT-5 for ≤ 400K tokens

    • Gemini 2.5 Pro for > 400K and ≤ 1M tokens

    • GPT-4.1 as fallback for ≤ 1M tokens

  4. Creates a specialized prompt instructing the model to format responses using SEARCH/REPLACE blocks

  5. Sends the combined context + instruction to the selected model

  6. Returns edit suggestions formatted as SEARCH/REPLACE blocks for easy implementation

Debate Mode

Both sage-opinion and sage-review support an optional debate mode that can be enabled by adding debate: true to the arguments. When enabled, the system orchestrates a structured debate between multiple models to generate higher-quality responses.

1. Multi-Model Debate Flow

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 response*]
  JUDGE --> FP[Final Response]

  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

Key phases in the multi-model debate:

Setup Phase

  • The system determines available models, selects a judge, and allocates token budgets

Round 1

  • Generation Phase - Every available model (A, B, C, etc.) generates its response in parallel

  • Critique Phase - Each model reviews all other responses (never its own) and produces structured critiques in parallel

Rounds 2 to N (N defaults to 3)

  1. Synthesis Phase - Each model improves its previous response using critiques it received (models work in parallel)

  2. Consensus Check - The judge model scores similarity between all current responses

    • If score ≥ 0.9, the debate stops early and jumps to Judgment

  3. Critique Phase - If consensus is not reached AND we're not in the final round, each model critiques all other responses again (in parallel)

Judgment Phase

  • After completing all rounds (or reaching early consensus), the judge model (Claude Opus 4.1 by default):

    • For sage-opinion: Selects the single best response (no synthesis)

    • For sage-review: Can either select the best response OR merge multiple responses

    • Provides a confidence score for its selection/synthesis

2. Self-Debate Flow - Single Model Available

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

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

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

  R1 --> RN
  DEC -->|No| FP[Final Response = last response generated]

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

When only one model is available, a Chain of Recursive Thoughts (CoRT) approach is used:

  1. Initial Burst - The model generates three distinct responses, each taking a different approach

  2. Refinement Rounds - For each subsequent round (2 to N, default N=3):

    • The model reviews all previous responses

    • It critiques them internally, identifying strengths and weaknesses

    • It produces one new improved response that addresses limitations in earlier responses

  3. Final Selection - The last response generated becomes the final output

What Actually Happens in Code (quick reference)

Phase / Functionality

Code Location

Notes

Generation Prompts

prompts/debatePrompts.generatePrompt

Creates initial responses from each model

Critique Prompts

prompts/debatePrompts.critiquePrompt

Uses "## Critique of {ID}" sections

Synthesis Prompts

prompts/debatePrompts.synthesizePrompt

Model revises its own response

Consensus Check

orchestrator/debateOrchestrator

Judge model returns JSON with consensusScore

Judgment

prompts/debatePrompts.judgePrompt

Judge returns final response + confidence

Self-Debate Prompt

prompts/debatePrompts.selfDebatePrompt

Chain-of-Recursive-Thoughts loop

Performance and Cost Considerations

⚠️ Important: When using debate mode:

  • It can take more time to complete (2-5 minutes with multiple models)

  • Consumes more API tokens due to multiple rounds of debate

  • Incurs higher costs than single-model approaches

Typical resource usage:

  • Multi-model debate: 2-4x more tokens than a single model approach

  • Processing time: 2-5 minutes depending on complexity and model availability

  • API costs vary by models used and complexity

Prerequisites

  • Node.js (v18 or later)

  • API keys for the models you want to use:

    • OpenAI API key (for GPT-5 and GPT-4.1)

    • Google Gemini API key (for Gemini 2.5 Pro)

    • Anthropic API key (for Claude Opus 4.1 as judge in debates)

Note: While the server can function with just one API key, it works best when all three are provided. This enables:

  • Optimal model selection based on token count

  • Multi-model debates for higher quality responses

  • Claude Opus 4.1 as an impartial judge in debate mode

Installation

Installing via Smithery

To install Sage for Claude Desktop automatically via Smithery:

npx -y @smithery/cli install @jalehman/mcp-sage --client claude

Installing manually

# 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

Environment Variables

Set the following environment variables:

  • OPENAI_API_KEY: Your OpenAI API key (for GPT-5 and GPT-4.1 models)

  • GEMINI_API_KEY: Your Google Gemini API key (for Gemini 2.5 Pro)

  • ANTHROPIC_API_KEY: Your Anthropic API key (for Claude Opus 4.1)

Recommended: Provide all three API keys for the best experience. This ensures:

  • The server can select the optimal model for any token count

  • Debate mode works with multiple diverse models

  • Claude Opus 4.1 serves as an effective judge in debates

Usage

After building with npm run build, add the following to your MCP configuration:

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

You can also use environment variables set elsewhere, like in your shell profile.

Prompting

To get a second opinion on something just ask for a second opinion.

To get a code review, ask for a code review or expert review.

Both of these benefit from providing paths of files that you wnat to be included in context, but if omitted the host LLM will probably infer what to include.

Debugging and Monitoring

The server provides detailed monitoring information via the MCP logging capability. These logs include:

  • Token usage statistics and model selection

  • Number of files and documents included in the request

  • Request processing time metrics

  • Error information when token limits are exceeded

Logs are sent via the MCP protocol's notifications/message method, ensuring they don't interfere with the JSON-RPC communication. MCP clients with logging support will display these logs appropriately.

Example log entries:

Token usage: 1,234 tokens. Selected model: gpt-5-2025-08-07 (limit: 400,000 tokens)
Files included: 3, Document count: 3
Sending request to OpenAI gpt-5-2025-08-07 with 1,234 tokens...
Received response from gpt-5-2025-08-07 in 982ms
Token usage: 435,678 tokens. Selected model: gemini-2.5-pro (limit: 1,000,000 tokens)
Files included: 25, Document count: 18
Sending request to Gemini with 435,678 tokens...
Received response from gemini-2.5-pro in 3240ms

Using the Tools

sage-opinion Tool

The sage-opinion tool accepts the following parameters:

  • prompt (string, required): The prompt to send to the selected model

  • paths (array of strings, required): List of file paths to include as context

  • debate (boolean, optional): Enable multi-model debate mode for higher quality responses

Example MCP tool call (using 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 Tool

The sage-review tool accepts the following parameters:

  • instruction (string, required): The specific changes or improvements needed

  • paths (array of strings, required): List of file paths to include as context

  • debate (boolean, optional): Enable multi-model debate mode for higher quality responses

Example MCP tool call (using 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"]
    }
  }
}

The response will contain SEARCH/REPLACE blocks that you can use to implement the suggested changes:

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

When using debate mode with either tool, the system will:

  1. Generate initial responses from multiple models (GPT-5 and Gemini by default)

  2. Have models critique each other's responses

  3. Allow models to refine their responses based on critiques

  4. Use a judge model (Claude Opus 4.1 by default) to select or synthesize the best response

This results in more thoughtful and comprehensive responses at the cost of additional time and API usage.

Running the Tests

To test the tools:

# 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 debate mode
OPENAI_API_KEY=your_openai_key GEMINI_API_KEY=your_gemini_key ANTHROPIC_API_KEY=your_anthropic_key node test/run-sage-opinion-debate.js

Note: Tests using debate mode may take 2-5 minutes to run as they orchestrate multi-model interactions.

Project Structure

  • src/index.ts: The main MCP server implementation with tool definitions

  • src/pack.ts: Tool for packing files into a structured XML format

  • src/tokenCounter.ts: Utilities for counting tokens in a prompt

  • src/gemini.ts: Gemini API client implementation

  • src/openai.ts: OpenAI API client implementation for O3 model

  • src/orchestrator/debateOrchestrator.ts: Multi-model debate orchestration

  • src/prompts/debatePrompts.ts: Templates for debate prompts and instructions

  • test/run-test.js: Test for the sage-opinion tool

  • test/test-expert.js: Test for the sage-review tool

  • test/run-sage-opinion-debate.js: Test for debate mode functionality

License

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
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.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