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ビデオ分析

  • Web検索

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 search : Web 検索

主なアップデート

最新バージョン(2024-03)

  • PM2によるサーバー自動化の実装

  • gemini-2.0-flashモデルで統一

  • 自動再起動とエラー回復機能の追加

  • 環境設定の改善

以前のバージョン

  • YouTubeビデオ分析機能を追加

  • 画像生成/分析機能の改善

  • ウェブ検索機能の追加

トラブルシューティング

一般的な問題

  1. サーバーが起動しない場合

    # PM2 로그 확인
npm run logs

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

  2. API キーエラー

    • config.tsファイルでAPIキーが正しく設定されていることを確認する

    • Gemini API クォータと権限の確認

  3. メモリ使用量の問題

    • ecosystem.config.jsでメモリ制限設定を確認する

    • PM2モニタリングによるメモリ使用量の追跡

貢献する

  1. Fork the Project

  2. Create your Feature Branch ( git checkout -b feature/AmazingFeature )

  3. Commit your Changes ( git commit -m 'Add some AmazingFeature' )

  4. Push to the Branch ( git push origin feature/AmazingFeature )

  5. Open a Pull Request

ライセンス

このプロジェクトはMITライセンスに従います。詳細については、 LICENSEファイルを参照してください。

お問い合わせ

プロジェクトマネージャ：techkwon Eメール： 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 (ウェブサーバーフレームワーク)

  • googleapis: ^148.0.0 (Google API サポート)

  • typescript: ^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ロガーを使用して構造化ロギングを実装しました

  • 開発環境では、pino-prettyを介して読みやすいログが出力されます

タイプ安定性

  • TypeScriptとZodを使用してランタイムタイプの安定性を確保

  • APIリクエスト/レスポンスのスキーマ検証が実装されています

CLINE MCPマーケットプレイス登録ガイド

事前準備

  1. GitHubリポジトリが公開されている必要があります

  2. README.mdファイルに明確なインストールと設定方法が含まれている必要があります

  3. （オプション） llms-install.mdファイルを使用してAIエージェント用の追加インストールガイドを提供できます。

登録手順

  1. CLINE MCPマーケットプレイスストアに新しい問題を作成します

  2. 問題には次の情報が含まれています。

    • GitHubリポジトリURL： https://github.com/techkwon/mcp-gemini

    • ロゴ画像： 400×400サイズのPNGファイル

    • **追加の理由：**この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

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

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

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

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

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

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