get_pool_activity

Get recent trade and liquidity activity for a specific Spectra pool. Returns individual transactions: buys, sells, and liquidity adds/removes with USD values, timestamps, and tx hashes. Pool activity shows only the Curve pool's perspective (IBT ↔ PT swaps and LP events). The Spectra Router batches operations atomically, so any single pool event may be one step of a multi-step strategy. There is no BUY_YT or SELL_YT event type — the pool never touches YT directly. Use get_protocol_context for the full mechanics of how Router batching maps to pool activity types. Protocol mechanics that affect how activity appears: - BUY_PT and SELL_PT are Curve pool swaps between IBT and PT. - There is NO "BUY_YT" or "SELL_YT" type. The pool never touches YT directly. - YT selling via the Router's flash-redeem internally buys PT from the pool to pair with YT for redemption — so YT sells show up as BUY_PT in the activity log. - A standalone mint (deposit IBT → PT+YT) does NOT appear in pool activity. However, the Router can batch a mint + LP add in one atomic execute() call. The minted PT + remaining IBT enter the pool as AMM_ADD_LIQUIDITY while the minted YT goes directly to the user's wallet. So AMM_ADD_LIQUIDITY events may ALSO represent YT acquisition — the YT minting is invisible in pool data. - The Router can also flash-mint atomically: flash-borrow IBT → mint PT+YT → sell PT on the pool → user tops up the shortfall → user receives YT. This shows up as SELL_PT but the user's net action is acquiring YT, not selling PT. - AMM_REMOVE_LIQUIDITY returns IBT + PT from the pool. Users often follow up by selling the PT (SELL_PT) to recover capital, completing a mint→LP→remove→sell loop that nets them YT at the cost of the PT discount (~1 - ptPrice). Key principle: any pool event type can be one step of a multi-step Router operation. Do not assume SELL_PT means "user is bearish on PT" or AMM_ADD_LIQUIDITY means "user is providing liquidity for yield." Always cross-reference with get_portfolio to see what the address actually holds (PT, YT, LP balances) — the holdings reveal the true strategy better than the activity log alone. Analysis tips — IMPORTANT: each observation below has multiple valid interpretations. The tool output now presents these as competing branches. Do not collapse to one interpretation without cross-referencing get_portfolio and other data sources. - High SELL_PT count: could be flash-mint YT accumulation (check YT balance >> PT) OR simple PT liquidation OR one leg of cross-protocol arb. Portfolio resolves this. - BUY_PT events: could be fixed-rate accumulation OR flash-redeem YT selling (check if YT balance dropped). These predict opposite future behavior. - Paired ADD/REMOVE liquidity: could be LP cycling in a mint loop OR fee harvesting OR rebalancing. The intent is not observable from pool activity alone. - Large volume vs small holdings: could be capital recycling (looping) OR completed round-trip (entered and exited) OR funds moved to another venue. Output includes an Address Concentration section with full addresses and per-address type breakdowns. Use get_portfolio on those addresses to see their PT, YT, and LP balances. Most analysis can be done without a block explorer — use get_portfolio on addresses from Address Concentration, and compare_yield or get_pt_details for rate context. Address isolation mode: When you provide an 'address' parameter, the tool filters to that address only, sorts chronologically (oldest first), and adds: - Sequence Analysis: detects repeating action cycles (e.g., ADD→REMOVE→SELL repeated 8×). Presents COMPETING INTERPRETATION BRANCHES (A/B/C) that predict different future behavior. Small repetition counts (≤5) are flagged as statistically insufficient for extrapolation. CRITICAL: do NOT collapse these branches into a single narrative without external evidence from get_portfolio or other tools. The branches exist as friction against premature pattern-matching — the tension between them IS the information. - Flow Accounting: cross-references portfolio data to show PT/YT flow reconciliation. When position shape is observable (e.g., YT-only, PT-only, fully exited), presents competing hypotheses for WHY the position looks that way. Each hypothesis predicts different future behavior. Do not select one without additional evidence. - Capital Efficiency: compares total activity volume against the address's throughput, flagging high ratios that indicate capital recycling (looping) vs accumulation. - If the address shows high-frequency activity (>10 txns), consider checking whether it is a contract (programmatic execution via Router execute()) vs an EOA (manual/scripted). Contracts execute atomically; EOAs submit separate transactions. This distinction affects whether apparent "sequences" are truly sequential or batched. - Contract Detection: checks whether the address is a contract or EOA via on-chain eth_getCode. Contracts execute atomically; EOAs submit sequential transactions. - Pool Impact: flags when SELL_PT or BUY_PT volume is significant relative to pool liquidity, indicating potential market impact on implied APY. - Gas Estimates: estimates total gas cost from transaction count using chain-specific gas heuristics. Shows gas as percentage of activity volume and position value. - Pool Context: fetches pool liquidity and implied APY for baseline context. - Observation Coverage: quantifies the blind spots of this analysis. Shows: (1) Value coverage — what % of the position is explained by observable activity. (2) Temporal coverage — active days vs dark periods with no observable events. (3) Data source coverage — which of the available data sources were consulted. CRITICAL: coverage metrics bound the domain of validity for ALL interpretations above. If value coverage is low (<50%), the competing interpretation branches are based on a minority of the address's actual behavior. Position sizing should reflect the coverage level, not the confidence of the best-fitting interpretation. For multi-pool activity scanning, use get_address_activity to find all pools an address has interacted with in a single call.. It is categorised as a Read tool in the Spectra MCP Server, which means it retrieves data without modifying state.

Add a rule in your Intercept YAML policy under the tools section for get_pool_activity. You can allow, deny, rate-limit, or validate arguments. Then run Intercept as a proxy in front of the Spectra MCP server.

get_pool_activity is a Read tool with low risk. Read-only tools are generally safe to allow by default.

Yes. Add a rate_limit block to the get_pool_activity rule in your Intercept policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.

Set action: deny in the Intercept policy for get_pool_activity. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.

get_pool_activity is provided by the Spectra MCP server (spectra-mcp-server). Intercept sits as a proxy in front of this server to enforce policies before tool calls reach the server.