Skip to main content
Glama
enesjakozh
techkwon

MCP Gemini API Server

by techkwon
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

MCP Gemini API 服务器

适用于 Cursor 和 Claude 的 Google Gemini API 服务器。 Gemini 提供多种功能，包括文本生成、图像分析和视频分析。

主要特点

  • 文本生成（使用gemini-2.0-flash模型）

  • 图像创建和分析

  • YouTube 视频分析

  • 网络搜索

Related MCP server: Gemini Gen MCP

开始

基本要求

  • Node.js 18.0.0 或更高版本

  • npm 或 yarn

  • Google API 密钥（用于访问 Gemini API）

安装

# 저장소 클론
git clone https://github.com/techkwon/mcp-gemini.git
cd mcp-gemini

# 의존성 설치
npm install

偏好设置

  1. 在config.ts文件中设置您的 Google API 密钥：

export default {
  googleApiKey: "your_api_key_here",
  // 기타 설정...
};

构建并运行

# TypeScript 빌드
npm run build

# 서버 시작 (PM2 사용)
npm start

# 개발 모드로 실행
npm run dev

PM2 服务器管理

服务器通过 PM2 自动管理。您可以使用以下命令管理您的服务器：

# 서버 상태 확인
npm run status

# 서버 로그 확인
npm run logs

# 서버 중지
npm run stop

# 서버 재시작
npm run restart

# 시스템 재시작 시 자동 실행 설정
pm2 startup
pm2 save

Cursor/Claude 集成

MCP 设置

将以下设置添加到您的~/.cursor/mcp.json文件：

{
  "github.com/techkwon/mcp-gemini": {
    "command": "npm",
    "args": ["start"],
    "cwd": "<프로젝트_경로>",
    "env": {
      "NODE_ENV": "production"
    },
    "disabled": false,
    "autoStart": true,
    "autoApprove": [
      "gem-generate",
      "gem-generate-image",
      "gem-analyze-video",
      "gem-search"
    ]
  }
}

API 端点

  • /gem-generate ：生成文本

  • /gem-generate-image ：图像生成/分析

  • /gem-analyze-video ：分析 YouTube 视频

  • /gem-search ：网页搜索

重大更新

最新版本（2024-03）

  • 通过 PM2 实现服务器自动化

  • 统一到 gemini-2.0-flash 模型

  • 增加了自动重启和错误恢复功能

  • 改善您的设置

先前版本

  • 添加了 YouTube 视频分析功能

  • 改进的图像创建/分析能力

  • 添加网页搜索功能

故障排除

常见问题

  1. 如果服务器没有启动

    # PM2 로그 확인
npm run logs

# PM2 프로세스 상태 확인
npm run status

  2. API 密钥错误

    • 确保您的 API 密钥在config.ts文件中设置正确。

    • 检查 Gemini API 配额和权限

  3. 内存使用问题

    • 检查ecosystem.config.js中的内存限制设置

    • 使用 PM2 监控跟踪内存使用情况

贡献

  1. 分叉项目

  2. 创建你的功能分支（ git checkout -b feature/AmazingFeature ）

  3. 提交您的更改（ git commit -m 'Add some AmazingFeature' ）

  4. 推送到分支（ git push origin feature/AmazingFeature ）

  5. 打开拉取请求

执照

该项目遵循 MIT 许可证。请参阅LICENSE文件以了解详细信息。

接触

项目经理：techkwon 电子邮件： techkwon@example.com项目链接： https://github.com/techkwon/mcp-gemini

关键依赖关系

  • @google/generative-ai：^0.1.3（Gemini API SDK）

  • @fastify/cors：^8.5.0（CORS 支持）

  • fastify：^4.29.0（Web 服务器框架）

  • googleapis：^148.0.0（Google API 支持）

  • 打字稿：^5.0.0

  • zod：^3.24.2（数据验证）

  • pino: ^8.21.0 (日志记录)

Claude 桌面应用程序集成指南

设置文件位置

