Skip to main content
Glama

Agent Einstein — Crypto & Market Intelligence

by io.emc2ai

Uniswap v4 Hook Radar

scan_v4_hooks
Read-onlyIdempotent

Census the Uniswap v4 hook layer on Robinhood Chain (4663) and Base: which hook contracts are creating the most pools, what each is permitted to do to a trader or an LP (take an arbitrary cut of a swap, reject a swap, block a liquidity withdrawal), which sit behind an upgradeable proxy, and which hooks no registry has catalogued. Permissions are decoded from the hook address itself, so they describe capability, not intent — most delta-taking hooks are ordinary launchpads. Robinhood Chain is the largest v4 venue by volume and about a quarter of its hooked liquidity is uncatalogued. [Paid: $0.25 per call from your Einstein credit balance. Free alternatives exist for several of these — see list_einstein_capabilities.]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chainIdNoRestrict to one chain. 4663 = Robinhood Chain, 8453 = Base. Omit for both.

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses the cost model ($0.25 per call from Einstein credit balance) and provides an important interpretive caveat: permissions are decoded from the address and describe capability, not intent, with most delta-taking hooks being ordinary launchpads. This materially prevents misuse or misinterpretation of the data.

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 dense but every sentence earns its place: scope and outputs, interpretation guidance, market context, and cost/alternatives. The action verb is front-loaded, and the prose avoids fluff while conveying substantial detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully summarizes what the tool returns: pool-creating hooks, permission capabilities, proxy status, and catalog coverage. It also covers chain selection, cost, and the caveat about permission semantics; minor details like pagination or result limits are not addressed, but nothing essential for selecting and invoking the tool is missing.

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?

The schema already provides 100% coverage for the single optional chainId parameter, including enums and an 'Omit for both' note. The description adds no new parameter-level meaning beyond naming the chains, so a 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 ('Census') and names an exact resource (Uniswap v4 hook layer on Robinhood Chain and Base), while enumerating concrete output categories: pool creation, hook permissions, upgradeable proxies, and uncatalogued hooks. This clearly distinguishes the tool from broad siblings like scan_launchpads or get_launchpad_radar.

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 identifies a clear use case: a paid census of Uniswap v4 hooks with permission decoding, and explicitly directs the agent to list_einstein_capabilities for free alternatives. However, it stops short of specifying precise conditions for when the paid tool should be preferred over those alternatives, making the guidance strong but not fully exclusionary.

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

All Agent Einstein — Crypto & Market Intelligence toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.3/5.0
Disambiguation2/5

With 40 tools, many share overlapping domains: get_smart_money_flow vs get_smart_money_inflow, scan_launchpads vs get_launchpad_radar, track_whales vs get_hyperliquid_whales, and check_token_safety vs analyze_token_security. The detailed descriptions help, but the boundaries are not always clear, making misselection likely.

Naming Consistency2/5

The tool names employ a wide variety of verbs (get_, analyze_, scan_, track_, find_, generate_, recommend_, run_, list_, ask_, assess_, detect_) with no consistent pattern. While all use snake_case, the inconsistent verb choices and occasional deviations like forecast_chart prevent predictability.

Tool Count2/5

40 tools is well above the typical 3-15 well-scoped range and exceeds the 25+ threshold for 'too many'. While the broad 'crypto intelligence' purpose justifies some breadth, the sheer number makes the surface unwieldy and suggests a lack of focused scoping.

Completeness4/5

The tool set covers a wide range of crypto intelligence domains: market analysis, forecasting, whale tracking, yield/arbitrage, security checks, prediction markets, backtesting, and even content generation. Missing operations are minor (e.g., no direct portfolio management), but core analysis and data retrieval workflows are well represented.

Resources