Skip to main content
Glama

BitCLI — Crypto Futures & Order Flow

by io.bitcli.mcp
OverviewDiscussionsAdmin

Server Details

Real-time crypto futures order flow, liquidation cascades, and quantitative TA metrics across 1,650+ perpetuals (Binance, Bybit, Hyperliquid). Delivers ultra-dense, token-efficient summaries and async SSE alerts directly into AI agent context without burning tokens on raw OHLCV candles.

Ownership verified
Status
Healthy
Last Tested
Transport
Streamable HTTP · MCP 2024-11-05
URL

TDQS

A4.5/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: the three alert tools (create/list/cancel) target distinct lifecycle actions, while get_market_snapshot handles broad discovery and get_ta_consensus handles single-coin confirmation. The descriptions explicitly cross-reference each other with 'use X instead' guidance, eliminating overlap.

Naming Consistency5/5

All five names follow a strict verb_noun snake_case pattern (create_alert, cancel_alert, list_alerts, get_market_snapshot, get_ta_consensus). No mixing of conventions or vague verbs.

Tool Count4/5

Five tools is a small but well-scoped set where each earns its place, covering alert management and two distinct market-analysis paths. It sits at the lower bound, so the surface feels lean but not underbuilt for the stated purpose.

Completeness4/5

The alert lifecycle is fully covered (create/list/cancel), and read access spans both market-wide and single-coin analysis. Minor gaps exist (no alert update/edit, no explicit historical or position/order data), but core workflows have no dead ends.

Available Tools

5 tools
cancel_alertAInspect

BEHAVIOR & SIDE EFFECTS: State-mutating and destructive. Irreversibly unregisters and removes an active trigger from both C++ HFT engine memory and Redis state. Operation is idempotent: canceling an already expired or non-existent alert safely returns an explanatory message without corrupting state.

WHEN TO USE: Call this tool as soon as a trading setup is executed, invalidated, or no longer needed, to free engine capacity.

WHEN NOT TO USE: Do not use to inspect active triggers (use list_alerts).

PREREQUISITES: Requires a valid alert_id previously returned by create_alert (e.g. 'alrt_101').

FAILURE MODES: If the alert_id is missing or expired, returns isError: true with a clear diagnostic message.

ParametersJSON Schema
NameRequiredDescriptionDefault
alert_idYesUnique identifier of the alert returned by `create_alert`.

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so: it discloses the operation is state-mutating and destructive, irreversible, idempotent for expired/non-existent alerts, requires a prior create_alert id, and returns isError:true with a diagnostic on failure. This is rich behavioral context beyond what structured fields provide.

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 labeled sections (BEHAVIOR, WHEN TO USE, WHEN NOT TO USE, PREREQUISITES, FAILURE MODES) are front-loaded and scannable, with no filler sentences. It is slightly verbose for a single-parameter tool, but every section carries distinct decision-relevant information.

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?

For a one-parameter destructive tool with no annotations and no output schema, the description covers side effects, irreversibility, idempotency, prerequisites, and error behavior. Nothing an agent needs to invoke it safely is missing.

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 coverage is 100%, so the alert_id parameter is already documented in the schema, giving a baseline of 3. The description adds origin and format context (previously returned by create_alert, example 'alrt_101') and ties the parameter to the failure mode when missing, exceeding the baseline.

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 names a specific verb and resource ('cancel_alert' unregisters and removes an active trigger) and states exactly which systems are affected (C++ HFT engine memory and Redis state). It is clearly distinguishable from siblings like create_alert and list_alerts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit WHEN TO USE trigger condition (setup executed, invalidated, or no longer needed) and a WHEN NOT TO USE with the named alternative tool ('use list_alerts' to inspect triggers). No inference is required to route correctly.

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

create_alertAInspect

BEHAVIOR & SIDE EFFECTS: State-mutating operation. Registers an active in-memory HFT trigger in the C++ engine (<500ns tick evaluation). When triggered, an asynchronous event is pushed via SSE to wake up the agent. Alerts auto-expire after ttl_minutes. Idempotent: repeated calls allocate distinct alert IDs.