Claude 桌面应用程序的设置文件位于以下路径：

  • Windows： %APPDATA%/Claude/config.json

  • macOS： ~/Library/Application Support/Claude/config.json

JSON 设置示例

{
  "apis": [
    {
      "name": "MCP Gemini",
      "url": "http://localhost:8000",
      "methods": [
        {
          "name": "텍스트 생성",
          "method": "gem-generate",
          "template": {
            "jsonrpc": "2.0",
            "id": "{uuid}",
            "method": "gem-generate",
            "params": {
              "prompt": "{input}"
            }
          }
        },
        {
          "name": "이미지 생성",
          "method": "gem-generate-image",
          "template": {
            "jsonrpc": "2.0",
            "id": "{uuid}",
            "method": "gem-generate-image",
            "params": {
              "prompt": "{input}"
            }
          }
        },
        {
          "name": "비디오 분석",
          "method": "gem-analyze-video",
          "template": {
            "jsonrpc": "2.0",
            "id": "{uuid}",
            "method": "gem-analyze-video",
            "params": {
              "videoUrl": "{input}",
              "query": "이 영상의 주요 내용을 요약해주세요"
            }
          }
        },
        {
          "name": "웹 검색",
          "method": "gem-search",
          "template": {
            "jsonrpc": "2.0",
            "id": "{uuid}",
            "method": "gem-search",
            "params": {
              "query": "{input}"
            }
          }
        }
      ]
    }
  ]
}

变量描述

  • {uuid} ：自动生成的唯一请求ID。

  • {input} ：输入到 Claude 聊天窗口的文本

如何使用

  1. 打开 Claude 桌面应用程序的设置文件。

  2. 将上面的 JSON 设置添加到您现有的设置中。

  3. 重新启动 Claude 桌面应用程序。

  4. 您可以在聊天窗口中使用它，如下所示：

@MCP Gemini.텍스트 생성 한국의 전통 음식에 대해 설명해주세요
@MCP Gemini.이미지 생성 한옥마을의 아름다운 풍경
@MCP Gemini.비디오 분석 https://youtube.com/watch?v=VIDEO_ID
@MCP Gemini.웹 검색 최신 인공지능 기술 동향

响应格式

所有 API 响应都遵循以下格式：

{
  "jsonrpc": "2.0",
  "id": "요청에서 보낸 ID",
  "result": {
    "content": "응답 내용"
  }
}

错误响应

如果发生错误，请按照以下格式进行响应：

{
  "jsonrpc": "2.0",
  "id": "요청에서 보낸 ID",
  "error": {
    "code": 오류코드,
    "message": "오류 메시지",
    "data": {
      "details": "상세 오류 정보"
    }
  }
}

错误处理

在以下情况下，服务器将返回适当的错误响应：

  • 400：错误的请求格式

  • 401：身份验证错误（API 密钥相关）

  • 500：内部服务器错误

安全注意事项

  • 确保将您的 API 密钥作为环境变量进行管理。

  • 在生产环境中，添加适当的安全设置。

  • 注意不要记录敏感信息。

故障排除

端口冲突

如果端口 8000 已被使用：

# 기존 Node.js 프로세스 종료
pkill -f "node"

服务器稳定性

如果服务器意外终止：

  • 考虑使用 PM2 或其他进程管理器。

  • 检查日志以确定终止的原因。

开发指南

日志记录

  • 使用 Pino logger 实现结构化日志记录

  • 在开发环境中，通过 pino-pretty 输出可读的日志。

类型安全

  • 使用 TypeScript 和 Zod 确保运行时类型安全

  • 已实现 API 请求/响应的模式验证。

CLINE MCP 市场注册指南

前期准备

  1. 您的 GitHub 存储库必须是公开的

  2. README.md 文件应包含清晰的安装和设置说明。

  3. （可选）您可以通过llms-install.md文件为您的 AI 代理提供额外的安装说明。

注册程序

  1. 在CLINE MCP Marketplace 存储库中创建新问题

  2. 该问题包含以下信息：

    • GitHub 仓库网址： https://github.com/techkwon/mcp-gemini

    • 徽标图像： PNG文件，尺寸为400×400

    • **附加原因：**此 MCP 服务器可以为 CLINE 用户提供的价值示例：GXP12

  3. 测试 CLINE 是否能仅使用 README.md 成功安装服务器

