Deep Research für Krypto - kostenlos & vollständig lokal 🧠
Related MCP server: deeplook
Umfassende Recherche: Sammeln Sie detaillierte Informationen zu jedem Kryptowährungs-Token
Multi-Quellen-Analyse: Recherche über mehrere Quellen hinweg, einschließlich CoinGecko, CoinMarketCap, DeFiLlama und mehr
Strukturierte Berichterstattung: Erstellen Sie detaillierte Berichte zu technischen Grundlagen, Marktdaten, sozialer Stimmung und mehr
Ressourcenverwaltung: Speichert Suchergebnisse und Inhalte automatisch als Referenz
Statusverfolgung: Verfolgen Sie den Forschungsfortschritt durch verschiedene Phasen und Abschnitte
Node.js (v16 oder höher)
Um web3-research-mcp automatisch für Claude Desktop über Smithery zu installieren:
npx -y @smithery/cli install web3-research-mcp --client claudeBearbeiten Sie Ihre Claude Desktop-Konfigurationsdatei
Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Fügen Sie dies Ihrer Claude Desktop-Konfigurationsdatei hinzu:
{
"mcpServers": {
"web3-research-mcp": {
"command": "npx",
"args": ["-y", "web3-research-mcp@latest"]
}
}
}Starten Sie anschließend Claude Desktop neu
Gehen Sie zu: Settings -> Cursor Settings -> MCP -> Add new global MCP server Fügen Sie dies in Ihre Cursor ~/.cursor/mcp.json Datei ein. Weitere Informationen finden Sie in der Cursor MCP-Dokumentation.
{
"mcpServers": {
"web3-research-mcp": {
"command": "npx",
"args": ["-y", "web3-research-mcp@latest"]
}
}
}Starten Sie anschließend Cursor neu
Erstellt einen strukturierten Forschungsplan für einen Token.
Parameter:
tokenName: Vollständiger Name des Tokens
tokenTicker: Ticker-Symbol des Tokens
Führt eine Websuche durch und gibt die Ergebnisse zurück.
Parameter:
query: Suchanfrage
searchType: Art der Suche (web, news, images, videos)
Sucht nach einem Token mit spezifischen Schlüsselwörtern und speichert die Ergebnisse.
Parameter:
tokenName: Name des Tokens
tokenTicker: Ticker-Symbol
keywords: Array von Suchbegriffen
Aktualisiert den Status eines Forschungsabschnitts.
Parameter:
section: Name des zu aktualisierenden Abschnitts (z. B. 'projectInfo', 'technicalFundamentals')
status: Neuer Status für den Abschnitt (planned, in_progress, completed)
Ruft Inhalte von einer URL ab und speichert sie als Ressource.
Parameter:
url: URL, von der Inhalte abgerufen werden sollen
format: Ausgabeformat (text, html, markdown, json)
Listet alle verfügbaren gespeicherten Ressourcen auf.
Sucht nach Informationen über einen Token aus einer bestimmten Quelle.
Parameter:
tokenName: Name des Tokens
tokenTicker: Ticker-Symbol
source: Zu durchsuchende Quelle (z. B. 'CoinGecko', 'DeFiLlama', 'News')
Ruft Live-Marktdaten direkt von der öffentlichen CoinGecko-API ab – Preis, Marktkapitalisierung, 24h/7d/30d-Änderungen, ATH/ATL, zirkulierendes Angebot, Vertragsadressen über verschiedene Chains hinweg sowie soziale/Entwickler-Links. Umgeht die 403-Probleme des HTML-Scrapings.
Parameter:
tokenName: Vollständiger Name des Tokens (z. B. 'Bitcoin')
tokenTicker: Ticker-Symbol (z. B. 'BTC')
Kein API-Schlüssel erforderlich. Nutzt die kostenlose öffentliche Stufe (~30 Anfragen/Min.).
Optional: Setzen Sie COINGECKO_API_KEY in der Umgebung, um einen CoinGecko Pro API-Schlüssel zu verwenden. Wenn dieser gesetzt ist, werden Anfragen an https://pro-api.coingecko.com/api/v3 mit dem x-cg-pro-api-key-Header gesendet. Anfragen haben ein Zeitlimit von 15 Sekunden.
Durchsucht den Coin-Index von CoinGecko und gibt Treffer mit ihren CoinGecko-IDs zurück. Nützlich, wenn der Ticker mehrdeutig ist (z. B. mehrere Token mit demselben Symbol).
Parameter:
query: Suchanfrage – Name, Ticker oder Vertragsadresse
Ruft Protokolldaten direkt von der öffentlichen DeFiLlama-API ab – gesamte TVL, TVL-Aufschlüsselung pro Chain, Gebühren (24h/7d/30d/all-time), Token-Adressen, Finanzierungsrunden und Links. Umgeht HTML-Scraping für die gängigsten DeFi-Protokoll-Abfragen.
Parameter:
tokenName: Vollständiger Protokoll-/Token-Name (z. B. 'Uniswap')
tokenTicker: Ticker-Symbol (z. B. 'UNI')
Kein API-Schlüssel erforderlich. Nutzt die kostenlose öffentliche API. Anfragen haben ein Zeitlimit von 15 Sekunden. Der Protokoll-Index wird pro Prozess für 5 Minuten zwischengespeichert, um ein Überlasten von /protocols bei jedem Aufruf zu vermeiden.
Durchsucht den Protokoll-Index von DeFiLlama und gibt Treffer mit ihren Slugs, TVL und Kategorien zurück. Nützlich, wenn der Ticker mehrdeutig ist (z. B. mehrere Protokolle mit ähnlichen Namen).
Parameter:
query: Suchanfrage – Protokollname, Ticker oder Slug
Initiiert eine umfassende Recherche zu einem Kryptowährungs-Token.
Parameter:
tokenName: Vollständiger Name des Kryptowährungs-Tokens
tokenTicker: Ticker-Symbol des Tokens (z. B. BTC, ETH)
Wenn die Recherche beginnt, wird ein strukturierter Plan erstellt, der alle Aspekte des Tokens abdeckt
Der Server führt Suchen über mehrere Quellen hinweg durch, um Informationen zu erhalten
Suchergebnisse werden als Ressourcen gespeichert, auf die verwiesen werden kann
Die Recherche schreitet durch verschiedene Abschnitte voran, wobei der Status verfolgt wird
Ein umfassender Bericht wird erstellt, der alle Aspekte des Tokens abdeckt
Einige Websites blockieren Web-Scraping, daher kann das direkte Abrufen von Inhalten mit 403-Fehlern fehlschlagen
Basiert auf Suchergebnissen, die möglicherweise nicht immer vollständig sind
Für Suchvorgänge können Ratenbegrenzungen gelten
Dieses Projekt ist unter der Apache License 2.0 lizenziert – siehe die LICENSE-Datei für Details.
| 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.
