Standalone MCP server for LinkedIn post scheduling with a publisher daemon
Wellknown found it in public sources; nobody has proven control of it yet. Claiming takes one click if the repository is under your GitHub account, or a small file on your domain otherwise. Verified owners get the badge, 15-minute checks, status alerts, edits that outrank crawled data, and a ranking boost.
Agents can do it too: POST https://wellknown.network/api/v1/claims with {"agent":"linkedin-mcp-scheduler-ldraney","method":"well_known_file"} — machine-readable steps at claim.json, guide at /docs/claim.
Everything here was measured by our prober or read from a registry. Nothing is self-reported.
Attributed to the source that supplied each field. Treated as claims, not facts.
[](https://pypi.org/project/linkedin-mcp-scheduler-ldraney/) [](https://opensource.org/licenses/MIT) [](https://www.python.org/downloads/) # linkedin-mcp-scheduler Schedule and manage LinkedIn posts through conversation with an AI agent. Posts publish reliably on time — locally or in a container. ## User Story You're chatting with your AI agent. You say: > "Schedule that post for tomorrow at 9am" Done. Then later: > "Show me my queue" You see everything — what's pending, what published, what failed. You say: > "Actually push that one to Thursday and change the second paragraph" The agent edits it in-place and reschedules. No cancelling, no re-creating, no UUIDs to copy-paste. > "That failed post from yesterday — retry it now" Retried. Published. You never opened LinkedIn. This is what linkedin-mcp-scheduler provides: a standalone MCP server with a reliable publishing daemon, full CRUD on your post queue, and a conversational UX designed for AI agents to manage your LinkedIn presence. ## Why a Separate Project [linkedin-mcp](https://github.com/ldraney/linkedin-mcp) wraps the LinkedIn API as MCP tools — posting, engagement, auth. It has basic scheduling, but scheduling is a different problem: - It needs a **daemon** that runs continuously and publishes due posts. The API wrapper doesn't. - It needs **persistent state** (a database) with its own lifecycle. The API wrapper is stateless. - It needs to be **containerizable** — running in k8s with a volume-backed DB, HTTP transport, and env-based credentials. The API wrapper runs fine as a local stdio MCP. - The UX surface area is large enough to be its own product: queue management, editing, rescheduling, retries, media scheduling, recurring posts. ## Architecture ``` ┌──────────────────────────────────…
Mapped onto the structured taxonomy from declared text and observed tool names. Confidence shown for derived entries.
Every source is kept verbatim. Field changes are logged as events.