The 12 Tools an AI Agent Needs for Social Media

I shipped PostSider’s MCP server with 12 tools. The REST API underneath it has more endpoints than that. This is the design essay about why I cut the list down instead of exposing everything, what specifically got cut, and the rule I used to decide, because I think the reasoning transfers to any MCP server you are building, not just a social one.

Tool sprawl is how MCP servers fail

The failure mode nobody warns you about before you ship your first MCP server is not “the model is not smart enough.” It is “the model has too many similar-looking options and picks the wrong one, or burns tokens reading descriptions for tools it will never call.”

Every tool on an MCP server costs context. The agent reads the full list, with descriptions and input schemas, before it decides anything, every session. A server with 50 tools is not a superset of a server with 12 good ones, it is a worse version of it: more surface for the agent to misjudge, more overlapping names to confuse, more tokens spent on tools that never get called. A REST API can afford a hundred narrow endpoints because code does not mind reading docs once. An agent pays that cost fresh, every single session.

So the design question is not “what can the API do.” It is “what is the smallest set of outcome-shaped actions that covers what an agent actually needs to do here.” That question is what got PostSider’s server down to 12.

What agents actually call in practice: reads dominate

Before deciding what to cut, I looked at the shape of what an agent doing this job actually needs, and it skews heavily toward reading, not writing.

Eight of the twelve tools are reads: list channels, list channel groups, find next free slot, list posts, check a post for missing fields, post analytics, channel analytics, notifications. Only two are writes that create content: upload media from URL, and the single create-or-schedule-or-publish-post tool. Two more are management actions on things that already exist: update post status, delete post.

That eight-to-two-to-two split is not an accident, it is the shape of good agent behavior. A well-behaved agent checks before it acts. It lists channels before it schedules something, so it has real identifiers instead of guessing at account names. It checks free slots before it drafts a time. It reads analytics before it claims a post did well. The read tools are not padding, they are what makes the two write tools trustworthy enough to let an agent touch without reviewing every call by hand.

The 12, one by one, and why each earned its place

Group	Tool	Why it exists
Read	List channels	The agent needs real channel identifiers before anything else works
Read	List channel groups	Lets the agent target a brand or client group instead of naming every channel one by one
Read	Find next free slot	Turns “when should this go out” into a call instead of the agent guessing at your calendar
Read	List posts	Gives the agent visibility into what is already queued, so it does not double-book a slot
Read	Check post for missing fields	The preflight check, covered in its own section below
Read	Post analytics	Lets the agent close the loop on a specific post it created
Read	Channel analytics	Lets the agent reason about a channel’s performance before recommending a cadence
Read	Notifications	Surfaces anything that needs a human’s attention without a separate polling loop
Write	Upload media from URL	The one media path, deliberately narrow: give it a URL, it handles the rest
Write	Create, schedule, or publish a post	One tool, one status argument, covers draft, schedule, and immediate publish
Manage	Update post status	Moves a draft to scheduled, or scheduled to published, without recreating the post
Manage	Delete post	Housekeeping on something that already exists

Notice the write group has exactly one content-creation tool doing three jobs through a status argument, not three separate tools named create-draft, schedule-post, and publish-post. That collapsing is the outcome-shaped design principle in miniature: the agent’s actual intent is “get this content into the world at the right time,” and a status flag on one tool expresses that better than three near-identical tools it has to choose between.

What got cut, and the rule behind each cut

The public REST API exposes more than these 12 actions. Three categories of endpoint did not make it onto the MCP server, and each one followed the same rule: does an agent, mid-conversation, actually need to call this directly, or is it something a person configures once and never touches again.

Account and billing management stayed off the server. Connecting a new social channel involves an OAuth flow with the platform itself, something a human has to click through in a browser regardless of what tool calls it. There was never a version of “have the agent connect my Instagram account” that made sense as a tool call, so it is not one.

Workspace and team settings stayed off the server. Inviting a team member, changing a role, renaming a workspace: these are configuration a person does a handful of times a year, not something an agent needs mid-task. Exposing them as tools would add to every session’s context for a capability that gets used almost never.

Granular sub-resource endpoints got merged into their parent tool instead of staying separate. The REST API has more fine-grained routes than the 12 tools suggest; several of those collapsed into the single create-or-schedule-or-publish-post tool’s status argument, per the same outcome-shaped principle from the section above, rather than surviving as their own tools.

The rule underneath all three: if a human would only ever do this by clicking through a UI once in a while, it does not belong on the agent’s tool list, no matter how easy it would be to expose. Context budget is not free, and every unused tool the agent has to read is a small tax on every tool it does use correctly.

Preflight tools beat error messages

The single most useful tool on the server, and the one I would tell anyone building their own MCP server to copy, is check-post-for-missing-fields.

Without it, the failure mode is: the agent calls create-post, the API rejects it because a required field is empty, and the agent gets an error message back that it has to interpret and recover from, burning a turn on a mistake it could have caught itself. With it, the agent can call the check before it ever tries to create anything, get a direct list of what is missing, fix it, and only then call the write tool. Same underlying validation, completely different agent experience: one path debugs after a failure, the other prevents it.

That distinction generalizes past social media. Any MCP server with a validation-heavy write path benefits from a cheap, side-effect-free preflight tool the agent can call before committing to the expensive or irreversible action. It costs one more tool in the list, and it is worth more than most of the write tools it protects.

How to apply this to your own MCP server

Three questions, in order, if you are cutting your own tool list down from an existing API surface. First: what does the agent actually need to check before it acts, and does a preflight tool exist for the risky write paths, the way check-post-for-missing-fields exists here. Second: which near-duplicate actions can collapse into one tool with a status or mode argument, the way three publish states became one argument on one tool. Third: which endpoints are things a human configures rarely and an agent almost never needs mid-conversation, and can be left off the list entirely rather than included because the API happens to support them.

None of this is exotic advice. It is the same discipline as designing a good CLI: fewer commands, each one doing a complete job, with the dangerous ones gated by a check. The difference with MCP is that the agent pays for every tool you expose whether it calls it or not, which makes the discipline worth more here than almost anywhere else you will apply it.

If you want the exact current tool names and schemas rather than the design reasoning, docs.postsider.com/mcp is the source of truth and stays current as the server changes. For the mechanics of how an agent discovers and calls tools over MCP in the first place, what an MCP server is and MCP vs REST vs SDK for social media cover that ground this post assumed you already had.