Simple Support System MCP

Local MCP server (stdio) for the REST API of the Simple Support System add-on for Concrete CMS. It lets an assistant work a support queue the way a human would: find the ticket, read it with its history, write a reply, move it to the next state. Projects, attachments and moderation are covered as well.

The server talks to any site that runs the package. Nothing is hardcoded, the site URL and the API key come from environment variables. It speaks stdio only and never opens a port.

claude mcp add simple-support-system \ -e SIMPLE_SUPPORT_SYSTEM_BASE_URL=https://support.example.com \ -e SIMPLE_SUPPORT_SYSTEM_API_KEY=your-api-key \ -- node "/absolute/path/to/simple-support-system-mcp/dist/src/index.js"

Or in~/.claude.json/claude_desktop_config.json:

{ "mcpServers": { "simple-support-system": { "command": "node", "args": ["/absolute/path/to/simple-support-system-mcp/dist/src/index.js"], "env": { "SIMPLE_SUPPORT_SYSTEM_BASE_URL": "https://support.example.com", "SIMPLE_SUPPORT_SYSTEM_API_KEY": "your-api-key" } } } }

The API key is generated when the package is installed and lives in the site config undersimple_support_system.api_key. Calls without it run as an anonymous visitor: reading public projects and their approved tickets, creating tickets and writing comments still work, everything administrative (state changes, deleting, approving, projects) does not.

The three everyday tools arelist_tickets,get_ticketandreply_to_ticket, plusset_ticket_stateto move a ticket along.

Reading tools are annotated as read only, the fourdelete_tools as destructive. All of them additionally requireconfirm: true, so a delete cannot happen as a side effect of a vague instruction. There is no trash and no restore on the API side, a deleted ticket, comment or project is gone.

list_tickets { "state": "open", "sortBy": "updatedAt" } get_ticket { "ticketId": 42 } reply_to_ticket{ "ticketId": 42, "comment": "Thanks for the report, we are on it." } set_ticket_state { "ticketId": 42, "state": "in_progress" }

list_ticketsalso takesprojectHandleinstead ofprojectIdand resolves it through the project list first.

- States:new,open,in_progress,on_hold,resolved,duplicate,invalid,wont_fix,closed.set_ticket_stateaccepts all of them exceptnew, which is only set when a ticket is created.
- Types:bug,enhancement,proposal,task
- Priorities:trivial,minor,major,critical,blocker
- Tickets in the stateclosedorinvalidare locked: the API refuses edits of the ticket, its comments and its attachments until the state changes.

upload_attachment { "filePath": "/tmp/screenshot.png" } -> fileId add_ticket_attachments { "ticketId": 42, "fileIds": [123] }

upload_attachmentputs the file into the file manager of the site without linking it anywhere, the second call attaches it.create_tickettakes the same ids inattachmentFileIds.

A private project is only reachable with its access token. Pass it per call astoken, or setSIMPLE_SUPPORT_SYSTEM_PROJECT_TOKENas the default. With an API key the token is not needed, the key already grants full access.

The package answers in several shapes, the server normalises all of them so tools return the bare resource:

- Collections come back as a plain array, single tickets and comments inside aticketorcommentkey, attachments insidedata.
- Failures arrive either as{"errors": [...]}or as a ConcreteEditResponsewith anerrorflag. The second one can come with status 200, so a 200 alone is not treated as success. Every error becomes a tool error with the message the API sent.
- create_ticketanswers with a status envelope and not with the new record, so the id of a freshly created ticket has to be looked up withlist_tickets.
- download_attachmentfollows the redirect the API returns and reports the resolved URL.

The tests run against a stubbed HTTP layer, they never touch a live site and need no credentials. They cover the URL and form encoding the PHP controllers expect (including PHP boolean and array notation), the response envelopes, the error mapping, the filtering and sorting oflist_tickets, and the guard rails of the destructive tools.

An MCP server for WordPress plugin audits

A free WordPress plugin that turns your site into a governed MCP server: 153 abilities that are all off until you switch them on, bound to a least-privilege WordPress user, with every call audited.

Access WordPress.com feeds, notifications, tags, and manage blogs within Claude Desktop.

Connects Claude to WordPress sites to create posts and manage sites using the WordPress REST API.

A personality-based MCP server for WordPress, providing role-appropriate tools for content management.

Lightweight WordPress MCP server with 42 tools. Token-optimized responses reduce REST API verbosity by 95%+. Posts, pages, users, plugins, themes, media, taxonomies, comments.

Manage WordPress sites and create content with AI-generated featured images.

Manage WordPress sites via the REST API. Enables AI assistants to handle content, posts, and site configurations.

A secure bridge between AI assistants and WordPress, enabling site management and content operations through natural language.

The most secure MCP Server for WordPress with built-in Undo