The same product. A new interface.

Publer brings accounts, drafts, scheduled content, media and analytics into one operating environment. Its API makes those capabilities programmable. But a conversational request such as “What worked recently, and turn that into next week’s campaign” is not a single endpoint call.

The request crosses context, analysis, planning and execution. It must select a workspace, identify the right accounts, retrieve enough history, handle partial insight data, distinguish evidence from inference, propose a plan and create content in the correct state.

That is the gap MCP can close. Not by replacing Publer, but by giving AI clients a governed language for using it.

The product question did not appear in isolation. In March 2026, a Publer engineer described operating an account through Claude Code using natural language and reduced the idea to four words: “Same API. Different interface.”

In May, Publer’s founder challenged students at the Canadian Institute of Technology to build an MCP server for Publer in 24 hours. By August, Publer’s help center documented an official MCP beta for eligible customers and multiple AI clients.

This timeline provides context for the interface shift. The Cadmus engagement described here is the Copilot MVP; Publer’s current MCP beta is documented separately in its help center.

A useful social media agent needs broad context. It should understand the workspace, recent posts, account performance, hashtags, publishing windows and the campaign brief. A safe social media agent needs narrow authority. It should not guess identifiers, invent metrics, hide failed requests or publish content merely because a model produced it.

The design problem was therefore not “How many API endpoints can we wrap?” It was “What is the smallest set of operations an agent needs to complete a valuable workflow, and what must each operation guarantee?”

The initial scope answered with ten tools and a deliberate stop at drafts. The agent could research, interpret, plan and prepare. Human review remained between preparation and publication.

We reduced the full campaign workflow to three legible stages. Read establishes the operating context and evidence. Reason turns that evidence and a brief into recommendations. Draft writes the approved plan back into Publer without making it public.

This sequence created a mental model for users, a tool taxonomy for the model and a test boundary for engineers. Each stage could be inspected independently, while the campaign prompt could compose the stages into a single guided flow.

The sequence also made failure easier to communicate. If analytics were incomplete, the plan could say so. If draft creation became an asynchronous Publer job, the interface could report progress. If no model provider was available, a deterministic fallback could still demonstrate the workflow.

The MCP surface was intentionally compact. Instead of mirroring every low-level API operation, it exposed the decisions an agent actually needs to make. Discovery tools establish scope. Evidence tools retrieve performance. Synthesis tools produce recommendations. The write path creates drafts and reports job state.

Typed inputs make missing context visible before a request reaches Publer. Normalized outputs reduce provider-specific payload noise. Tool descriptions tell the model when to call an operation and what not to infer from its result.

The result is less like a remote control with every button exposed and more like an operating contract: a small vocabulary whose boundaries can be reviewed by product, engineering and security together.

Agent errors often begin before generation. A request runs against the wrong workspace, a display name is mistaken for an identifier, a page of posts is treated as the complete history, or a raw provider response consumes context without improving the answer.

The Publer client contained those risks behind one boundary. It owned authentication, workspace headers, pagination, timeouts, error parsing and normalized responses. Higher-level services received a stable product model rather than learning Publer’s transport details independently.

That structure let the agent build evidence in order: discover the workspace, identify the accounts, retrieve recent posts, request the available insights and state what could not be known.

Raw metrics do not make a campaign. The analytics layer converted recent post and insight data into a stable summary: what appeared to perform, which formats or themes deserved attention, where the evidence was thin and what an operator could test next.

The campaign service then combined that summary with the brief, brand voice, hashtag evidence and useful publishing windows. Its output was structured enough to preview, edit and pass to draft creation, rather than appearing only as a persuasive paragraph in chat.

A deterministic path could complete the same high-level sequence if the model provider was unavailable. That fallback was not meant to imitate sophisticated creative judgment. It kept the product demonstrable and the system honest about which layer had failed.

The most consequential design decision was also the simplest: content created by the Cadmus implementation entered Publer as a draft. The model could prepare a multi-post campaign, but the public act of publishing remained a separate human decision.

Draft creation still had operational complexity. Platform aliases had to be normalized, media could require upload, and Publer could return an asynchronous job rather than a finished record. The client polled that job with a bounded timeout and reported progress back to the MCP client.

This made waiting visible and authority explicit. The user could see that work was still happening, inspect the resulting drafts in Publer and use Publer’s existing review and scheduling environment for the final step.

The project exposed a standards-compliant MCP server for external clients and a first-party web chat for direct product use. Those surfaces needed different protocols, but they needed the same business behavior.

A dedicated Publer client handled the external API. Analytics and campaign services expressed product logic above it. The MCP server registered tools, the brand resource and the campaign prompt over Streamable HTTP or local stdio. The web API adapted the same operations into provider-compatible function tools for the chat loop.

The implementation proved the reuse pattern, while also revealing the next architectural step: move every operation into a shared application-command layer so MCP, REST and the internal tool adapter cannot drift as the product grows.

A conversational surface can hide too much. The user sees a polished answer while workspace selection, data retrieval, failures and write operations disappear behind a typing indicator. Publer Copilot made the important work visible through context controls, tool progress, campaign previews and draft status.

The web experience organized chat history and workspace context around a primary conversation. Structured campaign output could appear as a reviewable object rather than a wall of prose. Responsive drawers kept the same context available on smaller screens without forcing a desktop control panel into a phone.

The interface used chat for intent and explanation, then switched to cards, lists and statuses when structure mattered. That distinction is essential in agent products: conversation starts the work; product UI makes the work accountable.

The MVP was designed to remain understandable when an optional dependency failed. If detailed insights were unavailable, analytics could fall back to recent posts and attach a limitation note. If the model provider failed, a deterministic campaign path could still exercise the product flow. If persistence was unavailable, the core request could continue without pretending the save succeeded.

Timeouts bounded external calls. Job polling had a clear interval and deadline. Dependency injection made client and service behavior testable without live Publer calls. Tool telemetry was best-effort rather than a new reason for the user’s task to fail.

This is not the same as claiming nothing can go wrong. It is a design for honest failure: preserve useful work where possible, identify the missing layer and never fill an evidence gap with invented certainty.

The project produced a complete working path from workspace discovery to campaign drafts. It made Publer’s existing operations available through a standards-based agent interface and a first-party conversational product, without asking the model to become the system of record.

Ten tools gave the model a compact operating vocabulary. Typed schemas and normalized results contained the API boundary. Progress made asynchronous work visible. Fallbacks preserved the workflow when optional layers failed. Draft-first behavior kept public consequences under human review.

Publer’s help center now documents an official MCP beta for eligible customers and multiple AI clients. That direction shows the relevance of the interface problem. The engagement described here covers the Cadmus Copilot prototype; the current beta is a separate Publer product release.

MCP makes software callable by models. It does not decide which calls are appropriate, what evidence is sufficient or when a person should take over. Those are product decisions expressed through schemas, tool descriptions, permissions, defaults and interface feedback.

Publer Copilot reinforced a principle central to Cadmus’s agent work: the strongest integration does not make the underlying product disappear. It keeps the system of record visible, preserves its rules and gives people a clearer way to direct it.

The protocol creates reach. The boundary creates trust.