审批流程

  1. CLINE 团队审查已提交的 MCP 服务器

  2. 我们正在进行安全性和稳定性验证

  3. 一旦获得批准，您将被列入市场并可供所有 CLINE 用户访问。

优化安装指南

您可以通过创建llms-install.md文件为您的 AI 代理提供额外的安装说明：

# MCP Gemini 서버 설치 가이드 (AI 에이전트용)

## 환경 요구사항
- Node.js 18.0.0 이상
- npm 또는 yarn
- Google AI Studio API 키

## 설치 단계
1. 저장소 클론
2. 의존성 설치: `npm install`
3. 환경 변수 설정: GOOGLE_API_KEY 추가
4. 빌드: `npm run build`
5. 서버 실행: `npm run start`

## 설정 검증
- 8000번 포트 사용 가능 여부 확인
- API 키 유효성 검증
- CORS 설정 확인

## 문제 해결
- 포트 충돌 시 해결 방법
- API 키 오류 해결 방법
- 일반적인 설치 문제 해결 가이드

Available Tools

6 tools
analyze_directoryC

Analyze a directory with a given prompt using Gemini CLI

NameRequiredDescriptionDefault
dirYesDirectory path to analyze
maxOutputKBNoMaximum output size in KB (optional)
promptYesQuestion or instruction for analysis
recursiveNoWhether to analyze recursively
timeoutNoTimeout in seconds (optional)

TDQS

C2.9/5.0
Behavior2/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 mentions the tool uses 'Gemini CLI' but doesn't explain what this entails—such as potential side effects, error handling, or output format. For a tool with 5 parameters and no annotations, this is a significant gap in transparency.

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

Conciseness5/5

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

The description is a single, efficient sentence that front-loads the core purpose without unnecessary details. Every word earns its place, making it highly concise and well-structured.

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

Completeness2/5

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

Given the complexity of 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks information on behavioral traits, output expectations, and differentiation from siblings, making it inadequate for a tool of this complexity.

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?

The schema description coverage is 100%, meaning all parameters are documented in the input schema. The description adds no additional parameter semantics beyond what's already in the schema, so it meets the baseline of 3 without compensating for any gaps.

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 action ('analyze a directory') and the method ('using Gemini CLI'), which provides a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from sibling tools like 'analyze_files' or 'raw_prompt', which would be needed for a score of 5.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'analyze_files' or 'raw_prompt'. There's no mention of prerequisites, context, or exclusions, leaving the agent with minimal usage direction.

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

analyze_filesC

Analyze multiple files with a given prompt using Gemini CLI

NameRequiredDescriptionDefault
maxOutputKBNoMaximum output size in KB (optional)
pathsYesArray of file paths to analyze
promptYesQuestion or instruction for analysis
timeoutNoTimeout in seconds (optional)

TDQS

C2.9/5.0
Behavior2/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 mentions using 'Gemini CLI' but doesn't explain what that entails—such as whether it's an external API call, potential rate limits, authentication needs, or what happens during analysis (e.g., file reading, processing time). This leaves significant gaps in understanding the tool's behavior.

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

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core action and mechanism, making it easy to grasp quickly.

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

Completeness2/5

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

Given the complexity of analyzing files with an external CLI, no annotations, and no output schema, the description is incomplete. It doesn't cover critical aspects like expected output format, error handling, or behavioral traits (e.g., whether files are modified), leaving the agent with insufficient context for effective use.

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 no additional meaning beyond what's in the schema, such as explaining how 'paths' should be formatted or what 'analyze' entails for the 'prompt'. This meets the baseline for high schema coverage.

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 action ('analyze multiple files') and the mechanism ('using Gemini CLI'), which is specific and actionable. However, it doesn't explicitly distinguish this tool from its sibling 'analyze_directory', which likely analyzes directories instead of individual files, leaving some ambiguity in sibling differentiation.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'analyze_directory' or 'raw_prompt'. It lacks context about prerequisites, such as file accessibility or Gemini CLI setup, and doesn't mention any exclusions or specific use cases.

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

