Mark

Get Performance Overview

get_performance_overview

Read-onlyIdempotent

Reports the Performance page's Overview tab for a date range: one row per funnel stage, each the same number its tab shows. Visibility is Search Console impressions; Visits are Search Console clicks and PostHog site pageviews; AI answers is the Named rate per engine from the latest weekly check in the market (no compare, no target, never one blended number); Leads are first-touch leads Mark recorded, counted on the Pacific Time days Search Console reads. Each row has stage, metric, value, previous and changePercent (with compare), target, dataThrough, connection (ready, or why there is no number, such as not_connected, no_property, no-posthog, no-signal or failed) and appUrl, the tab it opens. A failed Site pageviews row has failure: busy means PostHog didn't answer in time (it runs 3 queries at once per project and queues the rest), so try again in a minute; the PostHog connection is fine. error is any other failure, such as lost access, so check the PostHog connection. target is { month, target, actual, progressPercent }, exactly as the Targets page and get_content_performance compute it, and only when from to to is one target month (a whole past month, or this month from the 1st to today); today only leads have a matching KPI metric. compare adds the window of the same length just before. Does not change anything. Related: get_search_performance, get_visitor_locations, get_ai_visibility, get_content_performance.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_performance_overview"
  }
}

Input Schema

Name	Required	Description
`to`	No	Range end YYYY-MM-DD.
`from`	No	Range start YYYY-MM-DD. Defaults to the last 28 settled days.
`compare`	No	Add the previous window of the same length.
`marketId`	No	One active market: Search Console filters to its country and AI answers reads it. Defaults to all markets and the priority market.

Output Schema

Name	Required	Description	Default
`to`	Yes
`from`	Yes
`rows`	Yes
`appUrl`	Yes
`compareTo`	Yes
`compareFrom`	Yes
`showTargets`	Yes
`targetMonth`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 20, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already establish that this is a read-only, idempotent, non-destructive operation, and the description still adds substantial operational context: metric definitions, connection states, why values may be missing, and the distinction between busy and error failures. It also explains target computation and compare-window behavior without contradicting the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence is front-loaded and useful, but the following explanation is extremely dense and run-on, with extensive return-field detail that may duplicate the output schema. The content is valuable but not tightly structured for quick scanning.

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 complex multi-metric overview with connection-dependent values and conditional target fields, the description is sufficiently complete. It covers what the rows mean, how missing data is represented, and what compare and marketId do.

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 schema itself documents the four parameters. The description adds meaningful semantics beyond the schema, especially that marketId filters Search Console country and drives AI answers, and that target only appears when the from/to range matches one target month.

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 resource and view: the Performance page's Overview tab, over a date range, with one row per funnel stage. It also clarifies the row model and names related tools, so an agent can distinguish this overview tool from narrower siblings.

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

Usage Guidelines3/5

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

It lists related tools and explains parameter-driven behavior like compare and target-month applicability, but it does not explicitly state when to use this tool instead of get_search_performance, get_ai_visibility, or get_content_performance. Usage is implied rather than routed.

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

All Mark 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?