Skip to content
Swingback, home
Docs / MCP server

MCP server

Let AI agents such as Claude, ChatGPT and Claude Code search your feedback, triage posts and draft changelog entries, through the Model Context Protocol (MCP).

The server gives an agent 16 tools, shaped as tasks: 9 that read and 7 that write. They act on one workspace, the one the agent was connected to, and on nothing else. Settings → MCP server has the steps for each agent, with the values to copy.

The endpoint#

POST https://api.swingback.dev/v1/mcp

The server speaks MCP's Streamable HTTP transport without sessions: each message is its own POST, answered in JSON. It serves clients of the protocol's 2026-07-28 revision, and older clients that start with initialize.

An agent proves who it acts for in one of two ways:

  • By signing in (OAuth). The agent sends you to Swingback, where you choose the workspace and what it may do. Claude's and ChatGPT's connectors connect this way, and so can Claude Code, Codex and Gemini CLI.
  • With an API key, sent as a bearer token. Any client that can send a header connects this way.

What an agent may do#

Its access decides, whether it comes from a key or from what you allowed when it signed in:

  • Read has the reading tools only: questions about your feedback, roadmap and changelog.
  • Read and write also has the writing tools, which act at once. An agent can comment publicly and change a post's status, and the post's followers hear of both, by email too. It can edit changelog entries, published ones included.

Give an agent the least access it needs: what it reads includes what your customers wrote, and that text may try to steer it.

An agent does what the member who created its key, or allowed it, may do, and it stops working when they leave the workspace. What it writes shows as that member's, unless it names a customer. See What an agent can't do for what no access gives.

Connect by signing in#

Owners and admins allow an agent. When it connects, it opens Swingback in your browser:

  1. Sign in, if you aren't.
  2. Check the app's name, and its domain when Swingback could verify it.
  3. Choose the workspace, and Read or Read and write: at most what the app asked for.
  4. Click Allow. The browser goes back to the agent, connected.

The agent then acts as an API key of yours would, in that workspace only. An app allowed to read asks again before it writes. A connection ends after 30 days without use.

Settings → MCP server lists the connected apps: who allowed each, its access and when it was last used. Revoke stops one at once. A workspace has up to 100 connected apps.

Claude#

On the web, the desktop and the mobile apps:

  1. In Claude, open Customize → Connectors.
  2. Click + Add, then Add custom connector.
  3. Enter a name, such as Swingback, and the endpoint as the remote MCP server URL. Click Continue.
  4. Keep the sign-in Claude detected, click Continue, then Add.
  5. Connect it, and allow it in Swingback.

On a Team or Enterprise plan, an owner adds the connector under Organization settings → Connectors, and members then click Connect.

ChatGPT#

  1. Open ChatGPT's plugins, at chatgpt.com/plugins.
  2. Select the plus button, then Add custom MCP server.
  3. Enter a name and a description, and the endpoint under Connection.
  4. Set the authentication to sign in, review the warning, and select I understand and want to continue.
  5. Select Create as a plugin, install it, and allow it in Swingback.
  6. In a new conversation, type @ and select the plugin.

Your ChatGPT account's and workspace's policies decide whether you may add a custom MCP server.

Claude Code#

claude mcp add --transport http swingback https://api.swingback.dev/v1/mcp

Then run /mcp in Claude Code and sign in in your browser.

Codex#

codex mcp add swingback --url https://api.swingback.dev/v1/mcp
codex mcp login swingback

The Codex CLI, its IDE extension and the ChatGPT desktop app share these settings.

Gemini CLI#

gemini mcp add --transport http swingback https://api.swingback.dev/v1/mcp

Then run /mcp auth swingback in Gemini CLI and sign in in your browser. The command keeps the server for the project you run it in; add -s user to have it in all of them.

Other clients#

A client that signs in to MCP servers finds everything from the endpoint: the server answers 401 with where its metadata is. It registers itself, with a client ID metadata document or by dynamic registration, so there is no client ID or secret to copy, and it proves itself with PKCE (S256). For a client that asks:

