Let your agent run the calendar.

utsk_live_a1b2c3d4e5f6.WKq7Lm3PxZ2vN8tRfY0sHcJ4bA6dE1gU9iO5nQwT2xM

claude mcp add --transport http uptrended-social \
  https://uptrended.social/mcp \
  --header "Authorization: Bearer utsk_live_xxxxxxxxxxxx.your-secret-here"

Draft a post announcing our Tuesday launch and put it on
the calendar for 9am Tuesday, Instagram and X. Validate it
before you create anything.

The workflow that works

Every posting task follows the same three steps, and skipping one is how agents produce payloads that fail:

Linking an Instagram, Facebook, TikTok, X, Pinterest or YouTube account is an interactive OAuth flow: the platform shows its own consent screen in a browser, and in several cases the person has to pick which Page, board or channel to grant. That cannot be driven headlessly, and shipping an API that pretends otherwise would just fail confusingly.

So: connect accounts once at uptrended.social, in the browser. After that they appear in list_accounts and in GET /api/v1/accounts, and everything else is programmable.

Remote (preferred)

Endpoint:  https://uptrended.social/mcp
Transport: Streamable HTTP
Header:    Authorization: Bearer utsk_live_xxxxxxxxxxxx.your-secret-here

No install, no local process, and the tool list is always current. Claude Code:

claude mcp add --transport http uptrended-social \
  https://uptrended.social/mcp \
  --header "Authorization: Bearer utsk_live_xxxxxxxxxxxx.your-secret-here"

stdio bridge (fallback)

For clients that can only spawn a local command — Claude Desktop, Cursor, VS Code — npx -y @uptrended/mcp proxies stdio to the same endpoint. It implements no tools of its own; it forwards JSON-RPC frames, so the server stays the only source of truth for what is available.

{
  "mcpServers": {
    "uptrended-social": {
      "command": "npx",
      "args": ["-y", "@uptrended/mcp"],
      "env": {
        "UTSOCIAL_API_KEY": "utsk_live_xxxxxxxxxxxx.your-secret-here"
      }
    }
  }
}

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json. Windows: %APPDATA%\Claude\claude_desktop_config.json. Restart the app afterwards — it reads that file only at launch.

{
  "mcpServers": {
    "uptrended-social": {
      "command": "npx",
      "args": ["-y", "@uptrended/mcp"],
      "env": {
        "UTSOCIAL_API_KEY": "utsk_live_xxxxxxxxxxxx.your-secret-here"
      }
    }
  }
}

{
  "inputs": [
    {
      "id": "utsocial-key",
      "type": "promptString",
      "description": "UT Social API key",
      "password": true
    }
  ],
  "servers": {
    "uptrended-social": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@uptrended/mcp"],
      "env": { "UTSOCIAL_API_KEY": "${input:utsocial-key}" }
    }
  }
}

Bridge configuration

The bridge validates the key format locally and writes every diagnostic to stderr, because stdout is the MCP wire. In Claude Desktop those land in ~/Library/Logs/Claude/mcp-server-uptrended-social.log.

Why validate_post matters more than it sounds

Platform rules are inconsistent enough that a payload which looks obviously fine is often not. validate_post takes the exact object you would pass to create_post and reports what each target would reject — for free, and without publishing anything. Two or three validate round-trips before a create is normal.

Quota is per post, not per target

One post fanned out to six platforms is one unit of quota. Six single-platform posts are six. Put every target in a single create_post call unless the content itself genuinely differs per platform — and even then, per-target overrides are usually the better answer than separate posts.

curl https://uptrended.social/api/v1/accounts \
  -H "Authorization: Bearer utsk_live_xxxxxxxxxxxx.your-secret-here"

Conventions

• Base URL https://uptrended.social/api/v1. Every request needs Authorization: Bearer utsk_live_….
• Collections return { data: [...], next_cursor, has_more } and paginate by keyset. Follow next_cursor while has_more is true; there are no page numbers.
• Errors return { error, code, request_id }. Quote the request_id when reporting a problem.
• organization_id is never accepted in a request body. The key determines the workspace.
• Mutating calls accept an Idempotency-Key header.

Endpoints

Validate, then create

curl https://uptrended.social/api/v1/posts/validate \
  -H "Authorization: Bearer utsk_live_xxxxxxxxxxxx.your-secret-here" \
  -H "Content-Type: application/json" \
  -d '{
    "caption": "Launching Tuesday. Here is what changed.",
    "scheduled_at": "2026-08-04T09:00:00-05:00",
    "targets": [
      { "social_account_id": "acc_2f9…", "kind": "post" },
      { "social_account_id": "acc_7c1…", "kind": "post" }
    ]
  }'

A clean validate returns no target errors. Then send the same body to POST /api/v1/posts with an Idempotency-Key.

Two ways to get bytes into a post.

• Ingest a URL — POST /media/ingest (or the ingest_media tool) fetches a publicly reachable URL server-side. 100 MB cap. This covers most cases.
• Direct upload — POST /media/upload-url returns a signed URL, you PUT the bytes to it, then POST /media/register to add it to the library. Use this for larger files or local bytes.

Check list_media before re-ingesting an asset you already have. Media carries its own per-platform constraints — aspect ratio, duration, codec — and validate_post checks those too, which is one more reason to validate before creating.

Presets expand into the granular scopes named in the tables above — accounts:read, media:write, posts:draft, posts:write, usage:read. GET /api/v1/me returns exactly what a key was granted.

Rate limits are per key per minute, so splitting traffic across two keys on the same workspace genuinely doubles headroom — up to the key cap. Exceeding a cap returns 402 PLAN_REQUIRED at key-creation time, not at request time.

A rate-limited response carries Retry-After plus RateLimit-* headers. Honour Retry-After rather than retrying on a fixed timer.

curl https://uptrended.social/api/v1/posts \
  -H "Authorization: Bearer utsk_live_xxxxxxxxxxxx.your-secret-here" \
  -H "Idempotency-Key: 6f1c9e2a-4b77-4a10-9d3e-8f2b5c0a71de" \
  -H "Content-Type: application/json" \
  -d @post.json

• Generate one fresh UUID per logical post.
• On a retry — timeout, 5xx, dropped connection — send the same key again. The server returns the original result instead of creating a second post.
• Generating a new key on retry is how you double-post to a real audience. It is the most damaging mistake available here and the easiest to avoid.
• If a create failed ambiguously and no key was sent, do not blindly retry — call GET /api/v1/posts and check whether it landed.

Cross-workspace ids return 404 rather than 403 on purpose — a key should not be able to probe for the existence of resources it cannot reach.