Skip to main content
Glama
1tylermitchell

Sairen

by 1tylermitchell
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

get_base_gas_oracle

Retrieve real-time Base network EIP-1559 gas prices and congestion metrics to set optimal max fees for transaction confirmations, avoiding reverts and overpayment.

Instructions

    [Cost: $0.0005 USDC on Base & Solana] Retrieves real-time Base network EIP-1559 gas price parameters and congestion metrics.
    Provides recommended maxFeePerGas and maxPriorityFeePerGas for slow, standard, fast,
    and instant transaction confirmation to prevent agent transaction reverts and gas overpayment.

    Args:
        force_refresh: Whether to bypass cache and query RPC directly (default: False).
        payment_signature: Optional x402 Base USDC transaction hash or developer mock key.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
force_refreshNo
payment_signatureNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.0

TDQS

A3.7/5.0
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. It discloses cost ($0.0005 USDC) and that force_refresh bypasses cache to query RPC directly, which is useful behavioral context. However, it does not detail return format, error handling, or authentication requirements for the payment_signature.

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 brief and front-loaded with cost and purpose, then lists parameters compactly. It avoids redundancy but could be more structured; still efficient for the information conveyed.

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 read-only oracle with 2 optional params and no output schema, the description covers purpose and basic param semantics, but lacks details on return structure and potential failure modes, which an agent would need for robust decision-making.

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?

Schema coverage is 0%, and the description adds only brief explanations: force_refresh wording and payment_signature mention x402 Base USDC transaction hash or developer mock key. It does not explain when to set force_refresh to true vs false, or how to obtain/use the payment signature, leaving ambiguity.

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 it retrieves real-time Base network EIP-1559 gas price parameters and congestion metrics, and provides recommended maxFeePerGas and maxPriorityFeePerGas for different confirmation speeds. It distinguishes itself from siblings like get_dex_spot_price and get_solana_dex_price by focusing on gas oracle data.

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 implies usage for preventing transaction reverts and gas overpayment, and mentions the cost and network (Base & Solana). It does not explicitly state when not to use it or name alternatives, but the context is clear enough for an agent evaluating gas prices before transactions.

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

Deploy Server

Other Tools