A
licenseA
qualityC
maintenanceDecodes Ethereum calldata and returns a safety verdict with plain-English explanations of what the transaction does, flagging dangerous actions like unlimited approvals or gasless permits.
2
MIT
Base Transaction Explainer
Server Details
Plain-English decode of any Base mainnet transaction: strict JSON, risk flags, no LLM.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- 0200project/base-tx-explain
- GitHub Stars
- 0
- Server Listing
- base-tx-explain
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
100% free. Your data is private.
Tool Definition Quality
A4.4/5.0
Tool DescriptionsA
Average 4.6/5 across 2 of 2 tools scored.
Server CoherenceA
Disambiguation5/5
The two tools serve completely distinct purposes: one is a purchase/payment mechanism for obtaining access, while the other is the core transaction explanation functionality. There is no overlap or ambiguity between them.
Naming Consistency5/5
Both tools use a clear verb_noun pattern: buy_pass (buy + pass) and explain_transaction (explain + transaction). The naming is consistent and predictable, reflecting their distinct actions.
Tool Count3/5
The server has only 2 tools, which is very few but appropriate for a focused transactional service. The count feels minimal, but both tools are essential: one for access/payment and one for the core functionality. It edges toward the lower boundary of acceptable scope.
Completeness3/5
The core transaction explanation is covered well with detailed output, but there are gaps: the server only supports Base mainnet and a single transaction hash input. Missing features could include batch explanations, support for multiple networks, or a way to check pass status/expiry without purchasing. For a minimal service, the surface is nearly complete, but there are notable limitations.
Available Tools
2 toolsbuy_passBuy a 30-day passAInspect
Buy a 30-day pass for $9 in USDC on Base via x402: up to 10,000 explain_transaction calls with no per-call payment. Returns a bearer pass token; attach it at _meta["btx/pass"] on MCP calls or as the X-BTX-Pass header on POST /explain. No account; the token is the only proof of purchase. Renew by buying a new pass after expiry.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses: the cost, payment method (USDC on Base), the limit (10,000 calls), the return token, how to attach it, the lack of an account requirement, and renewal. This is exceptionally transparent for a tool with no annotations.
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 a single dense sentence broken by semicolons, but every piece of information is useful and directly supports usage. It could be slightly more structured, but it's not verbose and is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and no annotations, the description covers everything needed: what it does, the cost, the token usage, and renewal. It's complete for a simple purchase tool.
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 zero parameters, so the schema provides no semantics. The description adds meaningful context about what the pass does, which compensates for the empty schema. Baseline of 4 is appropriate.
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 tool buys a 30-day pass for $9 in USDC on Base, with the specific benefit of up to 10,000 explain_transaction calls without per-call payment. It distinguishes itself from the sibling explain_transaction by focusing on the purchase action and the pass's usage.
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 explains when to use it (to access calls without per-call fees) and provides explicit instructions for attaching the token via _meta or header. It doesn't explicitly say when not to use it, but implies that it's for heavy usage, and mentions renewal after expiry, covering the lifecycle.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explain_transactionExplain Base transactionAInspect
Explain a Base-mainnet transaction in plain English. Input: a transaction hash. Returns strict JSON: summary (1-3 sentences), action_type (swap, erc20_transfer, nft_mint, bridge_out, approval_for_all, ...), assets_moved[] (token, amount, from, to), counterparties[] (labeled where known: routers, bridges, marketplaces), risk_flags[] (unverified_contract, unlimited_approval, approval_for_all, known_drainer, first_time_counterparty, nonstandard_token_symbol, impersonated_token, transaction_reverted), checks, gas_paid_usd, timestamp, basescan_url. Risk checks fail open, so read checks before drawing any conclusion from an empty risk_flags: it reports whether each check ran (ok / partial / unavailable / inconclusive / not_applicable), and no flags alongside a non-ok status means not checked, not clean. Deterministic onchain decode - no LLM in the response path. Base mainnet (chain id 8453) only.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tx_hash | Yes | The Base mainnet transaction hash to explain (0x + 64 hex characters). |
Tool Definition Quality
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden and excels: it discloses deterministic onchain decoding with no LLM, explains that risk checks fail open and that an empty risk_flags with non-ok checks means 'not checked, not clean', and details the exact response format. This prevents serious misinterpretation.
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 and then presents the input, output shape, and critical caveats in a logical order. Although lengthy, every sentence carries necessary information, especially given the lack of an output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, but the description compensates fully by enumerating the strict JSON fields, explaining the fail-open risk-check semantics, specifying the network, and confirming deterministic behavior. This is more than sufficient for an agent to correctly invoke and interpret the tool.
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 100%, and the schema already documents tx_hash as a Base mainnet transaction hash with the 0x + 64 hex format. The description adds only 'Input: a transaction hash', which does not materially extend the schema, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Explain a Base-mainnet transaction in plain English' and immediately distinguishes the tool's scope from buy_pass by emphasizing Base mainnet and transaction-level decoding. It clearly specifies the input (transaction hash) and the purpose, making the tool's role unambiguous.
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: use this for Base-mainnet transaction hashes and receive a structured plain-English explanation. It also sets an explicit constraint ('Base mainnet (chain id 8453) only'), but it does not name alternatives or state when not to use this tool relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
- AlicenseAqualityCmaintenanceDecodes raw EVM bytes into human-readable JSON via tools for logs, calldata, selectors, and ABIs across multiple chains. Read-only, keyless, and stateless, with optional x402 payment settlement.4MIT
- AlicenseNot gradedqualityDmaintenanceEnables querying Base Network blockchain data including blocks, transactions, balances, and smart contracts on mainnet and testnet.4MIT
- AlicenseNot gradedqualityDmaintenanceEnables querying Base Network blockchain data including blocks, transactions, balances, and smart contracts on mainnet and testnet.MIT
Try in Browser
Your Connectors
Sign in to create a connector for this server.