Thru blockchain explorer: blocks, transactions, accounts, and program ABIs on the Thru RISC-V L1
Get account details by address, including balance, owner, and metadata
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Account address |
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 does communicate that the tool returns balance, owner, and metadata, and 'Get' implies a read-only operation. However, it does not address error behavior, address format expectations, or whether the operation is guaranteed to be side-effect free.
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, well-structured sentence with no filler. The core purpose is front-loaded ('Get account details by address') and the output fields are appended compactly.
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 simple one-parameter getter, the description plus input schema provides enough to select and invoke the tool. It names the main return fields, though without an output schema, an agent must infer the exact shape and units of balance, owner, and metadata.
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 already documents the single parameter 'address' as 'Account address' with 100% coverage, so the description is not required to explain its meaning. The description adds minimal extra semantic value beyond confirming the address is used to identify the account.
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 verb (Get), the resource (account details), the lookup mechanism (by address), and the key returned fields (balance, owner, metadata). This distinguishes it from the sibling tools, which target blocks, transactions, ABIs, and listings.
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 given about when to choose this tool over alternatives, nor are any exclusions or related tools mentioned. The agent must infer that get_account is appropriate whenever account details are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get block details by slot number, including producer, timestamp, and transactions
| Name | Required | Description | Default |
|---|---|---|---|
| slot | Yes | Block slot number |
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 discloses the return contents (producer, timestamp, transactions) but does not mention behavior for missing slots, whether transactions are full objects or hashes, or any potential size/performance considerations. It is adequate but not richly transparent.
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?
A single, well-structured sentence that front-loads the action and resource, then lists the key included fields. No unnecessary words or repetition.
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 simple single-parameter get-by-slot tool, the description is reasonably complete. It names the input and the main output fields, and no output schema exists to fill in return-value details. Minor gaps remain around error behavior and transaction representation, but the core usage is covered.
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 100% because the slot parameter already has a description ('Block slot number'). The tool description adds 'by slot number' but no further semantic detail beyond what the schema provides, so the baseline of 3 is appropriate.
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 gets block details by slot number and enumerates key fields (producer, timestamp, transactions). This distinguishes it from sibling tools like get_transaction (transaction-level) and list_recent_blocks (which enumerates blocks rather than fetching a specific one).
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 phrase 'by slot number' gives a clear condition for when to use this tool: when a specific slot is already known. It does not explicitly name alternatives or exclusions, but the usage context is unambiguous enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the on-chain ABI for a program, including instruction and event definitions
| Name | Required | Description | Default |
|---|---|---|---|
| program | Yes | Program address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. 'Get' implies a read-only operation, and the description usefully reveals what the result contains (instruction and event definitions). However, it does not discuss output format, potential errors, or whether the ABI is fetched live from chain.
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?
A single, front-loaded sentence conveys the tool's purpose and the key content of its return value. There is no redundant wording or filler.
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?
The tool is simple: one required parameter that is fully documented, and no output schema. The description compensates by explaining what the result includes. This is sufficient for an agent to select and invoke the tool correctly.
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 100%: the only parameter, 'program', is already described as 'Program address'. The description adds no additional parameter-level detail, but none is needed given the schema's completeness.
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 uses a specific verb ('Get') and a specific resource ('on-chain ABI for a program'), and further clarifies scope by naming the included content ('instruction and event definitions'). This makes it clearly distinguishable from sibling tools like get_account, get_block, and get_transaction.
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 makes it clear when the tool should be used: whenever an agent needs the ABI for a specific program. It does not explicitly list exclusions or alternatives, but the sibling tools operate on different resources, so there is little ambiguity about usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get transaction details by signature, including status, accounts, instructions, and events
| Name | Required | Description | Default |
|---|---|---|---|
| signature | Yes | Transaction signature |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining behavior. It does disclose the kind of data returned, but does not mention edge cases such as invalid signatures, unconfirmed transactions, or error behavior, leaving some gaps for an agent to infer.
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, focused sentence that front-loads the core action and key output. Every part earns its place with no redundant wording.
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 single-parameter tool with no output schema, the description provides a useful outline of the returned content. It could be more explicit about possible failure conditions or response shape edge cases, but it gives enough context for an agent to invoke the tool correctly in normal usage.
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 already fully describes the only parameter, 'signature', and the description does not add substantial extra detail beyond confirming the parameter's role. Since schema coverage is 100%, a baseline score of 3 is appropriate.
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 fetches transaction details using a signature and names the key components returned (status, accounts, instructions, events). This distinguishes it from related tools like get_account or list_recent_transactions without ambiguity.
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 the tool should be used when you have a specific transaction signature and need detailed information about that transaction. However, it does not explicitly contrast itself with sibling list tools or mention when alternative tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List transactions for an account with pagination
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Account address | |
| pageSize | No | Number of transactions per page (1-100, default 10) | |
| pageToken | No | Pagination token for next page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It communicates read-only intent and paginated behavior, but it omits details like ordering, response shape, empty-result behavior, and invalid-address handling.
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 short, front-loaded with the verb and resource, and contains no filler. Every word earns its place, and the pagination qualifier adds practical value without bloating the text.
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?
The tool is simple and the schema thoroughly documents parameters, but with no annotations and no output schema, the description leaves operational context such as page contents, next-token behavior, and sorting to inference. It is sufficient for a basic call but not fully complete.
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 100%, so the input schema already documents all three parameters. The description adds no parameter-level meaning beyond the word 'pagination', so the baseline score of 3 is appropriate.
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 identifies the exact operation ('List transactions') and the resource scope ('for an account'), and the pagination qualifier distinguishes it from single-transaction retrieval and global recent-transaction lists. An agent can tell this apart from sibling tools like get_transaction and list_recent_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 conveys the core use case: listing account-scoped transactions with pagination. However, it does not explicitly state when to use this tool versus list_recent_transactions or search, nor does it mention exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the most recent blocks on the chain
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of blocks to return (1-50, default 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries full responsibility for behavioral disclosure. 'List' strongly implies a read-only retrieval operation with no side effects, and 'most recent' implies ordering by recency. However, it does not state whether results are returned newest-first, what fields each block includes, or any other behavioral caveats.
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 clear, front-loaded sentence with no filler or repetition. It communicates everything it attempts to communicate in the minimum possible 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?
This is a simple, single-parameter list operation with a clear name and description. While it omits return-format details, the phrase 'list the most recent blocks' reasonably implies the output is the requested block list, and the schema fully covers the only input. The absence of annotations is a minor gap for such a straightforward read operation.
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 fully documents the only parameter, `limit`, including its range and default value. The description adds no additional semantic detail beyond the schema, so the baseline score of 3 applies.
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 states a specific verb ('List') and a clear resource ('the most recent blocks'), making the tool's basic purpose immediately understandable. It distinguishes itself from siblings like get_block (single block vs. list) and list_recent_transactions (blocks vs. transactions), though it does not explicitly name any alternative.
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?
Usage context is implied: an agent would use this when it needs recent blocks. However, there is no explicit guidance about when to prefer this over get_block or list_recent_transactions, nor any mention of exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the most recent transactions across recent blocks
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of transactions to return (1-50, default 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden of behavioral disclosure. It only states the listing scope and does not mention ordering guarantees, block-window semantics, pagination, or whether results are final once blocks settle. Minimal operational transparency.
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 front-loaded sentence with no wasted words. It conveys the verb, resource, and scope efficiently.
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 simple read-only list call with one optional parameter, the description is functional, but no output schema or annotations exist and 'recent' is not precisely defined. An agent can call the tool, but would benefit from more context about response shape and recency semantics.
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 100% for the single limit parameter, including its range and default. The description adds no parameter details, but the schema already documents them adequately, so the baseline of 3 applies.
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 uses a specific verb ('List') and resource ('most recent transactions across recent blocks'), clearly distinguishing it from siblings like get_transaction (single transaction) and list_account_transactions (account-specific). The scope is immediately understandable.
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 when-to-use guidance is provided. The description does not contrast this tool with siblings such as search, list_recent_blocks, or list_account_transactions, so the agent must infer appropriate usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for blocks, transactions, or accounts by query (block number, tx signature, or address)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It only says 'search' and gives query examples; it does not disclose whether the operation is read-only, what the result shape or limit is, whether matches are exact or partial, or what happens on no results.
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, well-structured sentence that front-loads the verb and resource and immediately provides concrete query examples. There is no filler or redundant repetition.
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 one-parameter search tool, the description is adequate for selection and basic invocation, but with no output schema and no annotations, it leaves important context unspecified, such as the return format, possible mixed result types, and pagination or result limits.
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 only describes query as 'Search query', but the tool description adds meaningful semantics by listing acceptable query forms: block number, transaction signature, or address. This helps the agent construct valid queries.
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 a search action over three specific resource types (blocks, transactions, accounts) and gives concrete query examples. It is not a tautology, but it does not explicitly distinguish itself from the sibling get_account/get_block/get_transaction 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 implies when to use the tool: when you have a block number, transaction signature, or address to search by. However, it does not provide explicit alternatives or exclusions, such as 'use get_block when you already have the exact block number.'
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.
get_accountget_blockget_program_abiget_transactionlist_account_transactionslist_recent_blockslist_recent_transactionssearchClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Explore blockchain data across addresses, tokens, blocks, and transactions. Investigate any transa…
Blockchain data across 100+ chains: token prices, NFTs, transfers, simulation, traces, Solana DAS
Blockscout MCP — multi-chain block-explorer aggregate
Solscan MCP — Solana block-explorer API (Pro v2)
Add one secure layer between your agents and this server.
Each tool targets a distinct resource or query type: account, block, transaction, program ABI, account history, recent blocks, recent transactions, and cross-entity search. The generic search tool overlaps somewhat with individual getters, but its role as a unified lookup query is clear.
Tool names consistently follow a verb_noun pattern using get_, list_, or search_. This creates a predictable structure where the verb indicates retrieval mode and the noun indicates the target entity.
Eight tools is well-scoped for a read-only blockchain explorer. The set covers core entities without unnecessary redundancy, and each tool earns its place.
The toolset covers the main explorer workflows: fetching accounts, blocks, transactions, ABIs, and paginated history. Minor gaps such as token-specific balance lookups or direct program-account enumeration exist, but they are not critical for general chain exploration.
