The Web3 Research MCP server enables comprehensive cryptocurrency token research and analysis through multiple tools:
Create structured research plans for specific tokens
Conduct web searches (web, news, images, videos)
Research tokens using specific keywords
Track and update research progress (planned, in_progress, completed)
Fetch and store content from URLs in various formats (text, html, markdown, json)
List saved research resources
Search for token information from specific sources like CoinGecko, DeFiLlama, Dune, IQ Wiki, News, and CoinMarketCap
Initiate and manage detailed research projects on cryptocurrency tokens
Gathers detailed token information from CoinMarketCap to include in research reports about cryptocurrency tokens
Supports repository cloning for installation and setup of the Web3 Research MCP
Hosts preview images of the MCP interface shown in the README
Provides content formatting option when fetching resources from URLs
Required runtime environment for running the MCP server
Used for package management and running build/start commands
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., "@Web3 Research MCP research the latest trends in decentralized finance protocols"
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.
Comprehensive Research: Gather detailed information about any cryptocurrency token
Multi-Source Analysis: Research across multiple sources including CoinGecko, CoinMarketCap, DeFiLlama, and more
Structured Reporting: Generate detailed reports covering technical fundamentals, market data, social sentiment, and more
Resource Management: Automatically stores search results and content for reference
Status Tracking: Track research progress through different stages and sections
Related MCP server: deeplook
Node.js (v16 or higher)
To install web3-research-mcp for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install web3-research-mcp --client claudeEdit your Claude Desktop config file
Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Add this to your Claude Desktop configuration file:
{
"mcpServers": {
"web3-research-mcp": {
"command": "npx",
"args": ["-y", "web3-research-mcp@latest"]
}
}
}Then restart Claude Desktop
Go to: Settings -> Cursor Settings -> MCP -> Add new global MCP server Paste this into your Cursor ~/.cursor/mcp.json file. See Cursor MCP docs for more info.
{
"mcpServers": {
"web3-research-mcp": {
"command": "npx",
"args": ["-y", "web3-research-mcp@latest"]
}
}
}Then restart Cursor
Creates a structured research plan for a token.
Parameters:
tokenName: Full name of the token
tokenTicker: Ticker symbol of the token
Performs a web search and returns the results.
Parameters:
query: Search query
searchType: Type of search (web, news, images, videos)
Searches for a token with specific keywords and saves the results.
Parameters:
tokenName: Name of the token
tokenTicker: Ticker symbol
keywords: Array of keywords to search for
Updates the status of a research section.
Parameters:
section: Section name to update (e.g., 'projectInfo', 'technicalFundamentals')
status: New status for the section (planned, in_progress, completed)
Fetches content from a URL and saves it as a resource.
Parameters:
url: URL to fetch content from
format: Output format (text, html, markdown, json)
Lists all available resources that have been saved.
Searches for information about a token from a specific source.
Parameters:
tokenName: Name of the token
tokenTicker: Ticker symbol
source: Source to search (e.g., 'CoinGecko', 'DeFiLlama', 'News')
Searches a specific source for a token and saves the top result's page content as a markdown resource.
Parameters:
tokenName: Name of the token
tokenTicker: Ticker symbol of the token
source: Source to research (e.g., 'IQ Wiki', 'CoinMarketCap')
Fetches live market data directly from the CoinGecko public API — price, market cap, 24h/7d/30d changes, ATH/ATL, circulating supply, contract addresses across chains, and social/dev links. Bypasses the 403 issues of HTML scraping.
Parameters:
tokenName: Full name of the token (e.g., 'Bitcoin')
tokenTicker: Ticker symbol (e.g., 'BTC')
No API key required. Uses the free public tier (~30 req/min).
Optional: set COINGECKO_API_KEY in the environment to use a CoinGecko Pro API key. When set, requests are sent to https://pro-api.coingecko.com/api/v3 with the x-cg-pro-api-key header. Requests time out after 15s.
Searches CoinGecko's coin index and returns candidate matches with their CoinGecko IDs. Useful when the ticker is ambiguous (e.g., multiple tokens with the same symbol).
Parameters:
query: Search query — name, ticker, or contract address
Fetches active exchange listings for a token from CoinGecko — which CEXs/DEXs trade the pair, per-venue 24h USD volume, last price, bid-ask spread, trust score, and trade URL. Sorted by 24h USD volume desc; anomalies and stale prints are filtered out. Bypasses HTML scraping for the "where does this token actually trade" question.
Parameters:
tokenName: Full name of the token (e.g., 'Bitcoin')
tokenTicker: Ticker symbol (e.g., 'BTC')
limit: How many top venues to return (default 15, max 50)
No API key required. Uses the free public tier. Requests time out after 15s.
Fetches protocol data directly from the DeFiLlama public API — total TVL, ATH TVL with date, 30/90/365-day TVL change vs current, market cap (when available — DeFiLlama omits it for many protocols), per-chain TVL breakdown, fees (24h/7d/30d/all-time), token addresses, fundraising rounds, and links. Bypasses HTML scraping for the most common DeFi-protocol lookup.
Parameters:
tokenName: Full protocol/token name (e.g., 'Uniswap')
tokenTicker: Ticker symbol (e.g., 'UNI')
No API key required. Uses the free public API. Requests time out after 15s. The protocol index is cached for 5 minutes per process to avoid hammering /protocols on every call.
Searches DeFiLlama's protocol index and returns candidate matches with their slugs, TVL, and category. Useful when the ticker is ambiguous (e.g., multiple protocols with similar names).
Parameters:
query: Search query — protocol name, ticker, or slug
Initiates comprehensive research on a cryptocurrency token.
Parameters:
tokenName: Full name of the cryptocurrency token
tokenTicker: Ticker symbol of the token (e.g., BTC, ETH)
When research begins, a structured plan is created covering all aspects of the token
The server performs searches across multiple sources for information
Search results are stored as resources that can be referenced
The research progresses through different sections, with status tracking
A comprehensive report is generated covering all aspects of the token
Some websites block web scraping, so direct content fetching may fail with 403 errors
Relies on search results which may not always be comprehensive
Rate limits may apply to search operations
This project is licensed under the MIT License - see the LICENSE file for details.
Built by Aaron Elijah Mars, founder of Aeon and MiroShark · @aaronjmars
| Name | Required | Description | Default |
|---|---|---|---|
| tokenName | Yes | Full name of the token (e.g., 'Bitcoin') | |
| tokenTicker | Yes | Ticker symbol (e.g., 'BTC') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query — name, ticker, or contract address. Returns candidate CoinGecko IDs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many top venues to return (sorted by 24h USD volume) | |
| tokenName | Yes | Full name of the token (e.g., 'Bitcoin') | |
| tokenTicker | Yes | Ticker symbol (e.g., 'BTC') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| tokenName | Yes | Token name | |
| tokenTicker | Yes | Token ticker symbol |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| tokenName | Yes | Full protocol/token name (e.g., 'Uniswap') | |
| tokenTicker | Yes | Ticker symbol (e.g., 'UNI') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query — protocol name, ticker, or slug. Returns candidate DeFiLlama protocols with their slugs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to fetch content from (can be a resource:// URL) | |
| format | No | Output format | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Single source to research | |
| tokenName | Yes | Name of the token | |
| tokenTicker | Yes | Ticker symbol of the token |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Source to research (e.g., 'IQ Wiki', 'CoinMarketCap') | |
| tokenName | Yes | Name of the token | |
| tokenTicker | Yes | Ticker symbol of the token |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| keywords | Yes | Keywords to search for | |
| tokenName | Yes | Name of the token | |
| tokenTicker | Yes | Ticker symbol of the token |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| searchType | No | Type of search | web |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Source to search (e.g., 'Dune', 'IQ Wiki', 'News') | |
| tokenName | Yes | Name of the token | |
| tokenTicker | Yes | Ticker symbol of the token |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| status | Yes | New status for the section | |
| section | Yes | Section name to update (e.g., 'projectInfo', 'technicalFundamentals') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Multiple tools have unclear boundaries and overlapping purposes. 'search', 'search-source', 'research-with-keywords', and 'fetch-content' all appear to involve finding or retrieving information, making it difficult for an agent to choose the right tool. 'research-source' and 'research-token' might target different resources but lack descriptions to clarify their distinctness.
The naming shows mixed conventions with some consistency. Most tools use kebab-case (e.g., 'create-research-plan'), but 'update-status' uses a different verb style compared to others. There's no clear verb_noun pattern throughout, as tools like 'search' and 'list-resources' vary in structure, though they remain readable.
With 9 tools, the count is reasonable for a research-focused server. It's slightly on the higher side but still within a well-scoped range for handling various research tasks, assuming each tool serves a distinct purpose in the Web3 domain.
Inferring from tool names, the server covers research activities like planning, fetching, listing, and updating, but there are notable gaps. Without descriptions, it's unclear if there's full lifecycle coverage (e.g., deletion or analysis tools), and the overlap in search/research tools suggests potential redundancy rather than completeness.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Multi-LLM AI Research & Analysis — smart routing, consensus analysis, due diligence reports
Evidence-backed crypto due diligence with sources, freshness, and a runtime receipt on every call.
Signed BTC and macro market intelligence for autonomous research, risk, and trading agents.
Free daily AI crypto research verdicts: graded stance, dimensions, and key levels for 67+ coins.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/aaronjmars/web3-research-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