get_configC

Get configuration value

NameRequiredDescriptionDefault
keyYesConfiguration key to retrieve

TDQS

C2.7/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose if this is read-only, requires authentication, has rate limits, or what happens on errors. This is a significant gap for a tool with zero annotation coverage.

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

Conciseness5/5

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

The description is a single, efficient sentence with zero waste. It's appropriately sized for a simple tool and front-loaded with the core action, making it easy to parse quickly.

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

Completeness2/5

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

Given no annotations and no output schema, the description is incomplete. It doesn't explain what the return value looks like (e.g., string, object, error handling) or provide context for the configuration system. For a tool with 1 parameter and minimal structured data, it should do more to compensate.

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 the 'key' parameter fully. The description adds no additional meaning beyond what the schema provides, such as examples of valid keys or format constraints. Baseline 3 is appropriate when schema does the heavy lifting.

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

Purpose3/5

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

The description 'Get configuration value' states the basic action (get) and resource (configuration value), but it's vague about scope and doesn't distinguish from sibling tools like 'set_config'. It's not tautological but lacks specificity about what kind of configuration or system is involved.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like 'set_config' or other siblings. The description implies retrieval but doesn't specify prerequisites, contexts, or exclusions for usage.

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

raw_promptC

Execute a raw prompt without file context using Gemini CLI

NameRequiredDescriptionDefault
maxOutputKBNoMaximum output size in KB (optional)
promptYesThe prompt to execute
timeoutNoTimeout in seconds (optional)

TDQS

C2.9/5.0
Behavior2/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 states the tool executes a prompt via Gemini CLI but lacks critical behavioral details: what happens on timeout, how maxOutputKB truncates output, error handling, rate limits, or authentication needs. For a tool with no annotations and potential execution risks, this is insufficient disclosure.

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

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly. Every word earns its place.

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

Completeness2/5

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

Given no annotations, no output schema, and a tool that executes external commands (implying potential side effects), the description is incomplete. It doesn't cover return values, error conditions, or safety considerations. For a tool with this complexity and lack of structured data, more context is needed to be fully helpful.

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 three parameters (prompt, maxOutputKB, timeout) with their types and defaults. The description adds no additional parameter semantics beyond what's in the schema (e.g., prompt format examples or timeout implications). 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 action ('Execute') and the resource ('a raw prompt'), specifying it's done 'without file context using Gemini CLI'. This distinguishes it from siblings like analyze_files or analyze_directory that involve file operations. However, it doesn't explicitly contrast with all siblings (e.g., get_config/set_config).

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

Usage Guidelines2/5

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

The description provides minimal guidance: it mentions 'without file context', implying this tool is for text-only prompts. However, it doesn't specify when to use this versus alternatives (e.g., for simple queries vs. complex analyses), nor does it mention prerequisites or exclusions. No explicit when/when-not or alternative tool references are provided.

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

set_configC

Set configuration value

NameRequiredDescriptionDefault
keyYesConfiguration key to set
valueYesConfiguration value to set

TDQS

C2.4/5.0
Behavior2/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. 'Set configuration value' implies a write/mutation operation but provides no information about permissions required, whether changes are persistent or reversible, potential side effects, error conditions, or rate limits. For a mutation tool with zero annotation coverage, this represents a significant gap in behavioral transparency.

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

Conciseness5/5

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

The description is extremely concise at just three words: 'Set configuration value'. While this represents under-specification in terms of content, from a pure conciseness perspective it's maximally efficient with zero wasted words. Every word earns its place in conveying the core function.

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

Completeness2/5

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

For a configuration mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after setting the configuration, whether the change is immediate or requires restart, what format the value should be in, or what systems are affected. Given the complexity of configuration management and the lack of structured metadata, the description should provide more context about the operation's scope and effects.

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?