WHEN TO USE: Proactively call this tool to eliminate continuous API polling loops when waiting for price levels, breakout corridors, volume spikes, or liquidation cascades.

WHEN NOT TO USE: Do not use to inspect registered alerts (use list_alerts) or cancel alerts (use cancel_alert). Do not use for historical data analysis.

UNIFIED BITCLI SYNTAX EXAMPLES:

  • 'btc 95k' (Price cross)

  • 'sol +3.5% 5m' (Velocity pump detector)

  • '* vol 15m x4' (Global exchange-wide whale volume spike vs SMA20)

  • '* liq z3' (Statistical liquidation cascade anomaly > 3σ)

  • 'eth cvd div 15m' (Order flow CVD divergence)

  • 'btc 90k cd=30m' (With custom 30-minute cooldown)

FAILURE MODES: If command syntax cannot be parsed, returns isError: true with syntax guidance.

ParametersJSON Schema
NameRequiredDescriptionDefault
commandYesUnified BitCLI alert command string (e.g. 'btc 95k', '* vol 15m x4 cd=15m').
agent_idNoPersistent agent identifier used to recover alert states across network reconnects.default_agent
ttl_minutesNoSubscription lifetime in minutes (range: 1 to 1440, default: 60). Auto-expires upon expiration.

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does so well: state-mutating, in-memory trigger, asynchronous SSE wake-up, auto-expiry via ttl_minutes, and a parse-failure mode returning isError:true. However, the claim 'Idempotent: repeated calls allocate distinct alert IDs' is internally inconsistent — allocating distinct IDs on repeat is the opposite of idempotent, which could mislead an agent about retry safety.

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?

Front-loaded with BEHAVIOR & SIDE EFFECTS, then usage routing, then examples — a sensible order with labeled sections. The six syntax examples are individually valuable but make the block longer than strictly necessary; still, each line teaches distinct command grammar.

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?

For a mutating tool with no annotations and no output schema, the description covers side effects, lifetime/expiry, async notification path, and failure behavior. Gaps remain: it does not state whether an alert ID is returned, nor any auth/permission requirements.

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 coverage is 100%, so baseline is 3, but the description adds genuine meaning beyond the schema: six concrete BitCLI syntax examples showing how to build `command` (price cross, velocity pump, volume spike, liquidation anomaly, CVD divergence, cooldown modifier) and the ttl_minutes expiry consequence.

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 concrete verb+resource: registers an active in-memory HFT trigger in the C++ engine, with the evaluation latency and notification mechanism named. It explicitly distinguishes itself from sibling tools (list_alerts for inspection, cancel_alert for cancellation), so an agent can route correctly without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Has dedicated WHEN TO USE (replace polling loops for price levels, breakouts, volume spikes, liquidation cascades) and WHEN NOT TO USE sections that name the alternatives (list_alerts, cancel_alert) and exclude historical analysis. Nothing about selection is left to inference.

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

get_market_snapshotAInspect

BEHAVIOR & SIDE EFFECTS: Safe, idempotent, read-only operation. Zero side effects. Fetches a pre-computed market-wide anomaly snapshot directly from in-memory Redis cache (data latency <1s). Rate limits: Public Alpha tier (unrestricted).

WHEN TO USE: Use this as the FIRST exploratory step in your workflow to scan all 1,650+ perpetual contracts simultaneously and identify top statistical outliers (whale volume, funding extremes, volatility).

WHEN NOT TO USE: Do not use this tool to analyze a single specific coin in depth or fetch indicator history (use get_ta_consensus instead).

FAILURE MODES: If the market is completely flat or cache is refreshing, returns a valid array of top coins by 24h volume. Output length is strictly bounded by the limit parameter.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of coins to return (allowed range: 1 to 20, default: 10).
sort_byYesAnomaly screening criteria: 'rvol_5m' (Whale volume bursts vs SMA20), 'funding_rate' (Carry cost & squeeze traps), 'oi_change_1h' (Aggressive leverage buildup), 'natr_1h' (Normalized ATR volatility).

