Skip to main content
Glama
techkwon

MCP Gemini API Server

by techkwon

MCP Gemini API Server

Google Gemini API server for Cursor and Claude. Provides various Gemini features such as text generation, image analysis, video analysis, etc.

Key Features

  • Text generation (using the gemini-2.0-flash model)

  • Image creation and analysis

  • YouTube video analytics

  • Web search

Related MCP server: Gemini Gen MCP

Get started

Essential Requirements

  • Node.js 18.0.0 or later

  • npm or yarn

  • Google API Key (for accessing Gemini API)

installation

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

# 의존성 설치
npm install

Preferences

  1. Set your Google API key in config.ts file:

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

Build and Run

# TypeScript 빌드
npm run build

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

# 개발 모드로 실행
npm run dev

PM2 Server Management

The server is automatically managed via PM2. You can manage the server with the following commands:

# 서버 상태 확인
npm run status

# 서버 로그 확인
npm run logs

# 서버 중지
npm run stop

# 서버 재시작
npm run restart

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

Cursor/Claude integration

MCP Settings

Add the following settings to your ~/.cursor/mcp.json file:

{
  "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 endpoint

  • /gem-generate : Generate text

  • /gem-generate-image : Image generation/analysis

  • /gem-analyze-video : Analyze YouTube videos

  • /gem-search : Web search

Major Updates

Latest version (2024-03)

  • Implementing server automation via PM2

  • Unified to gemini-2.0-flash model

  • Added automatic restart and error recovery features

  • Improve your settings

Previous version

  • Added YouTube video analytics feature

  • Improved image creation/analysis capabilities

  • Add web search functionality

Troubleshooting

Common Problems

  1. If the server does not start

    # PM2 로그 확인
    npm run logs
    
    # PM2 프로세스 상태 확인
    npm run status
  2. API Key Error

    • Make sure your API key is set correctly in config.ts file.

    • Check Gemini API Quotas and Permissions

  3. Memory usage issues

    • Check memory limit settings in ecosystem.config.js

    • Track memory usage with PM2 monitoring

Contribute

  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

License

This project is licensed under the MIT License. See the LICENSE file for details.

contact

Project Manager: techkwon Email: techkwon@example.com Project Link: https://github.com/techkwon/mcp-gemini

Key Dependencies

  • @google/generative-ai: ^0.1.3 (Gemini API SDK)

  • @fastify/cors: ^8.5.0 (CORS support)

  • fastify: ^4.29.0 (web server framework)

  • googleapis: ^148.0.0 (Google API support)

  • typescript: ^5.0.0

  • zod: ^3.24.2 (data validation)

  • pino: ^8.21.0 (logging)

Claude Desktop App Integration Guide

Settings file location

The settings files for the Claude desktop app are located in the following path:

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

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

Example JSON settings

{
  "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}"
            }
          }
        }
      ]
    }
  ]
}

Variable Description

  • {uuid} : Unique request ID that is automatically generated.

  • {input} : Text entered into Claude's chat window

How to use

  1. Open the settings file of the Claude desktop app.

  2. Add the JSON settings above to your existing settings.

  3. Restart the Claude desktop app.

  4. You can use it in the chat window like this:

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

Response Format

All API responses follow this format:

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

Error response

If an error occurs, respond in the following format:

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

Error Handling

The server returns an appropriate error response in the following situations:

  • 400: Bad request format

  • 401: Authentication error (API key related)

  • 500: Internal server error

Security Considerations

  • Be sure to manage your API key as an environment variable.

  • In a production environment, add appropriate security settings.

  • Be careful not to log sensitive information.

Troubleshooting

Port conflict

If port 8000 is already in use:

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

Server Stability

If the server terminates unexpectedly:

  • Consider using PM2 or another process manager.

  • Check the logs to determine the cause of the termination.

Development Guide

Logging

  • Implemented structured logging using Pino logger

  • In the development environment, readable logs are output via pino-pretty.

Type safety

  • Ensure runtime type safety using TypeScript and Zod

  • Schema validation for API requests/responses is implemented.

CLINE MCP Marketplace Registration Guide

Preliminary Preparation

  1. Your GitHub repository must be public

  2. The README.md file should contain clear installation and setup instructions.

  3. (Optional) You can provide additional installation instructions for your AI agent via llms-install.md file.

Registration Procedure

  1. Create a new issue in the CLINE MCP Marketplace repository

  2. The issue includes the following information:

  3. Tests whether CLINE can successfully install a server with only README.md

Approval process

  1. The CLINE team reviews submitted MCP servers

  2. We are conducting security and stability verification

  3. Once approved, you will be listed on the Marketplace and accessible to all CLINE users.

Optimized installation guide

You can provide additional installation instructions for your AI agent by creating an llms-install.md file:

# 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. Dates show when Glama detected each change.

  1. 6 tool updatesv1.0.0
    • First observedanalyze_directory
    • First observedanalyze_files
    • First observedget_config
    • First observedraw_prompt
    • First observedset_config
    • First observedverify_feature

TDQS

B3/5.0
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

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/techkwon/mcp-gemini'

If you have feedback or need assistance with the MCP directory API, please join our Discord server