Concrete CMS MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools clearly target a distinct resource and action, such as page CRUD, user management, or block operations. However, get_page_content and update_page_content could be confused with get-page-by-id and update-page-by-id, since both relate to page content, though the descriptions help differentiate them.
Naming Consistency3/5
The dominant pattern is hyphenated lowercase verb-noun (e.g., list_files, add_group), but two tools break this with snake_case: get_page_content and update_page_content. This mixed convention makes the naming inconsistent, though the majority is predictable.
Tool Count2/5
With 37 tools, this server exceeds the typical scope for an MCP server. While it covers many CMS entities (pages, files, users, groups, blocks, sites), the number feels heavy and could be consolidated; it goes beyond the 'borderline heavy' range.
Completeness4/5
The tool surface provides solid coverage for pages, page versions, blocks, files, and users with CRUD operations and content-specific tools. Obvious gaps include missing update/delete for groups and lack of site management beyond read operations, but these are minor for the core CMS domain.
Average 3.1/5 across 37 of 37 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
- 5 of 7 community issues answered or closed in the last 6 months
- 49 commits in the last 12 weeks
- Last stable release on August 18, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry full behavioral disclosure. It only states a high-level add operation, with no mention of whether it uploads binary data, requires authentication, returns a file ID, or handles existing files. This is critically insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but under-specified. Being concise is not the same as being uninformative; this single sentence is too vague to serve as a useful tool guide.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters, no annotations, and no output schema, the description is severely incomplete. It does not explain required versus optional fields, expected return values, error behavior, or how the operation integrates with the rest of the API.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter-level meaning. It does not explain the 'file' binary parameter or the 'folder' integer parameter beyond their names/titles, leaving the agent to guess their relationships and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Adds a file object' essentially restates the tool name 'add-file' without specifying what the file is added to, what kind of file object is expected, or how it differs from sibling tools like add-page or move-file-to-location. It is a tautological restatement with no added clarity.
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 guidance on when to use this tool versus alternatives like move-file-to-location or get-files. No context, prerequisites, or scenarios are provided, so an agent has no basis for choosing this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Adds a user object' only implies mutation but does not mention permissions, idempotency, duplicate handling, side effects, or output. This is a significant gap for a create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short, it is under-specified rather than concise. It adds no information beyond the tool name, so the single sentence does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a 4-parameter create operation with no annotations and no output schema, this description is wholly inadequate. It fails to convey required inputs, behavioral context, or return value expectations, making the tool nearly unusable without external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters with 0% description coverage, and the description mentions none of them. It does not compensate for the missing schema documentation, leaving the agent to guess the meaning and requirements of email, language, password, and username.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Adds a user object.' essentially restates the tool name 'add-user' without adding any detail. It identifies the resource but fails to distinguish it from other add-* tools beyond the resource type, making it close to a tautology.
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 guidance is provided on when to use this tool versus alternatives like add-page or update-user-by-id. There is no mention of prerequisites, typical scenarios, or exclusions, leaving the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It gives none: no mention of required permissions, side effects, validation rules, or how the page object is created. The single sentence is entirely insufficient for a creation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse, but under-specification is not conciseness when key information is omitted. It provides a single generic sentence that fails to earn its place by adding useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, nested attributes, and no output schema, one sentence is grossly inadequate. The description covers neither the return format nor any constraints, and fails to contextualize the tool among its many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, and most parameter meanings are left to their titles. The description adds no explanation for 'name', 'parent', 'attributes', or 'description', and provides no help for the nested attributes object, leaving the agent to guess.
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 'Adds a page object' restates the tool name with minimal added specificity. It identifies the action and resource but does not differentiate this from other 'add' tools beyond the resource name, nor explain what a 'page object' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like add-file, add-group, or add-block-to-page-area. The description doesn't mention prerequisites, use cases, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the tool's intent without mentioning side effects, idempotency, duplicate handling, or permissions. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is under-specified rather than concise. It lacks essential detail and does not earn its place by adding meaningful value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, a minimal description might suffice, but 'Adds a Group object' is wholly inadequate. It does not describe return values, side effects, or the context of the group being added, and there is no output schema to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'name' parameter at all. The agent is left without any explanation of what the 'name' parameter is for, whether it is required, or any constraints on its value.
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?
The description 'Adds a Group object.' clearly states the action (adds) and the resource (Group object). It distinguishes from siblings like add-file and add-page through the specific resource type, but lacks any scope or context beyond the bare statement.
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 provides no guidance on when to use this tool versus alternatives such as get-groups or update-group. There are no context clues, prerequisites, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but states only the action 'move' without explaining side effects, required permissions, or confirmation behavior. It does not mention whether overwriting occurs, what happens to the original, or any error conditions. This leaves significant behavioral uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with no wasted words, which is structurally concise. However, it under-specifies by omitting essential details about the destination and parameters, making it too terse to be fully useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the minimal schema (1 param, no descriptions) and lack of output schema or annotations, the description should thoroughly explain the tool's behavior and parameter semantics. It fails to define what 'location' means, how the folder parameter relates to it, or any expected return values, leaving the tool incomplete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'folder' with 0% description coverage, and the description adds no meaning for it. The tool description does not mention the folder parameter at all, so the agent cannot infer that 'new location' refers to a folder ID. This is a critical gap for correct invocation.
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?
The description clearly states the verb 'Move' and the resource 'a file', making the primary purpose understandable. It also distinguishes from sibling tools like add-file or update-file-by-id by implying a relocation action. However, it leaves 'new location' vague without clarifying it refers to a folder destination.
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 provides no guidance on when to use this tool versus alternatives, such as update-file-by-id or copy operations. There are no use-case scenarios, prerequisites, or exclusions mentioned. Users are left to infer when moving a file is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only says 'Update a page version'. It fails to disclose permissions, side effects, reversibility, or what specific changes occur, offering minimal behavioral insight beyond implying a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise but under-specified. While it has no wasteful words, it is too short for a tool with 4 parameters and no annotations, making it more of an under-specification than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, and only partial schema coverage, the description is insufficient. It does not explain return values, behavioral effects, or parameter roles, leaving significant gaps for the agent.
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 50%, with only pageID and versionID having minimal descriptions. The description adds no parameter meaning, failing to clarify the purpose of is_approved and publish_end_date, despite needing compensation for the low coverage.
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?
The description 'Update a page version' clearly states the verb and resource, and it distinguishes from sibling tools like get-page-version and delete-page-version. However, it does not specify which fields can be updated, limiting specificity.
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 guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, recommended contexts, or exclusions, leaving the agent without direction on selecting this tool over related ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only says 'Update a file' without disclosing whether this is a partial update (PATCH) or a full replacement, what permissions are required, whether changes are reversible, or what happens to unspecified fields. The mutation side effects are completely opaque.
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?
The description is a single, direct sentence that states the action and target. It is concise with no filler. However, it is under-specified, which slightly detracts from the effectiveness of its conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and minimal description, the tool is incomplete for the agent. It does not explain the update semantics (e.g., whether attributes are merged or replaced), nor does it describe the response or errors. The 4 parameters and nested object require more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only 'title' has a description). The description text provides no explanation of parameters like 'tags', 'attributes', or 'description'. It also fails to clarify the nested 'attributes' structure or accepted formats, leaving the agent to guess.
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?
The description clearly states the verb 'update' and the resource 'file', with 'by its ID' specifying the identifier. This distinguishes it from add-file, delete-file-by-id, and get-file-by-id siblings. However, it does not list which file properties can be updated, leaving the full scope vague.
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 guidance on when to use this tool versus alternatives. It does not mention that this is for updating file metadata (e.g., title, tags, description, attributes) or that file content is not affected. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only states the action without revealing side effects (e.g., session invalidation), permission requirements, or consequences. This is insufficient for a state-changing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no wasted words. However, it is under-specified, lacking important context like usage conditions or parameter semantics, which makes it less effective as a complete specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It does not explain the impact of the password change, any required permissions, or expected return values, leaving the agent under-informed for safe invocation.
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 coverage is 50% (userID has a description, password only a title). The description adds no parameter details, leaving the 'password' parameter unclear (e.g., format, minimum length, or purpose). It does not compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Change') and resource ('user's password'), clearly stating the action. It distinguishes from sibling tools like update-user-by-id by focusing specifically on password changes rather than general user updates.
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 provides no guidance on when to use this tool versus alternatives, such as update-user-by-id or add-user. There are no mentions of prerequisites, exclusions, or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It only says 'Update a page by its ID,' which implies mutation but does not clarify whether it is a partial or full update, what permissions are required, side effects on existing attributes, or response behavior. This is a significant gap for a write operation.
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?
The description is a single sentence that is grammatically clear and front-loads the verb and object. It is very concise with zero wasted words, though it borders on under-specification. Given the emphasis on avoiding bloat, this structure earns a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex—6 top-level parameters, a nested attributes object, and no output schema—yet the description provides only a one-line overview. There is no mention of the request payload format, update semantics, or typical use cases, making it severely incomplete for an agent to invoke correctly.
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?
The description adds no parameter-level meaning. The schema has 50% coverage, with descriptions for pageID, type, and template, but the 'name' parameter has a confusing title 'ID' that is not clarified, and 'attributes' and 'description' lack descriptions entirely. The description fails to compensate for these gaps or help the agent understand parameter roles.
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?
The description clearly states the action (update) and resource (a page), with the ID as the locator. However, it does not specify which aspects of the page can be updated (e.g., type, template, attributes), nor does it differentiate from the sibling tool update_page_content, so it falls short of a high specificity score.
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 provides no guidance on when to use this tool versus alternatives, no context for appropriate scenarios, and no exclusions. It is a single statement without any usage direction, which offers minimal help in tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. The description only states that a block is added, but does not mention side effects, permission requirements, ordering with existing blocks, or whether the operation is reversible. For a mutating tool, this is a significant transparency gap.
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?
The description is a single, direct sentence with no wasted words. It is concise and front-loaded, stating the core action immediately. However, it may be too sparse to fully convey necessary context, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, includes a nested object, lacks annotations, and has no output schema. A one-sentence description is insufficient to cover these complexities. Missing details include required parameters, behavior of type and value, return values, and relationship to sibling block tools, making the description inadequate for an agent to confidently invoke the tool.
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?
The schema already provides descriptions for 3 out of 4 parameters (pageID, areaHandle, value), giving baseline coverage. The description itself adds no parameter information. The 'type' parameter lacks a description in the schema, and the tool description does not compensate, but overall schema coverage is sufficient to warrant a mid-range score.
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?
The description clearly states the action: adding a block to a page area. The verb 'adds' and the resource 'block' with the location 'page area' specify the operation. However, it does not explicitly distinguish this tool from sibling tools like update-block-in-page-area or delete-block-from-page-area, so it falls short of a 5.
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 provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or cases where update-block-in-page-area or delete-block-from-page-area would be preferable. The user is left to infer usage solely from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. For a destructive operation like deleting a page version, it fails to mention permanence, side effects, required permissions, or any consequences. The single sentence is not transparent.
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?
The description is a single, efficient sentence with no unnecessary words. It is front-loaded and appropriately sized for a simple operation, though it lacks substance that would affect other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is too minimal. For a destructive tool, it should explain return behavior, irreversibility, or error scenarios to be considered complete. The current description leaves many operational questions unanswered.
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 description coverage is 100% since both parameters (pageID and versionID) have descriptions. The tool description adds no additional meaning beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('a page version'), which distinguishes it from sibling tools like get-page-version or update-page-version. It fully conveys the tool's core function.
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 provides no guidance on when to use this tool versus alternatives, prerequisites, or scenarios where deletion might be inappropriate. It simply states the function without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states that it finds a file by ID, implying a read operation but not disclosing any details such as response format, error behavior, or how the 'includes' parameter affects results. This is minimal behavioral disclosure, so score 2.
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?
The description is a single front-loaded sentence with no unnecessary words. It efficiently states the core purpose, though it may be too brief for other dimensions. For conciseness and structure, it earns 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool description is extremely minimal. It lacks context about the optional 'includes' parameter, return behavior, or when to choose this over the sibling get-files or other file tools. Given the simplicity of the schema and lack of annotations/output schema, the description is not adequately complete for an agent to fully understand usage, so score 2.
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?
The schema covers the only parameter with a description ('includes parameter'), providing 100% coverage. Since the description adds no parameter semantics beyond the schema, a baseline of 3 is appropriate.
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?
The description clearly states the tool's function with a specific verb ('Find') and resource ('file') identified by ID. This inherently distinguishes it from sibling tools like add-file, update-file-by-id, and delete-file-by-id, though it doesn't explicitly name alternatives. The purpose is unambiguous but lacks explicit sibling differentiation, so 4.
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 provides no guidance on when to use this tool versus alternatives. It does not mention that get-files lists files without an ID, or that this tool requires a known ID. There is no when-to-use or when-not-to-use context, so score 2.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only states 'Find a page by its ID' and does not mention default version behavior, response shape, error handling, or authentication requirements. The schema provides some parameter context, but the description itself adds zero transparency beyond the tool's name.
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?
The description is a single, perfectly concise sentence with no redundant words. It is well-structured and front-loaded, but is so terse that it omits potentially useful context, though this does not detract from its conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 3 parameters and no output schema or annotations, the description remains minimal. It fails to explain version defaults, includes behavior, or what a successful response contains. The schema covers parameter semantics, but the overall tool context is incomplete, especially for an agent deciding how to handle the response.
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 description coverage is 100% with clear descriptions for pageID, version, and includes. The description adds no additional parameter meaning, but per rubric baseline for high coverage is 3, so the schema already carries the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Find a page by its ID' uses a specific verb ('find') and resource ('page') with an explicit identifier, clearly stating the tool's function. It distinguishes from sibling get-by-id tools by specifying 'page' rather than group, site, user, file, or block, and from get-page-version-by-page-id-and-version-id by targeting pages rather than versions.
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 provides no guidance on when to use this tool versus alternatives like get-pages, get-page-version-by-page-id-and-version-id, or get_page_content. It does not mention prerequisites, common use cases, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only says 'Update' without explaining side effects, permissions, partial update behavior, or return value. This is a significant gap for a mutation 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?
The description is extremely concise and front-loaded, using a single sentence that immediately conveys the core action. However, it is so brief that it borders on under-specification, which is why it does not receive a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters with nested objects, no annotations, no output schema, and low schema coverage, the description is incomplete. It fails to provide essential context about what fields can be updated, how attributes are structured, or what the response will be, making it insufficient for reliable tool invocation.
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?
The schema description coverage is only 20% (only userID has a description). The description does not compensate by explaining the other parameters (email, language, username, attributes). It adds no meaning beyond the schema's titles, leaving the agent uncertain about parameter roles and validation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a user by its ID' clearly states the action (update) and resource (user by ID). This distinguishes it from sibling tools like add-user, delete-user-by-id, get-user-by-id, and change-user-password.
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 usage guidance is provided. The description does not mention when to use this tool versus alternatives, nor does it state any exclusions or prerequisites. An agent is left to infer that this is the update tool without context on partial vs. full updates or required parameters beyond userID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are none, so the description carries the full behavioral burden. For a destructive operation, the description does not disclose whether deletion is permanent, whether special permissions are needed, what happens if the file is not found, or any side effects. It merely restates the tool name without adding transparency.
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?
The description is a single, focused sentence that wastes no words. It earns its place by succinctly stating the tool's core function, achieving high conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and no parameters documented, the description falls short of providing sufficient context for a destructive tool. It omits critical behavioral details like permanence, error handling, and impact on related resources. The tool is simple, but the lack of any supplementary context makes it incomplete.
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?
The input schema has 0 parameters, yet the description mentions deletion 'by its ID', implying the existence of an ID that is not in the schema. While the baseline for 0 parameters is 4, the description introduces a potential mismatch and does not explain how the ID is passed. The description adds minimal meaning beyond the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a file by its ID' clearly states the action (delete), the resource (file), and the identifier (ID). It distinguishes this tool from siblings like add-file, update-file-by-id, and get-file-by-id, making its purpose 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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of irreversibility, prerequisites, or exclusions (e.g., 'use move-file-to-location instead of delete if you want to keep the file'). The implied usage is apparent from the name, but the description offers no additional context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Find,' which implies a read operation. It does not mention whether the operation is read-only, what happens if the version is not found, response format, or any error conditions.
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?
The description is a single sentence of 14 words, front-loaded with the verb 'Find' and immediately specifying the target. Every word earns its place with no redundancy.
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 simple two-parameter get operation, the description is minimally adequate, but it omits the return value or any distinction from the closely related 'get-page-versions-by-page-id' tool. Given the lack of annotations and output schema, the description leaves gaps in what the agent can expect.
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?
The description adds modest value by explaining that versionID is the version's own ID and pageID is the ID of the containing page. However, the schema already has 100% coverage with descriptive parameter names, so the addition is marginal and only slightly clarifies the relationship.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds a single page version using both the version ID and the page ID, making the operation specific and distinct from the plural 'get-page-versions-by-page-id' sibling. The verb 'Find' and resource 'page version' are 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?
No guidance is provided on when to use this tool instead of alternatives like 'get-page-versions-by-page-id' or how it relates to update/delete version tools. There is no mention of exclusions or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral transparency, but it only restates the tool's purpose. It does not mention side effects, permissions, error conditions, or whether the update replaces or merges existing data. This is a critical gap for a mutation 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?
The description is a single, direct sentence that is easy to parse and free of fluff. However, it adds no information beyond the tool name, so it is concise but not particularly useful, hence 4 rather than 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a complex nested parameter (value), no output schema, and no annotations, the description is too sparse. It lacks preconditions, what the update does to the block, response format, and limitations, making it incomplete for an agent to invoke correctly.
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 description coverage is 100%, so the baseline is 3. The description adds no extra parameter context, but the schema already provides descriptions for all parameters, including the nested 'value' object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Updates') with a clear resource ('a block within a page area'), distinguishing it from sibling tools like add-block-to-page-area and delete-block-from-page-area. It accurately reflects the tool's function.
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?
The description gives no explicit guidance on when to use this tool versus alternatives. However, the tool name and sibling context (e.g., add-block-to-page-area, delete-block-from-page-area) imply it is for modifying existing blocks, so usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'Delete a block by its ID' without mentioning whether deletion is permanent, cascading, requires permissions, or what happens if the block does not exist. This lack of context is a significant gap for a destructive operation.
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?
The description is a single, front-loaded sentence with no redundant words or filler. It conveys the essential information efficiently and is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, and the description does not clarify side effects, error behavior, or reversibility. Even though the schema covers the single parameter, the overall lack of contextual detail makes the description incomplete for a delete operation, especially given the destructive nature.
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?
The input schema already provides a clear description for blockID ('ID of block to delete'), and the description's phrase 'by its ID' adds no extra semantic meaning. Since schema coverage is 100%, a baseline score of 3 is appropriate; the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a block by its ID' uses a specific verb (delete) and resource (block), and explicitly differentiates from sibling tools like delete-block-from-page-area by specifying deletion by ID. It is direct, unambiguous, and clearly names the action and target.
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 information about when to use this tool versus alternatives such as delete-block-from-page-area, nor any prerequisites, exclusions, or recommended context. The description only states what it does, not when to choose it, leaving the agent without guidance on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only says 'Deletes a block from a page area' without explaining whether the block is permanently deleted, whether it is merely detached from the area, or what effects cascade. This lack of detail leaves the agent uncertain about the operation's consequences.
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?
The description is a single concise sentence that conveys the core action without any filler or redundant information. It is front-loaded and appropriately sized for a straightforward delete operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks annotations and an output schema, and the description is minimal. It does not explain the exact semantics of 'from a page area' (whether the block is deleted or just unlinked), any preconditions, or what happens on success/failure. Given the ambiguity around the operation's scope, the description is incomplete for an agent to fully understand the tool's behavior.
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?
The input schema has 100% description coverage for all three parameters (pageID, blockID, areaHandle), providing basic semantics. The tool description adds no additional meaning beyond what the schema already states, such as how the parameters interrelate or the role of areaHandle. Thus, the description does not enhance parameter understanding beyond the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Deletes a block from a page area' clearly states the specific action (delete), the resource (block), and the context (page area). This differentiates it from siblings like 'delete-block-by-id' and 'add-block-to-page-area', making the purpose 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?
The description provides no guidance on when to use this tool versus alternatives such as 'delete-block-by-id' or 'update-block-in-page-area'. It only states what it does, not the conditions or trade-offs that would help an agent choose among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions sorting order but omits pagination behavior, default limit, the meaning of the 'includes' parameter, or any side effects. This is insufficient for a list operation with query parameters.
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?
The description is concise, consisting of two short sentences. It is front-loaded with the core function and adds a clarifying detail about sorting order. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has pagination and an includes parameter, but the description does not mention these features or the default limit. With no output schema and no annotations, the description is incomplete for an agent to understand the full behavior of the tool.
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 description coverage is 100%, so the baseline is 3. The description adds no information about the parameters (after, limit, includes), leaving the schema to fully document them. Since the schema descriptions are present, the tool description need not repeat them, but it also adds no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a list of page objects, with a specific sorting behavior. This distinguishes it from siblings like get-page-by-id (single page) and get-child-pages (hierarchical), making its purpose 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?
No guidance is provided on when to use this tool versus alternatives such as get-page-by-id or get-child-pages. The description only states what it does, not the appropriate context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the HTTP method (GET), which implies a read-only operation, but does not explicitly mention that it is safe, lacks side effects, requires authentication, or has any rate limits. This is minimal transparency.
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?
The description is a single concise sentence that clearly states the action and endpoint. It is appropriately sized for a zero-parameter GET request, with no unnecessary words.
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?
The description is minimally complete for a simple GET request, but it omits any information about the response format or expected content. Since there is no output schema, the description would benefit from mentioning that it returns system information, but the endpoint path provides some clue.
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 has zero parameters, and the schema coverage is 100% (trivially). Since there are no parameters to describe, a baseline score of 4 is appropriate. The description adds no parameter information because none is needed.
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?
The description states a specific action ('Make a GET request') and a specific resource ('/ccm/api/1.0/system/info'), making it clear this tool retrieves system information. It is distinct from sibling tools by its unique endpoint, though it does not explicitly describe the purpose in human terms.
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 guidance is provided on when to use this tool versus alternatives. The description simply instructs to make a GET request; it does not mention use cases, prerequisites, or situations where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only restates the tool's name's meaning. It does not disclose whether deletion is permanent, cascades to child pages, requires specific permissions, or what happens to associated content. This is a significant gap for a destructive operation.
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?
The description is one clear sentence with zero redundancy. It is front-loaded and immediately communicates the action and target.
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?
While the tool is simple (one parameter, no output schema) and the core function is clear, the lack of annotations or behavioral context leaves the description merely at a minimum viable level. It doesn't address potential side effects or prerequisites that an agent might need to avoid failed invocations.
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?
The input schema already fully documents the single pageID parameter with 100% coverage, including a description and location. The tool description adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Delete' and identifies the resource 'page' and the means 'by its ID'. It clearly distinguishes from sibling tools like get-page-by-id, update-page-by-id, and more granular deletes like delete-page-version-by-page-id-and-version-id.
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 guidance is provided on when to use this tool versus alternatives. The description simply states the action without contextual cues or exclusions, and no reference is made to sibling tools or scenarios where it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to mention whether the delete is permanent, whether it requires special permissions, or if there are cascading effects on related resources. This is a significant gap for a destructive operation.
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?
The description is a single, direct sentence with no filler or redundancy. It is front-loaded with the action and resource, making it highly concise.
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 the simple one-parameter signature, the description is minimally viable, but it omits important context such as permanence of deletion, error responses, and whether the operation is idempotent. With no output schema or annotations, these gaps remain unfilled.
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?
The input schema already documents the userID parameter with description 'ID of user to delete', so the schema coverage is 100%. The tool description adds no additional parameter semantics beyond confirming the identifier's role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' and identifies the resource 'a user' with the method 'by its ID'. This clearly distinguishes it from sibling tools like update-user-by-id and get-user-by-id.
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 guidance on when to use this tool versus alternatives, no context about irreversible consequences, and no mention of preconditions. The description only states the operation without any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only states a read action ('Find') without mentioning response format, error behavior, authorization requirements, or the meaning of the includes parameter, leaving significant behavioral unknowns.
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?
The description is a single, front-loaded sentence with no redundant words. It directly states the tool's purpose and is appropriately sized for a straightforward lookup operation.
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?
The description is minimally viable for a simple get-by-id operation, but it leaves the optional includes parameter unexamined and provides no information about the return shape. Given no output schema and no annotations, the description is adequate but has clear gaps around optional behavior.
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 100% and the blockID parameter is adequately described as 'ID of block to return'. The description adds little beyond reinforcing the key parameter, and the vague 'includes parameter' schema text is not clarified, but the required parameter is clear enough for basic invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Find' and the resource 'block by its ID', making the operation unambiguous. It naturally differentiates from sibling tools like get-page-by-id, get-file-by-id, and get-user-by-id by naming the exact entity type.
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 usage context or alternative tool guidance is provided. The description does not mention when to prefer this tool over get_page_content or get-child-pages, nor does it explain any prerequisites or when the optional includes parameter should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states a read operation but gives no details about safety, authentication, response format, or whether the includes parameter affects behavior.
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?
The description is a single, concise sentence with the verb and resource front-loaded. It contains no redundant information and is easy to scan.
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?
The tool is simple with no output schema, but the description fails to explain the optional 'includes' parameter, which is relevant for retrieving locales or custom attributes. The description is adequate for basic awareness but leaves a gap in understanding the full capabilities of the tool.
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?
The input schema has 100% description coverage for the single parameter, but the description is unhelpful ('includes parameter'). The tool description itself doesn't mention the optional 'includes' parameter or its possible values, though the enum in the schema provides some semantics. The description adds no additional meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') and a specific resource ('the default site'), clearly distinguishing it from sibling tools like get-site-by-id and get-sites. The phrase 'for your Concrete installation' adds useful context about the scope.
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 provides no guidance on when to use this tool instead of alternatives such as get-site-by-id or get-sites. There is no mention of prerequisites, exclusions, or a preferred use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It only reveals the sort order, but omits other important behaviors such as pagination, authentication requirements, or whether the list includes all sites. The core behavior of returning a list is already implied by the tool name.
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?
The description is a single sentence with no redundancy. It conveys the essential information (return type and sort order) efficiently.
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 simple list tool, it provides the return type and sort order but lacks crucial context: it doesn't clarify the scope ('all sites'), doesn't explain the optional 'includes' parameter, and with no output schema, the description should offer more detail about what a 'site object' contains.
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?
The schema has 100% coverage for its one parameter, but the parameter description ('includes parameter') is purely tautological. The tool description doesn't explain what 'includes' does with the enum values. Baseline 3 applies due to schema coverage, but no added value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Returns') and resource ('list of site objects'), and adds a meaningful sorting detail ('sorted by date added ascending'). It distinguishes itself from sibling 'get-site-by-id' by using plural 'sites'.
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 guidance is provided on when to use this tool versus alternatives. It doesn't mention that it returns all sites, nor does it reference sibling tools like get-site-by-id for single-site retrieval. The reader is left to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states the HTTP method 'GET', which implies a read-only operation and is a useful behavioral cue, especially given no annotations are provided. However, it does not disclose potential errors, authentication requirements, or response handling, so transparency is limited.
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?
The description is a single sentence that succinctly states exactly what to do. There is no fluff or redundant information, making it highly concise and well-structured.
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?
The tool is extremely simple (no parameters, no output schema), but the description does not explain what the account data looks like or how to interpret the response. Given the lack of annotations and output schema, a bit more detail would be needed for full completeness, but the simplicity keeps it at an adequate level.
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?
There are 0 parameters, so the baseline is 4. The description does not need to explain parameter semantics because there are none to document.
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?
The description clearly specifies the action ('Make a GET request') and the resource ('/ccm/api/1.0/account'), which distinguishes it from sibling tools that target users, groups, sites, etc. However, it does not explain what 'account' refers to or what data is returned, so it falls short of a full 5.
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 guidance on when to use this tool versus alternatives, no mention of prerequisites, and no exclusions. The description simply states the HTTP request without context, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic action and does not mention expected responses, error behavior, authentication requirements, or whether the group is returned fully or partially.
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?
The description is a single, direct sentence with no unnecessary words. It is front-loaded and efficient, effectively communicating the core purpose without verbosity.
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?
Given the tool's low complexity (one parameter, no output schema), the description is nearly complete. It states what the tool does and the schema documents the required input. A minor gap is lack of mention of not-found error behavior, but for a simple get-by-id the description is adequate.
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 description coverage is 100% because the parameter groupID has a clear description ('ID of group'). The tool description adds no further meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'find' and the specific resource 'user group by its ID', distinguishing it from sibling tools like get-groups (list all groups) and add-group (create group).
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 provides no guidance on when to use this tool versus alternatives such as get-groups. It does not mention scenarios or exclusions, leaving the usage context implied only by sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the sorting behavior, which is useful. However, it does not mention pagination behavior or the limit default, though these are covered in the schema. The description adds some context but misses higher-level behavioral details like whether it returns all groups or only a page.
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?
The description is a single concise sentence, front-loaded with the action and resource, with no extraneous words. Every word earns its place.
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 simple list tool with fully documented parameters and no output schema, the description is sufficient. It clearly identifies the operation and adds a useful behavioral detail (sorting). It lacks explicit usage guidance but is otherwise complete for its complexity.
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 description coverage is 100%, with both 'after' and 'limit' fully described. The description adds no additional parameter context beyond what the schema provides, so the baseline score of 3 is appropriate.
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?
The description clearly states it returns a list of Group objects, with a specific verb ('Returns') and resource. The sorting detail (by ID ascending) adds specificity. It is distinct from get-group-by-id (single object) and other list tools, though not explicitly differentiated.
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 guidance is provided about when to use this tool versus alternatives like get-group-by-id or other list tools. The description does not mention any exclusions, prerequisites, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention behavior such as recursion depth, ordering, what happens for leaf pages, or the effect of the 'includes' parameter. The phrase 'traversal of the sitemap' adds some context but lacks concrete details about output or side effects.
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?
The description is a single, front-loaded sentence that earns its place. It is concise, with no filler or redundant phrasing, and clearly communicates the tool's core purpose.
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 simple read-only hierarchy navigation tool, the description covers the essential purpose and the schema handles parameters. However, it lacks guidance on the 'includes' parameter's effect, expected return shape, or edge cases (e.g., non-existent parent). Given no annotations or output schema, this is adequate but not rich.
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 description coverage is 100%, so the baseline is 3. The description adds no parameter-specific meaning beyond the schema. The 'includes' parameter's schema description is tautological ('includes parameter'), but the enum values clarify its intent; the description does not compensate for this weakness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: traversing the sitemap to show child pages of a specific page. It uses a specific verb ('showing') and resource ('child pages of a particular page'), and it is distinguishable from sibling tools like get-pages (all pages) or get-page-by-id (single page).
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 implied: use this tool when you need to navigate the page hierarchy by retrieving children of a given page. However, there is no explicit guidance on when to prefer this over alternatives or any exclusions, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only states 'Find a site by its ID' and does not mention read-only behavior, error handling, return format, or any side effects. This is insufficient for a description with no other 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It immediately and clearly conveys the action and the object, making it well-structured and appropriately sized.
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 simple one-parameter lookup, the description is minimally adequate, but the lack of an output schema and behavioral details leaves gaps about the return structure and error scenarios. The simplicity of the tool raises the baseline, but the description could still do more to inform the agent about the response.
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?
The schema covers 100% of the parameters with a clear description for siteID ('ID of Site to return'), so the description does not need to expand on it. The description adds no additional semantic detail beyond restating 'by its ID', which is already clear from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Find' with a specific resource 'site by its ID', clearly distinguishing this from siblings like get-sites (presumably listing all sites) and get-default-site. It clearly states what the tool does.
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?
The description implies usage when a site's ID is known, but it does not explicitly mention alternatives or when not to use this tool. There is no comparison to sibling get* tools, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only restates the action (finding a user) without disclosing behavior such as handling of non-existent users, required permissions, or the effect of the optional 'includes' parameter on the response. For a read operation the risk is low, but the description adds no behavioral context beyond what the name suggests.
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?
The description is a single concise sentence, front-loaded with the verb and resource. No wasted words; it is appropriately minimal for a simple lookup tool.
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?
With no output schema and no annotations, the description is minimal but adequate for a straightforward get-by-id operation. It does not mention return format, error behavior, or the optional includes feature, which are not covered elsewhere. However, the tool is simple and the schema covers parameters, so it is not critically incomplete.
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 covers both parameters with descriptions ('ID of user to return' and 'includes parameter'), so baseline is 3. The tool description adds no extra meaning to the parameters; notably, the 'includes' parameter description is vague in the schema, but the description does not compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a clear verb ('Find') and specifies the resource ('user') and lookup key ('ID'). It distinguishes from sibling list tool 'get-users' by indicating single-user retrieval. No ambiguity with 'get-group-by-id' as the resource is explicitly 'user'.
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?
No explicit guidance on when to use this tool vs alternatives. Usage is implied by the name and required userID parameter, but the description does not mention list alternative 'get-users' or when to include optional 'includes' parameter. There are no exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses the sort order (date added descending), which is useful, but it does not mention authentication requirements, pagination using the 'after' parameter, or that the 'includes' parameter is needed to get custom_attributes or groups. These are behavioral gaps.
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?
The description is concise at two sentences, front-loaded with the core purpose, and contains no unnecessary information. Every word 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?
For a list tool, the description covers the basic return type and sort order, but it falls short of explaining how to paginate through all users (via 'after' and 'limit') and the effect of the 'includes' parameter on the response shape. No output schema exists, so the description should provide more context.
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?
The input schema describes all three parameters completely (100% coverage), including the meaning of 'after' and the default/limit for 'limit'. The description adds no parameter-specific details, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Returns a list of user objects, sorted by date added descending.' This specific verb-resource pairing and the sorting detail distinguish it from the sibling 'get-user-by-id', which likely fetches a single user.
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?
The description implies usage for listing users but does not explicitly state when to use this tool versus alternatives like 'get-user-by-id' or 'get-groups'. No exclusions or alternative recommendations are provided, but the purpose is clear enough for basic guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It adequately discloses the sorting order, but does not mention absence of side effects, authentication requirements, handling of empty results, or pagination behavior beyond the limit parameter. The description adds the key sorting behavior but leaves other aspects unspecified.
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?
The description is brief and front-loaded with the core purpose. However, the second sentence restates the sorting order (descending already implies most recent first), which is slightly redundant; otherwise it is well-structured.
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?
This is a simple list operation with no output schema. The description covers the basic behavior and sorting, but does not explain the effect of the 'includes' parameter on the response, return object fields, or behavior when no files exist. Given the tool's simplicity and schema coverage, it is adequate but not fully complete.
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?
The input schema already provides descriptions for both parameters (limit with constraints and default, includes with enum). The description does not add any additional meaning or guidance for parameters, so it adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Returns', names the resource 'list of file objects', and adds a distinct sorting behavior (last updated descending). This clearly distinguishes it from sibling tools like get-file-by-id or add-file.
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?
The description implies the tool is for retrieving a list of files, but does not explicitly state when to use it over alternatives such as get-file-by-id, nor does it mention exclusions or prerequisites. The usage context is clear but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It adds useful context about sorting (date created descending) but does not mention pagination behavior, error conditions, or permission requirements, which are relevant for a retrieval operation.
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?
The description is a single, front-loaded sentence that states the core action and result with no redundant language. Every word earns its place.
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 simple list-retrieval tool with three well-documented parameters and no output schema, the description covers the primary purpose and sorting. It lacks explicit pagination guidance, but the schema provides parameter descriptions for limit and resultsPage, so the tool is adequately specified.
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?
All three parameters are fully documented in the schema with descriptions, so the description adds no extra parameter semantics. The schema provides complete coverage, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Returns') and resource ('list of page version objects') with a clear parameter (page ID), distinguishing it from sibling tools that operate on a single version by ID. It clearly states the action and scope.
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?
The description implies use when a list of versions for a specific page is needed, but does not explicitly mention alternatives such as get-page-version-by-page-id-and-version-id for a single version or update/delete operations. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the internal steps: creates a new editable page version (PUT page), remaps block IDs, then updates each block. It also states that the new version is not approved, which is an important behavioral trait. This goes beyond vague 'updates content'.
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?
Four short sentences, front-loaded with the purpose, and each sentence provides essential information (purpose, process steps, required input, limitation). No redundant text.
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?
The tool has a complex operation with nested objects and no output schema. The description explains the workflow and the requirement for pre-inspection block IDs, and notes the no-approval behavior. It could mention what the API returns or possible errors, but the core semantics are covered.
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 schema has 100% coverage, but the description adds crucial guidance: block IDs must come from the version you inspected, and the tool remaps IDs after creating a new version. The blocks parameter description in the schema also reinforces this. This enhances the agent's understanding of how to supply parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: updating page block content safely. It distinguishes itself from siblings like update-page-by-id and update-block-in-page-area by describing a multi-step composite process (new version creation, block ID remapping, per-block updates), which is specific and action-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context: it requires blockID values from the inspected page version, and it notes that the new version is not approved. This gives clear usage context. However, it doesn't explicitly compare against alternatives like update-block-in-page-area for single-block edits, so it lacks explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return format and scope limitation (no areas/blocks). It implies a read-only operation ('Review', 'Returns') but does not explicitly confirm no side effects or authentication needs. Still, the provided context is strong for a read tool.
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?
Three efficient sentences: purpose and return type, usage preference, and scope limitation. Every sentence provides distinct value without redundancy, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with two parameters and no output schema, the description thoroughly covers purpose, return types, and scope. It gives an agent enough to select and invoke the tool correctly without missing critical behavioral details.
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?
The input schema covers both parameters (pageID and version) with descriptions, enum, and default. The description adds no additional parameter-level detail; it only references behavior. Since schema coverage is 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool reviews a Concrete CMS page as a document, lists return types (sanitized HTML, raw HTML, plain text), and distinguishes itself from getPageById with includes=content. This is a specific verb+resource with clear scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Prefer this over getPageById with includes=content when summarizing or reading page copy' and notes 'Does not return areas/blocks', giving clear when-to-use and when-not-to-use guidance. This effectively differentiates from the sibling get-page-by-id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![concretecms-mcp-server MCP server](https://glama.ai/mcp/servers/concrete5-community/concretecms-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/concrete5-community/concretecms-mcp-server)

Score Badge

Copy to your README.md:

[![concretecms-mcp-server MCP server](https://glama.ai/mcp/servers/concrete5-community/concretecms-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/concrete5-community/concretecms-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/concrete5-community/concretecms-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server