Skip to main content
Glama

Base gas price

get_base_gas
Read-onlyIdempotent

Base gas price (chain 8453) in BOTH gwei and wei, with base fee, priority fee and block number when the node supplies them. Both units are returned because a caller asking in wei and a caller asking in gwei are asking the same question. Served from keyless public RPC with three-node fallback, so there is no API key to rotate or expire. Costs 0.005 USDC per call (x402, USDC on Solana, Base, Polygon, Arbitrum or Arc).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYesthe get_base_gas payload; a real captured example is free at https://x402.ochinimus.app/api/sample/get_base_gas
toolYesthe tool that produced this payload

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": false,
      +  "properties": {
      +    "data": {
      +      "additionalProperties": {},
      +      "description": "the get_base_gas payload; a real captured example is free at https://x402.ochinimus.app/api/sample/get_base_gas",
      +      "propertyNames": {
      +        "type": "string"
      +      },
      +      "type": "object"
      +    },
      +    "tool": {
      +      "const": "get_base_gas",
      +      "description": "the tool that produced this payload",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "tool",
      +    "data"
      +  ],
      +  "type": "object"
      +}
  2. Added

TDQS

A3.9/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses a per-call cost of 0.005 USDC with the x402 payment rails and accepted chains, and states the data comes from keyless public RPC with three-node fallback so no API key must be managed. This is exactly the auth/payment/reliability context annotations cannot express. No contradiction with readOnlyHint/idempotentHint.

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?

Purpose is front-loaded and the payment/source facts are compact and useful. The 'a caller asking in wei and a caller asking in gwei are asking the same question' sentence is mildly redundant justification that could be trimmed, but the whole is still tight.

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?

An output schema exists, so return values needn't be described; the description still names the returned fields and notes they appear 'when the node supplies them.' Combined with annotations covering safety and the description covering cost and sourcing, nothing needed to call this correctly is missing.

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 takes zero parameters, so per the rubric the baseline is 4. The description correctly adds no parameter noise, and its unit discussion (gwei and wei both returned) usefully frames the no-argument call.

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?

States a specific resource and scope: 'Base gas price (chain 8453)' plus the exact fields returned (base fee, priority fee, block number). An agent immediately knows what this retrieves. It stops short of 5 because it never distinguishes itself from overlapping siblings like get_priority_fees or get_base_balance, which an agent scanning a 90-tool list would need.

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?

There is no when-to-use or when-not-to-use guidance, and no alternative is named despite get_priority_fees and get_eth_price sitting adjacent and partially overlapping. The sentence about wei vs gwei explains output units, not tool selection. The agent must infer usage purely from the name.

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.