postnext

Mini site analytics

get_mini_site_analytics

Read-only

Performance of a bio page: LIFETIME totals for views, clicks, best-performing links, visitor source/device/country and AI-crawler reads, plus which published posts drove clicks (post-to-click attribution) over a configurable recent window. Every figure except the attribution rows is an all-time counter, not a windowed one — say so when reporting numbers. Omit siteId when the team has exactly one site.

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

Input Schema

Name	Required	Description	Default
`siteId`	No
`attributionDays`	No

Output Schema

Name	Required	Description	Default
`ai`	Yes
`byDevice`	Yes
`bySource`	Yes
`topLinks`	Yes
`byCountry`	Yes
`attribution`	Yes
`viewsAllTime`	Yes
`clicksAllTime`	Yes
`attributionWindowDays`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 2, 2026
- removedOutput schema / $schema
```
Removed value: -"http://json-schema.org/draft-07/schema#"
```
First observedSep 22, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare read-only, non-destructive, closed-world behavior, so the description's main burden is to disclose non-obvious semantics. It does this strongly by warning that every figure except the attribution rows is an all-time counter rather than a windowed metric and instructing the agent to say so when reporting numbers.

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

Conciseness5/5

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

The description is front-loaded with the tool's purpose and uses three sentences without filler. The long first sentence is dense but every clause adds necessary metric-scope information, and the lifetime-vs-windowed caveat is placed prominently.

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 the output schema and annotations, the description is largely complete: it explains what the tool reports, the key lifetime-counter caveat, and the single-site siteId omission rule. The main remaining gap is that attributionDays is not explicitly named or bounded in the prose, though those constraints are present in the schema.

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 description coverage is 0%, so the description must carry parameter meaning. It explains the optional siteId case and frames attribution as a configurable recent window, but it does not name attributionDays, its default of 30, or its 1–90 bound, leaving some important parameter semantics to the raw schema.

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 the specific resource (bio page / mini site) and enumerates the exact analytics returned: views, clicks, top links, visitor dimensions, AI-crawler reads, and post-to-click attribution. This is clearly distinguishable from siblings such as get_channel_analytics and get_post_metrics.

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 establishes a clear context for use: performance reporting for a bio page, including both lifetime totals and a configurable attribution window. It also gives one concrete operational rule for omitting siteId when the team has exactly one site, though it does not explicitly compare itself to sibling analytics tools.

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

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