TDQS

A4.4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden and does well: read-only, idempotent, zero side effects, <1s cache latency, unrestricted rate limit, and a documented degenerate-case return. However, it omits how fresh the snapshot can be relative to the cache refresh cycle and what the item-level fields look like, so it stops short of full disclosure.

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?

Labeled sections (behavior, when to use, when not to use, failure modes) make it scannable and front-load the safety profile. Every line contributes a decision-relevant fact; nothing is redundant padding.

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 compensates by stating the return is an array of top coins by 24h volume with length bounded by `limit`, plus the flat-market edge case. Item-level field contents are the only meaningful gap for a two-parameter screening tool.

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 coverage is 100%, so the baseline is 3; the description adds the non-obvious consequence that output length is strictly bounded by `limit`, tying the parameter to result shape rather than just restating its range. The enum semantics remain fully in the schema, so it does not need to repeat them.

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 verb and resource (fetches a pre-computed market-wide anomaly snapshot) with concrete scope: all 1,650+ perpetual contracts screened simultaneously from a Redis cache. It is clearly distinguishable from get_ta_consensus, which is named as the single-coin/indicator-history alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to use this as the FIRST exploratory step for scanning the whole market, and names the exclusion case (single-coin deep analysis or indicator history) with the sibling tool to use instead. Both the when and the when-not are stated outright.

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

get_ta_consensusAInspect

BEHAVIOR & SIDE EFFECTS: Safe, idempotent, read-only operation. Zero side effects. Queries cross-exchange aggregated technical consensus across Binance, Bybit, and Hyperliquid. Returns EMA20 trend bias, RSI14, 1h ATR volatility, and Cumulative Volume Delta (CVD) order flow. Eliminates raw OHLCV candle downloads.

WHEN TO USE: Use when you already have a target coin (e.g. from get_market_snapshot) and need instant quantitative confirmation before formulating a trade hypothesis.

WHEN NOT TO USE: Do not use for broad market discovery across multiple coins (use get_market_snapshot). Do not use to set price triggers (use create_alert).

FAILURE MODES: Automatically strips suffixes ('BTCUSDT' -> 'BTC'). If an invalid or unlisted ticker is provided, returns a structured error object with isError: true.

ParametersJSON Schema
NameRequiredDescriptionDefault
coinYesTarget cryptocurrency ticker (e.g. 'BTC', 'SOL', 'ETH', 'BTCUSDT'). Case-insensitive, automatically normalized.

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so: it declares read-only, idempotent behavior with zero side effects, names the upstream data sources, and discloses failure modes (automatic ticker suffix stripping, structured error object with isError:true on invalid or unlisted tickers). Little behavioral context an agent needs is missing.

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?

Labeled sections (BEHAVIOR, WHEN TO USE, WHEN NOT TO USE, FAILURE MODES) make it skimmable and front-loaded with the safety profile. Slightly padded by benefit framing such as 'Eliminates raw OHLCV candle downloads,' which is not actionable for the agent.

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?

For a single-parameter, no-annotation, no-output-schema tool, the description supplies everything needed: what is queried, what is returned, when to pick it, when to pick a sibling, and how failures surface.

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?

Schema description coverage is 100% and the schema already documents case-insensitivity and automatic normalization, so the description largely restates it ('BTCUSDT' -> 'BTC'). The added value is the invalid-ticker error behavior, but that is already captured under failure modes, so the baseline 3 applies.

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 verb and resource ('Queries cross-exchange aggregated technical consensus across Binance, Bybit, and Hyperliquid') and enumerates the exact outputs (EMA20 trend bias, RSI14, ATR, CVD). It also distinguishes itself from the discovery-oriented sibling by scoping to a single target coin.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit WHEN TO USE and WHEN NOT TO USE sections name the triggering condition ('you already have a target coin') and route the agent to specific alternatives (`get_market_snapshot` for discovery, `create_alert` for triggers). This is a complete selection guide.

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

