Block MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation2/5
The 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.
Naming Consistency3/5
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.
Tool Count4/5
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.
Completeness3/5
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.
Average 3.4/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![block-mcp MCP server](https://glama.ai/mcp/servers/CollinDex/block-mcp/badges/card.svg)](https://glama.ai/mcp/servers/CollinDex/block-mcp)

Score Badge

Copy to your README.md:

[![block-mcp MCP server](https://glama.ai/mcp/servers/CollinDex/block-mcp/badges/score.svg)](https://glama.ai/mcp/servers/CollinDex/block-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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