Point Claude, Codex, or Cursor at your workspace and the chore of feeding it context disappears. Ask which drafts are waiting, what goes out this week, or how last month's campaign did, and it answers from what is really in Maeve, not from a pasted screenshot. Reading is open, drafting and scheduling need permission, and anything public or permanent has to be confirmed by name before it runs.
3 days free. Cancel anytime.
› Which drafts are still waiting on media this week? ⚙ list_content { status: "draft", workspace: "lily-dia" } ✓ 6 drafts · 4 Instagram · 2 TikTok · 2 missing media › Publish the ring-stack reel now. ⚙ publish_now requires mcp:dangerous + confirmation → confirm with "publish_now:cnt_8f3k2" to proceed
MCP earns its place when an agent needs to know what is actually going on before it can help. It can list the drafts waiting for review, compare what is scheduled across platforms, see which media there is to work with, or pull the last thirty days of analytics, straight from the workspace over typed tools.
What the agent does lands back in the surfaces your team already uses, so a draft it creates opens in the Composer and shows on the Calendar like any other.
Reading the workspace needs mcp:read and workspace access. Creating drafts, scheduling, and media uploads need mcp:write and an editor or admin role, and nothing skips the validation the app already runs. The tools that go public or cannot be undone, publishing now, deleting, bulk media moves, sit behind mcp:dangerous and only run when the call includes the exact confirmation text for that action and target, like publish_now with the content ID.
You approve the client in your browser over OAuth with PKCE, see exactly which scopes it asked for, and can revoke the connection at any time from MCP Connections. Every tool call is logged with who ran it, what it touched, and how it ended.
A hosted Model Context Protocol server at the Maeve API. Connected clients get typed tools for real workspace tasks, with the risky ones kept on a short leash.
MCP is not a separate automation island. It reads from and writes into the same product surfaces your team already uses, so agent help stays visible in the normal workflow.
Maeve MCP is a controlled AI-agent interface focused on the posting workflow for your Maeve workspace. It lets MCP-compatible tools inspect social media drafts, schedules, integrations, media, analytics, tags, hashtags, campaigns, and grid-planner items, and compose, schedule, and publish content, with write actions gated by scopes, roles, and confirmations.
An MCP server exposes product actions as typed tools that an AI client can call after authorization. In Maeve, those tools sit on top of the real publishing, media, and analytics systems instead of giving an agent a separate sandbox. MCP is the curated posting slice of the product; other surfaces stay in the app, REST API, and CLI.
Maeve provides setup copy for Claude Code, Codex, and Cursor or other JSON-configured MCP clients. Browser-approved MCP has been validated in the product guidance with Codex and Claude Code, and any compliant HTTP MCP client can connect if it supports the required authentication flow.
With mcp:read, an agent can list workspaces, integrations, integration capabilities and options, content, content counts, campaigns, taxonomy, hashtag groups, media, media folders and labels, media usage history, grid items, analytics summaries, aggregate metrics, post analytics, demographics, and integration health.
Yes, when the connection has mcp:write and the user has editor or admin access. MCP can create draft content and schedule an existing item for a specific timestamp. Drafts and scheduled posts appear in the Composer and Calendar.
Yes, but only through the high-risk publish_now tool. The connection must include mcp:dangerous, the user must have editor or admin access, and the call must include exact confirmation text such as publish_now:<contentId> unless a server-side dangerous auto-confirm policy has explicitly allowed that action.
No. The Inbox is a separate community-management surface and is intentionally outside the MCP posting surface. Agents do not read or act on inbox threads through MCP. Use the Maeve app, the REST API, or the CLI for Social Inbox work.
Yes. Dangerous tools are not exposed unless the connection has mcp:dangerous, workspace roles still apply, and each high-risk call requires exact confirmation text tied to the action and target ID. Tool allowlists and denylists can also hide specific tools globally or for an organization.
High-risk tools require a confirmationText value that exactly matches the server's expected action and target, such as publish_now:<contentId>, delete_content:<contentId>, or organize_media_assets:<operationKey>:<count>. If the text is missing or wrong, the tool returns a confirmation-required error with the expected text.
Yes. Every workspace-scoped tool checks access before it reads or writes. Read tools require workspace access; write and dangerous tools require editor or admin roles. Viewer access can inspect allowed data but cannot create, schedule, publish, or delete through MCP.
No. Approvals and client review are human sign-off workflows and are intentionally outside the MCP posting surface. MCP does not read approval history or act on reviews. Manage agency approvals and client reviews in the app, REST API, or CLI.
MCP can read analytics summaries, aggregate metrics, post analytics, audience demographics, and integration health. It does not generate PDF analytics reports in MCP v1; use the app, API, or CLI for report generation where that workflow is available.
No. MCP is the agent-friendly surface: typed tools, OAuth scopes, and confirmations for AI clients. The REST API remains better for software integrations, servers, CI jobs, custom dashboards, and full endpoint coverage.
No. MCP is for AI tools such as Claude, Codex, and Cursor. The CLI is for humans, shell scripts, cron jobs, and CI.
MCP is focused on posting. It does not handle the Inbox, approvals, or client review; it does not generate PDF reports, run destructive or broad media operations beyond the preview-first organize tool, reorder or promote grid items, manage API keys, or bypass platform/API constraints. Those workflows live in the app, REST API, or CLI. Publishing still depends on the connected platform's API.