LotsSocialWiring LotsSocial into Your AI Agent: An MCP Walkthrough for Builders
You finish a release. The build is green, the tests passed, and your deploy agent is ready to tell the world. So it reaches for a social platform API. Then it hits Meta's app review, X's paid API tier, LinkedIn's separate OAuth flow, the Threads API's evolving endpoints, and per-platform media handling — all before writing a single line of business logic. What should take twenty minutes ends up taking two days, and most of that time is not coding. It is paperwork.
The fastest path is a single Model Context Protocol endpoint that already speaks the supported platforms and routes them through one auth flow. This post walks through that path, end to end.
By the end, your MCP-compatible agent can register the LotsSocial endpoint, call draft_post with platform-specific inputs, hand the draft to a human for review, and read the publish result back. You will know which permission level to set for autonomous versus human-approved publishing, and you can ship the integration in one sitting.
What the LotsSocial MCP endpoint actually is (and is not)
The endpoint at https://api.lots.social/mcp follows the Model Context Protocol standard, so any MCP-compatible agent or client can register it as a tool. MCP is an open protocol, not a vendor SDK — the official spec is maintained publicly, and reference clients include Claude, ChatGPT, Visual Studio Code, and Cursor. Authenticate once with your LotsSocial account, and the server exposes the same actions available in the UI: draft, schedule, publish, list connected accounts, read activity log.
It is not a generic social posting SDK, and it is not a replacement for strategy. It is a thin, scoped surface that lets an agent call social publishing the same way it calls email, calendar, or web search. One interface, nine supported platforms, no per-platform OAuth to manage. Every UI action is available through MCP/API, and the default is draft-first — publishing requires explicit permission. That approval-first boundary is not bolted on at the API layer; it is the same one a human uses in the UI, which is why Permission Levels Explained: What Your AI Agent Can and Cannot Do is worth reading alongside this walkthrough.
Prerequisites before you wire it up
You need three things ready before you start.
A LotsSocial account on the Business plan, where the MCP server lives, or an active developer sandbox for evaluation. A workspace is already created. At least one social account is connected in the workspace — for this walkthrough we will use LinkedIn because most builders already have it for testing.
An MCP-compatible client. Examples: Claude Desktop, Cursor, an in-house agent built on the MCP SDK, or any other client that supports tool registration over stdio or HTTP.
A working understanding of JSON-RPC requests and your agent's tool-calling loop. No prior social platform API experience is required.
Step 1: Register the MCP server in your client
For a typical stdio client, point the command or URL field at the endpoint and put the auth token in the environment variable. The endpoint URL is https://api.lots.social/mcp.
{ "mcpServers": { "lotssocial": { "command": "npx", "args": ["-y", "@lotssocial/mcp-client"], "env": { "LOTSSOCIAL_TOKEN": "your_workspace_token", "LOTSSOCIAL_WORKSPACE_ID": "your_workspace_id" } } } }
Restart the client. The available tools from the server should appear in your tool list: draft_post, schedule_post, publish_post, list_accounts, get_activity. If those show up, the connection is live.
Step 2: Inspect the tools the server exposes
The schema for draft_post is the one you will use most. Required fields are workspace_id, account_id, content, and platforms. Optional fields are media_urls, scheduled_for, link, hashtags, and first_comment. Each optional field has a clear job: media_urls attaches images or video, scheduled_for sets a future timestamp, link adds a URL with preview, hashtags is a per-platform list, and first_comment is a Threads- and LinkedIn-friendly follow-up.
Notice the explicit separation between draft_post, schedule_post, and publish_post. This is the approval-first boundary showing up in the API. An agent can draft and queue without permission, can schedule inside an approved window, and can only publish when the workspace permission level allows it. The default is draft, not live. If you want a deeper read on why that default matters and what changes when you flip it, see Why AI Social Media Tools Need Approval Workflows, Not Autopilot.
Step 3: Call draft_post from your agent
Your agent has just shipped a release. It sends a draft_post request with the release headline, a one-paragraph body, the LinkedIn account id, and an optional link.
{ "tool": "draft_post", "input": { "workspace_id": "ws_8a14", "account_id": "li_92d", "platforms": ["linkedin"], "content": "Shipped: 2.4.0 — faster sync, better exports, fewer retries. Full notes in the link.", "link": "https://example.com/releases/2-4-0" } }
The response includes the draft id and a status of in_review. Behind the scenes, the MCP server adapts the body length and tone for LinkedIn, attaches the link preview, and routes the draft into the workspace's review queue. Your agent does not handle platform adaptation itself.
Step 4: Handle the human approval step
The default flow is: agent drafts, the workspace owner reviews in the LotsSocial UI (or on Telegram, or by email reply), and the post moves from in_review to approved.
If you want the agent to publish without per-post review — say, for an internal status board — the right path is a separate workspace with a publish-when-permitted permission level scoped to that one account. Workspace isolation is the safety boundary. Nothing goes live without the workspace owner, unless the workspace permission is configured otherwise. This is a workspace setting, not an API flag.
Step 5: Read the result back and log it
get_activity is how the agent polls or subscribes to the result of a publish. The response includes the platform post id, the live URL, the publish timestamp, and any error code.
The practical pattern is to write the post id back into the agent's memory or the originating task record, so the next time the agent references the post, it has the canonical link. If a publish fails — token expired, platform outage, media rejected — the response includes a structured error. The recommended pattern is to surface the error to the agent's user, not to silently retry. Same draft-first principle that applies to humans.
Step 6: Multi-platform fan-out without extra code
The same draft_post call works with two platforms in the request array.
{ "tool": "draft_post", "input": { "workspace_id": "ws_8a14", "account_id": "li_92d", "platforms": ["linkedin", "x", "threads"], "content": "Shipped: 2.4.0 — faster sync, better exports, fewer retries. Full notes in the link.", "link": "https://example.com/releases/2-4-0" } }
The server adapts the caption per platform, not per request: a LinkedIn-leaning body, an X-trimmed version, a Threads-native phrasing. Your agent wrote one brief. The platform-specific versions are handled at the MCP layer. You do not write or maintain per-platform prompt logic. The server owns that. This is the difference between integrating nine APIs and integrating one.
What to watch for in production
Four things bite builders in production, and each has a known answer.
Latency. A multi-platform publish makes serial calls under the hood. For a single post, that is fast. For 20 posts to 5 platforms, expect the request to take several seconds. Design the agent's tool loop to await it.
Permission scope. A token scoped to one workspace cannot publish in another. If you need multi-brand publishing, the token has to be authorized per workspace, and the request must include workspace_id explicitly.
Rate limits. The MCP server enforces platform-side rate limits on your behalf. If you hit a ceiling, the error code is specific and the server surfaces a retry-after hint.
Media. Include media_urls as fully qualified URLs. The server uploads and validates. For video, confirm the platform supports it in the API reference before sending.
How this fits into a real agent workflow
Two short vignettes show the same pattern at work.
A deploy agent posts a release announcement to LinkedIn and X once a build goes green. The agent finishes its job, calls draft_post with the release headline, and hands the draft id to the workspace owner for review. The agent does not own the publishing decision; the human does.
A research agent publishes a weekly digest to Threads after summarizing a long-form source. Same three steps. The agent summarizes, the agent drafts, the workspace owner approves. The agent is the worker, the workspace owner is the editor, the MCP server is the pipe.
For a wider view on social media management tools and where MCP fits among them, see the comparison guide for small teams.
Start free and evaluate before you commit
If you are still deciding whether MCP is the right social layer for your agent, the lowest-friction way to find out is to spin up a free LotsSocial workspace, connect one low-traffic account (Mastodon and Bluesky are good candidates — both have open APIs with no app review), and run a few draft_post calls against the live endpoint. You will see the platform-specific adaptation, the activity log, and the approval loop before you spend anything. When you are ready to wire it into a real product, the MCP server lives on the Business plan and includes the full reference docs at https://api.lots.social/mcp. Start Free — No Credit Card Required at lots.social →
Frequently Asked Questions
Do I need the Business plan to use the MCP endpoint? Yes. The MCP server is on the Business plan, and a developer sandbox is available for builders evaluating it. The REST API at https://api.lots.social/v1 is also available on the Business plan for app-style integrations that are not MCP-compatible. You can compare tiers on the LotsSocial pricing page.
Can my agent publish without a human in the loop? Only if the workspace is configured with a publish-when-permitted permission level. The default for every workspace is draft-first. Changing the permission is an explicit workspace setting, not an API flag.
What happens if the platform rejects the post after I approve it? The MCP server returns a structured error from the activity log. The draft is not retried automatically. The workspace owner (or the agent, if configured) sees the error and decides what to do next.
Can I scope the agent's token to a single social account? Yes. Tokens are workspace-scoped by default, and within a workspace, you can constrain the account_ids the agent is allowed to publish to. There is no global "post to all my accounts" token.
How is this different from the REST API? The REST API at https://api.lots.social/v1 is the same surface, exposed for applications and custom builds that do not speak MCP. If your client is an MCP-compatible agent, use the MCP endpoint. If your client is a SaaS dashboard or an internal tool, use the REST API.
Will the MCP server generate images or videos for posts? No. The MCP server handles routing, adaptation, and publishing. Image and video generation are not part of the surface. For visual assets, supply media_urls you have already created or sourced.
What if my agent is on a different agent framework? Any framework that supports the Model Context Protocol can register the endpoint. The reference clients listed in the MCP docs include Claude, ChatGPT, Visual Studio Code, and Cursor, and the protocol is open — community-maintained clients are listed in the same documentation.
How do I test without posting to a live account? Connect a low-traffic account — Mastodon or Bluesky are good candidates — and use the draft_post tool exclusively. Drafts do not publish, so you can exercise the full flow without going live.
Read the full MCP reference and example requests at https://api.lots.social/mcp. To build against the social publishing surface from your own agent or app, start at lots.social — the MCP endpoint is live on the Business plan and available as a docs walkthrough for builders.