Skip to main content
Glama

Send Out

by app.openkrill
OverviewDiscussionsAdmin

Create X post

create_x_post
Read-onlyIdempotent

Makes an X (Twitter) share link. Use when the user wants to post or reply on X. Needs text; url, hashtags, via and in_reply_to are optional. Counts characters the way X does and sets is_within_free_limit to false when the post is over 280 characters (only X Premium can post it, so offer a shorter version). Returns an x.com link that opens the composer with the post filled in, and the user posts it. Nothing is posted or stored.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoOptional web link to attach, such as "https://example.com". X counts it as 23 characters.
viaNoOptional X username to credit, without the @ sign, such as "openkrill".
textYesPost text (at most 25,000 characters), such as "We shipped our new CLI today!". Standard accounts can post up to 280 characters; X Premium up to 25,000.
hashtagsNoOptional hashtags without the # sign, such as ["devtools", "opensource"].
in_reply_toNoOptional numeric ID of the post to reply to, the digits at the end of its URL, such as "1850000000000000000". Not the full URL.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
notesYesShort notes to pass on to the user, including any warning.
x_urlYesOfficial X share intent link (x.com/intent/tweet).
statusYesAlways ok when the link was made. Bad input returns an error instead.
warningNoWarning if text exceeds free character limit or safe URL limits.
url_lengthYesTotal length of the generated intent URL.
character_countYesEstimated effective character count on X.
is_within_free_limitYesTrue if within the 280-character free limit.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedInput schema / examples
      Removed value: -[
-  {
-    "text": "Hello from a probe"
-  }
-]
  2. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
+  {
+    "text": "Hello from a probe"
+  }
+]
  3. Changed7 schema fields changed
    • changedInput schema / properties / hashtags / description
      Previous value: -"Optional hashtags without '#' symbol."New value: +"Optional hashtags without the # sign, such as [\"devtools\", \"opensource\"]."
    • changedInput schema / properties / in_reply_to / description
      Previous value: -"Optional status ID of the tweet to reply to."New value: +"Optional numeric ID of the post to reply to, the digits at the end of its URL, such as \"1850000000000000000\". Not the full URL."
    • changedInput schema / properties / text / description
      Previous value: -"Post text (at most 25,000 characters). Standard accounts support up to 280 characters; X Premium supports up to 25,000."New value: +"Post text (at most 25,000 characters), such as \"We shipped our new CLI today!\". Standard accounts can post up to 280 characters; X Premium up to 25,000."
    • changedInput schema / properties / url / description
      Previous value: -"Optional web link to attach to the post."New value: +"Optional web link to attach, such as \"https://example.com\". X counts it as 23 characters."
    • changedInput schema / properties / via / description
      Previous value: -"Optional username attribution without '@' symbol."New value: +"Optional X username to credit, without the @ sign, such as \"openkrill\"."
    • addedOutput schema / properties / notes / description
      Added value: +"Short notes to pass on to the user, including any warning."
    • addedOutput schema / properties / status / description
      Added value: +"Always ok when the link was made. Bad input returns an error instead."
  4. Changed1 schema field changed
    • removedOutput schema / properties / note_from_openkrill
      Removed value: -{
-  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
-  "type": "string"
-}
  5. Changed1 schema field changed
    • addedOutput schema / properties / note_from_openkrill
      Added value: +{
+  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
+  "type": "string"
+}
  6. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new behavioral context beyond them: the tool returns an x.com composer link rather than publishing, nothing is posted or stored, characters are counted the way X does, and is_within_free_limit flips to false past 280 characters with actionable advice to offer a shorter version. That is exactly the kind of consequence-level detail annotations cannot express.

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?

Four tight sentences, front-loaded with the action, then trigger, then parameters, then return/limits. Dense but every sentence carries information; the parameter enumeration sentence is the weakest since the schema already covers it.

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?

For a 5-parameter tool with an output schema, the description covers the full decision surface: what it produces (a composer link the user completes), what it does not do (no posting, no storage), the character-limit edge case and its remediation. Nothing an agent needs to call this correctly or set user expectations is missing.

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 every parameter is already documented with examples, limits and the 23-character URL counting rule. The description only restates which field is required (text) and that the other four are optional, adding no syntax or constraint detail beyond the schema — the 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?

The description opens with a specific verb and resource — "Makes an X (Twitter) share link" — which is distinct from every sibling (calendar events, markdown files, Obsidian notes, WhatsApp links). It also pre-empts a likely misconception by stating "Nothing is posted or stored," so an agent can distinguish it from an actual posting tool 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Use when the user wants to post or reply on X" gives a clear trigger condition covering both composition and reply scenarios. It stops short of naming an alternative or an explicit when-not-to-use case (e.g., when the user wants an actual API post rather than a share link), so it earns a 4 rather than a 5.

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

All Send Out toolsInspect
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