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 batche...
Part of the Spectra server.
Free to start. No card required.
AI agents call get_pool_activity to retrieve information from Spectra without modifying any data. This is common in research, monitoring, and reporting workflows where the agent needs context before taking action. Because read operations don't change state, they are generally safe to allow without restrictions -- but you may still want rate limits to control API costs.
Even though get_pool_activity only reads data, uncontrolled read access can leak sensitive information or rack up API costs. An agent caught in a retry loop could make thousands of calls per minute. A rate limit gives you a safety net without blocking legitimate use.
Read-only tools are safe to allow by default. No rate limit needed unless you want to control costs.
{
"version": "1",
"default": "deny",
"tools": {
"get_pool_activity": {}
}
}See the full Spectra policy for all 25 tools.
These attack patterns abuse exactly the kind of access get_pool_activity gives an agent. Each links to the full case and the policy that stops it:
Other read tools across the catalogue. The same approach applies to each: allow, with a rate cap to control cost.
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.
Register the Spectra MCP server in PolicyLayer and add a rule for get_pool_activity: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Spectra. Nothing to install.
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 PolicyLayer 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 PolicyLayer 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). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
Deterministic rules across all 25 Spectra tools. Per-identity grants. Full audit log. Live in minutes. Nothing to install.
Free to start. No card required.
4,600+ MCP servers and 31,000+ tools scanned and risk-classified.