A marketing analytics API should expose the same governed metrics that people see in the product, while MCP lets an authorized AI client discover and query those read-only tools. Neither interface fixes weak definitions. Automation makes a trustworthy metric system faster—and an inconsistent one more dangerous.

The first design decision is therefore not REST versus MCP. It is the reporting contract: metric definitions, dimensions, time boundaries, provenance, aggregation rules, permissions, and freshness.

What belongs in a reporting contract?

Each metric needs a stable definition that is independent of a particular chart:

Contract element	Example question
Name and meaning	Does `revenue` mean observed, predicted, or forecast-total revenue?
Grain	Is one row an asset-day-country-platform combination?
Supported dimensions	Can the metric be grouped by creative, campaign, network, app, or country?
Aggregation	Is it additive, recomputed from components, or not aggregatable?
Time	Which timezone and date boundary apply?
Currency	Is the value source currency or normalized currency?
Freshness	When was the source last successfully updated?
Provenance	Which network, MMP, warehouse, or model supplied it?

Once that contract exists, the dashboard, API, export, alert, and agent can share the same implementation rather than recreating business logic in every consumer.

Why read-only access is the safe default

Analysis and mutation have different failure costs. A malformed read may produce a bad answer; a malformed write may move budget, alter campaigns, or overwrite configuration. Marketing reporting should begin with read-only, least-privilege credentials and explicit resource boundaries.

Use separate scopes for apps or accounts, short-lived credentials where practical, audit logs, rate limits, and predictable error responses. Never include report keys or access tokens in URLs, examples, browser storage, logs, or generated agent output.

Read-only does not mean consequence-free. Customer metrics can still be sensitive. Restrict columns and rows to the authorized account and avoid returning personal or device-level identifiers when the analytical job can be completed with aggregates.

REST API design for analytical queries

An analytical endpoint should make scope explicit. A request commonly needs:

Date range and timezone.
App or account boundary.
Metrics.
Dimensions or groupings.
Filters.
Sort order.
Pagination or row limit.

The response should echo the normalized request, report generation time, source freshness, metric definitions or version, and any incomplete-data warnings. If a requested combination is invalid, return a clear validation error rather than silently changing the grouping.

Ratios must be recomputed from additive components. If a client requests ROAS by country, the server should aggregate revenue and spend for each country and then divide. It should not average asset-level ROAS values.

What MCP adds

Model Context Protocol gives compatible AI clients a standard way to discover tools and their input schemas. For analytics, an MCP server can expose narrowly defined read tools such as:

List connected apps.
Query creative performance.
Compare cohorts by media source.
Retrieve data freshness and coverage.
Explain a metric definition.

The tool description should state what the result can and cannot establish. “Top creatives” is ambiguous; “rank creative assets by observed D30 ROAS for one app and date range” is inspectable.

Agents should receive structured fields, not a prewritten conclusion. The client can then explain or summarize the result while retaining the source dimensions, timestamps, and warnings that make the answer auditable.

Guardrails for AI-assisted analysis

Keep every tool read-only unless a separate reviewed workflow authorizes writes.
Require an explicit app/account scope.
Cap date ranges and result sizes.
Return source freshness and incomplete-data warnings.
Distinguish observed and predicted values in field names.
Preserve metric provenance.
Reject unsupported aggregations.
Log tool name, authorized account, timing, and result status without logging secrets.
Treat the agent’s narrative as interpretation, not a new source of truth.

An AI client should be able to answer “Which assets improved D30 ROAS last week?” and show how it reached the answer. It should not quietly substitute CTR because D30 revenue was incomplete.

Lemon AI reporting interfaces

Lemon AI exposes read-only creative and cohort reporting through product views, API endpoints, and MCP tools backed by the same metric definitions. This lets analysts, scripts, and authorized AI clients inspect the same result rather than maintaining separate spreadsheet logic.

See Reports and API for the current interface, Creative Analytics for asset-level decisions, Cohort Prediction for forecasts, and the methodology for metric and aggregation rules.

Marketing Analytics API and MCP Automation