Connect your AI client over MCP: the six tools
NioConnect can be added to an AI client as an MCP server. The server offers six tools: five that only read, and one that saves a draft. This is what each one does and where the limits are.
The NioConnect teamUpdated 5 min readOn this page
What MCP gives an assistant
MCP is a standard way for an AI client to call tools that live somewhere else. Once NioConnect is added, the assistant can ask your workspace questions and propose posts, using the same services the web app uses. There is no second, looser path for assistants.
The server works with exactly one workspace: the one the connection belongs to. Every tool sees that workspace and nothing else.
The six tools
These are the tool names exactly as a client sees them. Five are read only. One writes, and what it writes is a draft.
| Tool | Access | What it does |
|---|---|---|
list-channels | Read | The accounts the workspace publishes to, with the id other tools need and whether each connection is healthy |
get-platform-rules | Read | What one platform accepts: media, threads, polls, communities and the extra settings a post needs |
list-posts | Read | A page of posts, newest first, including ones waiting on a teammate to approve |
list-workflows | Read | The workflows that copy one channel to another, with status, schedule and counters |
get-workflow | Read | One workflow by id: its channels, status, schedule and when it posts next |
create-post | Write | Saves a post to the calendar, as a draft unless a time is given |
A draft by default
The write tool is deliberately cautious. Without a time, create-post saves a draft, and a draft goes nowhere until a person opens NioConnect, reviews it and sends it. With a time, it schedules the post, and unless your workspace requires approval a scheduled post goes out at that time with nobody reviewing it first.
A time that has already passed is refused. There is no publish now option, no argument for it and no second tool for it: the server saves drafts and schedules, nothing more. And if a post is too long for one of its platforms, the tool refuses and names the limit, and nothing is saved.
Scheduling skips the human step unless approvals are on. Tell your assistant to leave posts as drafts unless you give a time yourself.
Two ways to connect
Which way you connect depends on the client. Some take a remote address and send you to NioConnect to sign in and press Allow. That connection acts with the role of the member who pressed Allow, checked again on every call. Others take a key in a config file. A key acts with the permissions of the member who created it, has no scopes, is shown once and can be revoked at any time.
Setup steps for each client are on the AI and MCP pages, and the guide to creating and revoking a key covers the key path. Use a separate key for each tool, so revoking one leaves the others alone.
A worked example
Say you ask an assistant to draft a launch post for Bluesky and Mastodon and not to schedule it. A well behaved assistant does roughly this, one tool at a time.
- It calls
list-channelsto find the ids of your Bluesky and Mastodon channels, and notes whether either connection is unhealthy. - It calls
get-platform-rulesfor each platform, so it writes inside what that platform accepts. - It calls
create-postonce, with the text and the two channel ids and no time. The result is a draft on your calendar. - You open NioConnect, read the draft in the composer with its per channel previews, and send it or change it.
To create several posts the assistant calls create-post once per post, and two identical calls create two posts. If something looks doubled, check the calendar before you ask again.
When a tool says no
Refusals are written for a model to read, so they say what to do next. A post too long for one of its platforms is refused with the limit named, and nothing is saved. A publish time that has already passed is refused. A cursor the server did not issue is refused with an instruction to start again from the newest page. An unexpected failure becomes a plain sentence, never a stack trace, and the assistant is told to say so rather than retry blindly.
Reading is just as bounded. list-posts returns a page at a time with a cursor for the next one, so an assistant should not assume the first page is the whole workspace.
Asking for things that work
The tools read well from plain requests. A good habit is to let the assistant look before it writes: list the channels, check what the platform accepts, then draft.
Which of my channels are connected, and are any unhealthy?
What does Bluesky accept in a post?
Draft a launch post for Bluesky and Mastodon. Do not schedule it.
What is scheduled this week, and is anything waiting on approval?Good habits
Create a separate key for each tool, so you can revoke one without disturbing the rest. Revoke a key as soon as a job is done: access ends immediately. Skim your calendar after a session, because a draft is quick to read and quick to delete.
And if a client offers a remote connection, prefer it. You sign in, press Allow, and nothing is pasted and nothing is stored on your side.
What the assistant cannot do
It cannot read another workspace, act above the role it was given, or publish immediately. It cannot create or change a workflow: workflows can be listed and inspected, not written. And its posts go through the same validation, approval and publish checks as yours. If your workspace needs review, an assistant draft waits for review too. Connecting an AI client without losing control goes deeper on that side of it.
Written by The NioConnect team.
Posts that say why they failed, on one calendar.
Start 7-day trial