Skip to main content
Glama
Sign In

Flaghand

by com.flaghand
OverviewDiscussionsAdmin

Draft, check and schedule in one call: the scheduled jobs, or each draft's problems and fixes

createPost
Destructive

Draft, check and schedule in one call: the scheduled jobs, or each draft's problems and fixes

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "drafts": "<drafts>"
    },
    "name": "createPost"
  }
}

Input Schema

NameRequiredDescriptionDefault
noteNoShown to the owner with any approval request: who posts which part, when, and what they do by hand.
draftsYesOne plan: the posts to schedule (and any the owner must approve).
workspaceNoLeave out for the token's workspace (ws_…).
idempotency_keyNoA new UUID per request; resending the same key and request is a safe retry.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / drafts / items / properties / kind / enum
      Previous value: -[
-  "x_post",
-  "x_thread",
-  "linkedin_post",
-  "bluesky_post",
-  "bluesky_thread",
-  "tiktok_photo",
-  "tiktok_video",
-  "youtube_video",
-  "youtube_reply",
-  "youtube_moderation",
-  "youtube_playlist",
-  "youtube_post",
-  "pinterest_image",
-  "pinterest_carousel",
-  "pinterest_video"
-]New value: +[
+  "patreon_post",
+  "x_post",
+  "x_thread",
+  "linkedin_post",
+  "bluesky_post",
+  "bluesky_thread",
+  "tiktok_photo",
+  "tiktok_video",
+  "youtube_video",
+  "youtube_reply",
+  "youtube_moderation",
+  "youtube_playlist",
+  "youtube_post",
+  "pinterest_image",
+  "pinterest_carousel",
+  "pinterest_video"
+]
    • changedInput schema / properties / drafts / items / properties / mode / description
      Previous value: -"schedule (post at post_at): scheduled at once with no approval step when it's a plain automatic post. post_now (post as soon as the owner approves) and approve (the decision only; nothing is posted) go to the owner's passkey approval: agents never post immediately. Left out: post_now with no post_at, schedule with one (or with by_hand \"first\"), approve with by_hand \"all\". Give a post_at (or next_slot) to schedule."New value: +"schedule (post at post_at): scheduled at once with no approval step when it's a plain automatic post. post_now (post as soon as the owner approves) and approve (the decision only; nothing is posted) go to the owner's passkey approval: agents never post immediately. Left out: Patreon and YouTube use schedule with post_at, otherwise post_now. Other drafts use post_now with no post_at, schedule with one (or with by_hand \"first\"), approve with by_hand \"all\". Patreon always requires the owner's passkey for a by-hand handoff, never an API publication. Give a post_at (or next_slot) to schedule."
  2. Changed4 schema fields changed
    • changedInput schema / properties / drafts / description
      Previous value: -"One plan: every post the owner approves with one passkey tap."New value: +"One plan: the posts to schedule (and any the owner must approve)."
    • changedInput schema / properties / drafts / items / properties / mode / description
      Previous value: -"What the owner is asked to approve: approve (the decision only; nothing is posted), schedule (post at post_at) or post_now (post as soon as it's approved). Left out: what the owner's approval page does with the draft: post_now with no post_at, schedule with one (or with by_hand \"first\"), approve with by_hand \"all\"."New value: +"schedule (post at post_at): scheduled at once with no approval step when it's a plain automatic post. post_now (post as soon as the owner approves) and approve (the decision only; nothing is posted) go to the owner's passkey approval: agents never post immediately. Left out: post_now with no post_at, schedule with one (or with by_hand \"first\"), approve with by_hand \"all\". Give a post_at (or next_slot) to schedule."
    • changedInput schema / properties / drafts / items / properties / post_at / description
      Previous value: -"When to post once approved: RFC 3339 with a UTC offset, like 2026-10-26T09:00:00-07:00, or \"next_slot\" (new drafts) for the account's next open posting time."New value: +"When it posts: RFC 3339 with a UTC offset, like 2026-10-26T09:00:00-07:00, or \"next_slot\" (new drafts) for the account's next open posting time."
    • changedInput schema / properties / note / description
      Previous value: -"Shown to the owner with the request: who posts which part, when, and what they do by hand."New value: +"Shown to the owner with any approval request: who posts which part, when, and what they do by hand."
  3. Changed1 schema field changed
    • changedInput schema / properties / drafts / items / properties / kind / enum
      Previous value: -[
-  "x_post",
-  "x_thread",
-  "linkedin_post",
-  "bluesky_post",
-  "bluesky_thread",
-  "tiktok_photo",
-  "tiktok_video",
-  "pinterest_image",
-  "pinterest_carousel",
-  "pinterest_video"
-]New value: +[
+  "x_post",
+  "x_thread",
+  "linkedin_post",
+  "bluesky_post",
+  "bluesky_thread",
+  "tiktok_photo",
+  "tiktok_video",
+  "youtube_video",
+  "youtube_reply",
+  "youtube_moderation",
+  "youtube_playlist",
+  "youtube_post",
+  "pinterest_image",
+  "pinterest_carousel",
+  "pinterest_video"
+]
  4. Changed1 schema field changed
    • changedInput schema / properties / drafts / items / properties / kind / enum
      Previous value: -[
-  "x_post",
-  "x_thread",
-  "linkedin_post",
-  "bluesky_post",
-  "bluesky_thread",
-  "tiktok_photo",
-  "tiktok_video"
-]New value: +[
+  "x_post",
+  "x_thread",
+  "linkedin_post",
+  "bluesky_post",
+  "bluesky_thread",
+  "tiktok_photo",
+  "tiktok_video",
+  "pinterest_image",
+  "pinterest_carousel",
+  "pinterest_video"
+]
  5. Changed1 schema field changed
    • changedInput schema / properties / drafts / items / properties / kind / enum
      Previous value: -[
-  "x_post",
-  "x_thread",
-  "linkedin_post",
-  "tiktok_photo",
-  "tiktok_video"
-]New value: +[
+  "x_post",
+  "x_thread",
+  "linkedin_post",
+  "bluesky_post",
+  "bluesky_thread",
+  "tiktok_photo",
+  "tiktok_video"
+]
  6. Changed1 schema field changed
    • changedInput schema / properties / drafts / items / properties / mode / description
      Previous value: -"What the owner is asked to approve: approve (the decision only; nothing is posted), schedule (post at post_at) or post_now (post as soon as it's approved). Left out: what the owner's approval page does with the draft: post_now with no post_at, schedule with one (or with by_hand \"first\"), approve with by_hand \"all\" (TikTok: post_now)."New value: +"What the owner is asked to approve: approve (the decision only; nothing is posted), schedule (post at post_at) or post_now (post as soon as it's approved). Left out: what the owner's approval page does with the draft: post_now with no post_at, schedule with one (or with by_hand \"first\"), approve with by_hand \"all\"."
  7. Changed2 schema fields changed
    • changedInput schema / properties / drafts / items / properties / connection_id / description
      Previous value: -"The account it posts as: an active connection's id from GET …/connections, for the kind's platform."New value: +"The selected account: an active connection's id from GET …/connections for the kind's platform. Video-platform drafts never infer it, even with one account. Draft-only saves may omit it; checks and posting approval require it. TikTok mode:approve review alone may keep null and creates no upload job."
    • changedInput schema / properties / drafts / items / properties / kind / description
      Previous value: -"A new draft's kind. With draft_id, only x_post and x_thread change into each other, with the body in the new shape."New value: +"A new draft's kind. With draft_id, compatible post kinds can change into each other with the complete body in the new shape."
  8. Changed2 schema fields changed
    • addedInput schema / properties / drafts / items / properties / body_patch
      Added value: +{
+  "description": "Partial edit: omitted fields stay, null removes optional fields. media_add appends uploaded {media_id, alt}; media_from imports and appends. Thread posts is one patch per current part. Not with body/options/kind changes. Media edits invalidate prior approval; updateDraft returns approval_effect and the re-request call.",
+  "type": "object"
+}
    • changedInput schema / properties / drafts / items / properties / draft_id / description
      Previous value: -"A draft an earlier call made (drafts[].id in its answer), to fix it and ask again. Send its rev and only the top-level fields that change; a body is always the complete new body."New value: +"A draft an earlier call made (drafts[].id in its answer), to fix it and ask again. Send its rev and only fields that change; body replaces the full body, body_patch edits only supplied body fields."
  9. First observed

