Provides tools to analyze and summarize content from URLs using Google Gemini's URL Context capability, with optional grounding through Google Search for enhanced research capabilities.
Click on "Install 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., "@URL-Context-MCP MCP summarize this article about AI trends: https://example.com/ai-article"
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.
The URL-Context-MCP MCP Server provides a tool to analyze and summarize the content of URLs using Google Gemini's URL Context capability via the Gemini API.
Now also supports optional grounding with Google Search alongside URL Context. The server is designed to follow prompt-only orchestration: control whether to search or scrape via the instruction text you provide.
Node.js 18+
Set GOOGLE_API_KEY in your environment
Sign in to Google AI for Developers and create an API key
Copy the generated key and set it as GOOGLE_API_KEY for this server
Cursor (project): add to .cursor/mcp.json under env
Claude CLI one-liner example: shown below
Or set it in your shell before launching
This MCP server is now available as a published npm package: @taiyokimura/url-context-mcp
No need to clone the repository locally
Can be run directly via npx @taiyokimura/url-context-mcp@latest
See setup instructions below for Cursor and Claude Code
cd /Users/kimurataiyou/url-context-mcp
npm i
npm run buildRelated MCP server: Scrapi MCP Server
Use this one-line command (replace with your real API key):
claude mcp add URL-Context-MCP -s user -e GOOGLE_API_KEY="sk-your-real-key" -- npx @taiyokimura/url-context-mcp@latestTo remove the server from Claude Code:
claude mcp remove URL-Context-MCPCreate .cursor/mcp.json at your repository root:
{
"mcpServers": {
"URL-Context-MCP": {
"command": "npx",
"args": ["@taiyokimura/url-context-mcp@latest"],
"env": { "GOOGLE_API_KEY": "sk-your-real-key" },
"autoStart": true
}
}
}Install in VS Code
Install in VS Code Insiders
Or add via CLI:
code --add-mcp '{"name":"URL-Context-MCP","command":"npx","args":["@taiyokimura/url-context-mcp@latest"],"env":{"GOOGLE_API_KEY":"sk-your-real-key"}}'Follow the MCP install guide and use the standard config above:
Add MCP Server with:
Command: npx
Args: ["@taiyokimura/url-context-mcp@latest"]
Env: GOOGLE_API_KEY=sk-your-real-key
Advanced settings → Extensions → Add custom extension:
Type: STDIO
Command: npx
Args: @taiyokimura/url-context-mcp@latest
Enabled: true
Example ~/.config/opencode/opencode.json:
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"url-context-mcp": {
"type": "local",
"command": [
"npx",
"@taiyokimura/url-context-mcp@latest"
],
"enabled": true
}
}
}Open Qodo Gen (VSCode/IntelliJ) → Connect more tools → + Add new MCP → Paste the standard config JSON → Save.
Follow Windsurf MCP documentation and use the standard config above:
GOOGLE_API_KEY: Your Gemini API key
analyze_urls
inputs:
urls: string | string[] (1-20 total)
instruction?: string
model?: string (default: gemini-2.5-flash)
use_google_search?: boolean (default: false) — enable grounding with Google Search in addition to URL Context
Scraping-only (user provided URLs). Example instruction:
"ユーザーが貼ったこれらのURLのみをURLコンテキストで解析し、要約・キーファクト・引用URLを日本語で提示。外部検索は禁止。取得失敗は明示。"
Research with search + scraping, iterative up to 5 rounds. Example instruction:
"以下のテーマを調査。まずGoogle検索で候補を収集し、引用する全URLは必ずURLコンテキストで取得・要約・統合。カバレッジ不十分なら最大5回まで再検索・再収集して補完。日本語で簡潔に要約・キーファクト・引用URLを提示。"
{
"name": "analyze_urls",
"arguments": {
"urls": "https://note.com/hawk735/n/nbc585d0774df",
"instruction": "日本語で、要約・キーファクト・引用URLを簡潔に",
"use_google_search": true
}
}Scraping-only example
{
"name": "analyze_urls",
"arguments": {
"urls": ["https://example.com/post1", "https://example.com/post2"],
"instruction": "ユーザーが貼ったこれらのURLのみをURLコンテキストで解析し、要約・キーファクト・引用URLを日本語で提示。外部検索は禁止。取得失敗は明示。"
}
}Research + scraping (iterative) example
{
"name": "google_search",
"arguments": {
"query": "最新のNext.js 14のApp Routerのベストプラクティス",
"instruction": "まずGoogle検索で候補を収集し、引用する全URLは必ずURLコンテキストで取得・要約・統合。カバレッジ不十分なら最大5回まで再検索・再収集して補完。日本語で簡潔に要約・キーファクト・引用URLを提示。"
}
}401 auth errors: verify GOOGLE_API_KEY
Ensure Node 18+
For npx usage: npx @taiyokimura/url-context-mcp@latest should work without local build
For local development: use absolute path to build/index.js
Analyze and summarize the content of given URLs using Google Gemini URL Context. Provide an optional instruction and model.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | One URL string or an array of URLs (max 20) | |
| instruction | No | Optional instruction or task description | |
| model | No | Gemini model id (e.g., gemini-2.5-flash) | |
| use_google_search | No | Enable grounding with Google Search (adds google_search tool alongside URL context) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool 'analyzes and summarizes' but doesn't describe what that entails (e.g., what format the summary takes, whether it extracts specific information types, or any limitations like rate limits, authentication needs, or content restrictions). The description is minimal and lacks operational 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?
The description is a single, efficient sentence that states the core purpose and mentions key optional parameters. Every word earns its place with no redundancy or fluff, making it appropriately front-loaded and concise.
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 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (summary format, structure, or content), any behavioral constraints, or how it differs from the sibling 'google_search' tool. For a content analysis tool with multiple parameters, this leaves significant gaps for an AI 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 description coverage is 100%, so the schema already documents all four parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema (e.g., it doesn't explain how 'instruction' affects analysis or what 'use_google_search' practically does). Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('analyze and summarize') and resource ('content of given URLs'), and mentions the technology used ('Google Gemini URL Context'). It distinguishes from the sibling 'google_search' tool by focusing on URL content analysis rather than web search. However, it doesn't explicitly contrast with the sibling tool's functionality.
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 like 'google_search'. It mentions the sibling tool name in the context of a parameter ('use_google_search'), but offers no explicit when/when-not instructions or comparison between the tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the web using Google Search grounding via Gemini API. Provides search results with sources and citations.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query to find information on the web | |
| instruction | No | Optional instruction for processing search results | |
| model | No | Gemini model id (e.g., gemini-2.5-flash) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool 'Provides search results with sources and citations,' which adds some context about output format. However, it lacks critical behavioral details such as rate limits, authentication requirements, error handling, or whether it's a read-only operation (though implied by 'Search'). For a tool with no annotations, this is insufficient.
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 highly concise and front-loaded: two sentences that directly state the tool's function and output. Every word earns its place, with no redundant or vague phrasing. It efficiently communicates the core purpose without unnecessary details.
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 moderate complexity (web search with three parameters) and lack of annotations and output schema, the description is minimally adequate. It covers the basic purpose and output format but misses behavioral context and usage guidelines. For a search tool without structured output documentation, it should ideally explain result structure or limitations.
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 schema already documents all three parameters (query, instruction, model) with descriptions. The description adds no parameter-specific semantics beyond what's in the schema. It implies the tool processes search results but doesn't elaborate on how parameters interact. Baseline 3 is appropriate when the schema does the heavy lifting.
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: 'Search the web using Google Search grounding via Gemini API.' It specifies the verb ('Search') and resource ('the web'), and mentions the mechanism ('via Gemini API'). However, it doesn't explicitly differentiate from its sibling tool 'analyze_urls' (which likely analyzes specific URLs rather than performing web searches).
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. It doesn't mention the sibling tool 'analyze_urls' or any other search-related tools, nor does it specify prerequisites, constraints, or typical use cases. The agent must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools have clearly distinct purposes: analyze_urls is for summarizing content from specific URLs, while google_search is for performing web searches to find information. There is no overlap in functionality, making it easy for an agent to choose the correct tool based on the task.
Both tool names follow a consistent verb_noun pattern (analyze_urls, google_search) with clear, descriptive verbs and nouns. The naming style is uniform and predictable across the set.
With only 2 tools, the server feels under-scoped for a URL and search context MCP. While the tools cover basic analysis and search, the lack of additional operations (e.g., URL validation, result filtering, or advanced search options) limits functionality and may require agents to work around gaps.
The tool set is severely incomplete for a URL and search domain. It lacks essential operations such as URL validation, content extraction beyond summarization, search result refinement, or integration with other web tools. This will likely cause agent failures when handling more complex tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Jina AI Reader/Search MCP — turn any URL into clean LLM-ready markdown, plus web search.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/nanameru/url-context-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
