Supports real-time cryptocurrency conversion between Bitcoin and other digital or fiat currencies.
Allows retrieving native wallet balances, monitoring real-time gas prices, and performing cryptocurrency conversions on the Ethereum network.
Enables checking native token balances for wallet addresses on the Optimism network.
Enables checking native token balances for wallet addresses on the Polygon network.
Supports real-time cryptocurrency conversion involving Ripple (XRP).
Allows programmatically sending messages and automated notifications to Telegram chats or channels via a bot.
Supports real-time cryptocurrency conversion involving XRP.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Block MCP Server Check the balance of 0x71C36358C5748E5656130022d114491223A369CF across all chains"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for Blockchain interactions. This server enables AI agents to interact with multiple blockchain networks, check financial data, and send real-time notifications to Telegram.
💰 Wallet Balance Checker: Retrieves native token balances for any wallet address across Ethereum, Polygon, Arbitrum, Optimism, and Base simultaneously using public RPC nodes.
📜 Frax Transactions: Fetches the 5 latest transactions on the FRAX network, including both native transfers and ERC-20 token events.
⛽ Gas Price Estimator: Provides real-time gas fee estimates (in Gwei) across multiple blockchain networks to help determine transaction costs.
💱 Crypto Converter: Converts cryptocurrency and fiat values using real-time market rates (e.g., BTC to ETH or USDC to USD).
🤖 Telegram Bot: Programmatically posts updates, messages, or automated notifications to a specific Telegram chat or channel.
Related MCP server: Universal Crypto MCP
Python 3.11+
uv
Create a .env file in the root directory and populate it with your credentials:
# Telegram Configuration
TELEGRAM_BOT_TOKEN=your_bot_token_from_botfather
TELEGRAM_CHAT_ID=your_numeric_chat_id
# Blockchain API Keys
FRAXSCAN_API_KEY=your_fraxscan_api_key
# Optional: CoinGecko API Key
COINGECKO_API_KEY=your_api_keyClone the repository:
git clone <YOUR_REPO_URL_HERE>
cd <YOUR_REPO_NAME>Install dependencies:
This project uses uv for fast dependency management.
make installThe easiest way to test the tools is using the built-in Makefile command, which launches the MCP Inspector.
make devAlternatively: uv run fastmcp dev main.py
Below are example inputs for testing the tools in the MCP Inspector.
wallet_check)Queries multiple public RPC endpoints to retrieve native balances across various chains.
Input:
{ "address": "0x..." }Response:
{
"Ethereum": "1.2450 ETH",
"Arbitrum": "0.0000 ETH",
"Polygon": "150.3200 MATIC",
"Optimism": "0.0500 ETH",
"Base": "0.1200 ETH"
}get_frax_transactions)Merges native and token transfer history from the Fraxscan API, sorted by timestamp.
Input:
{ "address": "0x4200000000000000000000000000000000000015" }Response:
[
{
"time": "2026-01-30 18:00:00",
"amount": "0.5000 frxETH",
"token": "frxETH",
"type": "Native",
"hash": "0x..."
}
]get_gas_prices)Monitors real-time gas prices (in Gwei) to estimate transaction costs.
Input:
{}Response:
{
"Ethereum": "🔴 45.2 Gwei",
"Base": "🟢 0.01 Gwei"
}convert_crypto)Converts time between timezones.
Input:
{
"amount": 1,
"from_coin": "bitcoin",
"to_coin": "ripple"
}Response:
{
"Response": "1 BITCOIN = 1235999999.0 XRP (Rate: 95000)"
}send_telegram_message)This tool allows the AI to send notifications to your phone via Telegram.
User Trigger: You give Claude a condition or a direct command (e.g., "If ETH is below $2000, alert me").
Decision: Claude evaluates the condition. If true, it decides to call send_telegram_message.
Execution: The MCP server receives the text payload and makes an HTTP POST request to the Telegram Bot API.
Confirmation: The Telegram API confirms the delivery, and the MCP server reports back to Claude that the task is done.
Input:
{
"message": "The deployment was successful"
}Response:
"Message sent successfully!"This mode enables the AI to automatically check for new messages and respond to them in a continuous loop, while also performing other operations in between.
Prompt to Initiate:
"I want you to run in Auto-Pilot Mode. Here is your loop:
1. **Check:** Run `telegram_read_messages`.
2. **Act:** If there is a NEW message (one you haven't answered yet), interpret it and use `telegram_reply` to send the answer.
3. **Wait:** If there are no new messages, carry out any pending commands then run `wait_for_seconds(4)`.
4. **Repeat:** Go back to Step 1.
Do not ask me for permission between steps. Just keep running this loop indefinitely."How the Loop Works:
Check: The AI polls the Telegram API for incoming messages.
Process: It reads the content of any new user messages (e.g., a user asking "What is the price of BTC?").
Action: It uses other available tools (like convert_crypto) to find the answer.
Reply: It sends the answer back to the user via Telegram and waits for the next cycle.
Convert cryptocurrency using real-time rates (e.g., BTC to ETH, USDC to USD).
Args: amount: Volume to convert (e.g., 1.5) from_coin: Coin ID/Symbol (e.g., 'bitcoin', 'ethereum', 'usdc') to_coin: Target currency (e.g., 'usd', 'eur', 'eth')
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | ||
| from_coin | Yes | ||
| to_coin | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'real-time rates,' which hints at up-to-date data, but doesn't disclose critical behavioral traits such as rate limits, authentication needs, error handling, or whether the conversion is simulated or executes a trade. For a financial tool with zero annotation coverage, this leaves significant gaps in understanding its operation.
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?
The description is well-structured with a clear purpose statement followed by parameter details. It uses bullet-like formatting under 'Args:' for readability. While efficient, it could be slightly more concise by integrating the examples into the main text, but overall it's front-loaded and wastes no space.
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?
Given the tool's complexity (financial conversion with 3 parameters), no annotations, and an output schema present (which handles return values), the description is moderately complete. It covers the purpose and parameters adequately but lacks behavioral details like execution implications or error cases, making it sufficient but with clear room for improvement in transparency.
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?
Schema description coverage is 0%, so the description must compensate. It adds meaningful context by explaining each parameter with examples (e.g., 'amount: Volume to convert (e.g., 1.5)'), clarifying that from_coin and to_coin accept IDs/symbols like 'bitcoin' or 'usd'. This goes beyond the bare schema, though it could specify format constraints or valid values more explicitly.
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?
The description clearly states the specific action ('convert cryptocurrency using real-time rates') and the resource involved (cryptocurrency/currency pairs). It provides concrete examples (BTC to ETH, USDC to USD) that illustrate the tool's function, making it immediately understandable and distinct from sibling tools like wallet_check or get_transactions.
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?
The description implies usage through examples (e.g., 'BTC to ETH, USDC to USD'), suggesting this tool is for currency conversion, but it doesn't explicitly state when to use it versus alternatives like wallet_check or get_transactions. There's no guidance on prerequisites, limitations, or specific contexts where this tool is preferred over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the current gas fees (in Gwei) across multiple blockchains. Low (<10) is cheap. High (>50) is expensive.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds useful context about gas fee ranges ('Low (<10) is cheap. High (>50) is expensive.'), which helps interpret the output. However, it lacks details on data sources, update frequency, or error handling, leaving gaps in behavioral understanding.
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?
The description is highly concise and well-structured in two sentences. The first sentence states the purpose clearly, and the second adds valuable context about gas fee ranges without redundancy. Every sentence earns its place, making it efficient and front-loaded.
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?
Given the tool's simplicity (0 parameters, no annotations, but with an output schema), the description is reasonably complete. It explains what the tool does and provides context for interpreting results. However, it could be more comprehensive by mentioning data sources or update frequency, which would enhance completeness for a tool with no annotations.
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?
The tool has 0 parameters, and the schema description coverage is 100%, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the tool's purpose and output interpretation. This meets the baseline for tools with no parameters.
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?
The description clearly states the tool's purpose: 'Check the current gas fees (in Gwei) across multiple blockchains.' It specifies the verb ('check'), resource ('gas fees'), and unit of measurement ('Gwei'), but does not explicitly differentiate it from sibling tools like 'get_transactions' or 'wallet_check', which prevents a score of 5.
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?
The description provides no guidance on when to use this tool versus alternatives. It mentions context about gas fee ranges ('Low (<10) is cheap. High (>50) is expensive.'), but this is behavioral information rather than usage guidelines. There is no mention of when to use this tool over siblings like 'get_transactions' or 'wallet_check'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the 5 latest transactions for a specific address on the FRAX Network
Args: address: the wallet address to check
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the tool fetches exactly '5 latest' transactions (a behavioral constraint) and specifies the FRAX Network context. However, it lacks details on error handling, rate limits, authentication needs, or response format beyond what the output schema might cover.
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?
The description is front-loaded with the core purpose in the first sentence, followed by a concise Args section. Every sentence earns its place with no redundant or verbose language.
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?
Given the tool has an output schema (which handles return values), 1 parameter with low schema coverage, and no annotations, the description is reasonably complete. It covers purpose, parameter meaning, and a key behavioral constraint (5 latest). It could improve by mentioning error cases or network-specific nuances.
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?
The schema has 0% description coverage, but the description compensates by explaining the 'address' parameter as 'the wallet address to check'. This adds meaningful context beyond the bare schema type. However, it doesn't specify address format (e.g., hexadecimal, case sensitivity) or validation rules.
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?
The description clearly states the specific action ('Fetch'), resource ('transactions'), scope ('5 latest'), and network context ('FRAX Network'). It distinguishes from siblings like wallet_check (which might check balance/status) and send_telegram_message (unrelated messaging).
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?
The description implies usage when needing recent transaction history for a specific address, but provides no explicit guidance on when to use this versus alternatives like wallet_check (which might provide different wallet data) or when not to use it (e.g., for older transactions beyond the latest 5).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a status message that the server is live
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns a status message, implying a read-only, non-destructive operation, but doesn't add context like error handling, response format details, or performance characteristics. This is adequate but minimal for a simple tool.
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?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded and appropriately sized for a simple tool, with zero waste.
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?
Given the tool's low complexity (0 parameters, no annotations, but has an output schema), the description is reasonably complete. It explains what the tool does, and the output schema will handle return values, though it could benefit from slight elaboration on usage context or response expectations.
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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate, but it could briefly note the lack of inputs. Baseline is 4 for zero parameters, as the schema fully covers the absence.
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?
The description clearly states the tool's purpose with a specific verb ('Returns') and resource ('status message'), explaining it checks if the server is live. However, it doesn't explicitly differentiate from siblings like 'wallet_check', which might also involve status verification but for a different resource.
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?
The description provides no guidance on when to use this tool versus alternatives, such as for initial connectivity testing or as a prerequisite for other operations. It lacks explicit when/when-not instructions or named alternatives, leaving usage context implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a notification to the configured Telegram Chat.
Args: message: The text to send to your phone.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Send a notification' implies a write operation, it doesn't disclose important behavioral traits like whether this requires specific permissions, rate limits, delivery guarantees, error conditions, or what happens if the chat isn't properly configured. The mention of 'configured Telegram Chat' hints at prerequisites but doesn't elaborate.
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?
The description is appropriately concise with two sentences that directly address the tool's purpose and its single parameter. The Args section is clearly separated, making it easy to parse. There's minimal wasted verbiage, though the structure could be slightly improved by integrating the parameter explanation more seamlessly.
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?
Given this is a write operation with no annotations, 1 parameter, and an output schema exists (which means return values are documented elsewhere), the description is moderately complete. It covers the basic purpose and parameter meaning but lacks important context about behavioral characteristics, error handling, and differentiation from sibling tools that would make it fully complete for agent use.
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?
Schema description coverage is 0%, so the description must compensate. It provides the parameter name 'message' and explains it as 'The text to send to your phone,' which adds meaningful context beyond the bare schema. However, it doesn't cover constraints like message length limits, formatting options, or special characters that might be relevant for Telegram messages.
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?
The description clearly states the action ('Send a notification') and target ('to the configured Telegram Chat'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'telegram_reply' or 'telegram_read_messages', which prevents a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives like 'telegram_reply' or other notification methods. It mentions 'configured Telegram Chat' which implies some setup but doesn't specify when this tool is appropriate versus other communication methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads the last few messages sent to the bot by the user. Useful for checking if the user has replied or asked a question.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions reading 'last few messages' but lacks details on permissions, rate limits, error handling, or what 'last few' means operationally (e.g., time-based or count-based). This leaves significant gaps for a tool that interacts with user data.
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?
The description is highly concise with two sentences that directly address purpose and usage, with no wasted words. It's front-loaded and efficiently structured, making it easy to parse quickly.
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?
Given the tool's moderate complexity (reading user messages), no annotations, and an output schema (which reduces need to describe returns), the description is minimally adequate. It covers basic purpose and usage but lacks details on behavior and parameters, making it incomplete for fully informed use.
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?
The input schema has 1 parameter with 0% description coverage, and the tool description doesn't mention the 'limit' parameter at all. This fails to compensate for the schema gap, leaving the parameter's meaning and usage unclear beyond its default value of 5.
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?
The description clearly states the tool's purpose with a specific verb ('Reads') and resource ('last few messages sent to the bot by the user'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'telegram_reply' or 'send_telegram_message', which handle message sending rather than reading.
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?
The description provides clear context on when to use this tool ('Useful for checking if the user has replied or asked a question'), which helps guide its application. It doesn't specify when not to use it or name alternatives, but the context is sufficient for basic usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sends a reply to a specific user/chat ID. Args: chat_id: The ID of the user to reply to. text: The message to send back.
| Name | Required | Description | Default |
|---|---|---|---|
| chat_id | Yes | ||
| text | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions sending a reply but doesn't cover important aspects like authentication requirements, rate limits, error conditions, or what constitutes a 'reply' versus a regular message. This leaves significant behavioral gaps for a mutation tool.
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?
The description is efficiently structured with a clear purpose statement followed by parameter explanations. Both sentences earn their place by providing essential information. The formatting with 'Args:' section is helpful, though slightly more polished structure could achieve perfection.
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?
For a 2-parameter mutation tool with no annotations but with an output schema, the description provides basic purpose and parameter semantics. However, it lacks important context about behavioral traits, usage guidelines, and how it differs from similar tools, making it only minimally adequate.
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?
The description provides clear semantic meaning for both parameters ('chat_id: The ID of the user to reply to' and 'text: The message to send back'), which is valuable given the 0% schema description coverage. While it doesn't explain format details like chat_id being an integer, it successfully conveys the purpose of each parameter.
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?
The description clearly states the action ('sends a reply') and target ('to a specific user/chat ID'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'send_telegram_message', which appears to serve a similar function, preventing a perfect score.
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?
No guidance is provided on when to use this tool versus alternatives like 'send_telegram_message'. The description only states what it does, not when it's appropriate or how it differs from similar tools, leaving the agent without contextual usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pauses execution for a set number of seconds. REQUIRED for running automated loops to reply messages.
| Name | Required | Description | Default |
|---|---|---|---|
| seconds | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states the tool pauses execution, which implies it's a blocking operation, but doesn't disclose important behavioral traits like whether it's synchronous, if it respects system limits, what happens during the pause, or error conditions. The description adds minimal behavioral context beyond the basic function.
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?
The description is appropriately concise with two sentences. The first sentence states the core function, and the second provides usage context. There's no wasted text, though the second sentence could be more clearly integrated.
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?
Given the tool has an output schema (which handles return values), no annotations, and simple parameters, the description is moderately complete. It covers the basic purpose and some usage context but lacks important behavioral details for a timing/blocking operation. For a tool that controls execution flow, more transparency would be beneficial.
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?
The schema has 0% description coverage for its single parameter 'seconds'. The description adds some semantic context by specifying it's 'a set number of seconds' and implies it's for timing in automated loops. However, it doesn't provide format details, constraints, or examples. With low schema coverage, the description partially compensates but not fully.
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?
The description clearly states the tool's purpose: 'Pauses execution for a set number of seconds.' This is a specific verb+resource combination that tells what the tool does. However, it doesn't distinguish from siblings since none are timing-related tools.
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?
The description provides some usage context: 'REQUIRED for running automated loops to reply messages.' This implies when to use it (for automated loops in message workflows) but doesn't explicitly state when not to use it or mention alternatives. The guidance is helpful but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the native token balance of a wallet across multiple blockchains. Args: address: The wallet address (must start with 0x)
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool checks balances 'across multiple blockchains,' which implies it might aggregate data from different sources, but doesn't detail how this works (e.g., rate limits, error handling, or what 'native token' means specifically). For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior and constraints.
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?
The description is appropriately sized and front-loaded, with the core purpose stated first and parameter details following in a clear 'Args:' section. There's no wasted text, though the structure could be slightly more integrated (e.g., merging the address note into the main sentence).
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?
Given the tool has an output schema (which likely defines return values), the description doesn't need to explain outputs. However, with no annotations and low schema coverage, it should do more to cover behavioral aspects like error cases or blockchain specifics. The description is adequate for a simple query tool but lacks depth for full contextual understanding.
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?
The description adds meaningful context for the single parameter 'address' by specifying it 'must start with 0x,' which clarifies format requirements not evident from the schema (which has 0% description coverage). This compensates well for the low schema coverage, though it doesn't explain potential variations or validation details beyond the prefix.
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?
The description clearly states the tool's purpose: checking native token balances across multiple blockchains. It specifies the verb ('check') and resource ('native token balance of a wallet'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'get_transactions' which might also involve wallet data, so it doesn't reach the highest score.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_transactions' (which might provide transaction history) or 'convert_crypto' (which might involve balances), nor does it specify prerequisites or exclusions. The only usage hint is the address format requirement, which is minimal guidance.
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. Dates show when Glama detected each change.
v0.1.0convert_cryptoget_gas_pricesget_transactionshealth_checksend_telegram_messagetelegram_read_messagestelegram_replywait_for_secondswallet_checkThe tool set has unclear boundaries and overlapping purposes, particularly in the Telegram-related tools. 'send_telegram_message', 'telegram_read_messages', and 'telegram_reply' all handle Telegram messaging but with ambiguous distinctions—'send_telegram_message' and 'telegram_reply' seem to serve similar functions, and 'telegram_read_messages' overlaps with monitoring interactions. Additionally, 'get_transactions' and 'wallet_check' both involve address queries but target different data (transactions vs. balances), which could cause confusion. The descriptions help somewhat, but the overlap is significant.
The naming conventions are mixed, with some tools using verb_noun patterns like 'convert_crypto' and 'get_gas_prices', while others use noun_verb like 'health_check' or inconsistent structures like 'telegram_read_messages' (noun_verb_noun) and 'wait_for_seconds' (verb_preposition_noun). This lack of a consistent pattern makes the set less predictable, though the names remain readable overall. The deviations are notable but not chaotic.
With 9 tools, the count is reasonable and well-scoped for a server covering cryptocurrency conversion, blockchain data, and Telegram integration. It's not excessive, and each tool appears to serve a distinct functional area, though some overlap exists. The number aligns well with the apparent scope, being neither too thin nor too heavy, making it appropriate for the server's purpose.
The server shows notable gaps in coverage for its implied domain of blockchain and messaging operations. For cryptocurrency conversion, tools like 'convert_crypto' and 'get_gas_prices' are present, but there's no tool for executing trades or managing wallets beyond checking balances. In Telegram functionality, basic send/reply/read tools exist, but there's no tool for configuring or managing chats. The surface covers core actions but lacks full lifecycle or advanced operations, which agents might need to work around.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Live crypto prices, conversion, gas tracker, portfolio tools, and calculators for AI agents.
AI agent tools: translation (95+ langs), crypto research, compliance, summarization.
Provide AI agents and automation tools with contextual access to blockchain data including balance…
Crypto yield data for AI agents: lending, savings, staking, borrowing & stablecoin rates. 18 tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/CollinDex/block-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
