F
licenseC
qualityD
maintenanceAn MCP protocol server that enables web search functionality using the Tavily API, allowing AI assistants to perform internet searches in real-time.
4
4
-
superhighway-mcp
by patwalls
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., "@superhighway-mcpsearch for the latest news on AI"
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.
superhighway-mcp
Web search for AI agents that pays for itself.
An MCP server that gives any MCP-speaking agent (Claude Desktop, etc.) a real-time web search tool. Under the hood it pays Superhighway $0.001 per search in USDC via the x402 protocol, using your wallet — no API key, no signup, no human in the loop.
Install
Add to your MCP client config (e.g. Claude Desktop's claude_desktop_config.json):
{
"mcpServers": {
"superhighway": {
"command": "npx",
"args": ["-y", "github:patwalls/superhighway-mcp"],
"env": {
"AGENT_PRIVATE_KEY": "0xYOUR_FUNDED_BASE_WALLET_KEY",
"X402_NETWORK": "base"
}
}
}
}Restart your client. The agent now has three tools that do the whole search job — web_search (live, ranked results), news_search (recent articles with dates), and scrape (read any URL as clean markdown). Find it, read it, pay per call.
Related MCP server: 4o-mini-search-mcp
Wallet
AGENT_PRIVATE_KEY is a wallet you control, funded with a little USDC on Base
(each search costs $0.001; gas is covered by the facilitator, so you don't need ETH).
The key only ever signs tiny USDC payments — keep it to a small balance.
Want to try free first? Set X402_NETWORK=base-sepolia and fund the wallet from a
Base Sepolia faucet to pay in test USDC.
What you get
web_search (web) and news_search (recent news) each return results as JSON:
{ "query": "...", "count": 5, "results": [ { "title": "...", "url": "...", "description": "..." } ] }Powered by Superhighway — the web-search API agents pay for.
Available Tools
5 toolsimage_searchA
Image search. Returns direct image URLs, source pages, and thumbnails as JSON from a multi-engine image metasearch. Paid per call in USDC via x402 — no signup, no API key. Use for visual grounding, finding images for content generation, and multimodal research.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, 1-20 (default 5). | |
| query | Yes | The search query. |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the pricing model (paid per call via x402, no signup, no API key) and the multi-engine metasearch nature. It does not mention rate limits or caching, but for a search tool, the transparency is sufficient.
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 three concise sentences: functional output, pricing model, and use cases. No wasted words; critical information is front-loaded.
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 only 2 parameters and no output schema, the description covers the essentials: what it searches, what it returns (image URLs, source pages, thumbnails, JSON), cost model, and use cases. It is complete enough for an agent to invoke correctly.
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% both parameters have descriptions. The description adds context about the return format but does not add meaning beyond what the schema already provides for the parameters. Baseline 3 applies.
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 'Image search' and enumerates the outputs (direct image URLs, source pages, thumbnails as JSON). This verb+resource combination is specific and easily distinguishes it from sibling tools like web_search, news_search, and research.
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 explicitly lists use cases: 'visual grounding, finding images for content generation, and multimodal research.' It does not explicitly state when not to use or alternatives, but the sibling tool names imply the context well enough for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
news_searchA
Real-time news search. Returns recent news articles (title, url, snippet, published date) as JSON from a multi-engine news metasearch. Paid per call in USDC via x402 — no signup, no API key. Use for current events, breaking news, monitoring, and time-sensitive facts.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, 1-20 (default 5). | |
| query | Yes | The search query. |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses payment model (paid per call in USDC via x402, no signup, no API key) and return format (JSON). Lacks details on rate limits or error 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?
Two concise sentences with clear structure: defines tool, then explains payment and use cases. No superfluous words.
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?
Covers return format and payment. No output schema, but description lists fields. Adequate for a simple two-parameter tool; missing only minor details like rate limits.
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% with descriptions for both parameters. Description does not add meaning beyond what the schema already provides.
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 it is a 'Real-time news search' and specifies output fields (title, url, snippet, published date). Distinguishes from sibling tools like web_search and image_search by focusing on news.
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 lists use cases (current events, breaking news, monitoring, time-sensitive facts) but does not mention when not to use or suggest alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
researchA
One-call web research: searches the live web AND reads the top result pages as clean markdown — content, not just links. Give a question, get ranked results plus the readable text of the best pages ($0.005/call in USDC via x402 — no signup, no API key). Use to answer questions from fresh sources in a single tool call instead of search-then-scrape round-trips.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| pages | No | How many top results to read as markdown, 1-3 (default 2). | |
| query | Yes | The question or topic to research. |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses core actions (search+scrape), output format (clean markdown, content not links), and cost. Missing failure modes or rate limits, but sufficient for basic use.
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?
Two sentences with no waste. The first sentence front-loads the core functionality and unique value. Every part serves a purpose, including pricing and usage guidance.
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 description explains the combined search+scrape behavior, but lacks details on the return structure (e.g., how results are ranked, text format). However, for a tool with no output schema and two simple params, it provides adequate context.
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% with both parameters described. The description reinforces they exist but adds only marginal context (e.g., 'top results', 'clean markdown'). No new constraints or clarifications beyond 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 'searches the live web AND reads the top result pages as clean markdown', specifying both the verb and resource. It distinguishes from siblings like web_search and scrape by combining search and scrape in one call.
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 says 'Use to answer questions from fresh sources in a single tool call instead of search-then-scrape round-trips', providing clear when-to-use and an alternative to sibling tools. Also mentions pricing and no signup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scrapeA
Read any web page as clean text + markdown. Give a URL, get back the page title, readable markdown, and plain text. Paid per call in USDC via x402 — no signup, no API key. Use to let the agent read pages, fetch articles/docs it can't access, scrape content, and feed RAG.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The page URL to read (http/https). |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the payment model (paid per call via x402, no signup), the output format (title, markdown, plain text), and that it's a read-only operation. It lacks details on rate limits or error handling, but for a simple tool this is adequate.
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 three sentences, front-loaded with the core purpose. Each sentence adds value: purpose, input/output, and use case/payment model. No wasted words.
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 (one parameter, no output schema, no annotations), the description covers all necessary information: what it does, how to use it, what to expect, and special conditions (payment). It is fully sufficient.
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 schema covers 100% of parameters with a basic description. The tool's description adds meaning by explaining what happens with the URL ('Get back the page title, readable markdown, and plain text') and the expected input (a URL). This goes 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 the tool reads web pages and returns clean text and markdown. It specifies the action (read, fetch, scrape) and the resource (web pages). The sibling tools are search-oriented, so this tool's distinct purpose is well-defined.
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 includes explicit use cases: 'Use to let the agent read pages, fetch articles/docs it can't access, scrape content, and feed RAG.' While it doesn't explicitly state when not to use, the context of siblings implies this is for direct URL access, not search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
web_searchA
Real-time web search. Returns ranked organic results (title, url, snippet) as JSON from a multi-engine metasearch. Paid per call in USDC via x402 — no signup, no API key. Use for fresh facts, research, fact-checking, and grounding/RAG.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, 1-20 (default 5). | |
| query | Yes | The search query. |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. Discloses multi-engine metasearch, paid per call via x402, no signup/key needed. Describes output format.
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?
Two concise sentences. First sentence covers purpose and output. Second sentence adds pricing and use cases. Every sentence earns its place.
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?
No output schema, but description explains return fields (title, url, snippet). Covers purpose, pricing, use cases. Parameters documented. Missing pagination details, but acceptable for a search tool.
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 covers 100% of parameters with descriptions. Description adds default for limit (5) and range (1-20), but schema already specifies these. Minimal extra value beyond 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?
Clearly states 'real-time web search' with specific output format (JSON, ranked, with title/url/snippet). Distinguishes from sibling tools by implying general web results.
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?
Explicit use cases: fresh facts, research, fact-checking, grounding/RAG. Pricing model noted. No direct alternatives named, but sibling list implies scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
5 tool updates
v1.2.0- First observed
image_search - First observed
news_search - First observed
research - First observed
scrape - First observed
web_search
TDQS
A4.4/5.0
Disambiguation5/5
Each tool targets a distinct source or operation: images, news, web search, combined search+scrape, and raw scraping. The descriptions clearly differentiate their use cases, so an agent can easily select the right one.
Naming Consistency4/5
Tool names mostly follow a verb_noun pattern (e.g., web_search, news_search, image_search), but 'scrape' is a bare verb and 'research' is a noun, creating a minor inconsistency. Overall still readable and predictable.
Tool Count5/5
Five tools cover the essential web research functionality without redundancy or bloat. Each tool serves a clear purpose, and the count feels well-scoped for the stated domain.
Completeness5/5
The set covers image, news, and general web search, plus page scraping and a combined research operation. This spans the full typical workflow for web-based information retrieval, leaving no significant gaps.
Maintenance
ActivityInactive
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Capability registry for the agentic economy. Semantic search over verified MCP server listings.
- UnifAPIOAuthcom.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Scrape, crawl and search the web for AI agents via MCP.
Related MCP Servers
- FlicenseNot gradedqualityNot gradedmaintenanceAn MCP server that enables AI models to search the web using OpenAI's 4o-mini Search model, allowing access to up-to-date information for just a few cents per search.32-
- AlicenseAqualityCmaintenanceAn MCP server that enables web search capabilities using OpenAI's o3 model, allowing AI assistants to perform text-based web searches and return AI-powered results.1110288MIT
- AlicenseAqualityDmaintenanceA general-purpose MCP server providing web search, persistent memory storage, and secure code execution capabilities. It enables AI agents to search the web, store and retrieve data, and run Python/JavaScript code in sandboxed environments.8MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/patwalls/superhighway-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server