암호화폐를 위한 심층 리서치 - 무료 및 완전 로컬 🧠
Related MCP server: deeplook
포괄적인 리서치: 모든 암호화폐 토큰에 대한 상세 정보 수집
다중 소스 분석: CoinGecko, CoinMarketCap, DeFiLlama 등을 포함한 여러 소스에서 리서치 수행
구조화된 보고서: 기술적 펀더멘털, 시장 데이터, 소셜 센티먼트 등을 다루는 상세 보고서 생성
리소스 관리: 참조를 위해 검색 결과와 콘텐츠를 자동으로 저장
상태 추적: 다양한 단계와 섹션을 통해 리서치 진행 상황 추적
Node.js (v16 이상)
Smithery를 통해 Claude Desktop용 web3-research-mcp를 자동으로 설치하려면:
npx -y @smithery/cli install web3-research-mcp --client claudeClaude 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 설정(Cursor Settings) -> MCP -> 새로운 글로벌 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')
CoinGecko 공개 API에서 실시간 시장 데이터(가격, 시가총액, 24시간/7일/30일 변동률, ATH/ATL, 유통 공급량, 체인별 컨트랙트 주소, 소셜/개발 링크)를 직접 가져옵니다. HTML 스크래핑의 403 오류 문제를 우회합니다.
매개변수:
tokenName: 토큰의 전체 이름 (예: 'Bitcoin')
tokenTicker: 토큰 티커 심볼 (예: 'BTC')
API 키가 필요하지 않습니다. 무료 공개 티어(~30회 요청/분)를 사용합니다.
선택 사항: 환경 변수에 COINGECKO_API_KEY를 설정하여 CoinGecko Pro API 키를 사용할 수 있습니다. 설정 시, x-cg-pro-api-key 헤더와 함께 https://pro-api.coingecko.com/api/v3로 요청이 전송됩니다. 요청은 15초 후 타임아웃됩니다.
CoinGecko의 코인 인덱스를 검색하고 CoinGecko ID가 포함된 후보 일치 항목을 반환합니다. 티커가 모호할 때(예: 동일한 심볼을 가진 여러 토큰) 유용합니다.
매개변수:
query: 검색어 — 이름, 티커 또는 컨트랙트 주소
DeFiLlama 공개 API에서 프로토콜 데이터(총 TVL, 체인별 TVL 분석, 수수료(24시간/7일/30일/전체), 토큰 주소, 펀딩 라운드, 링크)를 직접 가져옵니다. 가장 일반적인 DeFi 프로토콜 조회 시 HTML 스크래핑을 우회합니다.
매개변수:
tokenName: 전체 프로토콜/토큰 이름 (예: 'Uniswap')
tokenTicker: 토큰 티커 심볼 (예: 'UNI')
API 키가 필요하지 않습니다. 무료 공개 API를 사용합니다. 요청은 15초 후 타임아웃됩니다. 프로토콜 인덱스는 모든 호출 시 /protocols를 과도하게 호출하지 않도록 프로세스당 5분 동안 캐시됩니다.
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.
