Skip to main content
Glama
Sign In
Markaestro

Markaestro

Official
by markaestro
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Refresh analytics from the platforms

refresh_analytics
Destructive

Update stored analytics for authorized brands' connected social accounts by reading post metrics and follower counts, then save the latest readings in the private workspace.

Instructions

Refresh stored analytics only for the user's authorized brands and their already connected social accounts. Reads their post metrics and follower counts through those account integrations and stores the results in the private Markaestro workspace, replacing each post's latest stored reading (readings from earlier stages are kept). Cannot query arbitrary accounts, URLs, or public search, and does not publish or change social posts. Covers posts in the window (optionally one channel or one authorized brand) and today's follower counts. The answer says how many posts were updated and how many remain; a large window may take more than one refresh. Limited to a few calls a minute.

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

Input Schema

NameRequiredDescriptionDefault
daysNoWindow ending now; default 28
channelNo
productIdNoOne brand, on an all-brands connection

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.4.0
    • changedInput schema / properties / channel / enum
      Previous value: -[
-  "facebook",
-  "instagram",
-  "tiktok",
-  "threads",
-  "pinterest",
-  "linkedin",
-  "x"
-]New value: +[
+  "facebook",
+  "instagram",
+  "tiktok",
+  "threads",
+  "pinterest",
+  "linkedin",
+  "x",
+  "youtube"
+]
  2. First observedv0.3.3

TDQS

A4.6/5.0
Behavior5/5

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

Annotations declare destructiveHint=true and idempotentHint=false, and the description explains exactly what is destroyed and what survives: each post's latest stored reading is replaced while readings from earlier stages are kept. It also discloses rate limiting ('a few calls a minute'), partial-completion semantics ('a large window may take more than one refresh'), and what the response reports.

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?

Front-loaded with the scope constraint before the exclusions, and every sentence carries information. Some sentences pack several ideas (window scoping, follower counts, and response contents) into one line, making it denser than strictly necessary, but nothing is redundant.

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?

There is no output schema, and the description compensates by describing what the answer returns (posts updated vs. remaining). For a mutating, rate-limited, potentially partial tool it covers permissions scope, mutation effect, exclusions, and result shape — nothing an agent needs to call it correctly is missing.

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 67% and the description adds real meaning: filters are optional and mutually scoping (one channel or one authorized brand), and follower counts are always today's regardless of the window. It does not mention the 90-day maximum on days or the full channel enum, so it does not fully compensate for the uncovered portions of the 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?

States a specific verb and resource (refresh stored analytics) plus precise scope: only the user's authorized brands and already connected social accounts. It explicitly distinguishes itself from read-only siblings (get_analytics, list_post_analytics) by noting it rewrites stored readings, and explicitly rules out arbitrary accounts, URLs, and public search.

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 clear when-to-use context (refreshing stored post metrics and follower counts within a window, optionally narrowed to one channel or one brand) and explicit when-not conditions (no arbitrary accounts/URLs/public search, no publishing). It does not name the sibling tools an agent should pick instead for read-only access, which keeps it short of a 5.

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

Deploy Server

Other Tools