SmartPost used NitroStack to build a read-only MCP application that lets marketers inspect their content calendar, posts, connected accounts and plan usage directly from an AI client.
Customer: SmartPost
Industry: Social Media Management / Marketing Operations
Use case: Conversational access to scheduling and account data
NitroStack role: MCP application framework and visual widget layer
MCP scope: 4 read-only tools
Authentication: Per-user SmartPost API key
Current capability: Calendar, posts, accounts and plan usage
SmartPost already gives marketers one place to plan, queue and publish content across major social platforms.
The MCP question was not how to rebuild that scheduler inside a chat window.
It was much smaller, and more useful.
Could someone ask the operational questions they check every day without opening the dashboard first?
What is going out this week? Which drafts are waiting? Which accounts are connected? Am I getting close to my plan limit?
SmartPost used NitroStack to turn those questions into four read-only Model Context Protocol tools. Each one maps to a job a marketer already understands, while visual widgets turn the returned data into a calendar, post list, accounts panel and usage meter.
The result is not an autonomous social media agent. SmartPost MCP cannot create, edit, schedule, publish or delete a post.
That boundary is part of the product.
Four questions covered most of the useful read-only workflow
A social scheduling API can expose a lot of information.
Posts have statuses, timestamps, accounts, media, provider-specific fields and pagination. Accounts have platform metadata and connection details. Subscription data contains limits and usage. A calendar combines several of those concepts at once.
SmartPost MCP does not push all of that complexity into the conversation.
It exposes four tools:
- get_post_usage
- get_content_calendar
- list_posts
- list_connected_accounts
Each tool answers a recognizable question rather than representing an arbitrary API resource.
get_post_usage answers how much of the user's plan has been consumed.
get_content_calendar answers what is scheduled across a given date range.
list_posts lets the user inspect content by state, such as drafts.
list_connected_accounts gives a safe view of the social profiles connected to SmartPost.
That makes the MCP surface intentionally small.
The model does not need to choose between dozens of narrowly named endpoints to answer a basic marketing question. It gets a small set of tools that correspond to the information the user is actually trying to retrieve.
Plan usage makes more sense when the limit travels with the number
A raw usage count is not very helpful on its own.
If SmartPost reports that a user has 18 queued posts, the next question is obvious: 18 out of what?
SmartPost MCP reports usage in the context of the user's subscription tier.
That matters because the limits differ by plan. SmartPost's current Free plan, for example, includes 30 queued posts, 25 drafts and 7 days of post history. Premium and Pro provide different allowances.
So instead of returning a number that the AI has to interpret separately, get_post_usage can answer the actual question:
How close am I to my limit?
In the recorded fixture used for the MCP demo, the Free account returned 0 of 30 queued posts, 2 of 25 drafts, a 7-day history window and no reached limits.
A usage widget can turn that response into a meter instead of leaving the user to calculate the remaining allowance from JSON.
This is a small design choice, but it reflects the broader approach of SmartPost MCP. The tool output is shaped around the decision the marketer needs to make, not simply around whatever the upstream API happens to return.
The content calendar brings schedule checks into the conversation
Checking the calendar is one of the most repetitive actions in a social scheduling product.
A marketer may not need to change anything. They just need to know what is already going out.
With get_content_calendar, the AI client can request a defined date range and return valid scheduled posts in chronological order. The response explicitly states the covered dates and the timezone used for scheduling.
Timezone handling is important here.
A post without a valid timezone-aware scheduled time should not quietly appear in the wrong place on a calendar. SmartPost MCP accounts for that case and can explain when entries have been excluded because they do not contain a valid scheduled timestamp.
The user can therefore ask a normal question such as:
"What's going out this week?"
The MCP tool deals with the date boundaries and scheduling data behind that request.
This is also one of the places where a visual response is more useful than plain text. A schedule is naturally spatial. Showing the result as a calendar gives the marketer a faster way to understand the week than reading a long sequence of timestamps.
NitroStack's Widget SDK provides the visual layer for these tool responses, allowing SmartPost to keep the conversational entry point while rendering the data in a form suited to the task.
Drafts and connected accounts stay useful without exposing everything underneath
The same principle applies to posts.
A marketer can ask SmartPost MCP to list draft posts, specify pagination and receive the number of matching drafts together with short excerpts and relevant scheduling information.
The tool does not need to return the full internal representation of every post.
For connected accounts, that restraint becomes a security decision.
list_connected_accounts returns the pieces someone actually needs to identify an account, such as the platform, safe handle, display name when available, connection status and total account count.
It deliberately excludes sensitive or implementation-specific fields.
Tokens are not returned.
Credentials are not returned.
Profile URLs and internal provider identifiers are not required for the conversational use case either.
In the recorded demo fixture, SmartPost MCP returned 26 connected accounts across several platforms, including both connected and expired states. The point of that result was not simply that the MCP server could retrieve 26 records. It was that the user could see which accounts were available and which ones needed attention without exposing the underlying credentials used to connect them.
The fixtures themselves were scrubbed from a test account before being used for the demo.
That is the right trade-off for a read-only management interface. Give the model enough information to answer the question. Do not return sensitive fields simply because the upstream API contains them.
Read-only was a product decision, not a missing feature
It would be easy to look at a social media MCP server and immediately ask when it will start publishing posts.
SmartPost MCP deliberately stops before that point.
The current application does not create, edit, schedule, publish or delete posts. It does not connect or disconnect social accounts.
Those operations carry a different level of consequence.
Reading a content calendar and publishing something publicly are not equivalent permissions. Checking whether an Instagram account is connected is different from changing that connection.
By beginning with read-only tools, SmartPost creates a useful MCP surface without giving the conversational client mutation capabilities it does not currently need.
Per-user API key authentication keeps the MCP requests tied to the SmartPost account being queried. The application also controls which fields leave the underlying API response, so authentication secrets and provider details are not pushed back into the conversation.
This keeps the boundary easy to understand:
The AI can inspect the state of the SmartPost workspace. It cannot change it.
For an MCP application, that clarity is valuable.
NitroStack's TypeScript MCP framework gives SmartPost a structured way to define those tools, validate their inputs and attach visual responses without requiring the MCP layer to mirror every capability in the main application.
A dashboard does not disappear just because the data can be queried
SmartPost MCP is not an attempt to replace SmartPost's scheduling interface.
The dashboard remains the place where users create, organize and publish their social content.
MCP adds another route into the information around that work.
A marketer can be in an AI client and ask what is scheduled this week. They can check how many drafts exist before planning another batch of content. They can see which social accounts are still connected. They can ask whether their queue is approaching the allowance of their current plan.
Those are small interactions individually.
Together, they remove a common kind of context switching: opening an application not because you need to work inside it, but because you need one answer from it.
SmartPost's implementation shows a practical way to approach that problem.
Start with the questions users repeatedly ask.
Expose only the data needed to answer them.
Present visual information visually.
Keep sensitive fields out of the model context.
And if the first version only needs to read, keep it read-only.
That gives SmartPost a focused MCP interface around the parts of its product that marketers need to inspect most often. NitroStack provides the MCP and widget layer behind that interface, while SmartPost continues to own the scheduler, account connections, subscription rules and social publishing workflow itself. https://smartpostapp.com/