Skip to main content
Glama

Mantle block number

mantle_block
Read-only

Latest block number and block details on Mantle, or any block by decimal number: hash, timestamp, transaction count, gas used and limit, base fee in gwei and producer. Use for timestamps and confirmation counts; for current fees use mantle_gas. A block that does not exist yet returns 404, uncharged. Example: number=latest. Price $0.01/call via x402 USDC or a card key (/credits), first 25 free; failed calls free. Reads or computes only and changes nothing; each call is charged, so repeats are not free.

Input Schema

NameRequiredDescriptionDefault
numberNoBlock number, or 'latest' (default)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond annotations: 404/uncharged behavior for future blocks, $0.01/call pricing, first 25 free, failed calls free, and that repeats are not free (consistent with idempotentHint=false). This is exactly the billing and failure context annotations cannot express.

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?

Front-loads purpose and return fields, then usage, then billing. Dense but each clause carries information; the pricing sentence is long but relevant to call planning.

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?

No output schema exists, yet the description enumerates returned fields (hash, timestamp, tx count, gas used/limit, base fee, producer) and covers error and cost behavior, leaving nothing essential missing for a single-param 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?

Schema coverage is 100% and already documents 'number' with 'latest' default, but the description adds the decimal-number format expectation and a concrete example (number=latest), giving modest extra value.

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?

States a specific verb+resource ('Latest block number and block details on Mantle') and enumerates the returned fields, so an agent knows exactly what it gets and can distinguish it from mantle_gas and mantle_tx.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes usage: 'Use for timestamps and confirmation counts; for current fees use mantle_gas.' It names the alternative and the condition that selects it, plus shows the 'latest' example.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources