Skip to main content
Glama
Sign In

Simplo

by ai.getsimplo
OverviewDiscussionsAdmin

Get post metrics

get_post_metrics
Read-only

How the published posts did: one row per post and platform with views, reach, likes, comments, shares, saves and profileVisits as the platform reports them (a number it doesn't report is left out: Instagram reports profileVisits for feed posts and carousels, never for Reels), engagement (likes + comments + shares + saves), and lastSyncedAt. Each row also says what the post was made as: postType (single, carousel, video), style (the carousel style its slides were drawn in, if any) and durationSeconds (a video's length). The numbers are read live from Instagram, TikTok and X on every call, as the Analytics page does. A row with error could not be read this time (the account needs a reconnect, or TikTok has not given the video an id yet); its numbers are the last good ones. overview totals the posts Simplo published in the range. With groupBy (postType or style), overview.groups breaks it down: per format or carousel style, postCount (rows), totals and medians of each number over the rows that reported it, over every row in the range and not only the ones returned (style "none" holds pictures, videos and plain slides). Compare medians: one big post skews totals. With includeOutside: true, outside also lists the posts on the connected accounts that Simplo did not publish (made in the platform's app or another tool), with their numbers, sorted and limited the same way; they have a platformPostId and url instead of a postId. outside.accounts says which accounts were read and why any could not be (read: false with a reason, such as a reconnect; only Instagram and TikTok are read). On TikTok, unmatchedSimploPosts counts Simplo posts TikTok has not given a video id yet, which may appear among the outside posts. Use it before planning to see what worked: sort by engagement or reach, and pass includeOutside to count every post on the account; order: "asc" lists the posts that did worst first. Follower counts are in get_account_summary.

Input Schema

NameRequiredDescriptionDefault
daysNoPosts published in the last 7, 30 or 90 days
sortNorecent (newest first), engagement, reach or views (highest first)recent
limitNoRows to return (and outside rows, separately)
orderNodesc (highest or newest first) or asc (lowest or oldest first: the posts that did worst); rows without the number come last either waydesc
postIdNoOnly this post (published within days)
groupByNoBreak the overview down by postType (carousels against Reels and pictures) or style (one carousel style against another)
platformNoOnly this platform
projectIdYesSimplo project id (from list_projects)
includeOutsideNoAlso list the posts on the accounts that Simplo did not publish

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / order
      Added value: +{
+  "default": "desc",
+  "description": "desc (highest or newest first) or asc (lowest or oldest first: the posts that did worst); rows without the number come last either way",
+  "enum": [
+    "desc",
+    "asc"
+  ],
+  "type": "string"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / groupBy
      Added value: +{
+  "description": "Break the overview down by postType (carousels against Reels and pictures) or style (one carousel style against another)",
+  "enum": [
+    "postType",
+    "style"
+  ],
+  "type": "string"
+}
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond readOnlyHint/openWorldHint: it discloses that numbers are read live from Instagram, TikTok and X on every call, that error rows carry last-good numbers when an account needs reconnecting or TikTok has no video id yet, that only Instagram and TikTok outside accounts are read, and that TikTok may double-count unmatchedSimploPosts. These are exactly the failure modes an agent needs before trusting the output.

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?

Dense but essentially waste-free — nearly every clause adds a fact that is unavailable in the schema, and the payload shape is front-loaded before the grouping and outside-post semantics. The single unbroken paragraph makes it hard to scan for a 9-parameter tool, which is the main structural cost.

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 and nine parameters, the description carries the full burden and does so: it defines the row shape, the overview/group breakdown, outside-account behavior, per-platform reporting quirks and error semantics. An agent can call this correctly and interpret the result without further documentation.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: groupBy medians/totals are computed over every row in the range rather than only returned rows, style 'none' holds pictures, videos and plain slides, and includeOutside rows expose platformPostId and url instead of postId. The days/postId interaction ('published within days') is left implicit.

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?

Opens with a concrete verb and resource — 'How the published posts did: one row per post and platform' — and immediately enumerates the metrics returned (views, reach, likes, comments, shares, saves, profileVisits, engagement, lastSyncedAt). It also distinguishes itself from get_account_summary by routing follower counts there, so an agent can separate it from a nearby reporting tool.

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?

Gives an explicit usage scenario: 'Use it before planning to see what worked: sort by engagement or reach, and pass includeOutside to count every post on the account', plus the meaning of order=asc. What is missing is any contrast with sibling listing tools (list_posts, get_post) — an agent must infer when to fetch metrics versus plain post data.

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

All Simplo toolsInspect
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