sprkly

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 likes and comments only, and Threads and Facebook produce no metrics at all, so read coverage before comparing platforms.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`days`	No	How many days back to analyse. Default 30.
`profile_ids`	No	Limit to these accounts. Omit for every account this connection can see.

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the `readOnlyHint: true` annotation, the description discloses nuanced behavior: recommendations carry sample counts, percentages include base totals, `topPosts` is ranked only within platform groups, and platform metric coverage varies (Instagram likes/comments only; Threads/Facebook no metrics). This is exactly the kind of contextual behavior an agent needs and goes well beyond the annotations.

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?

The description is dense but all sentences carry substantive caveats. It is somewhat run-on and would benefit from bulleted structure, but the front-loaded purpose sentence and focused details keep it usable.

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?

With no output schema, the description does the heavy lifting: it names the key result fields (`samples`, `topPosts`, `relativeToPlatformBest`, `coverage`, `value`, `metric`) and explains grouping/ranking and comparability constraints. This is sufficient for an agent to know what to expect and how to interpret results.

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?

Input schema coverage is 100%, so the schema already describes `days` and `profile_ids` adequately. The description does not add new parameter-level semantics such as defaults or interaction effects, so it earns the baseline 3.

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 opens with a specific verb-plus-resource statement: "How the user's published posts actually performed" followed by a concrete list of outputs (total views, engagement, period-over-period changes, best posting hour, weekday, category, top posts). This clearly distinguishes it from sibling tools like get_account_summary or get_post_status.

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?

The description provides clear context for when the tool is useful and how to interpret it, e.g., quoting `samples` for thin evidence and reading `coverage` before comparing platforms. It does not explicitly name alternatives or when-not-to-use conditions, but the scope ('published posts') implies appropriate use.

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

All sprkly tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0

Disambiguation5/5

Every tool targets a distinct action and resource: media ingestion, draft creation, scheduling, deleting, updating, validation, approval, analytics, and account/profile listing. The only slight overlap is between sprkly_list_profiles and sprkly_list_scheduled_posts, but they serve clearly different purposes (target selection vs. queue view).

Naming Consistency5/5

All 16 tools follow the exact sprkly_verb_noun pattern with lowercase snake_case. Verbs are consistent (add, delete, draft, get, list, request, schedule, update, validate) and nouns are clear (media, scheduled_post, account_summary, analytics, profiles, etc.). No style mixing or vague naming.

Tool Count4/5

16 tools is slightly above the typical 3–15 sweet spot but each tool covers a distinct part of the content-scheduling lifecycle. The count feels justified given the breadth of features (media, drafts, scheduling, approvals, analytics), though a few tools could be merged (e.g., get_account_summary could be part of analytics) without much loss.

Completeness4/5

The surface covers the core workflows well: draft, schedule, update, delete, approve, validate, and analyze. Minor gaps exist—there's no explicit tool to list drafts or edit a draft after submission, and no direct way to unpublish or cancel an approval—but the domain is well-served for typical scheduling needs.

Resources

Need Help?