Skip to main content
Glama
enesjakozh
techkwon

MCP Gemini API Server

by techkwon
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Servidor API MCP Gemini

Servidor API de Google Gemini para Cursor y Claude. Gemini ofrece una variedad de funciones que incluyen generación de texto, análisis de imágenes y análisis de video.

Características principales

  • Generación de texto (utilizando el modelo gemini-2.0-flash)

  • Creación y análisis de imágenes

  • Análisis de vídeos de YouTube

  • Búsqueda web

Related MCP server: Gemini Gen MCP

Empezar

Requisitos esenciales

  • Node.js 18.0.0 o posterior

  • npm o hilo

  • Clave API de Google (para acceder a la API de Gemini)

instalación

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

# 의존성 설치
npm install

Preferencias

  1. Establezca su clave API de Google en config.ts :

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

Construir y ejecutar

# TypeScript 빌드
npm run build

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

# 개발 모드로 실행
npm run dev

Administración del servidor PM2

El servidor se gestiona automáticamente a través de PM2. Puede administrar su servidor con los siguientes comandos:

# 서버 상태 확인
npm run status

# 서버 로그 확인
npm run logs

# 서버 중지
npm run stop

# 서버 재시작
npm run restart

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

Integración de Cursor/Claude

Configuración de MCP

Agregue las siguientes configuraciones a su archivo ~/.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"
    ]
  }
}

Punto final de API

  • /gem-generate : Generar texto

  • /gem-generate-image : Generación/análisis de imágenes

  • /gem-analyze-video : Analiza vídeos de YouTube

  • /gem-search : Búsqueda web

Actualizaciones importantes

Última versión (2024-03)

  • Implementación de la automatización del servidor a través de PM2

  • Unificado al modelo gemini-2.0-flash

  • Se agregaron funciones de reinicio automático y recuperación de errores.

  • Mejora tu configuración

Versión anterior

  • Se agregó la función de análisis de videos de YouTube

  • Capacidades mejoradas de creación y análisis de imágenes

  • Añadir funcionalidad de búsqueda web

Solución de problemas

Problemas comunes

  1. Si el servidor no se inicia

    # PM2 로그 확인
npm run logs

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

  2. Error de clave API

    • Asegúrese de que su clave API esté configurada correctamente en config.ts .

    • Comprobar las cuotas y permisos de la API de Gemini

  3. Problemas de uso de memoria

    • Verifique la configuración del límite de memoria en ecosystem.config.js

    • Realice un seguimiento del uso de la memoria con la monitorización de PM2

Contribuir

  1. Bifurcar el proyecto

  2. Crea tu rama de funciones ( git checkout -b feature/AmazingFeature )

  3. Confirme sus cambios ( git commit -m 'Add some AmazingFeature' )

  4. Empujar a la rama ( git push origin feature/AmazingFeature )

  5. Abrir una solicitud de extracción

Licencia

Este proyecto sigue la licencia MIT. Consulte el archivo de LICENCIA para obtener más detalles.

contacto

Gerente de proyecto: techkwon Correo electrónico: techkwon@example.com Enlace del proyecto: https://github.com/techkwon/mcp-gemini

Dependencias clave

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

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

  • fastify: ^4.29.0 (marco de servidor web)

  • googleapis: ^148.0.0 (compatibilidad con la API de Google)

  • mecanografiado: ^5.0.0

  • zod: ^3.24.2 (validación de datos)

  • pino: ^8.21.0 (registro)

Guía de integración de la aplicación de escritorio de Claude

Ubicación del archivo de configuración

Los archivos de configuración de la aplicación de escritorio Claude se encuentran en la siguiente ruta:

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

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

Ejemplo de configuración 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}"
            }
          }
        }
      ]
    }
  ]
}

Descripción de la variable

  • {uuid} : ID de solicitud único que se genera automáticamente.

  • {input} : Texto ingresado en la ventana de chat de Claude

Cómo utilizar

  1. Abra el archivo de configuración de la aplicación de escritorio Claude.

  2. Agregue la configuración JSON anterior a su configuración existente.

  3. Reinicie la aplicación de escritorio Claude.

  4. Puedes usarlo en la ventana de chat de la siguiente manera:

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

Formato de respuesta

Todas las respuestas de la API siguen este formato:

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

Respuesta de error

Si ocurre un error, responda en el siguiente formato:

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

Manejo de errores

El servidor devuelve una respuesta de error apropiada en las siguientes situaciones:

  • 400: Formato de solicitud incorrecto

  • 401: Error de autenticación (relacionado con la clave API)

  • 500: Error interno del servidor

Consideraciones de seguridad

  • Asegúrese de administrar su clave API como una variable de entorno.

  • En un entorno de producción, agregue la configuración de seguridad adecuada.

  • Tenga cuidado de no registrar información confidencial.

Solución de problemas

Conflicto portuario

Si el puerto 8000 ya está en uso:

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

Estabilidad del servidor

Si el servidor finaliza inesperadamente:

  • Considere utilizar PM2 u otro gestor de procesos.

  • Verifique los registros para determinar la causa de la terminación.

Guía de desarrollo

Explotación florestal

  • Se implementó el registro estructurado utilizando el registrador Pino

  • En el entorno de desarrollo, los registros legibles se generan a través de pino-pretty.

Seguridad de tipos

  • Garantice la seguridad de tipos en tiempo de ejecución utilizando TypeScript y Zod

  • Se implementa la validación de esquema para solicitudes/respuestas de API.

Guía de registro del mercado de CLINE MCP

Preparación preliminar

  1. Su repositorio de GitHub debe ser público

  2. El archivo README.md debe contener instrucciones claras de instalación y configuración.

  3. (Opcional) Puede proporcionar instrucciones de instalación adicionales para su agente de IA a través llms-install.md .

Procedimiento de registro

  1. Crear un nuevo problema en el repositorio de CLINE MCP Marketplace

  2. El número incluye la siguiente información:

    • URL del repositorio de GitHub: https://github.com/techkwon/mcp-gemini

    • Imagen del logotipo: archivo PNG en tamaño 400×400

    • Razón adicional: Ejemplo del valor que este servidor MCP puede proporcionar a los usuarios de CLINE: GXP12

  3. Comprueba si CLINE puede instalar correctamente un servidor con solo README.md

Proceso de aprobación

  1. El equipo de CLINE revisa los servidores MCP enviados

  2. Estamos realizando una verificación de seguridad y estabilidad.

  3. Una vez aprobado, aparecerá en el Marketplace y será accesible para todos los usuarios de CLINE.

Guía de instalación optimizada

Puede proporcionar instrucciones de instalación adicionales para su agente de IA creando un archivo llms-install.md :

# 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