Глубокое исследование криптовалют — бесплатно и полностью локально 🧠
Related MCP server: deeplook
Комплексное исследование: Сбор подробной информации о любом криптовалютном токене
Анализ из нескольких источников: Исследование по множеству источников, включая CoinGecko, CoinMarketCap, DeFiLlama и другие
Структурированная отчетность: Создание подробных отчетов, охватывающих технические основы, рыночные данные, социальные настроения и многое другое
Управление ресурсами: Автоматическое сохранение результатов поиска и контента для справки
Отслеживание статуса: Отслеживание прогресса исследования по различным этапам и разделам
Node.js (v16 или выше)
Чтобы автоматически установить web3-research-mcp для Claude Desktop через Smithery:
npx -y @smithery/cli install web3-research-mcp --client claudeОтредактируйте файл конфигурации Claude Desktop
Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Добавьте это в ваш файл конфигурации Claude Desktop:
{
"mcpServers": {
"web3-research-mcp": {
"command": "npx",
"args": ["-y", "web3-research-mcp@latest"]
}
}
}Затем перезапустите Claude Desktop
Перейдите в: Settings -> Cursor Settings -> MCP -> Add new global MCP server Вставьте это в ваш файл Cursor ~/.cursor/mcp.json. Дополнительную информацию см. в документации Cursor MCP.
{
"mcpServers": {
"web3-research-mcp": {
"command": "npx",
"args": ["-y", "web3-research-mcp@latest"]
}
}
}Затем перезапустите Cursor
Создает структурированный план исследования для токена.
Параметры:
tokenName: Полное название токена
tokenTicker: Тикер токена
Выполняет веб-поиск и возвращает результаты.
Параметры:
query: Поисковый запрос
searchType: Тип поиска (web, news, images, videos)
Ищет токен по определенным ключевым словам и сохраняет результаты.
Параметры:
tokenName: Название токена
tokenTicker: Тикер токена
keywords: Массив ключевых слов для поиска
Обновляет статус раздела исследования.
Параметры:
section: Название раздела для обновления (например, 'projectInfo', 'technicalFundamentals')
status: Новый статус раздела (planned, in_progress, completed)
Получает контент по URL и сохраняет его как ресурс.
Параметры:
url: URL для получения контента
format: Формат вывода (text, html, markdown, json)
Выводит список всех сохраненных ресурсов.
Ищет информацию о токене из конкретного источника.
Параметры:
tokenName: Название токена
tokenTicker: Тикер токена
source: Источник для поиска (например, 'CoinGecko', 'DeFiLlama', 'News')
Получает рыночные данные в реальном времени напрямую из публичного API CoinGecko — цена, рыночная капитализация, изменения за 24ч/7д/30д, ATH/ATL, оборотное предложение, адреса контрактов в разных сетях, а также социальные/разработческие ссылки. Обходит ошибки 403 при HTML-парсинге.
Параметры:
tokenName: Полное название токена (например, 'Bitcoin')
tokenTicker: Тикер токена (например, 'BTC')
API-ключ не требуется. Используется бесплатный публичный уровень (~30 запросов/мин).
Опционально: установите COINGECKO_API_KEY в переменных окружения, чтобы использовать API-ключ CoinGecko Pro. Если он установлен, запросы отправляются на https://pro-api.coingecko.com/api/v3 с заголовком x-cg-pro-api-key. Время ожидания запроса — 15 секунд.
Ищет в индексе монет CoinGecko и возвращает подходящие варианты с их ID CoinGecko. Полезно, когда тикер неоднозначен (например, несколько токенов с одинаковым символом).
Параметры:
query: Поисковый запрос — название, тикер или адрес контракта
Получает данные протокола напрямую из публичного API DeFiLlama — общий TVL, распределение TVL по сетям, комиссии (24ч/7д/30д/за все время), адреса токенов, раунды финансирования и ссылки. Обходит HTML-парсинг для наиболее распространенных запросов DeFi-протоколов.
Параметры:
tokenName: Полное название протокола/токена (например, 'Uniswap')
tokenTicker: Тикер токена (например, 'UNI')
API-ключ не требуется. Используется бесплатный публичный API. Время ожидания запроса — 15 секунд. Индекс протоколов кэшируется на 5 минут для каждого процесса, чтобы избежать перегрузки /protocols при каждом вызове.
Ищет в индексе протоколов DeFiLlama и возвращает подходящие варианты с их слагами, TVL и категорией. Полезно, когда тикер неоднозначен (например, несколько протоколов с похожими названиями).
Параметры:
query: Поисковый запрос — название протокола, тикер или слаг
Инициирует комплексное исследование криптовалютного токена.
Параметры:
tokenName: Полное название криптовалютного токена
tokenTicker: Тикер токена (например, BTC, ETH)
Когда исследование начинается, создается структурированный план, охватывающий все аспекты токена
Сервер выполняет поиск информации по нескольким источникам
Результаты поиска сохраняются как ресурсы, на которые можно ссылаться
Исследование продвигается по различным разделам с отслеживанием статуса
Генерируется комплексный отчет, охватывающий все аспекты токена
Некоторые веб-сайты блокируют веб-скрейпинг, поэтому прямое получение контента может завершиться ошибкой 403
Зависит от результатов поиска, которые не всегда могут быть исчерпывающими
К операциям поиска могут применяться лимиты по количеству запросов
Этот проект лицензирован по лицензии Apache License 2.0 — подробности см. в файле LICENSE.
| 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.4coingecko-datacoingecko-searchcoingecko-tickersdefillama-datadefillama-searchv1.0.0list-resources1 field changedInput schema / additionalPropertiesRemoved value: -falsecreate-research-planfetch-contentlist-resourcesresearch-sourceresearch-tokenresearch-with-keywordssearchsearch-sourceupdate-statusScored across 14 tools
Multiple tools appear to serve overlapping purposes: 'search', 'search-source', 'coingecko-search', and 'defillama-search' are hard to distinguish by name alone. Similarly, 'research-source', 'research-token', and 'research-with-keywords' blur together without descriptions to clarify their exact roles.
Tool names mix kebab-case verbs like 'fetch-content' and 'create-research-plan' with noun-only names like 'coingecko-data' and 'defillama-search', plus a bare generic 'search'. There is no consistent verb_noun or domain-prefixed pattern across the set.
Fourteen tools is within a reasonable range for a research-oriented server, but several names appear to cover nearly identical actions, making the set feel padded. The count itself is not extreme, but the apparent duplication reduces the sense that each tool earns its place.
The set covers a plausible web3 research workflow: planning, searching, fetching content, researching tokens/sources, status updates, and pulling market data. However, there are notable gaps in explicit output/result management and no clear end-to-end lifecycle, making completeness mediocre.
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.
Agentic AI runtime: persistent memory, vault, autonomous agents, deep research, DeFi execution.
Signed BTC and macro market intelligence for autonomous research, risk, and trading agents.
