Skip to main content
Glama

Get Content Performance

get_content_performance
Read-onlyIdempotent

Reports how content performed over a period, the numbers Performance › Social shows: performance.rows, one per pillar plus No pillar and Total, each with its posts in postRows. impressions and engagement are what each social post gained on days in the period, wherever it was published, so an older post still gaining counts (its postRows entry has publishedBeforeRange true); clicks are tracked-link clicks in the period. pageviews is a blog, FAQ or competitor page's views on the period's days, from the site tag in PostHog, from every country even with marketId, each day counted once it's over in the workspace time zone; 0 for social posts and without PostHog; a row whose posts are all social reads 0, which the app shows as n/a since social posts have no pageviews. posts counts posts published in the period, measured those with a gain dated in it, or for a website post Search numbers or a pageview day in it; an older website post with pageviews in the period is listed with publishedBeforeRange true. performance.daily is every day of the period with the impressions and engagement social posts gained on it, 0 on a day with none (blog Search numbers are only in the rows). previous has each row's impressions, engagement, clicks and pageviews, and its daily, for the same number of days just before. Mark reads a post daily to day 30, then weekly to day 90, and spreads a gain evenly over the days between readings; posts read only at day 1 and day 7 show nothing after day 7. A blog or other website post's impressions and clicks are Google Search's for its page in the period, from Search Console (with marketId, only searches from that market's country when it is an ISO code, as get_performance_overview and Performance › Search filter), with no engagement; KPI actuals leave them and pageviews out. kpis is the Targets page (/targets): every KPI target with its month (YYYY-MM), target, actual and progressPercent, computed the same way the page does. Impressions and engagement_rate actuals are what social posts gained on days in the target's month, wherever they were published, the same as performance for that month without blog Search numbers; posts_per_week counts posts published in it and leads those created in it; all in the workspace time zone; it ignores from, to, pillarId and marketId. period is past, current (actual so far) or not_started (actual null). When there is no number, actual is { note } with the reason, such as a metric Mark doesn't track yet. engagement_rate values are percents (4.5 means 4.5%). Does not change anything. Related: save_strategy_item (kind kpi_target), delete_strategy_item, get_search_performance, get_calendar, search_posts.

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_content_performance"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoRange end YYYY-MM-DD.
fromNoRange start YYYY-MM-DD. Defaults to the last 28 settled days.
marketIdNoFilter to one market's posts; website posts' Search numbers filter to its country.
pillarIdNoFilter to one pillar.

Output Schema

NameRequiredDescriptionDefault
kpisYes
appUrlYes
previousYes
performanceYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / marketId / description
      Previous value: -"Filter to one market."New value: +"Filter to one market's posts; website posts' Search numbers filter to its country."
  2. Changed2 schema fields changed
    • addedOutput schema / properties / previous / properties / rows / items / properties / pageviews
      Added value: +{
      +  "type": "number"
      +}
    • changedOutput schema / properties / previous / properties / rows / items / required
      Previous value: -[
      -  "clicks",
      -  "engagement",
      -  "impressions",
      -  "key",
      -  "label"
      -]New value: +[
      +  "clicks",
      +  "engagement",
      +  "impressions",
      +  "key",
      +  "label",
      +  "pageviews"
      +]
  3. Changed2 schema fields changed
    • addedOutput schema / properties / previous
      Added value: +{
      +  "additionalProperties": false,
      +  "properties": {
      +    "daily": {
      +      "items": {
      +        "additionalProperties": false,
      +        "properties": {
      +          "date": {
      +            "type": "string"
      +          },
      +          "engagement": {
      +            "type": "number"
      +          },
      +          "impressions": {
      +            "type": "number"
      +          }
      +        },
      +        "required": [
      +          "date",
      +          "engagement",
      +          "impressions"
      +        ],
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "from": {
      +      "type": "string"
      +    },
      +    "rows": {
      +      "items": {
      +        "additionalProperties": false,
      +        "properties": {
      +          "clicks": {
      +            "type": "number"
      +          },
      +          "engagement": {
      +            "type": "number"
      +          },
      +          "impressions": {
      +            "type": "number"
      +          },
      +          "key": {
      +            "type": "string"
      +          },
      +          "label": {
      +            "type": "string"
      +          }
      +        },
      +        "required": [
      +          "clicks",
      +          "engagement",
      +          "impressions",
      +          "key",
      +          "label"
      +        ],
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "to": {
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "daily",
      +    "from",
      +    "rows",
      +    "to"
      +  ],
      +  "type": "object"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "appUrl",
      -  "kpis",
      -  "performance"
      -]New value: +[
      +  "appUrl",
      +  "kpis",
      +  "performance",
      +  "previous"
      +]
  4. Changed4 schema fields changed
    • addedOutput schema / properties / kpis / additionalProperties
      Added value: +false
    • addedOutput schema / properties / kpis / properties
      Added value: +{
      +  "appUrl": {
      +    "type": "string"
      +  },
      +  "currentMonth": {
      +    "type": "string"
      +  },
      +  "targets": {
      +    "items": {
      +      "additionalProperties": false,
      +      "properties": {
      +        "actual": {
      +          "anyOf": [
      +            {
      +              "anyOf": [
      +                {
      +                  "additionalProperties": false,
      +                  "properties": {
      +                    "value": {
      +                      "type": "number"
      +                    }
      +                  },
      +                  "required": [
      +                    "value"
      +                  ],
      +                  "type": "object"
      +                },
      +                {
      +                  "additionalProperties": false,
      +                  "properties": {
      +                    "note": {
      +                      "type": "string"
      +                    }
      +                  },
      +                  "required": [
      +                    "note"
      +                  ],
      +                  "type": "object"
      +                }
      +              ]
      +            },
      +            {
      +              "type": "null"
      +            }
      +          ]
      +        },
      +        "id": {
      +          "type": "string"
      +        },
      +        "label": {
      +          "type": "string"
      +        },
      +        "metric": {
      +          "type": "string"
      +        },
      +        "month": {
      +          "type": "string"
      +        },
      +        "period": {
      +          "enum": [
      +            "past",
      +            "current",
      +            "not_started"
      +          ],
      +          "type": "string"
      +        },
      +        "progressPercent": {
      +          "type": [
      +            "number",
      +            "null"
      +          ]
      +        },
      +        "target": {
      +          "type": "string"
      +        }
      +      },
      +      "required": [
      +        "actual",
      +        "id",
      +        "label",
      +        "metric",
      +        "month",
      +        "period",
      +        "progressPercent",
      +        "target"
      +      ],
      +      "type": "object"
      +    },
      +    "type": "array"
      +  }
      +}
    • addedOutput schema / properties / kpis / required
      Added value: +[
      +  "appUrl",
      +  "currentMonth",
      +  "targets"
      +]
    • addedOutput schema / properties / kpis / type
      Added value: +"object"
  5. First observed

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already cover the read-only, idempotent, non-destructive profile, and the description adds substantial behavior beyond them: period-based attribution rules, that older posts still gaining are included, pageview counting per settled day in workspace time zone, Mark's reading cadence and gain spreading, and that kpis ignores from/to/pillarId/marketId. That is real disclosure; credit is capped slightly because much of the text describes return shape rather than call-time behavior.

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

Conciseness2/5

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

The purpose is front-loaded, but the body is two dense walls of prose mixing output layout, attribution logic, and KPI computation without structure. Several clauses (e.g. the n/a explanation for social rows) restate output-schema detail and could be cut, making it hard for an agent to scan for the actionable parts.

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?

Given a read-only analytics tool with 4 optional parameters and an existing output schema, the definition covers almost everything needed to call it correctly, including time-zone and settled-day semantics and edge cases like missing-actual notes. It over-explains returns that the output schema already defines, while the only real gap is explicit routing guidance against the sibling performance tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/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. The description adds some genuine meaning beyond the schema, notably that marketId narrows website posts' Search numbers to that market's country and that kpis ignores all four parameters, but it gives no default or format guidance for from/to and pillarId beyond what the schema states.

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?

The opening sentence states a specific verb and resource ('Reports how content performed over a period') and anchors it to a named product surface ('the numbers Performance › Social shows'). It is clear what the tool returns, though differentiation from sibling tools like get_search_performance is only partial and buried in the body rather than stated up front.

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?

Usage is only implied: you call it for content performance and KPI actuals, and it 'Does not change anything.' The related-tools list names siblings without saying which condition selects this tool over get_performance_overview or get_search_performance, so an agent must infer the choice.

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