Tool reference

The server exposes 26 focused tools. You don't call these yourself — the agent picks them — but knowing what exists helps you phrase requests.

Agents work at two levels: rough ideas live on the post, publishable copy lives on its per-platform variants. If that distinction is new, read Core concepts first.

Discover

Tool	What it does
list_workspaces	Your workspaces, slugs, roles, and timezones — agents call this first
list_workspace_members	Searchable, pageable members in a workspace — useful when asking for peer review by teammate
list_states / list_labels	Workflow states and labels (with ids) in a workspace
list_social_profiles	Connected accounts you can use or reference — platform, profile type, display name, @username, active state, company/managed flags, and approval implications

Read

Tool	What it does
list_posts	Browse posts; filter by state group (idea/drafting/review/scheduled/published/…), campaign, or title search
get_post	One post in full: description + every variant's content, status, schedule, published URL; Twitter follow-ups include stable ids
list_post_activity	A post's activity log: what changed, who changed it, and approval/schedule events
list_post_comments	Pageable comments and replies on a post
list_post_attachments	Pageable attachment metadata and usable read URLs for a post, variant, or tweet
get_analytics_summary	Compact performance summary for visible published LinkedIn and X variants

Write

Tool	What it does
create_post / update_post	The container: title, description, state, campaign, labels
create_variant	Add platform content (one variant per platform per post); pass social_profile_id to choose the posting account, and set a future scheduled_at to schedule it
update_variant	Rewrite content, change the posting account, schedule/unschedule (scheduled_at: null returns it to draft). Published variants are locked
replace_twitter_thread	Strictly replace X/Twitter follow-ups: ids from get_post preserve rows/media, id-less items create rows, and omitted ids delete rows/media
swap_twitter_thread_opening	Swap the opening tweet with the first follow-up tweet, including media

Collaboration

Tool	What it does
create_post_comment	Add a comment or reply to a post; activity and notifications behave like the app
update_post_comment	Edit or resolve one of your own comments

Campaigns

Tool	What it does
list_campaigns	Campaigns in a workspace, with ids, date ranges, colors, and statuses
create_campaign	New campaign: name (max 50 chars, unique per workspace), start_date/end_date (ISO YYYY-MM-DD, end on or after start), optional description, hex color (defaults #6B7280), and status (draft/scheduled/running/completed/cancelled, default draft). Any member can create
update_campaign	Change any of those fields — only the fields you pass change. Restricted to workspace admins/owners and the campaign's creator

Posts join a campaign via create_post/update_post (campaign_id), not through the campaign tools.

Pagination and attachment URLs

list_workspace_members, list_post_activity, list_post_comments, and list_post_attachments accept limit and offset while still returning a bare array. Member listing also accepts a case-insensitive search across email and name. Increase offset until a page contains fewer rows than limit.

Attachment file_url values are absolute WriteMars API URLs and require the same token as other API calls. preview_url may instead be a short-lived signed URL that can be opened without an auth header. Storage bucket keys are never exposed through MCP.

Publish

Tool	What it does
publish_variant	Posts to the social platform immediately and returns the live URL. Agents are instructed to use it only when you explicitly say to publish. On a channel that requires sign-off it doesn't post — it returns the variant as needs_approval with an approval_note

Approvals

Tool	What it does
request_approval	Ask a teammate to peer-review a post — pass their email address or user id (must be a workspace member). They're notified and the post lands in their approval queue. Each reviewer can have at most one pending request per post
list_approvals	Without post_id: your personal queue — peer reviews assigned to you plus channel approvals you can resolve (pending by default; filter with status). With post_id: every approval on that post, all statuses. Each item carries post_title and can_resolve; channel approvals carry a social_profile, peer reviews a reviewer
resolve_approval	Decide a request: approved, rejected, or changes_requested, with an optional comment. Resolutions are final

Not exposed through MCP

MCP intentionally does not mirror every REST endpoint. Use the browser app or REST API for OAuth/social account connection, API-token management, workspace administration, label/state CRUD, media upload/presign/reorder/delete, notification mutation, engagement-rule automation, and full analytics dashboards.

Behavioral notes

• Scheduled variants don't need publish_variant — WriteMars's scheduler publishes them automatically at the scheduled time.
• One variant per platform per post. Asking for a second LinkedIn variant on the same post will fail; ask the agent to update the existing one instead.
• One posting account per variant. Use list_social_profiles first when the prompt names a handle, founder account, company page, or managed account, then pass that id as social_profile_id.
• Twitter threads are edited as a full follow-up list. replace_twitter_thread updates the replies after the opening tweet; the opening tweet itself is the variant content. Read stable tweet ids from get_post: including an id preserves that row and media, omitting an existing id deletes it, and an item without an id creates a new row. Legacy id-less positional behavior remains REST-only for old clients.
• Attachment tools are read-only. Agents can inspect media metadata, but uploads and media reordering stay in the app/API flows.
• Published variants are locked — they cannot be edited or rescheduled.
• Peer reviews are feedback only. request_approval asks a teammate for their take — it never unlocks publishing to a gated channel. Channel approvals are filed automatically when a variant is scheduled to a gated channel; you don't create those yourself. See approvals.
• Who can resolve an approval: a peer review, only the assigned reviewer; a channel approval, the channel's owner, their trusted members, or admins (company channels only). First eligible resolver wins and is stamped as the reviewer.
• Approving a channel approval releases that channel's held variants back to scheduled. Rejecting or requesting changes returns them to draft and notifies the author.
• Campaign names are unique per workspace (case-insensitive) — creating a duplicate fails; ask the agent to update or reuse the existing one instead.
• Results respect post visibility — list_posts skips private posts outside your audience and get_post returns not-found for them, exactly like the app.
• Errors come back to the agent in plain language (not_found, forbidden, validation_error) and it will usually self-correct — e.g. by calling list_workspaces to fix a wrong slug.

For example prompts that exercise these tools, see the prompt cookbook. For what an agent is and isn't allowed to do, see security and permissions.