gemini-webapi-mcp

by AndyShaman

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a unique function: analyzing URLs, chatting, generating images, resetting the client, starting multi-turn sessions, and uploading files. There is no overlap or ambiguity in their purposes.
Naming Consistency4/5
All tools use a consistent 'gemini_' prefix and snake_case, but there is slight inconsistency in verb vs. verb_noun patterns (e.g., 'gemini_chat' vs 'gemini_start_chat'). The naming is mostly predictable and descriptive.
Tool Count5/5
With 6 tools, the set is well-scoped without being too few or too many. Each tool serves a distinct purpose, covering core interactions with Gemini.
Completeness4/5
The tool set covers all major interaction modes: text chat, image generation, URL analysis, file upload, session management, and client reset. Minor gaps like model listing or conversation history management are non-essential.
Average 4.5/5 across 6 of 6 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- 3 of 3 community issues answered or closed in the last 6 months
- 8 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims to upload a file, which is a write operation, but the annotations set readOnlyHint=true, creating a direct contradiction. This misleads the agent about the tool's side effects. Beyond this, the description only adds basic return info and default model, but fails to disclose rate limits, file size constraints, or error handling.
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 well-structured with separate args and returns sections. It is front-loaded with the purpose and remains concise, though the args section could be slightly streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the tool's moderate complexity, the description covers the basic workflow. However, it omits important contextual details like supported file formats, size limits, and error handling, which are critical for robust agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description provides essential meaning for all three parameters, including the default for model. However, the model parameter's default in the schema is null, while the description states a specific model name ('gemini-3.0-flash'), creating a discrepancy that could confuse agents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'upload' with the resource 'file to Gemini' and specifies the action of asking a question. This distinguishes it from sibling tools like gemini_chat or gemini_analyze_url, which handle different modalities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly suggests using the tool when a file needs analysis, but it does not explicitly contrast with siblings or provide when-not conditions. The purpose is clear enough from context, but explicit usage guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by stating 'Gemini can watch YouTube videos and read webpages, then answer questions.' This clarifies the tool's capabilities (including media processing). Annotations (readOnlyHint: true, destructiveHint: false) are consistent and the description adds value without contradiction.
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 very concise: a two-sentence overview followed by a structured Args section. Every sentence adds value, and the most critical information (purpose and capability) is front-loaded. No unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity and presence of an output schema, the description covers the tool's operation well (Args, returns, examples of content types). It lacks details on auth or rate limits, but annotations handle basic safety. Nearly complete for standard usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an Args section that explains each parameter's purpose (e.g., 'url: The URL to analyze', 'prompt: Question or instruction'), adding substantial meaning beyond the input schema's type/default information. With 0% schema description coverage, this fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Analyze a URL' and elaborates with specific examples like YouTube videos and webpages. It uses a specific verb ('analyze') and resource ('URL'), effectively distinguishing it from sibling tools like gemini_chat or gemini_generate_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (analyzing URL content) and implies it should be used instead of other tools for content analysis. However, it does not explicitly state when not to use it or mention alternatives, missing some guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses what the tool does (refresh cookies, clear state) beyond annotations. Annotations show idempotentHint=true and destructiveHint=false, which align with description. No contradictions.
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?
Three short sentences: purpose, usage scenario, return value. No wasted words. Front-loaded with key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and a simple action, the description fully explains purpose, when to use, and what to expect. Output schema is not needed as return type is described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100%. Description does not need to add param info. Baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action: 'Re-initialise the Gemini client' with specific actions (refresh cookies, clear state). It is distinct from sibling tools like gemini_chat or gemini_analyze_url.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises when to use: 'when you get authentication errors or want a fresh session'. Does not mention when not to use alternatives, but for a single-purpose tool this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations set readOnlyHint false, destructiveHint false, etc. Description adds that session maintains history and returns session_id. Discloses behavioral trait of context preservation. No contradictions.
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?
Very concise – three sentences plus structured Args/Returns sections. Front-loaded with main purpose. No redundant words. Each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 optional param, returns session_id), the description fully covers usage: what it does, how to use the output, and the model parameter. Sufficient for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'model' has 0% schema description coverage. Description provides default value (gemini-3.0-flash) and explanation, adding meaning beyond the schema. Could list available models, but adequate for a default parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Start a new multi-turn chat session with Gemini' with specific verb and resource. Distinguishes itself from siblings like gemini_chat and gemini_reset by indicating it initiates a session that maintains history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains that the session maintains conversation history for context, and instructs to pass the returned session_id to gemini_chat. Implicitly guides when to use this tool. Could explicitly state when not to use, but sufficient for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it states that the output includes the model's reasoning process when using flash-thinking model. Annotations already indicate readOnlyHint=true and destructiveHint=false, so no contradiction. The description is transparent about 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 concise and well-structured: a single paragraph with 'Args' and 'Returns' sections. Every sentence adds value, and the main action is front-loaded. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, output schema exists, annotations present), the description is complete. It covers parameter semantics, return value, and special behavior (thinking model reasoning), providing all necessary context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully explains all three parameters: prompt (text to send), model (with examples and default), and session_id (for multi-turn context from gemini_start_chat). This adds significant meaning beyond the schema's basic titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Send a text prompt to Google Gemini and get a response.' It specifies the verb (send), resource (text prompt to Gemini), and outcome (get response). It also distinguishes from sibling tools like gemini_start_chat by mentioning session_id for multi-turn conversation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage guidance, such as using the optional session_id from gemini_start_chat for multi-turn conversation and listing model options. However, it could be more explicit about when to use this tool compared to alternatives like gemini_analyze_url. The guidelines are mostly clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that images are saved to ~/Pictures/gemini/ and full paths are returned. Explains conversation continuation behavior. Annotations (readOnlyHint=false, destructiveHint=false) are not contradicted; description adds meaningful context beyond annotations.
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?
Well-structured with clear sections for modes, args, and returns. Every sentence adds value; no redundancy. Concise yet comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (image generation, editing, conversation history) and the presence of an output schema, the description covers all necessary aspects: mode selection, parameter usage, file saving, and return format. An agent can effectively invoke the tool based on this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description provides detailed explanations for all parameters: prompt (generation vs editing), model (name, default, aspect ratio hint), files (optional paths), and conversation_id (continuation method). Adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Generate or edit images with Gemini' and distinguishes between two modes (without files for new images, with files for editing). It uniquely identifies the tool's purpose among siblings, which are chat/analyze/upload/reset tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly guides when to use without files (new image) and with files (edit/transform). Also provides instructions for using conversation_id to continue refinement, and mentions model defaults. No direct alternatives exist among siblings, so this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![gemini-webapi-mcp MCP server](https://glama.ai/mcp/servers/AndyShaman/gemini-webapi-mcp/badges/card.svg)](https://glama.ai/mcp/servers/AndyShaman/gemini-webapi-mcp)

Score Badge

Copy to your README.md:

[![gemini-webapi-mcp MCP server](https://glama.ai/mcp/servers/AndyShaman/gemini-webapi-mcp/badges/score.svg)](https://glama.ai/mcp/servers/AndyShaman/gemini-webapi-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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

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

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