Authorization server      https://api.swingback.dev
Its metadata              https://api.swingback.dev/.well-known/oauth-authorization-server
The MCP server's own      https://api.swingback.dev/.well-known/oauth-protected-resource/v1/mcp
Authorization endpoint    https://api.swingback.dev/oauth/authorize
Token endpoint            https://api.swingback.dev/oauth/token
Registration endpoint     https://api.swingback.dev/oauth/register
Scopes                    read write offline_access

offline_access is for a refresh token. Settings → MCP server → Manual shows the same for your server.

Connect with an API key#

Create the agent's key under Settings → API keys (see REST API), with Read or Read and write access. The client sends it on every request:

POST https://api.swingback.dev/v1/mcp
Authorization: Bearer $SWINGBACK_API_KEY

Claude Code, with a key#

claude mcp add --transport http swingback https://api.swingback.dev/v1/mcp --header "Authorization: Bearer $SWINGBACK_API_KEY"

Your shell fills in the key from SWINGBACK_API_KEY, and Claude Code keeps it in its settings. The dialog that creates a key shows this command with the key already in it.

Codex, with a key#

In ~/.codex/config.toml, with the key in the SWINGBACK_API_KEY environment variable:

[mcp_servers.swingback]
url = "https://api.swingback.dev/v1/mcp"
bearer_token_env_var = "SWINGBACK_API_KEY"

Gemini CLI, with a key#

gemini mcp add --transport http --header "Authorization: Bearer $SWINGBACK_API_KEY" swingback https://api.swingback.dev/v1/mcp

Any other client, with a key#

A client that speaks the Streamable HTTP transport and can send a header connects the same way: the endpoint, and an Authorization header with Bearer and your API key.

A page in a browser can't connect: a request with an Origin header is refused (403), whichever way it proves itself.

Then ask your agent things like "Which planned posts do our most valuable customers want?" or "Summarize the comments on #42".

Tools#

Reading tools, for every access#

ToolWhat it does
list_postsLists or searches posts (typos allowed) by board, status, tag or author, sorted by date, votes, trend, customer value or relevance. Each has its status, votes, comments, tags, board and the start of its text.
get_postA post with its whole text, by id or by number (12 or #12).
list_commentsA post's comments, oldest first: the public ones and your team's internal notes, marked as such.
list_boardsThe workspace's boards.
list_tagsThe tags, for posts and for changelog entries.
list_changelog_entriesThe changelog's entries, newest first: drafts, scheduled and published, with their summary and the posts they announce.
get_changelog_entryA changelog entry with its whole text.
find_end_userA customer, by their id in your system or by email.
find_companyA company, by its id in your system: its value and its number of members.

Writing tools, for read and write access#

ToolWhat it does
create_postCreates a post on a board, from a customer (by their id in your system or their email) or, without one, from the agent's member.
update_post_statusMoves a post to another status, with an optional note.
add_post_tagsAdds tags to a post; it keeps the ones it has.
add_commentComments on a post publicly, or adds an internal note that only your team sees.
create_changelog_entryDrafts a changelog entry, optionally announcing posts.
update_changelog_entryChanges an entry's title, summary, text or tags.
link_changelog_postsAdds posts to those an entry announces; it keeps the ones it has.

Results link to the portal and the dashboard. They name people by id, name and kind; only find_end_user returns an email. When a tool fails, the agent reads why, such as not_found: The requested resource does not exist.

What an agent can't do#

No tool deletes, merges, moderates or publishes, and none touches settings, members, API keys or billing: those stay in the dashboard and the REST API. An entry an agent drafts stays a draft until your team publishes it.

The writing tools still act at once, and some reach people:

  • update_post_status and a public add_comment notify the post's followers, by email too.
  • update_changelog_entry edits published entries as well: the change shows in your portal right away.

What an agent writes has the source api, like a key's REST calls. A post or comment that names no customer shows as written by the member who created the key, or allowed the app. An internal note is always the team's.

Audit and limits#

Each tool call records an mcp.tool_called event: the key or the connected app, the tool, and whether it worked or the error's code. It never records what the agent sent, which holds your customers' text. The changes themselves record their own events, as a key's REST calls do.

Tool calls count against a rate limit of 300 requests a minute: a key's, shared with its REST calls, or a connected app's own.