Skip to main content
Glama
Coinversaa

Coinversaa Pulse

Official
by Coinversaa
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Builder Profile

builder_profile
Read-onlyIdempotent

Get revenue, fee timestamps, tokens, rates, daily metrics, top coins, and profitable-wallet counts for a 0x builder address on Hyperliquid by day, week, or month.

Instructions

Single-builder overview for a 0x-hex builder address: exact revenue from Hyperliquid's on-chain builder-fee ledger over the period (day/week/month), first/last fee accrual timestamps, distinct fee tokens, most common requested fee rate over the last 7d of orders (feeTenthsBp, tenths of a basis point), a daily attributed series (fees/volume/users/fills) with the biggest day highlighted, top coins by attributed volume, and how many of the period's attributed wallets are all-time profitable. Attributed metrics slightly undercount versus ledger revenue (trigger-order stop/TP fills not yet attributed — see the response's dataNotes); builderName comes from a curated registry, omitted when unknown. Returns 404 for addresses with no revenue in the fee ledger. Use for 'how is builder X doing?' or 'what do people trade on frontend Y?'. Requires Starter tier or higher. Availability: typically 10-25 seconds on large builders; the coin split (topCoins) may come back null with an explanation in dataNotes when the live pass exceeds its budget. Ledger history begins at the fee ledger's first on-chain entry (see data_coverage, builder_ledger).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
periodNoAggregation window: day, week, or month.month
builderYesBuilder address (0x...)
topCoinsNoHow many top coins (by attributed volume) to return (max 50).
useToonFormatNoReturn data in compact toon format (default: true). Set to false for standard JSON.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.11.1
    • changedInput schema / properties / builder / description
      Previous value: -"Builder address (0x...) — the fee-receiving address a frontend/bot/dex registers on Hyperliquid"New value: +"Builder address (0x...)"
  2. Addedv0.11.0

TDQS

A4.5/5.0
Behavior5/5

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

Adds substantial context beyond the annotations: 404 behavior for zero-revenue addresses, 10-25s latency on large builders, topCoins null-on-budget with dataNotes explanation, known undercounting vs ledger revenue, registry-sourced builderName omission, and ledger history scope. Annotations cover the safety profile, and the description layers on operational and data-quality traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded and every clause carries information, but the entire definition is a single dense run-on paragraph mixing return values, caveats, latency, and coverage notes. It is information-rich rather than wasteful, yet structure and scannability suffer.

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, so the description must carry the return-value explanation, and it does thoroughly (revenue, timestamps, tokens, rate, daily series, top coins, profitability count, dataNotes caveats). For a complex analytics tool with a mandatory address parameter, an agent has everything needed to call and interpret it.

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 description coverage is 100%, so baseline is 3, but the description adds meaning beyond the schema: it explains feeTenthsBp units (tenths of a basis point), clarifies that topCoins may come back null, and reinforces the period window semantics. Genuine added value over the structured fields.

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 resource ('single-builder overview for a 0x-hex builder address') and enumerates exactly what is returned: ledger revenue, timestamps, fee tokens, fee rates, daily attributed series, top coins, profitable wallets. It is unmistakably distinct from builder_leaderboard, builder_fills, and the pulse_* siblings.

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?

Provides concrete trigger phrasing ('how is builder X doing?', 'what do people trade on frontend Y?') plus a tier prerequisite (Starter+). It does not explicitly name a sibling alternative or a when-not-to-use condition, so it falls short of a 5.

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