Ravenpost

Get analytics

get_analytics

Read-onlyIdempotent

Get one workspace's analytics overview: follower counts per connected account (plus a daily follower series for the last 30 days) and engagement on recent posts. A post's source says where it came from: "ravenpost" for one published from here, "platform" for one already on the account and imported so its engagement counts too. An account's followers is null when we collect none for its platform — today TikTok, X, Telegram, LinkedIn, Threads and YouTube, whose APIs either expose no insights or need a permission that is not approved yet (or, for X, charge for every read, so we read none and its numbers are in its own app) — so null means "unknown", never zero. Likewise a post metric that is absent was not collected rather than being 0.

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

Input Schema

Name	Required	Description	Default
`workspaceId`	No	Which workspace to act in — an id from list_workspaces. Optional with a single workspace; REQUIRED once there are several, where guessing would mean posting one client's content to another client's accounts. Ask the user which one before publishing.

Output Schema

Name	Required	Description	Default
`posts`	No
`accounts`	No
`collectedAt`	No
`trackedPosts`	No
`totalFollowers`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 1, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower; the description nonetheless adds real interpretive context — that null followers means 'unknown, never zero', which platforms return null and why (no insights API, unapproved permission, X's per-read pricing), and that an absent post metric was not collected rather than being 0. It does not address data freshness, caching, or result size, which keeps it short of a 5.

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?

Purpose and scope are front-loaded in the first sentence, and the following sentences carry genuinely non-obvious semantics. The parenthetical platform list for null followers is long and slightly sprawling, but it earns its space by explaining why each platform is missing rather than just naming them.

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?

With an output schema present, the description needn't document return structure, and it correctly spends its budget on the interpretation caveats a schema cannot express. For a single-parameter, read-only analytics tool this is close to sufficient; only freshness/caching expectations are missing.

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?

There is a single parameter with 100% schema description coverage, and the schema field already explains the optional-vs-required workspace rule. The description adds nothing further about workspaceId, so baseline 3 applies.

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?

States a concrete verb and resource ('Get one workspace's analytics overview') and enumerates the contents: follower counts per connected account, a 30-day daily series, and engagement on recent posts. No sibling tool covers analytics, so the scope is unambiguous on its own.

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 implied by the content description (you come here to read follower/engagement numbers), but there is no explicit when-to-use framing, no mention of prerequisites such as needing connected accounts, and no routing away from any alternative. The workspaceId schema text does supply the multi-workspace decision rule, but that lives in the schema, not the description.

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

All Ravenpost 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.