list_alertsAInspect

BEHAVIOR & SIDE EFFECTS: Safe, idempotent, read-only inspection. Zero side effects. Queries the Redis registry for all currently active in-memory triggers owned by the specified agent_id.

WHEN TO USE: Call this tool immediately after network reconnects, session recovery, or before creating new triggers to audit active alerts and inspect remaining TTL.

WHEN NOT TO USE: Do not use to delete alerts (use cancel_alert). Do not use to inspect market data (use get_market_snapshot).

FAILURE MODES: Safe fallback. If no alerts are active or all have expired, returns an empty JSON array [].

ParametersJSON Schema
NameRequiredDescriptionDefault
agent_idNoAgent identifier used during alert creation.default_agent

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so: read-only, idempotent, zero side effects, Redis registry backing, TTL inspection, and the empty-array fallback when nothing is active. This is exactly the disclosure an agent needs for a no-annotation read tool.

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?

Front-loaded with clearly labeled sections and no filler sentences. Minor redundancy ('Safe, idempotent, read-only' plus 'Zero side effects', and 'Safe fallback' before the empty-array behavior) keeps it just short of a 5.

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?

No output schema exists, so the description must hint at return shape; it does state the empty-array case and that remaining TTL is inspectable. It stops short of describing the populated trigger object, a small but real gap for a list tool.

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 coverage is 100%, so baseline would be 3, but the description adds the ownership relationship ('owned by the specified agent_id'), clarifying that the parameter scopes results to one agent's triggers rather than merely naming an identifier.

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 precise verb+resource ('Queries the Redis registry for all currently active in-memory triggers') and scopes it to a single agent_id. It also names the sibling it is not (cancel_alert for deletion, get_market_snapshot for market data), so an agent can distinguish it without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit WHEN TO USE (after reconnects/session recovery, before creating triggers) and WHEN NOT TO USE with named alternatives (cancel_alert, get_market_snapshot). No inference needed to select this tool.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 5 tool updates
    • Changedcancel_alert1 field changed
      • changedInput schema / properties / alert_id / description
        Previous value: -"Unique alert ID returned by create_alert (e.g. 'alrt_101')."New value: +"Unique identifier of the alert returned by `create_alert`."
    • Changedcreate_alert3 fields changed
      • changedInput schema / properties / agent_id / description
        Previous value: -"Persistent agent or wallet identifier to track and recover alerts across reconnects."New value: +"Persistent agent identifier used to recover alert states across network reconnects."
      • changedInput schema / properties / command / description
        Previous value: -"BitCLI alert command string."New value: +"Unified BitCLI alert command string (e.g. 'btc 95k', '* vol 15m x4 cd=15m')."
      • changedInput schema / properties / ttl_minutes / description
        Previous value: -"Time-To-Live in minutes (1 to 1440). Alert auto-expires after this duration."New value: +"Subscription lifetime in minutes (range: 1 to 1440, default: 60). Auto-expires upon expiration."
    • Changedget_market_snapshot2 fields changed
      • changedInput schema / properties / limit / description
        Previous value: -"Maximum number of coins to return (1-20)."New value: +"Maximum number of coins to return (allowed range: 1 to 20, default: 10)."
      • changedInput schema / properties / sort_by / description
        Previous value: -"Anomaly sorting metric: 'rvol_5m' (Whale volume spikes), 'funding_rate' (Carry squeezes), 'oi_change_1h' (Leverage inflow), 'natr_1h' (Volatility)."New value: +"Anomaly screening criteria: 'rvol_5m' (Whale volume bursts vs SMA20), 'funding_rate' (Carry cost & squeeze traps), 'oi_change_1h' (Aggressive leverage buildup), 'natr_1h' (Normalized ATR volatility)."
    • Changedget_ta_consensus1 field changed
      • changedInput schema / properties / coin / description
        Previous value: -"Target cryptocurrency ticker. Accepts clean tickers ('BTC', 'SOL') or pairs ('BTCUSDT', 'ETHUSDC')."New value: +"Target cryptocurrency ticker (e.g. 'BTC', 'SOL', 'ETH', 'BTCUSDT'). Case-insensitive, automatically normalized."
    • Changedlist_alerts1 field changed
      • changedInput schema / properties / agent_id / description
        Previous value: -"Agent identifier used when creating alerts."New value: +"Agent identifier used during alert creation."
  2. 5 tool updates
    • Addedcancel_alert
    • Changedcreate_alert5 fields changed
      • addedInput schema / properties / agent_id
        Added value: +{
+  "default": "default_agent",
+  "description": "Persistent agent or wallet identifier to track and recover alerts across reconnects.",
+  "type": "string"
+}
      • removedInput schema / properties / coin
        Removed value: -{
-  "description": "Cryptocurrency symbol (e.g., BTC, SOL, ETHUSDT).",
-  "type": "string"
-}
      • addedInput schema / properties / command
        Added value: +{
+  "description": "BitCLI alert command string.",
+  "type": "string"
+}
      • removedInput schema / properties / condition
        Removed value: -{
-  "description": "Pre-compiled HFT anomaly trigger.",
-  "enum": [
-    "volume_spike_x3_5m",
-    "cvd_divergence_15m",
-    "liquidation_z3",
-    "funding_abs_above_001"
-  ],
-  "type": "string"
-}
      • changedInput schema / required
        Previous value: -[
-  "coin",
-  "condition"
-]New value: +[
+  "command"
+]
    • Changedget_market_snapshot2 fields changed
      • changedInput schema / properties / sort_by / description
        Previous value: -"Market anomaly filter metric."New value: +"Anomaly sorting metric: 'rvol_5m' (Whale volume spikes), 'funding_rate' (Carry squeezes), 'oi_change_1h' (Leverage inflow), 'natr_1h' (Volatility)."
      • changedInput schema / properties / sort_by / enum
        Previous value: -[
-  "funding_rate",
-  "rvol_5m",
-  "oi_change_1h",
-  "natr_1h"
-]New value: +[
+  "rvol_5m",
+  "funding_rate",
+  "oi_change_1h",
+  "natr_1h"
+]
    • Changedget_ta_consensus1 field changed
      • changedInput schema / properties / coin / description
        Previous value: -"Trading pair symbol (e.g., BTCUSDT)."New value: +"Target cryptocurrency ticker. Accepts clean tickers ('BTC', 'SOL') or pairs ('BTCUSDT', 'ETHUSDC')."
    • Addedlist_alerts
  3. 3 tool updates
    • First observedcreate_alert
    • First observedget_market_snapshot
    • First observedget_ta_consensus

Publisher details

Operator
BitCLI
Operator website
https://bitcli.io
Vendor relationship
First-party
Documentation
https://docs.bitcli.io
Trust center
Not available
Restrictions
Not applicable

Related MCP Servers

  • Adology by adologyai

    Adologyofficial

    adologyai
    A
    license
    Not graded
    quality
    B
    maintenance
    Perplexity for social: ask what competitors are running across social and get answers grounded in real ad and creative data, not guesses.
    2
    Apache 2.0

  • Citesurf MCP

    citesurf
    A
    license
    A
    quality
    C
    maintenance
    Enables brand visibility monitoring across major AI platforms like ChatGPT, Claude, Gemini, and Perplexity. It allows users to track visibility scores, analyze competitor data, and receive actionable insights to improve AI-generated brand recommendations.
    16
    11 npm
    1
    MIT
  • industrylens-mcp by IndustryLensOp

    industrylens-mcpofficial

    IndustryLensOp
    A
    license
    Not graded
    quality
    B
    maintenance
    Browse IndustryLens's published competitive-intelligence reports and head-to-head competitor comparisons from any AI agent — real, source-backed data.
    MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources