Skip to main content
Glama

OpenPanel: Get top pages

openpanel_get_top_pages
Read-only

Retrieves top pages by view count from OpenPanel Insights for a specified site and date range, helping identify high-traffic content.

Instructions

[UNIFIED] Get top pages by view count via Insights API.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "site": "<site>"
    },
    "name": "openpanel_get_top_pages"
  }
}

Input Schema

NameRequiredDescriptionDefault
siteYes
limitNo
date_rangeNo30d
project_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.14.0
  2. Removedv3.13.1
  3. First observedv3.4.0

TDQS

C2.6/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true, so safety is covered, and the description adds only that data comes from the Insights API. It says nothing about ordering guarantees, tie-breaking, pagination, or how "top" is bounded, which is what would add value beyond the annotation.

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

Conciseness4/5

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

A single front-loaded sentence with no wasted clauses, which is appropriate for the amount of content present. The brevity is efficient rather than padded, though it edges toward under-specification.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with four undocumented parameters and no output schema, the description is far too thin to guide correct invocation. Nothing explains what a valid site or project_id looks like, or what the response contains beyond an implied ranked list of pages.

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

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across four parameters, so the description carries the full burden and fails: site, limit, date_range, and project_id get no explanation of format or meaning. An agent cannot tell whether date_range accepts "30d", ISO dates, or timestamps from the definition alone.

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 description states a specific verb and resource ("Get top pages") plus the ranking metric ("by view count") and the underlying API ("Insights API"). It is clear what the tool returns, though it does not explicitly contrast itself with siblings such as openpanel_get_page_views or openpanel_get_top_referrers.

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

Usage Guidelines2/5

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

There is no statement of when to use this tool versus alternatives like openpanel_get_page_views or openpanel_get_overview_report. Usage is only implied by the name and the phrase "top pages by view count," leaving the agent to infer the selection criteria.

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

Deploy Server

Other Tools