Skip to main content
Glama

Publish a post immediately

posts_publish_now
Destructive

Publish a post immediately to a platform. The post goes live right away.

Use this when user explicitly wants to publish NOW, not schedule for later. This is a convenience wrapper around posts_create with publish_now=True.

⚠️ MULTI-ACCOUNT USERS: pass account_id when the user has more than one account on this platform. Call accounts_list first to find the right ID.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
contentYesThe post text/content (required)
platformYesTarget platform: twitter, instagram, linkedin, tiktok, bluesky, etc. (required)
account_idNoSpecific account ID. REQUIRED when the user has multiple accounts on this platform. Leave empty only if there is exactly one. Default: .
media_urlsNoComma-separated URLs of media files to attach Default: .
profile_idNoScope auto-resolution to a single profile when account_id is unknown. Default: .

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

TDQS

A4.5/5.0
Behavior4/5

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

Annotations only indicate readHint=false and destructiveHint=true. The description adds that the post 'goes live right away', identifies the wrapper relationship to posts_update, and warns about multi-account behavior with a clear list lookup step. It doesn't fully discuss reversibility or failure handling, but the destructive annotation covers the core risk.

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?

Two short paragraphs front-load the core action, then add usage context and a warning. Every sentence earns its place, and the warning is appropriately emphasized with a bullet and icon. No unnecessary fluff.

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 a full input schema, output schema, and annotations, the description adds the key missing decision criteria: when to use it, how to handle multiple accounts, and how to resolve the account via the accounts_list call. Nothing essential is omitted.

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%, so all parameters are already documented. The description reinforces 'account_id' for multi-account scenarios, but the schema already states the same requirement; it adds little beyond what's structured.

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?

Description clearly states a specific action: 'Publish a post immediately to a platform' and reinforces the result ('The post goes live right away'). It distinguishes itself as 'a convenience wrapper around posts_create with publish_now=True', which differentiates it from siblings like posts_create and posts_cross_post.

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 defines when to use: 'Use this when user explicitly wants an immediate post NOW, not schedule for a later time.' It also provides a clear prerequisite for multi-account users: 'pass account_id' and 'Call accounts_list first.' Alternatives are implied through the wrapper reference, and the condition is unambiguous.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

C2.7/5.0
Disambiguation3/5

Many tools are clearly separated by domain prefix, but several overlap: posts_publish_now duplicates posts_create's publish_now mode, posts_edit_post vs posts_update is confusing without reading both descriptions, and analytics_get_analytics broadly overlaps the more specific analytics metrics tools. The descriptions do help disambiguate, but the large number of similar post/analytics helpers still creates selection risk.

Naming Consistency3/5

Most tools follow a readable lower_snake resource_verb format, with domains like accounts_, posts_, profiles_, and queue_. However, there is notable drift: redundant suffixes (queue_create_queue_slot, tracking_tags_get_tracking_tag_stats), singular/plural mismatch (account_groups_ vs accounts_), non-prefixed helpers (call_tool, search_tools, docs_search), and paired verbs that seem arbitrary (posts_edit_post vs posts_update). It is readable but not cleanly consistent.

Tool Count2/5

51 tools is far above the range where an agent can quickly select the right one, and many entries are wrappers or variants: publish_now, edit_post, retry_all_failed, and multiple analytics/queue helpers could be consolidated. The broad domain justifies more tools than a tiny server, but this count is excessive and will add navigation overhead.

Completeness4/5

The server covers the core social media management lifecycle well: profiles, accounts, posts, scheduling, queueing, analytics, comments, mentions, media uploads, tracking tags, and usage billing are all represented. There are minor gaps—tracking tags are read-only, there is no direct account connection/disconnection flow, and published-post deletion is unsupported—but agents can complete the main workflows with these tools.