Creates a new user group in Concrete CMS by specifying the group name.
Adds a Group object.
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": "add-group"
}
}| Name | Required | Description | Default |
|---|---|---|---|
| name | No |
Changes observed during successful MCP inspections.
v1.0.0-alpha.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=true, so the mutation/safety profile is covered structurally. The description adds nothing on top of that: no note on what is created, whether the name must be unique, permission requirements, or what happens on duplicate or empty input. It does not contradict the annotations, but it contributes zero behavioral context.
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?
The single sentence is front-loaded and free of waste, so it satisfies the structural test. The problem is under-specification rather than verbosity, which keeps it at minimum-viable rather than strong.
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 mutating create tool with no output schema and an undocumented parameter, the description supplies nothing an agent needs to call it correctly. It does not even state that a name should be provided, even though the schema marks no required fields.
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 parameter "name" (title only, "Group Name"), so the description is the only place semantics could be supplied. It says nothing about the name — no uniqueness constraint, format, length, or whether it is effectively required despite required=[] — leaving the parameter meaningfully under-specified.
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?
"Adds a Group object" restates the tool name and title almost verbatim, so an agent learns nothing it could not infer from the identifier. It does name a verb and resource, but there is no scope, no definition of what a Group is, and no differentiation from siblings like add-user or add-page.
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?
There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as get-group-by-id or get-groups for checking whether a group already exists. Usage is only implied by the word "Adds".
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.