Skip to main content
Glama
hermoso-ai

Hermoso

Official

Post to Bluesky

post_to_bluesky

Publish posts to Bluesky with text, up to 4 images or one video, auto link cards, and pre-checks for character and byte limits to avoid rejections.

Instructions

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.
Behavior5/5

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

The description goes far beyond annotations. It discloses timed behaviors (Hermoso checks limits before round trip), error conditions (refusal for unconfirmed email), platform-specific rules (Bluesky's 3000-byte cap, video MP4 only), and side effects (media wins over link card). Annotations only cover readOnly/destructive hints; the description adds operational details essential for correct invocation.

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

Conciseness4/5

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

The description is dense but front-loaded with the most critical constraints (character/byte limits, media exclusivity) and then covers ancillary details (captions, link cards, reconnection). Some redundancy (e.g., mentions 'one embed' twice) but each section earns its place. Slightly long, but justified for a complex tool.

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 tool's complexity (8 parameters, interaction rules, platform quirks), the description covers all necessary points: return value (public URL), connection method, limits, media rules, error conditions, and the auto card behavior. No obvious gap for an agent to mis-invoke.

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?

Schema covers 100% of parameters with rich descriptions, but the tool description adds extra context: the byte/character limit interplay, the 'one embed' rule clarifying altText and videoAlt conflicts, the linkCard behavior with explicit vs implicit, and the on-fetch limits. It supplements, not just reiterates, the schema.

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 description states a clear verb ('Publish a post'), the resource ('to Bluesky'), and the connected account context. It distinguishes from sibling posting tools (post_to_x, post_to_tiktok, post_to_meta) by naming Bluesky specifically and detailing platform-specific constraints, making the tool's 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?

The description gives explicit when-to-use guidance: it covers text limits, media types, link card behavior, and even when to suppress the card. It also names alternatives implicitly (e.g., other social posting tools) and provides exclusions (e.g., media and link card cannot be combined, video requires confirmed email).

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hermoso-ai/hermoso'

If you have feedback or need assistance with the MCP directory API, please join our Discord server