Provides tools for interacting with Google's Gemini API, enabling chat, multimodal analysis, deep research, file management, and various generation tasks.
Allows analysis of public YouTube videos by URL, extracting content for processing via Gemini's multimodal capabilities.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Gemini MCP Server analyze this YouTube video: https://youtube.com/watch?v=dQw4w9WgXcQ"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server providing 23 tools for Google's Gemini API -- chat, multimodal analysis, deep research, file management, YouTube analysis, and more.
Built with @google/genai SDK (v1.0.0+).
Chat with Gemini models (single-turn, multi-turn, with tool modes)
Analyze images, audio, video, PDFs, YouTube videos, and URLs
Files API with auto-switching: inline for small files (<20MB), upload for large (up to 2GB)
Deep research agent with background polling and push notifications (Termux)
Structured JSON output, embeddings, code execution, translation, summarization
Google Search grounding and URL context
Thinking mode enabled by default (budget: 65535 tokens)
High media resolution by default
Related MCP server: Gemini Chat MCP
Node.js 18+
git clone https://github.com/salviz/gemini-mcp-server.git
cd gemini-mcp-server
npm installCLI:
claude mcp add gemini -- node /path/to/gemini-mcp-server/index.jsOr add to your MCP config (~/.claude/claude_desktop_config.json or .mcp.json):
{
"mcpServers": {
"gemini": {
"type": "stdio",
"command": "node",
"args": ["/path/to/gemini-mcp-server/index.js"],
"env": {
"GEMINI_API_KEY": "your-api-key"
}
}
}
}Variable | Required | Description |
| Yes | Your Google Gemini API key |
Tool | Description |
| Send a prompt with optional search grounding and URL context |
| Multi-turn conversation with message history |
| Chat with mode switching: |
| Search-grounded generation with source citations |
| Generate JSON output matching a provided schema |
| Analyze one or more URLs using Gemini's URL context tool |
Tool | Description |
| Analyze an image file with Gemini Vision (JPG, PNG, GIF, WebP, BMP, SVG) |
| Transcribe, summarize, or describe audio (MP3, WAV, OGG, FLAC, AAC, M4A, Opus) |
| Analyze a video file; auto-uploads large files via Files API (MP4, AVI, MOV, MKV, WebM) |
| Analyze a PDF document (up to 2GB via Files API) |
| Analyze a public YouTube video by URL (no download needed) |
| Analyze content from an HTTP/HTTPS URL or GCS URI ( |
Tool | Description |
| Start a deep research task; sends push notification on completion |
| Check status of a running deep research task by interaction ID |
Tool | Description |
| Upload a file to Gemini (up to 2GB, retained 48 hours) |
| List all uploaded files with metadata |
| Delete an uploaded file by name |
Tool | Description |
| List available Gemini models with capabilities and token limits |
| Count tokens in text using a model's tokenizer |
| Generate text embeddings (default: |
| Execute Python code via Gemini's built-in sandbox |
| Summarize text with configurable style (brief, detailed, bullet-points) |
| Translate text to any language with optional model override |
Default model: gemini-3.1-pro-preview. Every tool accepts an optional model parameter.
Model | Best For |
| Default. Best quality for most tasks |
| Faster responses, lower cost |
| Text embeddings (used by |
| Deep research agent (used internally) |
The server automatically handles file size:
<= 20MB: Sent inline as base64 (fast, no upload step)
> 20MB up to 2GB: Uploaded via Gemini Files API, then referenced by URI
YouTube URLs: Passed directly via fileData.fileUri (no download)
HTTP/HTTPS URLs: Passed via createPartFromUri (up to 100MB)
GCS URIs (gs://): Passed via fileData.fileUri
Uploaded files are retained for 48 hours. Use gemini_list_files and gemini_delete_file to manage them.
The gemini_deep_research tool uses Gemini's Interactions API with the deep-research-pro-preview-12-2025 agent:
Starts research in background mode
Polls for 50 seconds in case it finishes quickly
If still running, starts background polling (every 30s, up to 30 minutes)
Sends a push notification via termux-notification when complete
Saves full results to ~/.cache/deep_research_*.txt
Use gemini_check_research to manually poll at any time.
gemini-mcp-server/
index.js # Server entry point
tools/
shared.js # Shared config, AI client, extractText helper
chat.js # 17 tools: chat, analysis, research, files, YouTube
utility.js # 6 tools: models, tokens, embed, code, summarize, translate
package.jsonAPI key from environment only -- never hardcoded in source
File paths validated -- absolute paths required, existence checked before reading
Stdio transport -- no network server exposed
No data logged or stored -- prompts and responses are not persisted
Package | Version | Purpose |
| ^1.0.0 | MCP server framework |
| ^1.0.0 | Google Gemini AI SDK |
| ^3.24.0 | Input schema validation |
MIT
Analyze an audio file with Gemini (transcribe, summarize, describe)
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model name (default: gemini-3.1-pro-preview) | |
| prompt | No | Prompt for audio analysis (default: Transcribe and describe this audio) | |
| audioPath | Yes | Absolute path to the audio file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only lists high-level capabilities (transcribe, summarize, describe) without covering potential side effects, permissions, rate limits, or output format. This is insufficient for an AI agent to understand the tool's full behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the tool's purpose. It is appropriately brief, though could benefit from a structured breakdown of capabilities.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should provide details on return values, output format, or processing duration. It lacks completeness for a tool that performs multiple analysis tasks, leaving the agent without critical usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all three parameters (model, prompt, audioPath). The tool description adds minor context for the prompt parameter by mentioning the default, but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes audio files with Gemini, listing three capabilities (transcribe, summarize, describe). It distinguishes from sibling tools like gemini_analyze_image by specifying audio, but could be more precise about the analysis scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 gemini_analyze_video or gemini_analyze_youtube. The description lacks context for preferred use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze an image file with Gemini Vision
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model name (default: gemini-3.1-pro-preview) | |
| prompt | No | Prompt for image analysis (default: Describe this image in detail) | |
| imagePath | Yes | Absolute path to the image file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, placing full burden on the description. The description only states the action and technology, without disclosing behavioral traits such as return format, file reading behavior, supported formats, or model defaults. This is insufficient for an agent to understand side effects or expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is efficient and front-loaded with the core action. However, it could be slightly more informative without becoming verbose, earning a 4 for being concise yet somewhat minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and no annotations, the description is incomplete. It fails to explain what the output is (e.g., text description, confidence scores), any constraints (e.g., file size limits), or how the result is returned. Essential context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The tool description adds no additional context about parameters beyond what the schema already provides (e.g., defaults, meaning of 'prompt'). It neither clarifies nor enriches the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Analyze an image file with Gemini Vision' uses a specific verb ('analyze') and resource ('image file'), clearly distinguishing it from sibling tools that handle audio, video, PDF, URL, etc. The purpose is immediately clear and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for image files but does not explicitly state when to use this tool versus alternatives like gemini_analyze_audio or gemini_chat. No guidance is given on prerequisites or conditions, relying solely on the tool name and sibling names for differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze a PDF document with Gemini (summarize, extract, answer questions)
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model name (default: gemini-3.1-pro-preview) | |
| prompt | No | Prompt for PDF analysis (default: Summarize this document) | |
| pdfPath | Yes | Absolute path to the PDF file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose read-only nature, side effects, or constraints like file size limits or network requirements. The short description lacks behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose with zero wasted words. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple analysis tool with a good schema, the description is adequate but incomplete. It lacks information about output format, error handling, or constraints. No output schema exists to supplement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds context about the analysis types (summarize, extract, answer questions) which relates to the prompt parameter, but does not significantly enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Analyze' and the resource 'PDF document', and specifies capabilities including 'summarize, extract, answer questions'. This distinguishes it from sibling tools like gemini_analyze_image or gemini_chat.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for PDF analysis but provides no explicit guidance on when to use this tool vs alternatives such as gemini_analyze_url or gemini_chat. No when-not-to-use context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze a file from a public URL (HTTP/HTTPS) or Google Cloud Storage URI (gs://). Supports images, audio, video, PDFs, and documents up to 100MB.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public URL (https://...) or GCS URI (gs://bucket/file) | |
| model | No | Model name (default: gemini-3.1-pro-preview) | |
| prompt | No | Prompt for analysis (default: Describe this content) | |
| mimeType | Yes | MIME type of the file (e.g., application/pdf, image/jpeg, audio/mpeg, video/mp4) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose side effects (e.g., whether files are stored, if results are cached) or authentication requirements. With no annotations, the description should clarify that this is a read-only operation, but it only says 'Analyze' without elaboration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (2 sentences, 21 words) with no redundant information. Every sentence contributes to understanding the tool's core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 params, no output schema, no annotations), the description is too brief. It fails to explain what 'analyze' means, what the output looks like, or how errors are handled. The 100MB limit is a useful constraint but missing other context like rate limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are documented. The description adds minimal extra context beyond the schema, essentially restating the URL types. No parameter defaults or usage details are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes files from URLs (HTTP/HTTPS/GCS) and lists supported file types. However, it does not differentiate itself from sibling tools like gemini_analyze_youtube or gemini_analyze_image, which may also analyze URLs for specific media types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus specialized siblings (e.g., gemini_analyze_audio for audio files). No prerequisites, constraints, or when-not-to-use advice provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze a video file with Gemini (describe, summarize, extract info)
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model name (default: gemini-3.1-pro-preview) | |
| prompt | No | Prompt for video analysis (default: Describe what happens in this video) | |
| videoPath | Yes | Absolute path to the video file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry the burden. It does not disclose any behavioral traits such as destructiveness, authentication needs, rate limits, or output format. The description is too minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that directly states the tool's purpose with no redundancy. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is insufficient. It does not explain return values, error handling, prerequisites (e.g., file must exist), or limitations. More context is needed for an agent to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds context about possible tasks (describe, summarize, extract info) but does not add detailed parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Analyze a video file with Gemini (describe, summarize, extract info)' clearly states the action (analyze), the resource (video file), and the possible operations. It distinguishes this tool from siblings like analyze_audio or analyze_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., analyze_youtube, analyze_url). It only describes what the tool does without specifying context or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze a public YouTube video with Gemini (summarize, transcribe, answer questions). Supports up to 10 videos with Gemini 2.5+ models.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | YouTube video URL (e.g., https://www.youtube.com/watch?v=...) | |
| model | No | Model name (default: gemini-3.1-pro-preview) | |
| prompt | No | Prompt for video analysis (default: Summarize this video) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions that videos must be public and on YouTube, supports batch processing (up to 10 videos), and requires Gemini 2.5+ models. It does not disclose whether the tool downloads the video, what happens with private videos, or any error behavior. This is adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states the primary action and outputs, the second adds constraints (batch limit, model requirement). No redundant or unnecessary words. Information is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (summarization, transcription, Q&A, batch processing), the description covers the core functionality and key constraints. However, it does not explain output format or structure, how to craft prompts for questions, or error handling. With no output schema, the description should provide more detail on expected returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter (url, model, prompt) having a description. The tool description adds no additional per-parameter information beyond what the schema already provides. It provides a high-level summary of capabilities, which is expected for baseline scoring.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Analyze a public YouTube video' (verb+resource) and lists 'summarize, transcribe, answer questions' as specific capabilities. It distinguishes itself from sibling tools by specifying 'YouTube' and 'public', setting it apart from other gemini_analyze_* tools that handle different media types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: YouTube videos, public, with Gemini 2.5+ models, and up to 10 videos. However, it does not explicitly state when to use this tool versus siblings like gemini_analyze_video (for generic video files) or gemini_summarize (for text). No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a prompt to Gemini and get a text response. Optionally enable search grounding or URL context.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model name (default: gemini-3.1-pro-preview) | |
| prompt | Yes | The prompt to send to Gemini | |
| temperature | No | Temperature for generation | |
| enableSearch | No | Enable Google Search grounding (default: false) | |
| maxOutputTokens | No | Maximum output tokens | |
| enableUrlContext | No | Enable URL context processing (default: false) | |
| systemInstruction | No | System instruction for the model |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions optional search grounding and URL context but omits details on rate limits, token handling, or error behavior. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and contains no wasted words or redundancies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and no annotations, the description is too brief. It does not cover return format, error handling, or usage constraints, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning for 'enableSearch' and 'enableUrlContext' by naming them, but other parameters like temperature and maxOutputTokens are not explained beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a prompt to Gemini and returns a text response, with optional search grounding and URL context. This distinguishes it from siblings like gemini_chat_multi and gemini_chat_with_tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. Given many sibling chat tools, explicit usage context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Multi-turn conversation with Gemini using message history
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model name (default: gemini-3.1-pro-preview) | |
| messages | Yes | JSON array of {role: "user"|"model", text: "..."} messages | |
| systemInstruction | No | System instruction for the model |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'multi-turn conversation' without disclosing behavioral traits such as statefulness, rate limits, authentication needs, or side effects. This leaves significant gaps for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently conveys the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, annotations, and sibling tool distinctions, the description is insufficient for an AI agent to fully understand when and how to use this tool. It misses details like output format, error handling, and usage guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have descriptions in the schema (100% coverage), so the description adds no additional meaning beyond what the schema already provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a multi-turn conversation tool using message history, distinguishing it from single-turn or tool-enhanced variants like gemini_chat and gemini_chat_with_tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for multi-turn conversations but does not explicitly state when to use this tool over alternatives like gemini_chat or gemini_chat_with_tools, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Flexible Gemini chat with mode switching: "search" (Google Search + URL context), "code" (code execution), or "all" (everything)
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Tool mode: "search" (default) = Google Search + URL context, "code" = code execution, "all" = everything | |
| model | No | Model name (default: gemini-3.1-pro-preview) | |
| prompt | Yes | The prompt to send | |
| systemInstruction | No | System instruction |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the mode-switching behavior but does not address other behavioral traits like statefulness, conversation history, rate limits, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose and key functionality (mode switching). Every word adds value, and there is no superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic functionality and modes, but given the complexity of a multi-mode chat tool, it lacks details on how chat context is maintained, how tool invocation works, and what 'everything' entails. The schema covers all parameters, so completeness is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description reiterates the mode enum values already in the schema, adding no additional meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is a flexible Gemini chat with mode switching, listing three distinct modes (search, code, all). This effectively distinguishes it from siblings like gemini_chat, gemini_code_execute, and gemini_search_grounded.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the modes and their capabilities, providing implicit guidance on when to use each mode. However, it lacks explicit when-to-use versus alternative tools, such as recommending gemini_code_execute for pure code execution or gemini_chat for simple chat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check or wait for deep research results. Use wait=true to block until completion (ideal for background execution — the tool returns when research finishes, triggering a task notification in your AI client).
| Name | Required | Description | Default |
|---|---|---|---|
| wait | No | If true, block and poll until research completes (default: false, single check) | |
| interactionId | Yes | The interaction ID returned by gemini_deep_research | |
| timeoutMinutes | No | Max wait time in minutes when wait=true (default: 30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It mentions blocking behavior and task notification, but lacks details on error handling, side effects, or what happens with invalid interactionId.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The purpose is stated first, followed by usage guidance, making it front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and full schema parameter descriptions, the description covers main behavior but omits return value details and error conditions, which is a gap without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context for the wait parameter but does not significantly enhance meaning for interactionId or timeoutMinutes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks or waits for deep research results, distinguishing it from the sibling gemini_deep_research which initiates research. The verb 'check' or 'wait' and resource 'deep research results' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on using wait=true for background execution and indicates the tool returns upon completion. However, it does not explicitly state when not to use the tool or alternatives for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate and execute code using Gemini's built-in code execution capability
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model to use (default: gemini-3.1-pro-preview) | |
| prompt | Yes | The prompt describing what code to generate and execute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as execution environment, timeout, side effects, or what happens to generated code. For a code execution tool, this is a significant omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is concise and well-structured, though more detail could be included without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of code execution (potential for errors, resource usage, output handling), the description lacks critical context. No output schema or return value explanation is provided, and behavioral traits are absent. The description is inadequate for a tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already described. The description does not add additional meaning beyond the schema. The model parameter default is noted but not elaborated, and the prompt parameter is simply restated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates and executes code using Gemini's built-in capability, with a specific verb (generate and execute) and resource (code). It distinguishes from sibling tools like gemini_chat or gemini_analyze_image which do not involve code execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There is no mention of when code execution is appropriate, prerequisites, or situations where other tools like gemini_chat or gemini_structured_output might be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Count the number of tokens in the provided text using a Gemini model
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to count tokens for | |
| model | No | Model to use (default: gemini-3.1-pro-preview) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does not mention side effects, read-only nature, permissions, or any other behavioral traits beyond counting tokens.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, and concise sentence with no unnecessary words, making it efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple token counting tool with 2 parameters and no output schema, the description is minimally adequate. However, it lacks usage guidelines and behavioral transparency, leaving some context gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds minimal extra meaning beyond the schema. It repeats 'text' and implies 'model' but does not elaborate on format or constraints, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool counts tokens in provided text using a Gemini model. The verb 'Count' and resource 'tokens' are specific, and no sibling tool performs token counting, making it distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. With many sibling tools, such as chat or analysis tools, explicit usage context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a deep research task using Gemini Deep Research. Returns an interaction ID. Then call gemini_check_research with wait=true in the background to get notified when complete.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The research query or question |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description reveals async behavior (returns ID, background check) but omits details on permissions, rate limits, or cost implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences that front-load the purpose and output, with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple async research tool, the description covers the purpose, return value, and required follow-up step. No output schema needed for this completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for 'query'. The tool description adds no additional parameter detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb 'Start' and resource 'deep research task', and distinguishes from siblings by noting the subsequent call to gemini_check_research.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly describes the workflow: start task, then call gemini_check_research with wait=true. Implicitly distinguishes from other analysis tools but lacks explicit when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a file from the Gemini Files API
| Name | Required | Description | Default |
|---|---|---|---|
| fileName | Yes | File name (e.g., "files/abc123") from upload or list |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry full behavioral burden. It only states 'Delete a file' without disclosing permanence, irreversibility, or potential side effects (e.g., cascading deletions). This is insufficient for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. It is appropriately concise for a simple operation, though additional context could be added without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is incomplete. It doesn't explain what the result of deletion is (e.g., confirmation, error codes) or whether the file must exist. For a destructive action, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter is already documented. The description adds no extra meaning beyond the schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Delete a file from the Gemini Files API', clearly identifying the verb (delete), resource (file), and API context. It distinguishes well from sibling tools like upload and list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., after confirming file is no longer needed). No prerequisites or exclusions are mentioned, leaving the agent with only implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate text embeddings using a Gemini embedding model
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to generate embeddings for | |
| model | No | Embedding model to use (default: gemini-embedding-001) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks behavioral traits such as auth needs, rate limits, or side effects. It only states the core function, leaving the agent without transparency on what happens beyond generation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and to the point. However, it could include more context without becoming wordy, so slightly above average.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 2 parameters and no output schema, the description is complete enough for a simple embedding tool but lacks details on output format or embedding dimensions, leaving some gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and both parameters are described in the schema. The description adds no extra meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates text embeddings using a Gemini embedding model, which is a specific verb+resource. It distinguishes from sibling tools that focus on analysis, chat, or other tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as when to choose a different model or when not to use embeddings. No context on prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List files uploaded to the Gemini Files API
| Name | Required | Description | Default |
|---|---|---|---|
| pageSize | No | Number of files to list (default: 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It only states it lists files but does not mention that it is read-only, whether it requires authentication, or any details about pagination or rate limits. The parameter 'pageSize' hints at pagination but is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is front-loaded and efficient. It could be slightly expanded to include behavioral details without becoming verbose, but it is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description is adequate but lacks details about the return value (e.g., list of file objects, metadata). It covers the basic purpose but leaves out context about what the output contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; the parameter 'pageSize' is described in the schema as 'Number of files to list (default: 20)'. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'files', and the context 'Gemini Files API'. It distinguishes this tool from siblings like gemini_upload_file and gemini_delete_file by specifying it lists files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 others, no prerequisites, and no exclusions. There is no mention of alternatives or context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available Gemini models with their capabilities and token limits
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states it lists models, but omits details like read-only nature, authentication needs, rate limits, pagination, or any side effects. For a simple listing, minimal disclosure is acceptable but not ideal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that includes the action and key output details. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the low complexity (no parameters, no output schema), the description lacks details about the return format, whether the list is exhaustive or filtered, and any constraints. Since no output schema exists, the description should be more informative to fully guide the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, which gives a baseline of 4. The description adds value by specifying that the output includes 'capabilities and token limits,' clarifying what the list contains beyond just model names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists available Gemini models and mentions capabilities and token limits. This is a specific verb+resource combination that distinguishes it from siblings like gemini_list_files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description does not mention prerequisites, context, or scenarios where this tool is preferable over other Gemini tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a prompt to Gemini with Google Search grounding and URL context for up-to-date information
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model name (default: gemini-3.1-pro-preview) | |
| prompt | Yes | The prompt to send with search grounding | |
| enableUrlContext | No | Also enable URL context (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must convey behavioral traits. It only states it sends a prompt with grounding but does not disclose whether it is read-only, destructive, requires authentication, or has rate limits. Very limited behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key action and context, no unnecessary words or fluff. Very concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not explain what the response contains. Also lacks details on prerequisites, return format, or error handling. Incomplete for a tool that returns search results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter. The description adds little beyond schema, implying defaults for model and enableUrlContext but not providing additional semantic meaning. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a prompt to Gemini with Google Search grounding and URL context, which is a specific verb-resource combination. It distinguishes from sibling tools like gemini_chat that lack explicit search grounding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, but the implication is clear from the name and description that it is for up-to-date information. Lacks explicit when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get structured JSON output from Gemini using a provided JSON schema
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model name (default: gemini-3.1-pro-preview) | |
| prompt | Yes | The prompt to send to Gemini | |
| jsonSchema | Yes | JSON schema string defining the expected output structure |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only says 'Get structured JSON output'. It does not disclose failure modes (e.g., invalid schema), response format beyond structured JSON, authentication needs, or rate limits. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It is front-loaded and efficient, though adding a brief example or usage tip could improve it without significant bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, so the description should explain the return value (e.g., JSON object conforming to the schema). It also lacks usage context (e.g., compare to gemini_chat for structured output). Incomplete for a tool with 3 parameters and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond what the schema already provides (model, prompt, jsonSchema). It does not clarify expected JSON schema format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get structured JSON output from Gemini using a provided JSON schema'. The verb 'get' and the specific resource 'structured JSON output' distinguish it from sibling tools like gemini_chat (free-form text) or gemini_embed (embeddings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as gemini_chat or when not to use it. There is no mention of prerequisites, fallback options, or comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize long text using Gemini with configurable summary style
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to summarize | |
| model | No | Model to use (default: gemini-3.1-pro-preview) | |
| style | No | Summary style: brief, detailed, bullet-points (default: brief) |
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 only states the basic function without disclosing behaviors such as auth requirements, rate limits, or potential side effects. The term 'summarize' suggests a non-destructive generative operation but lacks explicit clarification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 8 words, delivering the core purpose without any wasted words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and three parameters with full coverage, the description is minimally complete for a simple tool but lacks details on return format, error handling, or limitations. It adequately covers the primary function but leaves gaps for a thorough understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters, so the description adds minimal extra meaning beyond what the schema provides. The phrase 'configurable summary style' aligns with the style parameter but does not enrich understanding of text or model parameters beyond their schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Summarize' and the resource 'long text using Gemini', distinguishing it from sibling tools like gemini_chat or gemini_deep_research by focusing specifically on summarization with configurable style.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for summarization of long text, but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Translate text to a target language using Gemini
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to translate | |
| model | No | Model to use (default: gemini-3.1-pro-preview) | |
| sourceLanguage | No | The source language (auto-detected if omitted) | |
| targetLanguage | Yes | The language to translate into |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behaviors like source auto-detection, model default, latency, or API requirements. It only repeats the basic purpose, leaving significant behavioral gaps for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, which is efficient. However, it could include a bit more detail without becoming verbose. The structure is front-loaded but too brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no output schema, and no annotations. The description fails to mention return value (text translation), error handling, or language format (code vs name). It is incomplete for the given complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no extra semantics beyond the schema's parameter descriptions, nor does it clarify format or usage for parameters like targetLanguage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (translate), the resource (text), and the goal (to a target language) using the Gemini model. It is distinct from sibling tools, which are primarily analytical or chat-based, so no confusion arises.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., gemini_chat for translation) or when not to use it. The description lacks context such as prerequisites or scenarios where auto-detection might fail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a file to Gemini Files API for use with analysis tools. Files are retained for 48 hours. Max 2GB per file, 20GB total.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the file to upload | |
| mimeType | No | MIME type override (auto-detected from extension if omitted) | |
| displayName | No | Display name for the uploaded file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses retention period and size limits, adding behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words. Every sentence provides essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description omits return values, but for a file upload tool this is acceptable. Size limits and retention are stated. Sibling tools provide context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds minor clarifications ('absolute path', 'MIME type override') but does not significantly enhance parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Upload') and resource ('file to Gemini Files API'), and distinguishes from sibling analysis tools by stating the file is for use with analysis tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States purpose ('for use with analysis tools') and provides constraints (48-hour retention, size limits). No explicit alternatives or when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze one or more URLs using Gemini URL context tool. Gemini fetches and reads the URLs directly.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | No | Array of URLs to analyze (optional) | |
| model | No | Model name (default: gemini-3.1-pro-preview) | |
| prompt | Yes | Prompt about the URL(s). URLs in the prompt text are also auto-detected. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description must fully disclose behavior. It mentions direct fetching but omits important details like authentication needs, rate limits, or potential side effects. This is insufficient for a tool that makes network requests.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. However, lacks structured formatting (e.g., bullets) that could improve scanability for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters, no output schema, and no annotations, the description is too brief. It does not explain the return format, error handling, or how this tool compares to similar siblings. Incomplete for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds useful info that URLs in the prompt are auto-detected, but does not enrich the other parameters beyond schema. Minimal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool analyzes one or more URLs using Gemini, with direct fetching. However, it does not distinguish from sibling tools like gemini_analyze_url, partially impacting clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. Sibling tools with similar names exist but are not mentioned, leaving the agent to infer usage on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v2.0.0gemini_analyze_audiogemini_analyze_imagegemini_analyze_pdfgemini_analyze_urlgemini_analyze_videogemini_analyze_youtubegemini_chatgemini_chat_multigemini_chat_with_toolsgemini_check_researchgemini_code_executegemini_count_tokensgemini_deep_researchgemini_delete_filegemini_embedgemini_list_filesgemini_list_modelsgemini_search_groundedgemini_structured_outputgemini_summarizegemini_translategemini_upload_filegemini_url_contextScored across 23 tools
Most tools have distinct purposes, but there is some overlap among chat variants (e.g., gemini_chat, gemini_chat_multi, gemini_chat_with_tools) and analysis tools (e.g., analyze_pdf vs. summarize). Descriptions help, but an agent might occasionally select the wrong tool.
All tools follow the consistent pattern 'gemini_verb_noun' (e.g., gemini_analyze_audio, gemini_list_files). The naming is uniform and predictable, making it easy for an agent to infer tool purposes.
23 tools cover a broad range of capabilities. While the count is slightly high, each tool serves a distinct function within the Gemini ecosystem. A few similarities exist, but overall the scope is justified.
The tool set covers all major Gemini features: multimodal analysis, chat variants, file management, embeddings, code execution, search, structured output, and more. There are no obvious gaps for typical use cases.
YouTube transcripts, search, channels, playlists and bulk transcript jobs for AI agents. 14 tools.
SEO & marketing toolkit for AI agents: GA4, Search Console, AdSense, GTM, PageSpeed, Trends.
SEO research, audits, backlinks, GSC, and content workflow tools for AI agents.
PDF, image, video, OCR, screenshot, SQL, QR and text tools for agents. No API key, no signup.
