BulkPublish

List platforms

list_platforms

Read-onlyIdempotent

List every social platform BulkPublish supports and whether it is currently available. Check this before telling a user they can connect a platform or scheduling a post to one: a platform in state 'off' rejects post creation with a 403 PLATFORM_DISABLED error and holds any already-scheduled posts until it is re-enabled, and one in state 'connect_off' cannot accept new connections although existing channels keep publishing. Disabled platforms are still listed, with enabled=false and a reason. A platform may also carry a 'variants' object keyed by channel accountType for sub-platforms gated on their own: LinkedIn reports variants.organization for company pages (a separate LinkedIn app with its own review), while the platform-level state covers personal profiles — so pages can be paused while personal-profile posting is live. A variant is never more permissive than its parent, and when a variant blocks a write the 403 PLATFORM_DISABLED error carries an accountType field naming it. Use this when the user asks which platforms are supported or available, or a connect/publish attempt failed with PLATFORM_DISABLED.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already mark read-only and idempotent, and the description complements them with operational behavior: disabled platforms are still listed with enabled=false and reason, off rejects writes with 403, connect_off blocks new connections but keeps existing channels publishing, and variants are gated separately. This goes well beyond the annotation hints.

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 long but every sentence adds operational value, from the state model to the LinkedIn-specific variant behavior. It is front-loaded with the core purpose before diving into edge cases.

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?

With no output schema, the description carries the burden of explaining return semantics, and it covers states, error codes, variants, and scheduling behavior. For a parameterless read-only tool, this is sufficient for an agent to call it correctly and interpret responses.

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 schema has zero parameters, so there is nothing to document; baseline 4 applies. The description instead focuses on output semantics (enabled flag, reason, variants object), which is the relevant information for invoking the tool.

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 action and resource: 'List every social platform BulkPublish supports and whether it is currently available.' Clearly distinguishes from sibling list_channels by scoping to platforms and their availability.

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 tells when to call it: before telling a user they can connect a platform or scheduling a post, and when a connect/publish attempt failed with PLATFORM_DISABLED. It also explains conditions like 'off' and 'connect_off' so an agent can decide correctly. No explicit alternative is named, but the use cases are unambiguous.

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

All BulkPublish tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0

Disambiguation3/5

Many tools occupy adjacent spaces, especially the interactive view_* tools versus their get_/list_ counterparts (view_posts/list_posts, view_analytics/get_analytics) and the multiple upload paths (upload_media, create_media_upload, multipart flow). Detailed 'Use this when' guidance helps, but an agent could still misselect between compose_post and create_post or between bulk_posts and the individual delete/retry/update operations.

Naming Consistency5/5

Tool names follow a highly consistent verb_noun pattern throughout: create/get/update/delete/list for each resource (posts, media, labels, channel sets, RSS feeds, schedules), plus publish/approve/reject/retry/upload/view. No style mixing or inconsistent casing.

Tool Count1/5

51 tools is an extremely large surface, crossing the calibration's 50+ extreme threshold. While the platform covers many subdomains, this volume is likely to overwhelm agents and makes the toolkit unwieldy for an MCP server.

Completeness4/5

The toolkit provides broad lifecycle coverage: CRUD for posts, media, labels, channel sets, RSS feeds, and schedules, plus publishing, approvals, retries, bulk operations, analytics, quota, channel health, and media upload variants. Minor gaps exist, such as no get_channel single-resource getter and no way to update media labels directly, but agents can work around these.

Resources

Need Help?