MCP overview

Staqly is an MCP server named staqly. Connect it to an AI agent (Claude Code, Codex, OpenCode, Cursor, Windsurf) and the agent gets 100 tools to write and schedule posts, connect channels, set up schedules, webhooks and alerts, and see what the workspace asks of it. Nearly everything the REST API can do is available as a tool, no HTTP code needed: browser sign-in flows, managing people and a few dashboard-only endpoints are left out (the list). Pick MCP when an agent does the work; for scripts and workflows, use the REST API or the CLI instead. Both go through the same domain services and authorization checks.

Connect an agentCopy Anchor Link

export STAQLY_API_KEY=$(staqly serve token)   # Docker: $(docker exec staqly server token)
claude mcp add --transport http staqly http://localhost:3333/mcp \
  --header "Authorization: Bearer $STAQLY_API_KEY"

TransportsCopy Anchor Link

HTTP works with staqly serve and with Docker. STDIO runs the mcp-stdio binary inside the staqly container, so it needs the Docker setup (or a mcp-stdio binary built from source).

staqly mcp config <client> prints the setup for claude, codex, opencode, cursor or windsurf, pointing at your current CLI profile's server. Flags: --stdio (use STDIO instead of HTTP), --container <name> (container for --stdio, default staqly) and --snippet (print only the config file snippet, to redirect into a file). With a key in the profile, the output references $STAQLY_API_KEY and never prints the key itself.

In the dashboard, Integrations → REST & MCP shows the same URL, the bearer header (cloud) and the STDIO command.

What the server tells the modelCopy Anchor Link

On connect, staqly sends instructions so the agent uses it well:

• the flow is connect channels, create posts, schedule them: a post has one target per channel, needs at least one to be scheduled or published, and preview_post shows what each platform objects to before publishing;
• collections can be referenced by ID (col_qjuybkx6355nz4no6pqk) or exact name;
• list_posts with publish_after / publish_before is the calendar; search_posts finds posts by their text;
• list_requested_work says what the workspace asks of the agent: targets on your own automation waiting for report_publish_result, and schedules that found nothing to publish and ask for drafts in their collection;
• report results only for work the agent did itself; a published post is read-only, duplicate it to post it again.

Tools at a glanceCopy Anchor Link

Inputs and scopes for each: Tools reference.

SecurityCopy Anchor Link

• Community Edition: the access token is required, like for the REST API, and gives every tool. STDIO (docker exec -i staqly mcp-stdio) needs none: it opens the database itself.
• Cloud mode: an API key is required and its scopes are enforced by the domain layer: a read-only key cannot write, create_post / update_post need posts:write, schedule_post / publish_post / report_publish_result need posts:publish, channels need channels:manage. See Authentication & scopes.
• The HTTP endpoint is stateless: every request is authenticated on its own; there is no MCP session to hijack. Cookies are never accepted.
• A STDIO process re-checks its STAQLY_API_KEY at most once a minute, so a revoked or expired key stops working within a minute.
• A suspended workspace (the trial or a paid period ended unpaid) can only call read-only tools and a short allowlist; see Tools reference.
• Channel credentials are never returned by any tool; the recovery key is never accepted or exposed over MCP.

Next stepsCopy Anchor Link