Antwork

get_performance

Read-only

How published posts are doing: one table per post, the per-day and follower tables, and findings.

rows: one per post Antwork published in the last days (posts made on the platform directly: fetch_platform_posts), with likes, comments, shares, impressions, reach, saves, clicks, bookmarks, linkClicks, profileVisits, follows, watchTimeSeconds, avgWatchTimeSeconds and totalEngagement (likes+comments+shares), plus platformTotals. impressions counts a different thing per platform, named by reachBasis, so different bases never add or compare; reach never adds. A null is a metric not measured or not reported, never a zero. coverage says what the numbers count (only posts published through Antwork, the window, posts not measured yet per platform, and per account notThroughAntwork when a stored read shows posts made elsewhere): quote it before comparing these totals with the platform or with daily. daily: engagement per (date, platform) plus an "all" row per date, and changeTotals, the window's daily growth summed (not lifetime); followers: per (date, account).

findings, computed from those numbers, in the workspace timezone: comparison (each platform against the previous window of equal length), ranking (top and bottom posts by engagement rate and the traits the top ones share, or enoughData: false), bestWindows (from the account's own posts, else labelled fallbacks), followers (change over the window), postAgainToday (the last and next 24 hours against the account's usual count and daily cap), growth (the posts that brought followers where the platform reports follows per post; growth.days on every platform: the stretches between follower counts that grew most, the posts in them, and growth with posts vs without, quoting its basis) and digest: the window as a report, with lines ready to show. A weekly or monthly report is days=7 or days=30 and its digest.

With post_id, that one post's per-day history instead (cumulative* and daily* columns); without days, its whole history.

format="table" answers only flat rows for a sheet or dashboard: per post (postId, account, platform, publishedAt, url, likes, comments, shares, impressions, reach, saves, clicks) and per account (followers, change).

Args: days: The window, ending today (1-365, default 30). platform: Restrict to one platform. account_id: Restrict to one connected account. post_id: One post's history instead of the workspace's. limit: Max post rows (default 30, max 50). workspace_id: Workspace ID or name. Optional if user has only one workspace. format: "table" for the compact rows above, nothing else.

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

Input Schema

Name	Required	Description
`days`	No
`limit`	No
`format`	No
`context`	No	The user's underlying goal for this call, in one sentence without personal details. Used for product analytics only.
`post_id`	No
`platform`	No
`llm_model`	No	The model identifier of the calling assistant, or "unknown". Used for product analytics only.
`account_id`	No
`workspace_id`	No
`conversation_id`	No	Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request.

Output Schema

Name	Required	Description	Default
`_mcp_instructions`	No	Server-issued metadata for this conversation.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 9, 2026

addedInput schema / properties / format

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Format"
+}

Changed5 schema fields changedOct 30, 2026

addedInput schema / properties / account_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Account Id"
+}

addedInput schema / properties / days / anyOf

Added value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / days / default
```
Previous value: -30New value: +null
```
removedInput schema / properties / days / type
```
Removed value: -"integer"
```

addedInput schema / properties / post_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Post Id"
+}

Changed1 schema field changedOct 26, 2026

changedInput schema / required

Previous value: -[
-  "context",
-  "llm_model"
-]New value: +[]

First observedOct 22, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly/destructive=false, so the safety profile is covered; the description instead discloses genuinely non-obvious data behavior — that `impressions` and `reach` are basis-dependent and must never be added across bases, that null means 'not measured' rather than zero, and that `coverage` limits what the totals count including `notThroughAntwork`. That is exactly the kind of caveat an agent needs before quoting numbers. It stops at 4 because no guidance is given on data freshness or the cost/latency of the call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The text is front-loaded and the caveats earn their place, but a large block enumerates returned columns (likes, comments, shares, impressions, reach, saves, clicks, bookmarks, linkClicks, profileVisits, follows, watchTimeSeconds...) and the exact `format="table"` column list, which duplicates what the output schema already declares. Dense backtick-heavy sentences with no headings by mode make it slow to scan for the branch an agent actually needs.

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?

For a 10-parameter analytics tool with an output schema, the definition covers the branches (workspace view, single-post history, table format), the metric caveats, and the derived `findings` structure including `enoughData: false` and fallback labelling. Since an output schema exists, the heavy return-value prose was not strictly required. Remaining gap is operational — nothing on refresh cadence or how stale the stored platform reads can be.

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 only 30%, so the description must compensate and largely does: it adds the 1-365 range and default for `days` (schema shows default null, no range), the max 50 for `limit`, the meaning of `post_id` overriding the workspace view and defaulting to whole history without `days`, and the exclusive behavior of `format`. Gaps remain for `workspace_id` resolution behavior beyond 'optional if user has only one workspace', and the three analytics-only params are left to the schema.

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 line names the resource and the shape of the answer ('How published posts are doing: one table per post, the per-day and follower tables, and `findings`'), which is specific enough to distinguish it from list_posts or fetch_platform_posts. It also clarifies the scope boundary that the row metrics only cover posts published through Antwork. It falls short of a 5 because the verb is implicit and the purpose statement is buried under a long return-value enumeration.

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?

Concrete usage scenarios are supplied: 'A weekly or monthly report is days=7 or days=30 and its `digest`', and 'format="table" answers only flat rows for a sheet or dashboard'. The post_id branch is scoped with a clear rule ('without `days`, its whole history'). It does not explicitly say when to prefer this over get_post or fetch_platform_posts, so the routing guidance is partial rather than complete.

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

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