Skip to main content
Glama

fivebar

Site breakdown

get_site_breakdown
Read-onlyIdempotent

One of a site's panes in full, as its view on the dashboard has it: the values of one dimension over a range, most first, each with its count, its share of the pane and the filter that narrows to it. The answer's caveats are the rules that apply to its figures, such as visitors being visitor-days or today being partial: read them before reporting any figure, and pass on those that change what it means. Name the site, range and filters as for get_site_summary, which refuses the same things. dimension is the pane. search keeps the values containing it, ignoring case: google finds Google News beside Google. limit, 1 to 50 (10 by default), and offset page through them: distinct is how many there are, following how many come after, and next_offset where the next page starts, null at the end. metric ranks a pane of pageviews, visits and visitors by one. By default a channel, source, referrer or campaign (utm_) pane is ranked by visits, and so are entry and exit, the rest by pageviews; ranked_by names the count, and dashboard_counts the linked view's where it differs. compare gives each row previous and change, against the period get_site_summary compares with, and is refused for all time. trend gives each row its counts by day, week or month; limit times their number must be at most 1000. Shares are fractions of 1; change, bounce_rate and average_percent whole percentages. A pane the filters rule out is answered with available: false, why and what to try.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoWith from: the last day, as YYYY-MM-DD, not after today.
dataNoWith dimension event_data, and only then: the name the event's data was sent under, such as plan. Leave it out, with no search, limit, offset, metric, compare or trend, for data_names: the names sent with the event in the range, most carried first. A name sent nowhere in the range, as one guessed wrong is, gives them too.
daysNoThe last this many days, ending today unless ending says yesterday.
fromNoWith to: the first day, as YYYY-MM-DD.
limitNoHow many values, 10 by default.
rangeNoA preset, as get_site_summary's range says what each covers.
trendNoGive each row's counts by day, week or month over the range.
domainYesA domain from list_sites, or any public site's.
endingNoWith days: the last day, today by default.
folderNoWith dimension folder: the folder to open, starting and ending with /, such as /blog/; / by default.
metricNoThe count to rank by: visits by default for channel, source, referrer and the utm_ dimensions, and for entry and exit; pageviews for the rest. Refused for a pane with one count, from outbound to event_data, and under a goal filter, where every pane counts conversions.
offsetNoHow many values to pass over first, 0 by default.
searchNoOnly the values containing this, ignoring case: of a country, its name or its code.
compareNoGive each row its count over the period before, and its change.
filtersNoEach narrows every figure to what has exactly that value, case and all, so google is not Google; all must hold.
propertyNoWith dimension property, and only then: the custom property, such as plan. Leave it out, with no search, limit, offset, metric, compare or trend, for properties: the site's custom properties counted in the range, most carried first, each by the name this takes. A property counted nowhere in the range, as a name guessed wrong is, gives them too.
dimensionYesThe pane: a dimension filters take, whose values are as get_site_summary's filters say, or one of these. folder: pages folder by folder, from / or the folder named by folder; a row with folder true is a folder, opened by asking again with folder set to its value. outbound: links followed to other sites, in clicks. download: files downloaded, by path. searches: what visitors searched the site for, by term and page, with no_results, its searches that found nothing. error: page loads answered with an error, by path, each with its status. time_on_page and scroll_depth: pages by their readings, with the average, and for depth read_to_end and scrolled. slowest_lcp and slowest_inp: pages by how many of their loads were poor, beside the loads measured, with poor_share. From outbound to slowest_inp, these are counted by page, not by visit, so a goal, entry or exit filter rules them out. property: the values of the custom property named by property, or without property, the custom properties themselves. event_data: under a filter by an event goal, and only then, the values the event's data was sent with under the name data gives, such as pro for plan in tally('Signup', { plan: 'pro' }), in events; without data, the names its data was sent under.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations cover the safety profile (read-only, idempotent, closed-world), and the description goes well beyond them: it discloses refusals (compare for all-time, metric under goals), the trend×limit=1000 ceiling, default ranking per dimension family, and the failure shape 'available: false, why and what to try'. That is exactly the extra context annotations cannot carry.

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?

Every sentence carries information, so it is not padded, but the entire definition is one undifferentiated block that interleaves purpose, caveats, parameter rules, pagination and output shape. For a 17-parameter tool some structure or front-loaded separation of behavior from parameters would materially aid parsing.

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?

With 17 parameters, no output schema and high complexity, the description nevertheless covers the return shape (count, share, filter), the pagination fields (distinct, following, next_offset), unit conventions and the empty-pane response. Nothing an agent needs to invoke or interpret it 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 baseline is 3, but the description adds meaning the schema lacks: output units ('shares are fractions of 1; change, bounce_rate and average_percent whole percentages'), the cross-parameter limit-times-trend constraint, and the default ranking rules. It stops short of exhaustively explaining every one of the 17 parameters.

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?

It names a specific verb and resource — the values of one dimension over a range, most first, each with count, share and the filter that narrows to it — which is a distinct artifact from get_site_summary's totals. An agent can tell this is the per-dimension breakdown tool without opening the schema.

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?

It routes the agent to get_site_summary for the conventions of site, range and filters ('which refuses the same things'), establishing the pairing. However it never states explicitly when to prefer this over get_site_summary or other siblings; the choice is left implicit in the phrase 'one of a site's panes'.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources