Connects to a Joomla site running GMC Builder via the Joomla remote API (2.0.1+) using the shared X-Gmc-Builder-Key; supports read-only site listing, authenticated ping, listing up to ten builder element types, and summarizing supplied layout JSON.
Connects to a WordPress site running GMC Builder via the WordPress authoring API (2.0.0+) using an Application Password; supports read-only site listing, authenticated ping, listing up to ten builder element types, and summarizing supplied layout JSON.
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., "@GMC Builder MCP Lite list my configured GMC Builder sites"
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.
Free limited companion to the GMC Pro product. This is a separate 0.1.3 client with a fresh history and only four read-only MCP tools. The Pro implementation is absent from this repository.
Capability | Lite | Pro product |
Configured site aliases | Yes | Yes |
Authenticated connection probe | Yes | Yes |
Up to 10 element types per call | Yes | Extended tools |
Local supplied JSON: node counts/types | Yes, input up to 64 KiB | Detailed inspection |
Create/edit/publish layouts or documents | No | Paid functionality |
Full export/import, bulk editing, backups | No | Paid functionality |
Private Pro implementation or CMS companion source | Absent | Separately distributed |
See Pro features and current annual plans. Contact gmcfuerte@gmail.com for companion requirements or product questions.
Lite is free to use under the limited commercial licence. Source visibility does not grant redistribution or resale rights.
Related MCP server: mysql-readonly-mcp
Open the resource Upgrade to Pro (gmc://lite/pro-features) to see the
capability comparison and the product's current plans. Editing, publishing,
full import/export, bulk editing and restoration are labelled unavailable
in Lite. They are informational previews; no Pro code or executable Pro
tools are bundled. The free tools keep working without an upgrade.
MCP clients decide how resources are displayed, so this is not a guaranteed popup or a graphical settings panel. Ask your assistant to read the resource if its client does not expose a resource browser.
Practical Lite guide (English): prerequisites, setup and a first read-only session.
Presentation for clients (Italian PDF): a short overview of the three Lite clients and the separate Pro editions.
Python 3.10 or newer. GMC Builder installed on the target site: WordPress authoring API (2.0.0+) with an Application Password, or Joomla remote API (2.0.1+) with the shared X-Gmc-Builder-Key. This repository does not distribute GMC Builder. Obtain the CMS product through GMC; no layout-export endpoint is included in Lite.
git clone https://github.com/gmcfuerte/gmcbuilder-mcp-lite.git
cd gmcbuilder-mcp-lite
python -m venv .venvWindows:
.venv\Scripts\python.exe -m pip install .macOS/Linux:
.venv/bin/python -m pip install .This Lite edition is distributed through this GitHub repository; it has not been published to PyPI. Do not install the separate full Pro package as a substitute for Lite.
Copy sites.example.json to a local sites.json and keep only the
sites you own or are authorized to access. The file is ignored by Git.
Set the credential environment variables named by username_env,
password_env, and the applicable Joomla token/key field. Never put
credential values in committed JSON or an MCP chat.
Set GMCBUILDER_MCP_LITE_SITES to the absolute path of that local JSON file.
Add the server using mcp.example.json: replace the placeholders with
the absolute Python executable and configuration file paths. Ensure
the MCP client passes the credential variables to its child process.
Start with gmcbuilder_lite_list_sites, then gmcbuilder_lite_ping_site.
rest_mode: "query" supports WordPress without pretty REST URLs; otherwise
use pretty. Subdirectory installations are supported in the base URL.
gmcbuilder_lite_list_sites: aliases and platforms only.
gmcbuilder_lite_ping_site: one authenticated GET, sanitized status only.
gmcbuilder_lite_list_element_types: List at most ten builder element type names; no schema or kit export.
gmcbuilder_lite_summarize_layout: pass the text from layout.example.json
as layout_json. Returns counts and types; no settings or content.
The server runs locally using stdio. No remote HTTP server, uploads, arbitrary URLs, SSH, license switch or Pro modules are included. Online tools use a fixed GET allowlist, verified TLS, no redirects, at most one request at a time per configured base URL, a two-second interval, and a 1 MiB response limit. HTTP is accepted only for exact loopback hosts. HTTP 403/415 stops subsequent requests to that base URL until restart.
Initial Lite release: source and package contents inspected and Python compiled. Site integration and runtime tests have not been performed. Do not treat this initial release as a production integration certification.
GMC · gmcfuerte@gmail.com. Independent GMC software; product names belong to their respective owners.
List at most ten builder element type names; no schema or kit export.
| Name | Required | Description | Default |
|---|---|---|---|
| site | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the description's contribution is the result cap and the exclusion of schema/kit data, which is useful. That said, 'at most ten' sits awkwardly against a free-form 'limit' parameter, leaving unclear whether larger limits are silently capped, and nothing is said about the ordering or identifier form of the returned names.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with no filler; the scope cap and the negative scope both land immediately. Slightly terse to the point of underspecification, but structurally sound.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with 0% schema coverage, no output schema, and an open-world read, the description is too thin — the meaning of 'site', the effect of 'limit' beyond the stated cap, and the shape of results are all left to guesswork.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning and it largely doesn't. It hints at a cap that bears on 'limit' but never explains the required 'site' parameter — no indication whether it takes a site name, URL, or ID — which is the single most important thing to get right when calling this tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb plus resource: it lists builder element type *names*, and the 'no schema or kit export' clause clarifies the shallow nature of the result. Sibling tools (list_sites, ping_site, summarize_layout) are not named, so the agent must infer separation itself, but the resource is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'no schema or kit export' clause implicitly tells the agent not to reach for this when full definitions are needed, which is a form of negative guidance. However, no positive when-to-use condition and no named alternative are given for the discovery-only case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List configured site aliases and platform names; never expose credentials.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior. The description adds meaningful security context by promising credentials are never exposed, beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. The semicolon-separated security guarantee is compact and useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description sufficiently conveys what is returned (aliases and platform names) and what is not (credentials). Minor format details would be the only incomplete element.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. Nothing further is required or possible.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List') and resource ('configured site aliases and platform names'), making the output scope explicit. It is clearly distinguishable from siblings like list_element_types and summarize_layout, which operate on different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for discovering configured sites but does not state when to choose this over ping_site or other siblings, nor any preconditions. Adequate for a no-param list tool, but no explicit guidance or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform a single authenticated read; return only connection status.
| Name | Required | Description | Default |
|---|---|---|---|
| site | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered. The description adds useful context by noting the call is authenticated and that the response is limited to connection status with no payload, but it says nothing about failure modes (auth errors, timeouts) or what "status" looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence with the key qualifier ("authenticated") and the return scope front-loaded. It earns its place but is arguably over-compressed for a tool whose parameter needs explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description does the right thing by stating the return is only connection status; annotations cover safety. Gaps remain on the site identifier format and on error/status semantics, which matter for a one-parameter connectivity tool with 0% schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single required parameter `site`, so the description carries the full burden of explaining it. It says nothing about whether `site` is an ID, hostname, or URL, nor about format or examples, leaving the only parameter effectively undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb phrase "perform a single authenticated read" plus "return only connection status" conveys a lightweight connectivity/permission check, and the resource is implied only by the tool name and the `site` parameter. It never explicitly states it pings the named site, and the sibling tools are not referenced, so an agent must infer the resource from the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Return only connection status" implicitly contrasts with the list/summarize siblings that return actual data, which hints at using this as a cheap pre-flight check. However, no explicit when-to-use, when-not-to-use, or named alternative is given, leaving the choice to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize supplied JSON node types; never return layout content or settings.
| Name | Required | Description | Default |
|---|---|---|---|
| layout_json | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral information by pre-empting the most likely agent concern for a read tool over a layout: that it will not surface layout content or settings. It does not say what the summary actually contains (counts vs. type names).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact clause-pair that front-loads the action and appends the key output constraint. No filler, nothing repeated from the name or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should characterize the return value; "summarize node types" leaves open whether the agent gets type names, counts, or both. For a single-parameter read tool with rich annotations this is adequate but has a visible gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter with 0% schema description coverage, so the description must carry the burden. It only implies that the input is JSON holding nodes; it never states whether layout_json is a serialized JSON string versus an object, nor what shape the payload must have (e.g. a nodes array).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb (summarize) and resource (node types in the supplied layout JSON), so the agent can tell it operates on a layout payload rather than on a site or the global element-type catalog. It does not explicitly distinguish itself from gmcbuilder_lite_list_element_types, which is a plausible point of confusion for an agent looking for type information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Supplied JSON" weakly implies the preconditions (you already hold a layout payload) and distinguishes it from the catalog-listing siblings by implication only. There is no explicit when-to-use, when-not-to-use, or named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.3gmcbuilder_lite_list_element_typesgmcbuilder_lite_list_sitesgmcbuilder_lite_ping_sitegmcbuilder_lite_summarize_layoutScored across 4 tools
Each tool has a distinct action: enumerating sites, checking one site's connection, enumerating element type names, and summarizing supplied JSON. The only mild overlap is list_sites vs ping_site, both site-scoped, but their descriptions (enumeration vs a single authenticated read returning only status) make the boundary clear.
All four tools follow the same gmcbuilder_lite_verb_noun pattern (list_sites, ping_site, list_element_types, summarize_layout) with consistent snake_case and consistent verb style. No mixed conventions.
Four tools is on the lean side but coherent for an explicitly 'Lite' read-only introspection server; each tool covers a distinct capability. It is slightly thin, with no tool for retrieving a single site's or element type's detail, but nothing is redundant.
The surface covers discovery (sites, element types) and one diagnostic (ping) plus layout summarization, but stops there: there is no way to get details for a specific site or element type, and the descriptions explicitly exclude schema/kit export and layout content. These are deliberate safety limits, yet they leave notable gaps for anything beyond a shallow read.
Read-only MCP access to a documented IT fleet: state, changes, posture. 15 tools.
Audit public webpages and supplied markup for HTML, CSS, SEO, JSON-LD, and link issues.
Read-only MCP server that answers questions about turva.dev from its published data. Five tools return JSON: the service catalog with prices, contact and operator details, engagement principles and dated agent-readiness and security evidence with verification links. Connect over Streamable HTTP. You need no API key. The server does not scan other websites or run audits.
Public AI web-readiness scanner and machine-facing observability discovery service.
