gemini-web-mcp

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 clearly distinct purpose: starting a new conversation, continuing an existing one, listing models, listing conversations, viewing history, and deleting. The overlap between new and continue is resolved by explicit descriptions of creating vs. continuing.
Naming Consistency4/5
All tools share the gemini_ prefix and mostly follow a resource_verb pattern (chat_new, chat_continue, chat_list, chat_delete, models_list). The exception is gemini_chat_history, where 'history' is a noun rather than a verb, creating a minor inconsistency.
Tool Count5/5
With 6 tools, the server is well-scoped for chat conversation management. Each tool serves a distinct function in the lifecycle (create, continue, list, read history, delete) plus model discovery, without unnecessary bloat.
Completeness5/5
The tool set covers the complete workflow: create a conversation, continue it, list all conversations, retrieve full history, and delete. Model listing supports selecting the right model upfront. No obvious gaps remain for the stated purpose of interacting with Gemini conversations.
Average 3.8/5 across 6 of 6 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
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?
There are no annotations, so the description carries the full burden for behavioral disclosure. It only states 'list of saved conversations' with no details on ordering, filtering, pagination, or response structure, which is insufficient for a full understanding of behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. However, it is under-specified, which limits its usefulness despite being well-structured.
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 that this is a simple zero-parameter list tool with an output schema, the description is minimally adequate for basic understanding. Yet it lacks any contextual cues about when to use it or what it returns beyond 'saved conversations', making it incomplete for an agent to fully leverage it.
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?
The tool has zero parameters, and the schema is an empty object. With no parameters to explain, the baseline score of 4 applies, as the description does not need to compensate for any undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '保存中の conversation 一覧。' clearly indicates this tool returns a list of saved conversations, which is a specific resource. However, it lacks an explicit verb like 'list' or 'get' and does not differentiate itself from sibling tools such as gemini_chat_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not state when to use this tool versus alternatives like gemini_chat_history or gemini_chat_new, leaving the agent to infer applicability from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does add the important context that deletion happens 'from local', implying no remote effect, but it does not disclose whether the action is reversible, whether associated history is also removed, or any destructive consequences. This is insufficient for a delete operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the action and scope. It is front-loaded and contains no irrelevant or redundant information, making it highly efficient.
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?
The tool is simple with one well-documented parameter and an output schema. However, despite the low complexity, the description lacks usage context and any warning about destructive consequences. The 'local' qualifier provides some scope, but overall it is only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the 'label' parameter as '削除する session の label' (the label of the session to delete), and the description echoes this with '指定 session'. With 100% schema coverage, the description adds little new meaning beyond the schema, so the baseline score of 3 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?
The description clearly states the action ('delete') and the target resource ('specified session') with a scope ('from local'), which clearly distinguishes it from sibling tools like gemini_chat_new, gemini_chat_list, and gemini_chat_history. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It simply states what the tool does, so an agent has no context for when deletion is appropriate or how it interacts with other operations like continuing or listing sessions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. However, it only states the basic action, with no mention of side effects (e.g., conversation persistence), auth needs, or rate limits. The description does not add behavioral context beyond what the name already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that communicates the core purpose without any fluff. It is appropriately front-loaded and every word contributes to the meaning, though it could benefit from slightly more detail on usage.
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?
With an output schema present and a well-covered input schema, the description is minimally sufficient for a simple creation tool. However, it omits the persistent side effect of creating a stored conversation and any caveats, which would be valuable given the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with thorough descriptions for each parameter (label format, model options, thinking mode). The tool description itself adds no parameter-specific meaning beyond the schema, which meets the baseline for a fully documented 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 the action: create a new conversation, send the prompt, and return a response. The use of '新規' (new) distinguishes it from sibling tools like gemini_chat_continue, which handles existing conversations.
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 tool's name and the phrase '新規 conversation' imply it is for starting fresh conversations, but the description does not explicitly state when to choose this over gemini_chat_continue or mention any exclusions. Usage context is implied rather than clearly spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It does mention that it returns '全件' (all records), which indicates no pagination or filtering. It also implies a read-only operation by nature, but does not explicitly state side effects or error conditions. Some relevant behavioral context is missing, such as whether it requires an existing session or how it orders results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the tool's function. No unnecessary words or redundancy, making it easy to parse.
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?
The tool is simple with one parameter, and an output schema exists, so the description need not explain return values. The description covers the core action (returning all history) and the input concept (session). It lacks explicit notes about prerequisites or error handling, but for a straightforward getter, it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter 'label' is described as '対象 session の label'. The tool description refers to '指定 session' which aligns with the label parameter, but adds no additional meaning beyond the schema. The parameter semantics are adequately covered by the schema, so a baseline score of 3 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?
The description states a specific verb and resource: '返す' (return) the '会話履歴' (conversation history) for a given session. This clearly distinguishes it from siblings like gemini_chat_list (which likely lists sessions) and gemini_chat_new/continue (which create or continue chats).
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 implies usage: when you have a specific session label and need its full history. However, it does not explicitly mention alternatives or when not to use it. The intended context is clear from the tool name and description, but no explicit guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. The word 'list' implies a read-only operation, but it does not explicitly state that there are no side effects or that it is safe to call. It also does not mention whether the list is dynamic or static, though the phrase 'actually usable' adds some context beyond a bare list.
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 two concise sentences, front-loaded with the purpose and immediately followed by the key usage tip. Every sentence earns its place; there is no fluff or repetition.
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 this is a simple list tool with no parameters, an output schema available, and a clear sibling relationship (gemini_chat_new), the description is complete. It tells the user what the tool does and how to apply the result, which is sufficient contextual information.
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?
The tool has zero parameters, so the description does not need to explain parameter details. The baseline for 0 parameters is 4, and the description appropriately focuses on the output (`name`) rather than input semantics, which is relevant since the schema has no properties.
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 lists models available for the account, using a specific verb (list) and resource (models). It also distinguishes itself by noting the `name` can be passed directly to `gemini_chat_new`, which ties it to the sibling tools and clarifies its unique role.
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 implies when to use this tool—when you need to know which models are available—and gives explicit guidance that the returned `name` values can be used with `gemini_chat_new`. It doesn't explicitly state exclusions or alternatives, but the context is clear and the guidance is actionable.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals important behavioral traits: model inheritance from conversation start, rejection of model changes with the specific error code 1050 (ModelInvalid), and the workaround via gemini_chat_new. This goes beyond what the tool's name implies and helps the agent avoid predictable errors.
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, with the primary purpose stated upfront in a single sentence. The second sentence adds critical technical context about model inheritance and error handling, each part earning its place. No unnecessary words or redundancy.
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?
For a two-parameter tool with an output schema, the description is fairly complete. It covers the main operation, a key error scenario, and provides an alternative tool usage. However, it does not mention what happens if the label does not exist or if the conversation context is invalid, which could be relevant for error handling. Overall, it is sufficient but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (label as existing session label, prompt as continuation text) with 100% coverage. The description adds minimal new semantic information about the parameters, primarily restating the purpose of 'prompt' and 'label' in the context of continuing a conversation. Thus, a baseline score of 3 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?
The description clearly states the tool's function: sending a prompt to an existing conversation and returning a response. It specifies the resource (existing conversation) and action (send prompt), and distinguishes itself from siblings by explicitly mentioning that creating a new label with gemini_chat_new is the alternative for different models.
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?
The description provides explicit usage guidance, stating that the model is carried over from the conversation start and that mid-conversation model changes are rejected. It further recommends using gemini_chat_new to start a new label if a different model is desired, clearly defining when to use the alternative.
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-web-mcp MCP server](https://glama.ai/mcp/servers/TakashiAihara/gemini-web-mcp/badges/card.svg)](https://glama.ai/mcp/servers/TakashiAihara/gemini-web-mcp)

Score Badge

Copy to your README.md:

[![gemini-web-mcp MCP server](https://glama.ai/mcp/servers/TakashiAihara/gemini-web-mcp/badges/score.svg)](https://glama.ai/mcp/servers/TakashiAihara/gemini-web-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/TakashiAihara/gemini-web-mcp'

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