The input schema has 100% description coverage, with both parameters ('key' and 'value') clearly documented in the schema itself. The description adds no additional parameter information beyond what's already in the structured schema. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description.

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

Purpose2/5

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

The description 'Set configuration value' is a tautology that essentially restates the tool name 'set_config' without adding meaningful specificity. It doesn't distinguish what kind of configuration, for what system, or how this differs from sibling tools like 'get_config'. While it includes a verb ('Set') and resource ('configuration value'), it lacks the specificity needed for clear differentiation.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling 'get_config' tool for retrieving configuration values, nor does it indicate any prerequisites, constraints, or appropriate contexts for setting configuration. There's no explicit or implied guidance about when this operation should be performed.

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

verify_featureC

Verify if a feature is implemented in the codebase

NameRequiredDescriptionDefault
featureQuestionYesQuestion about the feature to verify
maxOutputKBNoMaximum output size in KB (optional)
pathsNoOptional specific paths to check
timeoutNoTimeout in seconds (optional)

TDQS

C2.6/5.0
Behavior2/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 of behavioral disclosure. It mentions 'verify' but doesn't explain what this entails—whether it performs static analysis, runtime checks, or something else. Critical behavioral aspects like potential side effects, authentication needs, rate limits, or output format are omitted. The description is too brief to provide meaningful behavioral context for a tool with multiple parameters.

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 a single, concise sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and efficient, making it easy to parse. However, it could be slightly more informative without losing conciseness, such as by hinting at the verification method. Overall, it's well-structured but minimalistic.

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

Completeness2/5

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

Given the tool's complexity with 4 parameters and no annotations or output schema, the description is incomplete. It doesn't address what the tool returns, how verification is performed, or any behavioral traits. For a tool that likely involves code analysis or checking, more context is needed to understand its operation and results. The description is too sparse to be fully helpful without relying heavily on the schema.

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 input schema fully documents all parameters. The description adds no additional semantic information about parameters beyond what's in the schema. It doesn't explain how parameters like featureQuestion or paths relate to the verification process. With high schema coverage, the baseline score is 3, as the description doesn't compensate but also doesn't detract from the schema's documentation.

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

Purpose3/5

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

The description states the tool's purpose as verifying feature implementation in a codebase, which is clear but somewhat vague. It specifies 'verify' as the verb and 'feature' as the resource, but doesn't distinguish it from sibling tools like analyze_directory or analyze_files, which might have overlapping functionality. The purpose is understandable but lacks specificity about what 'verify' entails compared to analysis tools.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like analyze_directory or analyze_files, nor does it specify contexts or prerequisites for usage. Without any usage instructions, the agent must infer when this tool is appropriate based on the name alone, which is insufficient for effective tool selection.

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. 6 tool updatesv1.0.0
    • First observedanalyze_directory
    • First observedanalyze_files
    • First observedget_config
    • First observedraw_prompt
    • First observedset_config
    • First observedverify_feature
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

B3/5.0

Scored across 6 tools

Disambiguation3/5

The tools have some clear distinctions but also notable overlap. analyze_directory and analyze_files both perform analysis with a prompt, differing only in input scope (directory vs. multiple files), which could cause confusion. raw_prompt is similar but lacks file context. The config tools and verify_feature are distinct, but the analysis tools blur together.

Naming Consistency4/5

Tool names follow a consistent snake_case pattern with clear verb_noun structures (e.g., analyze_directory, get_config). All tools adhere to this convention, making them readable and predictable. Minor deviation in raw_prompt (which uses 'raw' as an adjective) is acceptable.

Tool Count5/5

With 6 tools, the count is well-scoped for a Gemini API server. It covers core analysis operations, configuration management, and a verification feature without being overwhelming. Each tool appears to serve a specific purpose, fitting a typical utility server scope.

Completeness3/5

The toolset covers basic analysis and configuration but has gaps. It lacks operations for managing analysis results (e.g., list or delete analyses) and doesn't support advanced Gemini features like model selection or streaming. The verify_feature tool is useful but doesn't fully round out the domain, leaving some workflows incomplete.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches