Skip to main content
Glama
gmcfuerte

YOOtheme MCP Lite

by gmcfuerte
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

YOOtheme MCP Lite

Free limited companion to the GMC Pro product. This is a separate 0.1.1 client with a fresh history and only four read-only MCP tools. The Pro implementation is absent from this repository.

Lite and Pro

Capability

Lite

Pro product

Configured site aliases

Yes

Yes

Authenticated connection probe

Yes

Yes

Up to 10 pages 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

YOOtheme MCP Base costs EUR 49/year for three sites (12 months, manual renewal). See current plans.

Lite is free to use under the limited commercial licence. Source visibility does not grant redistribution or resale rights.

Related MCP server: wpagent-mcp

Prerequisites

Python 3.10 or newer. WordPress REST API with an Application Password, or Joomla Web Services with a token. YOOtheme remains a separately licensed product. The generic page list does not prove YOOtheme is installed; layout counts operate on JSON you supply.

Install from GitHub

git clone https://github.com/gmcfuerte/yootheme-mcp-lite.git
cd yootheme-mcp-lite
python -m venv .venv

Windows:

.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.

Configure

  1. 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.

  2. 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.

  3. Set YOOTHEME_MCP_LITE_SITES to the absolute path of that local JSON file.

  4. 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.

  5. Start with yootheme_lite_list_sites, then yootheme_lite_ping_site.

rest_mode: "query" supports WordPress without pretty REST URLs; otherwise use pretty. Subdirectory installations are supported in the base URL.

Tools

  • yootheme_lite_list_sites: aliases and platforms only.

  • yootheme_lite_ping_site: one authenticated GET, sanitized status only.

  • yootheme_lite_list_pages: List at most ten page/article titles, ids and status; no content export.

  • yootheme_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.

Release status

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.

Contact

GMC · gmcfuerte@gmail.com. Independent GMC software; product names belong to their respective owners.

Available Tools

4 tools
yootheme_lite_list_pagesB
Read-onlyIdempotent

List at most ten page/article titles, ids and status; no content export.

ParametersJSON Schema
NameRequiredDescriptionDefault
siteYes
limitNo

TDQS

B3.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnlyHint, destructiveHint, idempotentHint). The description adds the cap of 'at most ten' and clarifies 'no content export,' which is useful scope context not in the annotations. It doesn't mention authentication requirements or error behavior, so it's adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single tight sentence that front-loads the key constraints (titles only, max ten, no content). Every part earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a simple two-parameter read tool with annotations and no output schema, the description covers the core purpose and key output scope. However, it omits parameter details and any guidance about the site context, leaving gaps for an agent using it without prior knowledge.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description doesn't explain the site parameter or the limit parameter's meaning beyond the default. The schema only provides types and a default, leaving the description to compensate and it mostly fails to do so.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a clear verb (list) and specific resource (page/article titles, ids, status). It distinguishes itself from siblings like summarize_layout by clarifying it returns titles only, not content. However, it doesn't explicitly distinguish from yootheme_lite_list_sites, which requires inference from the site parameter.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or when-not-to-use guidance. It implies a read/list use case but doesn't tell the agent when this is preferable to the sibling tools or what prerequisites (like a valid site) are needed beyond the required parameter.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

yootheme_lite_list_sitesA
Read-onlyIdempotent

List configured site aliases and platform names; never expose credentials.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds a genuinely useful constraint beyond them: it guarantees credentials are never exposed, telling the agent the returned payload is sanitized.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with two clauses, both of which carry information (what is listed, and the credential-safety guarantee). No filler, no restatement of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-arg, read-only enumeration tool with no output schema, the description covers both the operation and the shape of the returned fields (aliases, platform names). It could say more about ordering or completeness of the list, but it is adequate as-is.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is no schema semantics to compensate for; the baseline for an empty input schema is 4. Nothing in the description misrepresents the parameter surface.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List configured site aliases and platform names'), so an agent can tell it apart from list_pages, ping_site, and summarize_layout. It stops short of naming which sibling to prefer in ambiguous cases, but the purpose itself is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use, when-not-to-use, or alternative-routing guidance. The agent can infer this is a discovery/enumeration call, but nothing in the text states prerequisites or when another sibling is more appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

yootheme_lite_ping_siteC
Read-onlyIdempotent

