This MCP server lets an AI agent read and modify a Concrete CMS site through its REST API, constrained by the signed-in user's permissions.
Inspect the site: account, system info, sites/default site, pages, page versions, blocks, files, users, and groups.
Read page content as HTML/raw HTML/plain text, including areas, custom attributes, and linked files.
Update page content via high-level helpers that create a new editable version, remap block IDs, and update blocks without approving the version.
Manage pages: list, get, add, update, delete, inspect child pages, and manage page versions.
Manage blocks in page areas: add, update, delete, and get/delete blocks by ID.
Manage files: list, upload, get, update metadata, move, and delete.
Manage users and groups: list, get, add, update, delete users, change passwords, and add/get groups.
Run check_connection to verify reachability, pretty URLs, API access, Authorization header, and API integration settings without signing in.
Use bundled OpenAPI-generated tools or replace the OpenAPI spec to expose custom Concrete CMS API endpoints.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Concrete CMS MCP Server show me the page tree"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Use an AI agent, like Claude Desktop, to work with your Concrete CMS site: ask it about your pages, files and users, or let it update your content.
AI agents cannot work with a Concrete CMS site by themselves: they need a connector. This project is that connector: it tells the AI agent what it can do in your site, and it does it on behalf of the agent, using the REST API of Concrete CMS.
You decide what the connector is allowed to do, and it always acts with the permissions of the Concrete CMS user who signed in.
In technical terms, the connector is a Model Context Protocol (MCP) server, built with TypeScript.
There are two ways to use this connector. In both cases your Concrete CMS site can be anywhere.
The connector runs on your computer.
See Local configuration.
The connector runs on a server: always on, and shared by several users.
See Remote server.
Related MCP server: WordPress MCP Server
The MCP server is loading openapi.yml to know which endpoints are available in the Concrete CMS API.
The bundled openapi.yml file is generated from the Concrete CMS default installation, but you can also use your own OpenAPI specification.
If you added some Express Objects to your Concrete CMS installation and want to use them in your chat, you can generate a new OpenAPI specification from your installation and use it instead.
Check "Include this entity in REST API integrations." in the Express Object settings.
Open https://your-concrete.example/index.php/ccm/system/api/openapi.json in your browser, and copy the JSON output.
Replace the openapi.yml file in the concretecms-mcp-server directory with your own OpenAPI specification.
This MCP server is depended on the Concrete CMS API, so it supports all features that are available through the API. For example:
Get information about your Concrete CMS installation.
Get content from your Concrete CMS installation.
Update content in your Concrete CMS installation.
Upload files to your Concrete CMS installation.
Get a list of users in your Concrete CMS installation.
And more!
You can find a list of all available endpoints in Concrete CMS REST API - Endpoints
In addition to OpenAPI-generated tools, the server exposes helpers for common page workflows:
get_page_content — read a page as a document (html, html_raw, and plain text) via includes=content
update_page_content — create an editable page version, remap block IDs, then update specific blocks (PUT page + PUT area)
Prefer these when reviewing or editing page copy. Use the raw OpenAPI tools (getPageById, updateBlockInPageArea, etc.) for lower-level control.
Required OAuth scopes for the update helper: pages:read, pages:update, pages:areas:update_blocks.
The check_connection tool verifies that the connector can work with your Concrete CMS site, without signing in.
To use it, ask your AI agent something like "check the connection to my Concrete CMS site".
It checks that:
the site is reachable
the pretty URLs and the API are enabled
the web server passes the Authorization header to Concrete CMS
the API integration accepts the Client ID, the Redirect URI and the scopes of the connector
For every failed check, it tells how to fix it. It does not check the Client Secret, which is verified when you sign in.
Local configuration: how to run the connector on your computer
Remote server: how to install the connector on a server
Set up the Concrete CMS API: what to configure in your Concrete CMS site
Configuration reference: all the settings of the connector, and when they are needed
Connect an AI agent on your computer to a remote connector: how to use a connector installed on a server from Claude Desktop, ChatGPT, and others
Security: how the tokens and the keys are stored, and how to use the connector safely
For developers:
Test with other MCP clients.
Add useful prompts.
Support another authentication method than OAuth2.
MIT
Adds a block to a page area.
Inputs: pageID (required), areaHandle (required), type, value.
Adds a file object.
Inputs: file, folder.
Adds a Group object.
Inputs: name.
Adds a page object.
Inputs: name, type, parent, template, +2 more.
Adds a user object.
Inputs: email, language, password, username.
Change a user's password
Inputs: userID (required), password.
Check that this connector can work with the Concrete CMS site: site reachable, pretty URLs, API enabled, Authorization header, and the Client ID, Redirect URI and scopes of the API integration. It needs no sign-in. Use it when the user asks to check or troubleshoot the connection, or when the other tools fail with connection or authorization errors. Every failed check comes with how to fix it.
Inputs: no named parameters.
Delete a block by its ID
Inputs: blockID (required).
Deletes a block from a page area.
Inputs: pageID (required), blockID (required), areaHandle (required).
Delete a file by its ID
Inputs: no named parameters.
Delete a page by its ID
Inputs: pageID (required).
Delete a page version.
Inputs: pageID (required), versionID (required).
Delete a user by its ID
Inputs: userID (required).
Make a GET request to /ccm/api/1.0/account
Inputs: no named parameters.
Find a block by its ID
Inputs: blockID (required), includes.
Allows the traversal of the sitemap by showing child pages of a particular page.
Inputs: pageID (required), includes.
Retrieve the default site for your Concrete installation
Inputs: includes.
Find a file by its ID
Inputs: includes.
Returns a list of file objects, sorted by last updated descending. The most recent file objects appear first.
Inputs: limit, includes.
Find a user group by its ID
Inputs: groupID (required).
Returns a list of Group objects, sorted by ID ascending.
Inputs: after, limit.
Find a page by its ID
Inputs: pageID (required), version, includes.
Review a Concrete CMS page as a document. Returns sanitized HTML, raw HTML, and plain text. Prefer this over getPageById with includes=content when summarizing or reading page copy. Does not return areas/blocks.
Inputs: pageID (required), version.
Returns a list of page objects, sorted by last updated descending. The most recent Page objects appear first.
Inputs: after, limit, includes.
Find a page version by its ID and the ID of its page.
Inputs: pageID (required), versionID (required).
Returns a list of page version objects for a given page ID, sorted by date created descending.
Inputs: pageID (required), limit, resultsPage.
Find a site by its ID
Inputs: siteID (required).
Returns a list of site objects, sorted by date added ascending.
Inputs: includes.
Make a GET request to /ccm/api/1.0/system/info
Inputs: no named parameters.
Find a user by its ID
Inputs: userID (required), includes.
Returns a list of user objects, sorted by date added descending. The most recent user objects appear first.
Inputs: after, limit, includes.
Move a file to a new location
Inputs: folder.
Updates a block within a page area.
Inputs: pageID (required), blockID (required), areaHandle (required), value.
Update a file by its ID
Inputs: tags, title, attributes, description.
Update a page by its ID
Inputs: pageID (required), name, type, template, +2 more.
Update page block content safely. Creates a new editable page version (PUT page), remaps block IDs, then updates each block (PUT area). Provide blockID values from the version you inspected. Does not approve the new version.
Inputs: blocks (required), pageID (required), page.
Update a page version
Inputs: pageID (required), versionID (required), is_approved, publish_end_date.
Update a user by its ID
Inputs: userID (required), email, language, username, +1 more.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 38 tools
Most tools target a distinct resource and action, and descriptions clarify subtle boundaries such as get_page_content vs get-page-by-id and update-page-by-id vs update_page_content. A few overlaps remain around page content, page versions, and block deletion, but the set is generally distinguishable.
The tool set mixes kebab-case names such as get-page-by-id and update-user-by-id with snake_case names such as get_page_content and check_connection. The verb-first pattern is mostly readable, but the inconsistent casing/separator style prevents a higher score.
With 38 tools, the surface is heavy for a CMS connector and includes many narrow CRUD variants. The count exceeds the typical 3-15 well-scoped range and pushes toward too many tools for the apparent purpose.
Core page, file, user, group, site, block, and version operations are represented, but important gaps remain: groups lack update/delete, sites lack create/update/delete, and page version approval/publishing is explicitly not covered. These are notable lifecycle omissions that could cause agent dead ends.
Manage your WordPress site from your AI assistant: posts, pages, media, comments and WooCommerce.
Manage WordPress blogs and WooCommerce shops from Claude, ChatGPT, Cursor and other MCP apps.
Manage FireCMS Cloud from an AI agent: Firestore data, collections, schemas and users.
Manage your WordPress site from ChatGPT or Claude: posts, WooCommerce, SEO, images and upkeep.