MCP server

The HumanPost MCP server turns publishing, content-tagging, account, queue, analytics, and usage operations into structured tools that compatible AI clients can discover and call.

Connection details#

Client setup#

Create a key with the tools' required scopes, replace YOUR_API_KEY, and restart the client if it does not discover tools immediately.

claude mcp add --scope user --transport http humanpost https://us-central1-clickbaitcarousel.cloudfunctions.net/mcp --header "Authorization: Bearer YOUR_API_KEY"

URL: https://us-central1-clickbaitcarousel.cloudfunctions.net/mcp
Authorization: Bearer YOUR_API_KEY

{
  "mcpServers": {
    "humanpost": {
      "url": "https://us-central1-clickbaitcarousel.cloudfunctions.net/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_API_KEY"
      }
    }
  }
}

{
  "name": "humanpost",
  "transport": {
    "type": "streamable-http",
    "url": "https://us-central1-clickbaitcarousel.cloudfunctions.net/mcp"
  },
  "headers": {
    "Authorization": "Bearer YOUR_API_KEY"
  }
}

Tool catalog#

The catalog and schemas are generated from the running tools. MCP tools/list includes input and output schemas, required scopes, and read/write annotations. Tool failures return isError plus structuredContent.error with requestId, field details, and retryability. Keep idempotency keys and payloads unchanged when retrying.

These focused publishing tools enforce the API key's scopes on every call. A client can discover a tool even when the current key cannot run it.

create_post accepts 1–20 image upload IDs for a carousel; their upload order is the slide order.

Inspect stored account profiles#

list_accounts({platform: "tiktok"})
get_account({accountId: "ACCOUNT_ID"})

Requires accounts:read. Both tools include stored profilePictureUrl, bio (strings or null), and warmupSearchTerms (an array, empty when absent). Setup placeholders contain requested values; pending profile edits retain previous values until worker approval. These fields let GIMI display and compare stored configuration without independently verifying the live social profile or completed warm-up. create_accountstill accepts warmup.searchTerms (1–5 terms); longer historical lists remain readable.

Review artwork before submission#

Use create_draft, get_post_content, and update_draft with expectedVersionId to edit slide text and styles. request_post_preview renders the current version without approving or queueing it. Poll get_job, inspect get_post_preview, then queue_post. A later artwork edit invalidates the preview.

create_draft({media:["UP1","UP2"],idempotencyKey:"launch-draft-1"})
get_post_content({postId:"POST_ID"})
request_post_preview({postId:"POST_ID",idempotencyKey:"launch-preview-1"})
get_job({jobId:"JOB_ID"}) // poll until complete
get_post_preview({postId:"POST_ID"}) // inspect mediaUrls and status: ready
queue_post({postId:"POST_ID",accountIds:["ACCOUNT_ID"],idempotencyKey:"launch-submit-1"})

Batches and performance reports#

create_upload_batch imports up to 100 URLs with persisted ordered results and per-file errors. create_analytics_report compares UTC-day growth across equal periods, groups by account, platform, tag or template, and ranks destinations by latest cumulative views. Both return a jobId for get_job. Reports expose collection freshness and coverage; dates are UTC midnight, from inclusive to exclusive. Missing observations do not mean zero performance.

Content tags#

Content tags are optional internal reporting groups. They appear beside template attribution in analytics, but never change the public caption or the content sent to a social platform.

• Tagging is optional. A post can have up to 10 explicit tag or template reporting groups.
• Use the stable contentGroupId returned when a tag is created, not its display name or bare tagId.
• contentGroupIds is a replacement list: resend the complete desired list to add or remove one tag, or send [] to remove all explicit tags.
• Tag assignments can be changed before or after a post is published. Other post fields still follow normal editability rules.
• A template:<id> group inherited from the template used to create a post is provenance and remains visible even when explicit tags are cleared.

# Create a reusable company tag; keep the returned contentGroupId.
create_content_tag({ name: "Launch", color: "blue" })
→ { contentGroupId: "tag:abc123", ... }

# Add it when creating a post.
create_post({ media: ["UPLOAD_ID"], accountIds: ["ACCOUNT_ID"], contentGroupIds: ["tag:abc123"] })

# Replace the post's tags at any time, including after publishing.
update_post({ postId: "POST_ID", contentGroupIds: ["tag:abc123", "tag:def456"] })

# Remove every explicit tag.
update_post({ postId: "POST_ID", contentGroupIds: [] })

Scheduling posts#

Use get_company_schedule and update_company_schedule for the company default, or get_account_schedule and update_account_schedule for an individual account. Read tools need accounts:read; changes need accounts:write. Set schedule: null to restore inheritance. See Scheduling posts for window selection, examples, and missed-post behavior.

Example workflow#

Troubleshooting#