Skip to main content
Glama

Post to Bluesky

post_to_bluesky

Publish a post to Bluesky as the connected account. Text up to 300 characters — Bluesky ALSO caps a post at 3000 UTF-8 bytes, so an emoji-heavy post can be under 300 characters and still be refused; Hermoso checks both before spending the round trip and says which limit and by how much. MEDIA: either up to 4 images (imageUrls + altText) OR one MP4 video (videoUrl + videoAlt), never both — a Bluesky post record carries a single embed and images and video are two different embed types. Video is MP4 only, up to 300MB at Bluesky's end (Hermoso can fetch up to 150MB from a URL), with optional WebVTT caption tracks; the aspect ratio is measured from the file. Bluesky requires a CONFIRMED EMAIL on the account before it will process any video — if it is unconfirmed you get a refusal saying so, and reconnecting will not help. Links in the text are made clickable automatically. LINK CARDS: Bluesky does NOT scrape links, so a URL posted bare renders as plain blue text — the client composing the post has to build the card. Hermoso builds one AUTOMATICALLY when the post has a URL and NO media: it fetches the page, uses its title/description and uploads its image as the card thumbnail. Pass linkCard:false to suppress it, or linkCard:{uri,title,description,thumbUrl} to control it (give both title and description and the page is not fetched at all). A POST CARRIES ONE EMBED, so a card and images/video cannot both ride: if you pass linkCard explicitly ALONGSIDE media the call is REFUSED by name rather than silently dropping one, and if the URL was merely in the text the MEDIA WINS and the reply says the card was skipped (the link stays clickable either way). Returns the post's public bsky.app URL. Connect at Settings ▸ Connectors ▸ Bluesky with a handle and an APP PASSWORD.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYesThe post, up to 300 characters / 3000 UTF-8 bytes.
langsNoBCP-47 language tags, e.g. ['en'].
altTextNoAlt text — an ARRAY, one per image in the same order, or a single STRING to describe every image with it. WRITE ONE: Bluesky’s own lexicon makes `alt` a REQUIRED property of every image, so a post without it is undescribed by design rather than by omission, and Bluesky users expect it. No maximum length is published, so nothing is truncated.
captionsNoUp to 20 WebVTT caption tracks: [{lang:'en', url:'https://…/en.vtt'}] or [{lang:'en', content:'WEBVTT\n\n00:00…'}]. Each file is capped at 20000 bytes.
linkCardNoRich link card (`app.bsky.embed.external`). OMIT for the default (a card is built automatically when the post has a URL and no media). `false` never builds one. `true` builds one from the first URL in the text. An object {uri,title,description,thumbUrl} overrides any field — supply BOTH title and description and the page is never fetched. Cannot be combined with imageUrls/videoUrl: a post has ONE embed, so an explicit linkCard beside media is refused.
videoAltNoAlt text describing the video, for accessibility.
videoUrlNoOne public MP4 URL. Cannot be combined with imageUrls. Bluesky transcodes it, which takes a minute or two.
imageUrlsNoUp to 4 public image URLs to attach. Cannot be combined with videoUrl.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already state the operation is not read-only, not idempotent, and not destructive, but the description adds substantial behavioral detail: exact character and byte limits (including the UTF-8 nuance), media type exclusivity, automatic link-card generation logic, refusal-on-conflict behavior, and the confirmed-email prerequisite. It also discloses the return value. This far exceeds what structured annotations provide.

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?

Although long, every sentence carries essential information—no filler. The structure flows logically: purpose, text limits, media constraints, link cards, conflicts, return value, and connection. Information is front-loaded with the core action first, and the detailed rules are organized by theme, making it easy to scan.

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 8 parameters, many with nuanced constraints, the description covers all foreseeable edge cases: byte vs. character limits, media exclusivity, link-card suppression and override, refusal behavior, and the confirmed-email prerequisite. It also states the return value and connection method, so an agent can call it correctly without consulting external docs.

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

Parameters5/5

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

The schema has 100% coverage with descriptions, so the baseline is 3. However, the description enriches every parameter with practical context: text explains the byte-limit and pre-check behavior, altText explains Bluesky's required property and the array vs. string semantics, linkCard explains the default auto-build and override behavior, videoUrl notes transcoding time. This goes well beyond the schema phrases.

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?

The first sentence states exactly what the tool does: 'Publish a post to Bluesky as the connected account.' It is a specific verb+resource combination that clearly distinguishes it from sibling post_to_* and delete_bluesky_post tools. No ambiguity.

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?

While the description does not explicitly name competing post tools, it gives extensive platform-specific conditions: use linkCard for URLs without media, avoid combining media types, confirmed email requirement, and refusal conditions. It clearly explains when to use each optional parameter but stops short of an explicit 'use this tool for Bluesky vs. use post_to_meta for Meta' stance, which would be redundant given the name.

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

A3.7/5.0
Disambiguation2/5

With 293 tools, the surface is enormous and many tools have overlapping purposes—multiple posting tools (post_to_meta, post_to_linkedin, schedule_post, etc.), multiple analytics tools per channel, and several search tools (search_meta_ads, search_instagram, search_reddit...). While each description is detailed, the volume makes it difficult for an agent to reliably distinguish between similar tools without careful reading, leading to frequent misselection.

Naming Consistency4/5

The naming is largely consistent with a verb_noun pattern (post_to_*, list_*, create_*, delete_*, update_*, manage_*). There are clear families for major operations. A few outliers like 'google_business_account', 'hermoso_capabilities', and 'store_get' break the pattern, but the overwhelming majority follow a predictable structure, making navigation somewhat easier.

Tool Count1/5

293 tools is far beyond any reasonable scope for a single MCP server, even for a comprehensive marketing platform. The calibration guide flags 50+ as an extreme mismatch, and this is nearly six times that threshold. Such a large surface overwhelms context windows, increases the probability of misselection, and makes it impractical for agents to learn or use effectively.

Completeness4/5

The tool set covers a vast domain: ad creation and rendering, posting across nine+ social channels, analytics and reporting, file management (Drive/OneDrive), competitor research, brand management, and more. It appears to provide CRUD and lifecycle coverage for most resources. While there may be minor gaps given the immense scope, the overall coverage is impressively comprehensive.