TDQS

C2.3/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the safety profile is known from structured data. The description adds nothing beyond that: it does not say that drafts may be created or mutated in bulk (up to 50), that approval/passkey steps gate posting, that idempotency keys exist, or what gets overwritten when a draft_id is reused. The rich behavioral detail lives in the schema, not here.

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

Conciseness3/5

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

It is short and has no padding, but it is a single ungrammatical fragment with an ambiguous trailing clause, so it is not effectively front-loaded. Brevity without clarity does not earn a high score here.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a high-complexity mutation tool (batched draft creation/updating, scheduling modes, approval handoff, idempotency) with no output schema, so the description must explain the outcome and the approval behavior — it does neither. The only hint at return values is the tangled phrase 'the scheduled jobs, or each draft's problems and fixes', which is not enough to tell an agent what to expect.

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% and the per-field descriptions for drafts, mode, body_patch, post_at and connection_id are unusually detailed, so the schema carries parameter meaning. The tool description contributes nothing about parameters — the baseline 3 applies when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tautological: description restates name/title.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

'in one call' weakly implies this is the batch alternative to the single-purpose siblings, but there is no explicit when-to-use, when-not-to-use, or named alternative. An agent facing createDraft vs checkDraft vs schedulePost vs createPost gets no routing guidance from the description.

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

All Flaghand 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