AdaptlyPost

Official

by adaptlypost

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

List Connected Accounts

list_accounts

Read-only

Retrieve all social media accounts linked to your workspace, including platform, username, and account ID for use in posting operations.

Instructions

List the social accounts connected to the token's workspace across all nine platforms. Returns { accounts } with id, platform, displayName, username, avatarUrl, and pageId for Facebook pages. Call this before create_post, update_post, or bulk_schedule_posts: they take these ids, never usernames. Put each id in the array for its platform (linkedinConnectionIds, tiktokConnectionIds, and so on); Facebook page accounts go in pageIds. Not for post history or publishing status: use list_posts or list_post_results for those. Takes no arguments.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	No	An object with accounts: one { id, platform, displayName, username, avatarUrl } per connected account, plus pageId for Facebook pages. Use id as the connection id (or in pageIds for Facebook).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.1.1Sep 7, 2026

changedOutput schema / properties / result / description

Previous value: -"The connected social accounts with their platform, connection ID, username, and pageId for Facebook pages as returned by the AdaptlyPost API."New value: +"An object with accounts: one { id, platform, displayName, username, avatarUrl } per connected account, plus pageId for Facebook pages. Use id as the connection id (or in pageIds for Facebook)."

First observedv0.1.0Sep 7, 2026

TDQS

A4.7/5.0

Behavior4/5

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

The description clearly states it takes no arguments and returns a read-only list of accounts, aligning with the readOnlyHint annotation. It doesn't mention potential throttling or data pagination, but no destructive or side-effect behavior is hidden; annotation and description are consistent.

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

Conciseness5/5

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

The description is compact and well-structured: it states the result, the key usage imperative, the alternative for other use cases, and the no-arguments fact. Every sentence adds necessary guidance without redundancy.

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?

Given the empty schema and no parameters, the description covers everything an agent needs: what it returns, when to call it, how to use the IDs, and which sibling tools handle related but different tasks. The output schema likely provides the return structure, so no further detail is needed here.

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?

The tool has zero parameters and the schema already reflects that with an empty properties object. The description reinforces 'Takes no arguments,' so there is no missing parameter guidance; a small deduction because no mention of output schema details, but that's not parameter semantics.

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?

Clearly states the tool lists social accounts connected to the workspace across all nine platforms, and enumerates the returned fields. It also contrasts with related tools for posting and analytics, making its purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to call this before create_post, update_post, or bulk_schedule_posts to obtain IDs, and tells which ID arrays to use for each platform. It also directs users to list_posts or list_post_results for post history/publishing status, leaving no ambiguity about when to use this tool.

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

Deploy Server