Concrete CMS MCP Server

get-sites

Read-only

Retrieve a list of sites sorted by date added, with optional inclusion of locales and custom attributes. Use this to manage or inspect Concrete CMS sites.

Instructions

Returns a list of site objects, sorted by date added ascending.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get-sites"
  }
}

Input Schema

Name	Required	Description	Default
`includes`	No	includes parameter

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0-alpha.1Aug 11, 2026

TDQS

B3.4/5.0

Behavior3/5

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

The readOnlyHint annotation already establishes the safe-read profile, so the description's added value is the sort order (date added ascending), which is genuinely useful for result interpretation. It says nothing about pagination, result caps, or whether an empty list versus an error is returned when no sites exist.

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?

One front-loaded sentence with no wasted words. It is efficient, though the brevity comes at the cost of any usage or parameter context.

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 single-optional-parameter read tool with a readOnly annotation and no output schema, the description is minimally sufficient but does not describe what fields a site object carries or how the includes expansion affects the payload. A consumer still needs to probe the response to understand it.

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

Parameters3/5

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

Schema coverage is nominally 100%, but the sole parameter's schema description is the placeholder 'includes parameter', so the schema itself conveys no real meaning for the locales/custom_attributes enum, and the tool description never mentions the parameter at all. Per the high-coverage baseline this stays at 3, though it is a weak 3 given the tokens available to explain expansion behavior.

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 (returns a list of site objects) and adds the ordering rule, which distinguishes it from get-site-by-id and get-default-site. It does not explicitly name those siblings, but the list-vs-single distinction is evident.

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

Usage Guidelines3/5

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

Usage is only implied by the collection semantics; there is no explicit when-to-use guidance, no mention of get-site-by-id for single-site lookups or get-default-site as the alternative for the default site. An agent can infer the choice from the name but nothing in the text helps.

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