PostRite

List connected platform accounts

list_platform_connections

Read-only

List the organization's connected social accounts, including any that are out of service. Use the returned connection IDs as platformConnectionIds when creating or updating a post — but not where health is INACTIVE, DISCONNECTED or EXPIRED — those need the account owner to reconnect first and the api rejects a post targeting them. EXPIRING is fine to post to: it means the authorization lapses within a few days and cannot renew itself, so the account owner should reconnect soon. PostRite renews every other connection's authorization automatically — HEALTHY and DEGRADED need nothing from the user, so do not warn about token expiry unless health says EXPIRING or EXPIRED. Instagram and TikTok connections carry metadata.authMethod, the way the account was connected (Instagram: instagram_login or facebook_login; TikTok: login_kit, or business_api for TikTok Business, which an absent value also means as login_kit) — it decides what a post to that account may use, e.g. TikTok drafts and a separate cover image exist only on business_api. X connections carry metadata.subscriptionType, the account's X subscription as X reports it (absent until PostRite has read it): Basic, Premium, PremiumPlus let a post to that account run past 280 characters, up to 25000 (see the X long-post rule in create_post).

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

Input Schema

Name	Required	Description	Default
`organizationId`	No	Organization to act in — an id from list_organizations. Required when this connection was authorized for more than one organization; omit it when there is only one.

Output Schema

Name	Required	Description	Default
`connections`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 5, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations only declare readOnly/destructive/openWorld, so the description carries the real burden and does so: it explains that no connections are filtered out, that PostRite auto-renews authorizations except EXPIRING ones, and that health states gate posting. The metadata.authMethod and metadata.subscriptionType semantics go beyond the annotations, though they edge into return-value interpretation better left to the output schema.

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

Conciseness3/5

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

The core scoping and health-state guidance is front-loaded and earns its place, but the trailing sentence on X subscriptionType and the 25000-character limit is long and largely duplicates rules belonging to create_post. The description reads as one dense paragraph with no separation between calling guidance and output interpretation.

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 one-parameter read tool with an output schema present, the description covers the calling context, the state semantics that govern downstream use, and when to omit organizationId. What is missing is only trimming, not essential information.

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

Parameters3/5

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

Schema description coverage is 100% and the single organizationId parameter is fully documented there, including the multi-org requirement. The description adds no detail about the parameter itself, so baseline 3 applies.

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 ('List the organization's connected social accounts') plus a scope qualifier ('including any that are out of service') that separates it from siblings like list_organizations and list_pinterest_boards. An agent knows exactly what it returns without opening the schema.

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?

Gives explicit downstream usage ('Use the returned connection IDs as platformConnectionIds when creating or updating a post') and explicit exclusions by state ('but not where health is INACTIVE, DISCONNECTED or EXPIRED'), with the reason and the exception ('EXPIRING is fine to post to'). This is when/when-not guidance in concrete terms.

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

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

Resources

Need Help?