Replo

Query Replo analytics

query_replo_analytics

Read-onlyIdempotent

Run read-only ClickHouse SQL over a project's Replo analytics for traffic, conversion, revenue, and session-level questions. Queryable public tables are session_attribution, events_computed, currency_exchange_rates, daily_page_rollups, daily_namespace_rollups, and daily_namespace_purchase_rollups. Only SELECT/WITH queries are accepted, and project-scoped tables are automatically restricted to the requested project and its authorized same-workspace, same-store siblings. For table columns, query examples, and limits, see the Replo Public API analytics query docs.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`query`	Yes	Run a read-only analytics query for a project. Rules: - Use SELECT or WITH queries only. - Do not add project or namespace filters; project scoping is enforced server-side. - Use session_attribution(since, until) for cross-project session and attributed revenue; stored computed metrics and page rollups are project-local. - Session revenue repeats across visited pages: deduplicate by subject for totals. Attributed revenue splits credit across eligible pageviews before domain filters. - Aggregate-state rollup columns must use the matching ClickHouse merge function, such as countMerge, uniqMerge, or sumMerge, and queries must group by selected dimensions. - Maximum execution time: 60 seconds. - Maximum result rows: 100000. Queryable tables: Parameterized view: session_attribution(since='YYYY-MM-DD', until='YYYY-MM-DD'), inclusive UTC dates. Computes USD purchase, session, and equal-pageview attributed revenue across authorized sibling projects within that window, before domain filters. Cart/checkout views receive no attribution. Deduplicate sessionRevenueUsd by subject before summing. Inherits source row policies. Project scoped: yes. ```sql session_attribution ( subject UUID, date DateTime64(3), name LowCardinality(String), domain String, path String, title String, purchaseRevenueUsd Float64, sessionRevenueUsd Float64, sessionPurchaseCount UInt64, attributedRevenueUsd Float64 ) ``` Raw events with project-local computed session metrics. Use session_attribution for revenue across linked projects. Project scoped: yes. ```sql events_computed ( subject UUID, date DateTime64(3), name LowCardinality(String), path String, domain String, currencyCode String, subjectPurchaseSum Float64, subjectPurchaseCount Float64, subjectPurchaseFraction Float64, subjectPurchaseFractionalSum Float64, title String ) ``` Currency exchange rates for multi-currency reporting. Project scoped: no. ```sql currency_exchange_rates ( date Date, code String, rate Float32 ) ``` Pre-aggregated daily page metrics by day, domain, path, and UTM source. Revenue/conversion attribution is project-local; use session_attribution across linked projects. Project scoped: yes. ```sql daily_page_rollups ( day Date, domain String, path String, utm_source String, views_state AggregateFunction(count), unique_sessions_state AggregateFunction(uniq, UUID), converting_sessions_state AggregateFunction(uniq, UUID), fractional_conversions_state AggregateFunction(sum, Float64), fractional_revenue_usd_state AggregateFunction(sum, Float64), session_conversions_state AggregateFunction(sum, UInt64), session_revenue_usd_state AggregateFunction(sum, Float64) ) ``` Pre-aggregated daily project traffic metrics by day and UTM source. Project scoped: yes. ```sql daily_namespace_rollups ( day Date, utm_source String, views_state AggregateFunction(count), unique_sessions_state AggregateFunction(uniq, UUID), converting_sessions_state AggregateFunction(uniq, UUID) ) ``` Pre-aggregated daily purchase metrics by day and UTM source. Project scoped: yes. ```sql daily_namespace_purchase_rollups ( day Date, utm_source String, purchase_count_state AggregateFunction(count), total_revenue_usd_state AggregateFunction(sum, Float64), unique_purchasing_sessions_state AggregateFunction(uniq, UUID) ) ```
`projectId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 19, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds genuinely non-obvious behavior: only SELECT/WITH are accepted, project-scoped tables are server-side filtered to the requested project plus authorized same-workspace/same-store siblings, and limits/examples live in external docs. Execution-time and row caps are only in the schema, not the description.

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?

Four sentences, front-loaded: purpose, table inventory, write-restriction, scoping rule, doc pointer. The table enumeration partially duplicates the schema, but at four sentences total nothing is bloated.

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 tool with no output schema and a highly complex query surface, the description covers the accepted syntax, the scoping model, the table inventory, and offloads column/limit detail to referenced docs. Missing only the shape of the returned result set, which an agent might reasonably want before parsing output.

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 only 50% (the uuid projectId has no description), so the description carries weight by explaining that project scoping is enforced server-side against projectId rather than left to the caller's WHERE clause. The `query` param is exhaustively documented in the schema itself, so the description rightly doesn't repeat it.

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?

Opens with a specific verb and resource: 'Run read-only ClickHouse SQL over a project's Replo analytics for traffic, conversion, revenue, and session-level questions.' No sibling tool does anything comparable, and the read-only/SQL framing immediately separates it from the REST-style find_/get_ tools.

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?

Gives real routing guidance among the queryable tables: it names the six tables and, in the schema, distinguishes session_attribution (cross-project revenue) from project-local rollups with deduplication advice. It stops short of explicit when-not-to-use-this-tool or a named alternative for non-SQL analytics needs.

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

All Replo tools Inspect

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

Need Help?