Antwork

list_social_accounts

Read-only

The workspace's connected social accounts: the ids account_id takes.

One entry per active connection: id, platform, name, handle, token health and a reauthUrl that refreshes its OAuth token. platformHold (with advice) means the platform is holding a working connection, e.g. an Instagram checkpoint: its posts fail until the owner acts in the platform's app, and reconnecting does not help. Accounts waiting on payment are listed apart in pendingPaymentAccounts; accounts paused above the plan's account limit in pausedAccounts, with the chooseActiveUrl where the owner picks which stay active. Connecting a new account is get_connection_urls.

followers is the latest daily count (count, asOf) and its net change since changeSince over the last 30 days; a null count comes with a state/reason (e.g. awaiting_permission), never a 0. connectAttempts: the last day's latest connect per platform (outcome, reason, nextStep).

Args: workspace_id: Workspace ID or name. Optional if user has only one workspace.

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

Input Schema

Name	Required	Description
`context`	No	The user's underlying goal for this call, in one sentence without personal details. Used for product analytics only.
`llm_model`	No	The model identifier of the calling assistant, or "unknown". Used for product analytics only.
`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 changedOct 26, 2026

changedInput schema / required

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

First observedOct 22, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, and the description goes well beyond that by explaining the meaning of edge states: `platformHold` means posts fail until the owner acts and reconnecting will not help, pending-payment and over-limit accounts appear in separate buckets, and a null follower count always carries a state/reason rather than 0. That is genuinely useful behavioral context an agent could otherwise misread as an error or a zero.

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?

Purpose is front-loaded in the first line and the remaining paragraphs are organized by response bucket rather than rambling. It is dense and leans heavily on response-field explanation that partially duplicates the output schema, which keeps it from being maximally tight, but no sentence is filler.

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?

With an output schema present, the description need not enumerate return fields, yet it supplies the interpretive layer (null counts, held platforms, paused/pending buckets) that makes those fields actionable. The only gap is operational: nothing about ordering, volume of accounts, or whether results can be paginated for very large workspaces.

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 75%, so most parameters are self-documented, and the description adds real meaning for the one that matters: `workspace_id` accepts an ID or a name and is optional when the user has a single workspace. The analytics-only parameters (context, llm_model, conversation_id) are left entirely to the schema, which is appropriate.

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 specific verb-and-resource statement ('The workspace's connected social accounts') and immediately states the practical purpose — supplying the ids that `account_id` takes. It also names the sibling that does the different job (get_connection_urls for connecting new accounts), so an agent can separate the two without inspecting schemas.

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?

Use is clearly implied and reinforced by 'the ids `account_id` takes', which tells the agent this is the lookup step before any per-account call, and it explicitly routes account creation to get_connection_urls. It stops short of explicit when-not guidance (e.g. it never says not to call this repeatedly for cached ids), so it is clear context without full exclusions.

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.