Skip to main content
Glama

Site breakdown

get_site_breakdown
Read-onlyIdempotent

One of a site's panes in full, as its view on the dashboard has it, where it has one: 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

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.
sortNoUnder a goal filter, for a site sent revenue: revenue or revenue_per_visit reranks the first 1000 values by it. No trend.
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. form: forms sent, by page, and " → " and the host where sent to another site. call and email: tel: and mailto: links clicked. script_error: the scripts' errors, as message, file:line and page, a line each, with an id get_script_error takes. 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. Changed1 schema field changed
    • changedInput schema / properties / dimension / description
      Previous value: -"The 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. form: forms sent, by page, and \" → \" and the host where sent to another site. call and email: tel: and mailto: links clicked. script_error: the site's scripts' errors, as message, file:line and page, a line each. 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."New value: +"The 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. form: forms sent, by page, and \" → \" and the host where sent to another site. call and email: tel: and mailto: links clicked. script_error: the scripts' errors, as message, file:line and page, a line each, with an id get_script_error takes. 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."
  2. Changed2 schema fields changed
    • changedInput schema / properties / dimension / description
      Previous value: -"The 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."New value: +"The 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. form: forms sent, by page, and \" → \" and the host where sent to another site. call and email: tel: and mailto: links clicked. script_error: the site's scripts' errors, as message, file:line and page, a line each. 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."
    • changedInput schema / properties / dimension / enum
      Previous value: -[
      -  "path",
      -  "folder",
      -  "entry",
      -  "exit",
      -  "channel",
      -  "source",
      -  "referrer",
      -  "country",
      -  "city",
      -  "asn",
      -  "utm_medium",
      -  "utm_campaign",
      -  "utm_content",
      -  "utm_term",
      -  "goal",
      -  "device",
      -  "browser",
      -  "os",
      -  "outbound",
      -  "download",
      -  "searches",
      -  "error",
      -  "time_on_page",
      -  "scroll_depth",
      -  "slowest_lcp",
      -  "slowest_inp",
      -  "property",
      -  "event_data"
      -]New value: +[
      +  "path",
      +  "folder",
      +  "entry",
      +  "exit",
      +  "channel",
      +  "source",
      +  "referrer",
      +  "country",
      +  "city",
      +  "asn",
      +  "utm_medium",
      +  "utm_campaign",
      +  "utm_content",
      +  "utm_term",
      +  "goal",
      +  "device",
      +  "browser",
      +  "os",
      +  "outbound",
      +  "download",
      +  "form",
      +  "call",
      +  "email",
      +  "searches",
      +  "error",
      +  "script_error",
      +  "time_on_page",
      +  "scroll_depth",
      +  "slowest_lcp",
      +  "slowest_inp",
      +  "property",
      +  "event_data"
      +]
  3. Changed1 schema field changed
    • changedInput schema / properties / range / enum
      Previous value: -[
      -  "today",
      -  "yesterday",
      -  "this-week",
      -  "this-week-sun",
      -  "last-7-days",
      -  "last-week",
      -  "last-week-sun",
      -  "last-14-days",
      -  "this-month",
      -  "last-30-days",
      -  "last-month",
      -  "all-time"
      -]New value: +[
      +  "today",
      +  "yesterday",
      +  "this-week",
      +  "this-week-fri",
      +  "this-week-sat",
      +  "this-week-sun",
      +  "last-7-days",
      +  "last-week",
      +  "last-week-fri",
      +  "last-week-sat",
      +  "last-week-sun",
      +  "last-14-days",
      +  "this-month",
      +  "last-30-days",
      +  "last-month",
      +  "all-time"
      +]
  4. Changed1 schema field changed
    • addedInput schema / properties / sort
      Added value: +{
      +  "description": "Under a goal filter, for a site sent revenue: revenue or revenue_per_visit reranks the first 1000 values by it. No trend.",
      +  "enum": [
      +    "conversions",
      +    "revenue",
      +    "revenue_per_visit"
      +  ],
      +  "type": "string"
      +}
  5. First observed

TDQS

A4/5.0
Behavior5/5

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

Goes well beyond the read-only annotations: documents refusals such as compare for all time and metric for single-count panes, trend's 1000-cell cap, pagination fields, case sensitivity of search, filter exclusion returning available:false, and caveats that must be relayed. This is exactly the extra behavioral context the annotations do not supply.

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?

Information-dense but delivered as one long, clause-heavy paragraph with no structure; several sentences are hard to parse on first read. The length is justified by tool complexity, but formatting and front-loading could be much better.

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 an 18-parameter tool with no output schema, the description covers the return shape (count, share, filter, pagination, comparison fields), the special dimensions, and failure modes. Remaining details are delegated to get_site_summary, which is acceptable given the shared semantics.

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 carries most parameter definitions. The description still adds useful input semantics not in the schema, such as trend's limit-times-count constraint and compare being refused for all time, though much of the prose restates enum and default information already present.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States that the tool returns the values of one dimension over a range, most frequent first, each with its count, share, and narrowing filter, and distinguishes the pane concept from get_site_summary. The opening 'one of a site's panes' is jargon-heavy and not as front-loaded as it could be, but the resource and output are clear.

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?

Implies use for a single-dimension breakdown and points to get_site_summary for shared range and filter semantics, plus get_script_error for error ids. It never explicitly says when to choose this tool over get_site_summary or other siblings, so the guidance is inferred rather than stated.

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