Social Media MCP Server: Prepare a Reviewed Post in AppStruct

A social media MCP server lets an AI assistant work with a publishing tool through named operations. In AppStruct Social, those operations read connected channels, inspect posts and analytics, and save unscheduled drafts. The MCP interface never schedules or publishes a post. You review the saved draft in Social and choose the destination and publishing time there.

This guide takes one fictional product update from a short brief to a saved draft you can inspect. It includes a Cursor configuration without a secret and a plain-text practice brief. The files are free to download without an email address. Connecting requires an AppStruct account with Social access, a connected channel and permission to create a key in the selected workspace.

Choose the access for your first task

Open AppStruct Social, select the intended workspace, then open API and Connect an assistant. The Social connection page requires sign-in.

Create a short-lived key for this exercise with these permissions:

For the draft exercise, use the first two scopes. Analytics access is optional. The read permission includes unpublished posts and attachments in that workspace, so give the key only to a client you trust with that material. A key is bound to its account and workspace; it does not switch workspaces when an assistant supplies a different ID.

The separate social:publish permission is for explicit REST publication and scheduling. It is not needed here and does not add publishing tools to MCP. Draft deletion and media listing also have separate permissions that this exercise does not need.

Save the one-time secret in the environment or secret store used by your MCP client. Keep it out of source control, screenshots and messages. Existing channel connections are managed in Social; the assistant does not need a social network password.

Connect a client that supports a Bearer header

The AppStruct Social MCP endpoint uses Streamable HTTP:

https://api.appstruct.ai/v1/social/mcp

It requires an Authorization: Bearer header containing your Social key. A client limited to OAuth sign-in cannot use this key-based connection.

For Cursor, merge the following server entry into your personal ~/.cursor/mcp.json, keeping any other server entries you already use:

{
  "mcpServers": {
    "appstruct-social": {
      "url": "https://api.appstruct.ai/v1/social/mcp",
      "headers": {
        "Authorization": "Bearer ${env:APPSTRUCT_SOCIAL_MCP_KEY}"
      }
    }
  }
}

The downloadable JSON contains the same configuration and no API key. Set APPSTRUCT_SOCIAL_MCP_KEY in the environment used to launch Cursor, restart the client and refresh its MCP tool discovery. The variable must resolve to your actual secret; sending the literal placeholder is not authentication. See Cursor's MCP configuration documentation for supported settings and environment interpolation.

For a plugin-based connection, get the AppStruct Social package. It bundles the connection metadata and a workflow skill for channel selection, draft revisions and read-back checks. The Cursor Directory listing is public. Configure its key variable in the client's private plugin settings, following the repository's setup instructions. Choose one connection method so the same server is not installed twice.

Connect AppStruct Social to Claude Code

The same hosted MCP endpoint accepts Claude Code's HTTP transport with a Bearer header. Set APPSTRUCT_SOCIAL_MCP_KEY in the private environment used to start Claude Code. Keep the real value out of shared terminal transcripts and committed files.

The AppStruct-maintained plugin includes the connection and the draft-review skill. From the terminal in your intended project, run:

claude plugin marketplace add VladimirTambovtsev/appstruct-social-cursor-plugin
claude plugin install appstruct-social@appstruct-social-plugins --scope local

The repository retains its original Cursor name and contains separate manifests for both clients. This is AppStruct's own marketplace; publication does not mean approval by Anthropic. The local scope enables the plugin for this project and user. Review the connection permissions in Claude Code, open /mcp and confirm the server is connected before asking it to save anything.

If you prefer a manual connection, the Claude Code JSON file uses type: "http" and ${APPSTRUCT_SOCIAL_MCP_KEY} environment expansion. Merge its server entry into your project's .mcp.json, preserving other entries, and use the project trust and MCP approval controls in your client. The file contains no key. Use the plugin or the manual configuration so the same server is connected once.

See the Claude Code MCP reference and plugin marketplace documentation for client setup. The package manifests were validated locally; an authenticated draft run in Claude Code has not been performed for this release. Your first check is a channel read that matches your intended workspace, followed by the draft exercise below.

Confirm the workspace before drafting

Begin with a read request:

Use AppStruct Social to list my connected channels. Show each channel's name, platform, ID and connection status. Do not create, edit, schedule or publish a post.

The tool is social_list_channels. Compare its result with the channels visible in the selected Social workspace. If two channels have the same display name, use the platform and discovered ID to distinguish them. A successful connection to an empty workspace is not proof that you selected the workspace you intended.

These are the tools relevant to this exercise:

Use the argument schema returned by your client's tool discovery. A read-only key cannot create the practice draft. After changing permissions, reconnect or refresh discovery before treating a missing tool as a product failure.

Prepare one fictional product update

Download the practice brief, or give the assistant this source:

Exercise: DEMO-SOCIAL-001
Fictional product: Example Request Desk
Audience: a small team reviewing service requests
Update: a practice form lets someone enter a request title and status.
Acceptance check: save one fictional request, reopen it, then change only its status.
Public demo URL: not provided
Customer results, user counts and time savings: not provided
Desired post: under 500 characters, plain text, for one channel selected by the user.
Publication state: draft for review; no publishing date has been agreed.

Ask for text in the conversation first:

Propose one plain-text post using only this brief. Do not invent a demo URL, customer, usage statistic or launch date. Keep it under 500 characters. Show the complete text and the proposed destination from the channel list. Do not save anything until I approve that text and destination.

For example, a draft can invite the team to evaluate a small request workflow and list the save, reopen and status-change checks. It should not claim that real customers have used it. Review the tone, text and destination before saving it.

Save the draft and inspect the result

After reviewing the proposed text and exact channel, ask the assistant to save one unscheduled draft with social_create_draft. Ask it to return the saved post ID and review URL, then read the draft with social_get_post.

Creation uses a UUID request_id. If the same operation needs a retry, reuse the same ID and identical arguments. A different text or target is a new operation. If a response is interrupted, inspect the saved posts before attempting a second creation.

Open the returned review URL in Social and check:

Run social_validate_draft for the saved draft. Resolve any reported channel or content problems and inspect the result again. Passing validation checks the current requirements; it does not confirm future delivery by a social network.

If you choose to revise the draft through MCP, read it first. social_update_draft replaces the complete content of an unscheduled draft, so preserve any existing attachments and per-channel overrides you intend to keep. Its expected_revision must match the revision you just read. On a conflict, read again and review the difference before retrying. Scheduled and published posts are outside that editing operation.

For a real post, finish the review in Social, choose a publishing time and confirm the target channel. A scheduled item is still waiting. Record it as published only when the publishing system reports completion and provides the destination's URL. The launch tracker guide shows how to keep those states separate.

Read analytics without inventing missing results

With social:analytics:read, social_get_analytics reads available measured totals for a period of 1–90 days. A null metric means unavailable, not zero. The call does not force a fresh request to each social network.

Channel impressions and engagement describe activity on that network. To evaluate visits and registration events on your website, give each published link a UTM label and inspect your website analytics separately. The free UTM builder and launch tracker prepares those links; it does not automatically collect results.

Fix a connection or draft that does not work

The live Social API specification includes the current x-mcp-tools list and required scopes. REST scheduling and publication are separate operations with additional permissions and concurrency checks; this tutorial does not grant or call them.

The useful outcome is one saved draft that you can compare with its source and intended destination. Continue in AppStruct Social to review it, or explore the separate Docs MCP brief if your source material belongs in a document.