Loading today’s stories
Build1 distinct publisher3 min readPublished
An MCP server for social publishing shipped OAuth, sixteen tools and six destructive flags. The failures that actually hurt still come back as ordinary successes.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
A schema validator checks shape, not reference. A platformId with the right prefix and the right length is a valid platformId whether it points at a company account or someone's personal one, and a language model's output is optimised for exactly that kind of plausibility [4]. The request is well formed, the API does what it was asked, and there is no exception anywhere in the chain [4].
That pushes verification to either side of the call. Before it: the server's first instruction to any client is not a description of the product but a rule, call list_connections and copy each platformId verbatim, never invent one, placed ahead of the tool list and the examples [5]. After it: the author now reads the scheduled time back out of the confirmation, because the API takes ISO 8601 in UTC only, the model decides which 9am "tomorrow at 9am" meant, and a wrong timestamp is indistinguishable from a right one until the post fires [6] [7].
Four defences appear in the dev.to post, and three of them need someone other than the server to cooperate [16]. The instruction block is addressed to a reader the author characterises as one who will confidently improvise [c5a]. The destructive annotations, filled in on six of sixteen tools including deleting posts and removing a LinkedIn comment, are advisory, and the author says plenty of clients ignore them entirely [9] [10]. Reading back a confirmation only helps when a human reads it [7]. The one that runs in the server's own code is the playground platform: it accepts the post, validates it against the real rules, returns a normal response and throws it away [11].
The exposure that comes with the good plumbing is worth naming. Because the endpoint supports dynamic client registration, connecting an editor no longer means typing a key into a config file [2], which also means the server does not get to pick which client sits in front of its ten unflagged tools and its six destructive ones [19] [13].
The Instagram case shows where the boundaries actually sit. The queue enforces what the queue can check; the media requirement belongs to Instagram, TikTok and YouTube at publish time. So a text-only post validates, enters the queue, sits there looking healthy for a day, and dies when it is due [8]. Queue membership, in the author's phrase, is not a promise [15].
What remains is an evidence problem. A 500 lands in a log that somebody eventually reads [14]; a call that succeeds against the wrong target leaves a normal success, so reconstructing it later depends on having recorded the resolved arguments rather than the status code [17]. Twenty minutes of annotation work is the cheap half [10]. The discard target is the half the author says most integrations that write somewhere public still lack [18].
Ranked by verification strength, evidence, and original report placement.
A July post by the same author described wiring an AI agent into social platforms as six OAuth flows, three-step media uploads and tokens expiring on their own private schedules, and concluded that the answer was to hide all of it behind a single tool call.
Two months later the MCP server answers over OAuth, with metadata at /.well-known/oauth-authorization-server, PKCE and dynamic client registration, so connecting an editor no longer involves typing a key into a config file.
The annotations are advisory: a client can ignore them entirely and plenty do. The author says they cost almost nothing to add, roughly twenty minutes of work, and are the only way a server can tell a client that a tool deserves a confirmation dialog without inventing a private protocol.
A playground platform target (platforms: ["publora-playground"]) accepts the post, validates it against the real rules, returns a normal response and throws it away, so nothing reaches a real network.
It exists because there was previously no honest way to answer 'is this connected and working?': every genuine end-to-end test meant putting something real on someone's real timeline.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Specific first-party detail, no independent verification
The technical claims are unusually concrete for a single-source post — named OAuth metadata path, PKCE, dynamic client registration, sixteen tools, six destructive flags, a shown annotation block and a shown playground payload — and the author states he re-ran the playground response, annotations and OAuth metadata against the live server rather than recalling them. But every one of those checks is self-reported by the vendor's own author; there is no repository, transcript, third-party test, client survey or measurement of failure rates. Ecosystem-level assertions ('plenty' of clients ignore annotations, 'most' integrations lack a dry-run target) carry no data at all, and the derived claims are logical restatements of the same single account.
One vendor's own server, one self-reported user
Adoption evidence is limited to the vendor describing its own shipped surface (OAuth endpoint, sixteen tools, populated annotations, playground target) and the author's roughly two months of personal use. No customer count, request volume, client compatibility list, downstream integration or third-party deployment is disclosed, so the measured signal is real but very narrow — a release plus a single-operator usage disclosure.
Mostly calibrated, with unsupported ecosystem prescriptions
The framing is unusually restrained for a vendor post: the headline failure mode is the author's own mistakes, the mitigations are described as cheap and partly unenforceable, and the annotation mechanism is explicitly labelled advisory. That pulls the gap near zero. Modest overstatement comes from generalising one operator's two-month experience into ecosystem prescriptions — that most public-writing integrations lack a discard target and that plenty of clients ignore annotations — and from presenting a set of guardrails as sufficient to 'leave it running' when three of the four depend on the model, the human or the client behaving.
Vendor growth author writing about own product, bias disclosed
The author states his job is getting the product into people's hands, the server, tool counts and playground target all belong to that product, and the post ends with an engagement prompt on a developer-marketing platform — a strong promotional incentive. It is partly offset by explicit disclosure ('I'm biased about the product'), by a section deliberately framed as product-independent, and by the transparency about drafting with Claude and re-verifying claims. The generalised advice nonetheless routes readers toward the specific feature the vendor ships.
Coherent single-source account, unverifiable externally
Internal consistency is high and the mechanism claims are the kind an implementer would be unlikely to get wrong about their own server, so the descriptive facts can be reported with reasonable confidence. Confidence is capped by the structure of the cluster: one publisher, one vendor-affiliated author, self-verification only, no failure-rate data, and no independent view of client behaviour. The derived claims inherit that ceiling because they reason over the same single account.
build
Two ways to point Claude at production, and only one of them keeps the password1 distinct publisher
build
Green Tests, Useless Server: MCP Needs Task-Level Evals, And Call Count Moves First1 distinct publisher
invest
The remedy New Mexico won at trial is the one Meta's $18 billion settlement does not contain1 distinct publisher
security
Meta's $17.1B settlement turns teen safety into an audited product spec3 distinct publishers
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 27, 2026