Perform a single authenticated read; return only connection status.

ParametersJSON Schema
NameRequiredDescriptionDefault
siteYes

TDQS

C2.8/5.0
Behavior3/5

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, covering the safety profile. The description adds two useful pieces beyond that: authentication is required, and the response is scoped to connection status only (not full site data). Still, it omits failure/timeout behavior for a probe tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler. It is efficient, though slightly under-specified rather than truly economical.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter connectivity probe with annotations covering safety, the definition is minimally adequate. It still leaves the identifier format and the meaning of "connection status" unstated, but the tool's simplicity keeps this a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the single required "site" parameter has no description in either the schema or the tool description. The agent gets no guidance on whether "site" is a URL, hostname, or ID, so the description fails to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description conveys a connectivity/health-check intent ("a single authenticated read; return only connection status"), which is distinguishable from the list/summarize siblings. However, the verb "perform a read" is abstract and the resource being pinged isn't named explicitly, so the purpose is discernible but not crisp.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this tool versus alternatives, no prerequisites, and no mention of the sibling tools. The agent must infer that this is a lightweight connectivity probe rather than a data-fetching call.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

yootheme_lite_summarize_layoutB
Read-onlyIdempotent

Summarize supplied JSON node types; never return layout content or settings.

ParametersJSON Schema
NameRequiredDescriptionDefault
layout_jsonYes

TDQS

B3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description usefully adds an output-scope constraint ('never return layout content or settings'), but with no output schema it still doesn't say what the summary actually contains (counts, node type names, structure).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single tight sentence with the operation front-loaded and the negative constraint second; nothing is wasted. It is arguably too terse for the information an agent needs, but that is a completeness issue rather than verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter, read-only summarizer, the description covers the basic deal ('summarizes node types, returns no content/settings'). However the sole parameter is undocumented and no output schema exists, so an agent must guess the accepted input shape and what a summary looks like.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is one parameter with 0% schema description coverage: layout_json has no description in the schema. The description only implies the input is JSON of nodes, giving no format, encoding, or expected YOOtheme layout structure, so it fails to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb (summarize) and resource (JSON node types of the supplied layout JSON), which is enough to separate it from the sibling list/ping tools that operate on sites and pages. It does not name an alternative or explicitly tie the input to YOOtheme layout JSON, so the resource is slightly underspecified.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description says nothing about when to reach for this tool versus inspecting a layout another way, nor about prerequisites such as needing a layout JSON string obtained from list_pages. Only the operation itself is described.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv0.1.1
    • First observedyootheme_lite_list_pages
    • First observedyootheme_lite_list_sites
    • First observedyootheme_lite_ping_site
    • First observedyootheme_lite_summarize_layout
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored across 4 tools

Disambiguation5/5

Each tool targets a distinct action and resource: listing sites, pinging a site, listing pages, and summarizing layout JSON. No two tools overlap in purpose, and the descriptions clearly delineate their boundaries.

Naming Consistency5/5

All tool names follow the same yootheme_lite_ prefix and snake_case verb_noun pattern (list_sites, ping_site, list_pages, summarize_layout). This consistency makes them predictable and easy to select.

Tool Count5/5

Four tools are appropriate for a 'lite' server focused on safe, read-only introspection. Each tool earns its place without redundancy, and the count is well within the typical 3–15 range.

Completeness3/5

The surface covers listing and basic checks but lacks get operations for individual sites, pages, or layouts, and has no write or update capabilities. While intentional for a lite server, these gaps limit deeper inspection and may force agents to seek other tools.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • WP-MCP

    LAPSrj
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables interaction with WordPress sites through the WordPress REST API, dynamically exposing all routes as MCP tools for content management and site configuration.
    -

  • wpagent-mcp

    THE-KIPDEV
    A
    license
    B
    quality
    C
    maintenance
    Enables MCP-compatible clients to securely operate a WordPress site through a signed REST API, managing plugins, content, themes, menus, media, users, WooCommerce, Elementor, audits, and allowlisted WP-CLI commands.
    58
    59 npm
    MIT

  • mcp-tools

    stef7
    F
    license
    Not graded
    quality
    B
    maintenance
    Provides MCP servers to interact with WordPress sites via REST API, supporting multiple sites and aggregated tools.
    -