sprkly-mcp

Get post performance

sprkly_get_analytics

Read-only

How the user's published posts actually performed: total views and engagement, week-on-week / month-on-month / year-on-year change, their best posting hour, weekday and content category, and the top posts behind those numbers. Every recommendation carries a samples count: say how thin the evidence is rather than presenting a one-post pattern as a finding. Every period-on-period percentage carries the post counts and raw totals it came from: quote those, because a big percentage off a tiny base is not a big change. topPosts is grouped by platform and ranked only inside each group; relativeToPlatformBest compares a post with others on its OWN platform and never across platforms, so use the absolute value and its metric label to weigh one platform against another. Instagram contributes reach, saves, shares and views only for accounts connected or reconnected with the insights permission, and likes and comments only for the rest. X contributes views, likes, replies, reposts and bookmarks, read twice for each post: about a day after it goes out and about a week after. Bluesky contributes likes, replies and reposts, never views. Facebook reports reactions and shares for posts made with sprkly, plus comments once Meta allows it for the Page, and views and reach only for accounts that granted insights access. Threads reports nothing until the account grants insights access. LinkedIn and Telegram report no numbers yet. Read coverage before comparing platforms, and never rank platforms on a metric one of them lacks. Each top post also carries reach, views, saves and shares (null where the platform or the connection does not share that number, absent when the plan does not include saves and shares) and vsUsual: that post against the median of the same account's other posts, per metric, so you can say "3x your usual views". There is no count of followers gained per post: never credit a follow to a post. findings are computed from these numbers; use them as a starting point and check them against the data.

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": "sprkly_get_analytics"
  }
}

Input Schema

Name	Required	Description
`days`	No	How many days back to analyse. Default 30. Free plans read at most 30 days; paid plans read up to 730.
`limit`	No	Most top posts to return across all platforms. Default 12. Each platform still shows at most 5.
`profile_ids`	No	Limit to these accounts. Omit for every account this connection can see.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 26, 2026

addedInput schema / properties / limit

Added value: +{
+  "default": 12,
+  "description": "Most top posts to return across all platforms. Default 12. Each platform still shows at most 5.",
+  "maximum": 30,
+  "minimum": 1,
+  "type": "integer"
+}

Changed2 schema fields changedOct 14, 2026

changedInput schema / properties / days / description

Previous value: -"How many days back to analyse. Default 30."New value: +"How many days back to analyse. Default 30. Free plans read at most 30 days; paid plans read up to 730."

changedInput schema / properties / days / maximum
```
Previous value: -365New value: +730
```

First observedAug 21, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations only declare readOnly/openWorld=false/non-destructive; the description goes far beyond that with genuinely load-bearing behavior: per-platform metric availability (Instagram insights permission, X read twice at ~1 day and ~1 week, Bluesky never reports views, Threads reports nothing until insights access, LinkedIn/Telegram report nothing), null-versus-absent semantics for saves and shares tied to plan, and the explicit absence of follower-gained counts. It also explains data-quality mechanics — the `samples` count, raw totals behind percentages, grouping and ranking scope of `topPosts` — which no annotation could convey.

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?

One long but deliberately front-loaded block: the first sentence states what the numbers are, and each subsequent sentence is a distinct caution (thin samples, tiny bases, cross-platform ranking, permission-dependent coverage, missing metrics). Nothing restates the schema or the title. Density is high but no sentence is filler.

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 a zero-required-parameter analytics tool with no output schema, the description does the work the missing output schema would otherwise do: it names the returned fields (`coverage`, `topPosts`, `relativeToPlatformBest`, `vsUsual`, `value`+`metric`, `findings`, `samples`) and states how each should be read. An agent can call it and interpret the response correctly without further documentation.

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 100%, and the schema already documents `days` (including the 30/730 free-vs-paid cap), `limit` (default 12, and the per-platform cap of 5), and `profile_ids`. The description adds no parameter-level syntax, format, or edge-case meaning beyond that. Baseline 3 is appropriate where the schema carries the parameter burden entirely.

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 clause names the resource precisely ("How the user's published posts actually performed") and enumerates the metric families returned: views and engagement, period-on-period change, best hour/weekday/category, and top posts. It is clearly a read-analytics tool, distinguishable in kind from the posting/automation siblings. It does not, however, differentiate itself from adjacent read tools such as sprkly_get_engagement_summary or sprkly_get_audience, so an agent must infer which analytics surface to pick.

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?

Guidance is abundant but almost entirely about how to interpret the results once returned ("Read `coverage` before comparing platforms", "quote those" counts, "never credit a follow to a post"), not about when to choose this tool over a sibling. There is no explicit "use this when you want X; use Y otherwise" routing, and no stated prerequisite such as needing connected accounts with insights permissions before the call is worthwhile. Usage is implied by the topic rather than selected by the text.

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

All sprkly-mcp 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?