AEM 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 have distinct purposes targeting specific AEM operations like page management, asset handling, workflow control, and versioning. However, some overlap exists between 'getPageContent' and 'getAllTextContent'/'getPageTextContent', and between 'listPages' and 'enhancedPageSearch', which could cause minor confusion for agents.
Naming Consistency4/5
The naming follows a consistent verb_noun pattern throughout (e.g., 'activatePage', 'createComponent', 'getAssetMetadata'), with clear action-object pairs. Minor deviations like 'enhancedPageSearch' (adjective-verb-noun) and 'listMethods' (which doesn't fit the AEM domain) slightly break the pattern but overall maintain good readability.
Tool Count2/5
With 48 tools, the count is excessive for typical MCP server scope, likely overwhelming for agents and increasing complexity. While AEM is a complex system, this many tools suggests poor scoping or fragmentation, as many operations could be consolidated into fewer, more general tools.
Completeness5/5
The tool set provides comprehensive coverage for AEM content management, including full CRUD operations for pages, components, assets, and versions, plus workflow management, search, and validation. No obvious gaps exist; agents can perform end-to-end tasks without dead ends in this domain.
Average 2.6/5 across 48 of 48 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under AGPL 3.0.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Execute JCR query' gives no information about whether this is a read or write operation, what permissions are required, whether it has side effects, rate limits, error conditions, or what the output looks like. For a tool with two parameters and no output schema, this is critically inadequate.
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 extremely concise at three words, which could be appropriate if it were more informative. However, it's under-specified rather than efficiently structured—it doesn't front-load critical information or provide any meaningful elaboration. While not verbose, it lacks substance, making this a borderline case between conciseness and insufficiency.
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 the complexity implied by the tool name (JCR queries can be complex), two parameters with 0% schema coverage, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what the tool does beyond the name, how to use it, what it returns, or how it fits with siblings. This leaves the agent with insufficient information to use the tool 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?
Schema description coverage is 0%, meaning neither parameter ('query' and 'limit') has any documentation in the schema. The description adds no information about what these parameters mean, what format the query should be in, what query language is used, what the limit applies to, or default values. With two undocumented parameters, the description fails to compensate for the schema gap.
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 'Execute JCR query' is essentially a tautology that restates the tool name with minimal elaboration. While it indicates the tool performs query execution (verb) on JCR resources, it lacks specificity about what JCR queries are, what they return, or how this differs from sibling tools like 'searchContent' or 'enhancedPageSearch'. The purpose is vague and doesn't distinguish from alternatives.
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?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'searchContent', 'enhancedPageSearch', and 'getAllTextContent' that might overlap in functionality, there is no indication of when this specific JCR query tool is appropriate, what prerequisites exist, or when other tools should be preferred. This leaves the agent with no usage 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get asset metadata' implies a read-only operation but doesn't specify permissions required, rate limits, error conditions, or what format the metadata returns (e.g., JSON, structured data). This leaves critical behavioral traits undocumented for a tool with no output schema.
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 with just three words, which is front-loaded and wastes no space. However, this conciseness comes at the cost of being under-specified—it's too brief to be helpful, though it's structurally simple and direct.
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 the tool's complexity (a read operation with one parameter), lack of annotations, 0% schema coverage, and no output schema, the description is completely inadequate. It doesn't explain what 'asset metadata' includes, how to use the parameter, or what the tool returns, leaving the agent with insufficient context to invoke it 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?
Schema description coverage is 0%, meaning the parameter 'assetPath' is undocumented in the schema. The description adds no information about this parameter—it doesn't explain what 'assetPath' represents, its format (e.g., file path, URL, identifier), or examples. With one required parameter and no schema details, the description fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get asset metadata' is a tautology that restates the tool name 'getAssetMetadata' without adding meaningful context. It specifies the verb 'get' and resource 'asset metadata', but doesn't explain what constitutes 'asset metadata' or how it differs from similar tools like 'getNodeContent' or 'getPageContent' among the siblings.
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?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'getNodeContent', 'getPageContent', and 'getAllTextContent', there's no indication of whether this tool is for files, pages, or other assets, or what specific metadata it retrieves compared to other content-fetching tools.
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 states the action ('Get JCR node content') without detailing permissions, rate limits, output format, or side effects. For a read operation with no annotation coverage, this is insufficient.
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 'Legacy: Get JCR node content', which is efficient. However, it lacks necessary detail, making it under-specified rather than concise, but it avoids redundancy and is structured clearly.
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 the complexity implied by parameters and sibling tools, the description is incomplete. With no annotations, no output schema, and 0% schema coverage, it fails to provide essential context like usage scenarios, behavioral traits, or parameter details, making it inadequate for effective tool invocation.
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 provides no information about the parameters 'path' and 'depth'. It fails to explain what these parameters mean, their expected formats, or how they affect the operation, leaving them undocumented.
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 'Legacy: Get JCR node content' restates the tool name 'getNodeContent' with minimal elaboration, making it tautological. It specifies the resource ('JCR node content') but lacks a clear verb beyond 'Get', and doesn't differentiate from siblings like 'getPageContent' or 'getAllTextContent', leaving ambiguity about what distinguishes this tool.
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?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'getPageContent' and 'getAllTextContent', the description fails to indicate context, prerequisites, or exclusions, offering no help for an agent in selecting the appropriate tool.
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 fully disclose behavior. It only states the action without details on permissions, rate limits, output format, or side effects. For a tool with no annotation coverage, this is inadequate.
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 no wasted words. However, the 'Legacy' prefix is ambiguous and could be considered unnecessary clutter, slightly reducing efficiency.
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 the tool's complexity (1 parameter, no annotations, no output schema), the description is incomplete. It fails to explain what 'child nodes' are, the return format, or how it differs from similar tools, making it insufficient for effective use.
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 explain the 'path' parameter's meaning, format, or examples. With one required parameter undocumented in both schema and description, the description adds no value beyond the schema.
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 'Legacy: List child nodes' restates the tool name 'listChildren' with minimal elaboration, making it tautological. While 'List child nodes' clarifies the verb+resource, it lacks specificity about what 'child nodes' refer to in this context, and the 'Legacy' prefix adds confusion rather than clarity.
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?
The description provides no guidance on when to use this tool versus alternatives like 'listPages', 'getNodeContent', or other sibling tools. There is no mention of context, prerequisites, or exclusions, leaving the agent with no usage instructions.
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 states 'Complete a workflow step' but does not explain what 'complete' entails—e.g., whether it marks a step as done, triggers transitions, requires permissions, or has side effects. This leaves critical behavioral traits like mutability, authorization needs, or error conditions unspecified.
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 extremely concise with a single sentence, 'Complete a workflow step', which is front-loaded and wastes no words. However, this brevity comes at the cost of under-specification, but based solely on conciseness criteria, it earns a high score for efficiency.
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 the tool's complexity (involving workflow management), lack of annotations, 0% schema description coverage, and no output schema, the description is completely inadequate. It fails to explain what the tool does, how to use it, what parameters mean, or what to expect, leaving the agent with insufficient information for correct invocation.
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 description adds no meaning beyond the input schema, which has 0% description coverage. Parameters 'workflowId', 'stepName', and 'comment' are undocumented in both schema and description, with no explanation of their formats, constraints, or purposes. For a tool with 3 parameters and no schema descriptions, this is inadequate.
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 'Complete a workflow step' is a tautology that essentially restates the tool name 'completeWorkflowStep' without adding meaningful specificity. It mentions the verb 'complete' and resource 'workflow step' but fails to distinguish this tool from sibling workflow tools like 'cancelWorkflow', 'resumeWorkflow', 'suspendWorkflow', or 'startWorkflow', leaving the exact purpose unclear.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or exclusions, such as whether it applies only to active workflows or specific step states. With sibling tools like 'cancelWorkflow' and 'resumeWorkflow', the lack of differentiation makes it misleading for an agent to select the correct tool.
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 states the action 'delete' without explaining critical traits such as whether deletion is permanent or reversible, what permissions are required, if it affects other versions or content, or what happens on success/failure. This is inadequate for a destructive operation with zero annotation coverage.
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 extremely concise with a single sentence 'Delete a specific version', which is front-loaded and wastes no words. However, this brevity comes at the cost of under-specification, but for conciseness alone, it scores high as every word serves a purpose.
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 the tool's complexity (a destructive operation with 2 parameters), lack of annotations, 0% schema coverage, and no output schema, the description is severely incomplete. It does not address behavioral risks, parameter meanings, usage context, or expected outcomes, making it inadequate for safe and effective tool invocation.
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%, meaning neither parameter ('path' or 'versionName') is documented in the schema. The description adds no information about what these parameters mean, their expected formats, or examples (e.g., 'path' could be a file path or node path, 'versionName' could be a label or ID). This fails to compensate for the complete lack of schema documentation.
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 'Delete a specific version' is essentially a tautology that restates the tool name 'deleteVersion' with minimal elaboration. While it does specify the verb 'delete' and resource 'version', it lacks any distinguishing details about what type of version (e.g., page version, asset version, workflow version) or what system it operates in, making it vague compared to siblings like 'deleteAsset', 'deletePage', or 'restoreVersion'.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing an existing version), exclusions (e.g., cannot delete active versions), or related tools like 'restoreVersion' or 'getVersionHistory' from the sibling list, leaving the agent with no context for selection.
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 states only the action ('Get'), with no information about permissions required, rate limits, side effects, response format, or error conditions. For a read operation with no structured safety hints, this is a significant gap in 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 extremely concise at three words, with no wasted verbiage. However, this conciseness comes at the cost of under-specification, but as per scoring rules, it's efficient in structure.
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 the complexity of a page properties retrieval tool with no annotations, no output schema, and a parameter with 0% schema coverage, the description is completely inadequate. It fails to explain what properties are returned, how to interpret them, or any contextual nuances, making it insufficient for effective tool use.
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 1 parameter with 0% description coverage, and the tool description provides no information about the 'pagePath' parameter. It doesn't explain what format the path should be in, examples, or constraints, leaving the parameter entirely undocumented beyond its name and type.
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 'Get page properties' is a tautology that essentially restates the tool name, providing no additional specificity about what 'properties' entails or what resource is being accessed. It distinguishes from siblings like 'getPageContent' or 'getPageImages' only by the generic term 'properties', but doesn't clarify what types of properties (metadata, configuration, status, etc.) are retrieved.
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?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'getPageContent', 'getPageImages', 'getAllTextContent', and 'getPageTextContent', the description offers no indication of what distinguishes 'properties' from 'content' or other page-related data, leaving the agent with no basis for selection.
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 states the basic function ('compare') without detailing what the comparison entails (e.g., returns differences, metadata, or a visual output), whether it's read-only or has side effects, or any constraints like rate limits or authentication needs. This leaves critical behavioral traits unspecified, making it inadequate for safe and effective use.
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 ('Compare two versions of content') that is front-loaded and wastes no words. It directly conveys the core purpose without unnecessary elaboration, making it efficient and easy to parse for an agent.
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 complexity of a comparison tool with 3 parameters, no annotations, no output schema, and low schema coverage, the description is incomplete. It fails to explain the comparison output, parameter semantics, behavioral traits, or usage context. While conciseness is good, the description lacks the necessary details to compensate for the missing structured data, leaving gaps in understanding.
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 input schema has 3 parameters with 0% description coverage, so the schema provides no semantic information. The description does not explain what 'path', 'version1', or 'version2' represent (e.g., file paths, version IDs, timestamps), their formats, or how they relate to the content being compared. This lack of parameter meaning beyond the schema's basic types significantly hinders correct invocation.
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 'Compare two versions of content' clearly states the action (compare) and target (versions of content), avoiding tautology with the tool name. However, it lacks specificity about what 'content' refers to (e.g., pages, assets, components) and how the comparison is performed (e.g., diff, side-by-side view), making it somewhat vague. It does not distinguish this tool from potential siblings like 'getVersionHistory' or 'restoreVersion', which reduces its 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing existing versions), exclusions (e.g., not for comparing non-versioned content), or related tools like 'getVersionHistory' for listing versions first. Without such context, an agent must infer usage from the tool name alone, which is insufficient for optimal 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 behavioral disclosure. It states 'Create a new version' which implies a write/mutation operation, but doesn't clarify permissions needed, side effects (e.g., if it affects existing versions), or response behavior. This is a significant gap for a mutation tool with zero annotation coverage.
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 wasted words. It's front-loaded and to the point, though it could benefit from more detail given the tool's complexity. The brevity is appropriate but borders on under-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?
Given the tool's complexity (mutation with 3 parameters), lack of annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't explain parameters, behavior, or output, making it inadequate for an agent to use correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'content' but doesn't explain the three parameters (path, label, comment) or their roles. The description adds no meaning beyond the schema, failing to address the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new version of content' clearly states the action (create) and resource (version of content), but it's vague about what 'content' refers to and doesn't differentiate from sibling tools like 'restoreVersion' or 'deleteVersion'. It provides a basic purpose but lacks specificity about the domain or 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 offers no guidance on when to use this tool versus alternatives like 'restoreVersion' or 'undoChanges', nor does it mention prerequisites or context. It's a standalone statement with no usage instructions, leaving the agent to infer when this operation 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 provided, the description carries full burden but offers minimal behavioral insight. It hints at 'fallback strategies' and 'cross-section search' but doesn't explain what these entail (e.g., error handling, performance, or search scope). Critical details like permissions, rate limits, or output format are missing, leaving significant gaps in understanding how the tool behaves.
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 concise with a single sentence that front-loads key terms like 'intelligent page search'. However, it could be more structured by explicitly separating purpose from features, but it avoids unnecessary verbosity and gets straight to the point without wasted words.
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 complexity implied by 'intelligent' search and 3 parameters with 0% schema coverage, the description is incomplete. No output schema exists, and it doesn't explain return values or error handling. For a search tool with multiple parameters and no annotations, more detail on behavior and results is needed to be adequately helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but fails to do so. It doesn't mention any parameters or their meanings, leaving 'searchTerm', 'basePath', and 'includeAlternateLocales' entirely undocumented. This lack of semantic context makes it hard for users to understand what inputs are needed or how they affect the search.
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 states the tool performs 'intelligent page search' with 'comprehensive fallback strategies and cross-section search', which gives a general purpose but lacks specificity about what resources it searches (pages vs other content) or what 'intelligent' means operationally. It doesn't clearly distinguish from sibling tools like 'searchContent' or 'listPages', leaving ambiguity about when to choose this over alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives like 'searchContent' or 'listPages'. The mention of 'fallback strategies' and 'cross-section search' implies some context but doesn't specify scenarios, prerequisites, or exclusions. Users must infer usage from vague terms without concrete 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 carries full burden but offers minimal behavioral insight. It doesn't disclose whether this is a read-only operation, if it requires authentication, how results are returned (e.g., pagination, format), or any rate limits. The description lacks essential context for safe and effective use.
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 extremely concise with a single sentence, 'Get available page templates', which is front-loaded and wastes no words. It efficiently communicates the core purpose without unnecessary elaboration.
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 no annotations, no output schema, and low schema coverage (0%), the description is incomplete. It doesn't cover parameter meaning, return values, behavioral traits, or usage context, making it inadequate for a tool with even one parameter in a complex environment with many siblings.
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 input schema has one parameter 'sitePath' with 0% description coverage, and the tool description provides no information about parameters. The description doesn't explain what 'sitePath' is, its format, or if it's optional/required, failing to compensate for the schema's lack of documentation.
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 'Get available page templates' clearly states the action (get) and resource (page templates), but it's vague about scope. It doesn't specify whether this retrieves all templates globally, per site, or with filtering, nor does it distinguish from sibling 'getTemplateStructure' which might provide more detailed template information.
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 doesn't mention prerequisites, context (e.g., after fetching sites), or comparisons to siblings like 'getTemplateStructure' or 'listPages', leaving the agent to infer usage based on 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves information ('Get'), implying a read-only operation, but does not specify aspects like authentication needs, rate limits, error handling, or what 'detailed structure' includes in the response. This is a significant gap for a tool with no annotation coverage.
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, clear sentence that is front-loaded and efficient, with no unnecessary words. It effectively communicates the core purpose without redundancy, though it could be more informative by adding context or examples.
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 complexity of retrieving template structure, the lack of annotations, no output schema, and incomplete parameter documentation, the description is insufficient. It does not explain what the tool returns or how to interpret results, leaving critical gaps for the agent to understand and use the tool effectively.
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 input schema has 1 parameter with 0% description coverage, and the tool description does not explain the 'templatePath' parameter. It fails to add meaning beyond the schema, such as what format the path should be in or examples of valid values, which is inadequate given the low schema coverage.
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 states the action ('Get') and resource ('detailed structure of a specific template'), which clarifies the tool's purpose. However, it lacks specificity about what 'detailed structure' entails (e.g., fields, hierarchy, metadata) and does not distinguish it from sibling tools like 'getTemplates' or 'getPageContent', making it somewhat 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or exclusions, such as how it differs from 'getTemplates' (which might list templates) or 'getPageContent' (which might retrieve page data). This leaves the agent without clear usage instructions.
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 the full burden of behavioral disclosure. It mentions 'replicate and publish' but doesn't clarify if this is a read-only or destructive operation, what permissions are required, how errors are handled, or what the expected output is. This leaves significant gaps for a tool that likely involves content modification.
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, concise sentence with no wasted words. It's front-loaded with the core action, making it easy to scan. However, it could be more structured by including key details without sacrificing brevity.
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 complexity (3 parameters with nested objects, no output schema, and no annotations), the description is incomplete. It doesn't explain the tool's behavior, parameter details, or expected outcomes, leaving too much ambiguity for effective use by an AI 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 0%, so the description must compensate for undocumented parameters. It only vaguely references 'selected locales' and 'content', without explaining what 'componentData' or 'localizedOverrides' mean, their formats, or examples. This fails to add meaningful context beyond the bare schema.
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 states the tool's purpose as 'Replicate and publish content to selected locales', which includes a verb ('replicate and publish') and resource ('content'), but it's vague about what specific content is involved and doesn't distinguish it from sibling tools like 'publishContent' or 'bulkUpdateComponents'. It provides a basic purpose but lacks 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. The description doesn't mention prerequisites, exclusions, or compare it to sibling tools such as 'publishContent' or 'bulkUpdateComponents'. Users must 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 provided, the description carries the full burden of behavioral disclosure. It implies a mutation operation ('restore'), but doesn't specify critical details like whether this overwrites current content, requires permissions, is reversible, or has side effects (e.g., affecting workflows). This is inadequate for a tool that likely modifies data.
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 that directly states the tool's function without unnecessary words. It's appropriately front-loaded but could be more informative; however, it earns high marks for brevity and clarity within its limited scope.
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 complexity of a restore operation, no annotations, no output schema, and poor parameter documentation, the description is incomplete. It doesn't explain what 'content' entails, the restoration process, or expected outcomes, making it insufficient for safe and effective use by an AI 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?
The input schema has 0% description coverage, so parameters 'path' and 'versionName' are undocumented. The description adds no semantic information about these parameters (e.g., what 'path' refers to, how 'versionName' is formatted), failing to compensate for the schema gap. This leaves the agent guessing about input requirements.
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 'Restore content to a specific version' clearly states the action (restore) and target (content), but it's vague about what 'content' refers to (e.g., pages, assets, components) and doesn't distinguish it from sibling tools like 'undoChanges' or 'compareVersions', which might involve version-related operations. It avoids tautology but lacks 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a version history), exclusions, or comparisons to siblings like 'undoChanges' or 'getVersionHistory', leaving the agent to infer usage context from the tool 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?
No annotations are provided, so the description carries full burden. It mentions 'Query Builder' but doesn't explain what that entails—whether it's a specific query language, how results are returned (e.g., pagination, format), or any limitations (e.g., performance, access controls). This leaves significant behavioral gaps for a search 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 very concise—a single sentence—and front-loaded with the core action. However, it's arguably too brief, lacking necessary details, but within the given text, there's no wasted verbiage, earning a high score for efficiency.
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 complexity of a search tool with 4 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't cover parameter meanings, result format, or usage context, making it inadequate for effective tool selection and 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 description coverage is 0%, so the description must compensate. It doesn't explain any of the 4 parameters (type, fulltext, path, limit), such as what 'type' refers to (content types?), what 'fulltext' searches, how 'path' is used, or what 'limit' defaults to. This fails to add meaningful semantics beyond the bare schema.
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 states the tool searches content using Query Builder, which provides a basic purpose (searching content). However, it's vague about what 'content' refers to (pages, assets, components?) and doesn't distinguish this from sibling tools like 'enhancedPageSearch' or 'getAllTextContent', leaving ambiguity about scope and differentiation.
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. With siblings like 'enhancedPageSearch', 'listPages', and 'getAllTextContent', there's no indication of when this search method is preferred, what contexts it applies to, or any prerequisites for 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions validation before applying changes, implying a read-only or safe operation, but doesn't specify if it requires permissions, what happens on failure, or if it has side effects like logging. For a tool with 4 parameters and no annotations, this is insufficient to inform the agent about behavioral traits.
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 that gets straight to the point without unnecessary words. It's front-loaded with the core purpose, making it easy to parse. However, it could be more structured by including key details, but as is, it avoids wastefulness.
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 complexity (4 parameters with nested objects, no output schema, and no annotations), the description is incomplete. It doesn't explain what validation entails, what the output might be, or how it interacts with other tools like 'updateComponent'. For a validation tool in a content management context, more detail is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 4 parameters (locale, pagePath, component, props) are documented in the schema. The description adds no information about these parameters, such as what 'locale' or 'props' represent, leaving them entirely unexplained. This fails to compensate for the lack of schema documentation, making parameter understanding difficult.
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 states the tool's purpose as validating component changes before applying them, which is clear but somewhat vague. It specifies the action (validate) and target (component changes) but doesn't distinguish it from siblings like 'updateComponent' or 'scanPageComponents' that might involve similar validation steps. The purpose is understandable but lacks specificity about what validation entails.
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 doesn't mention prerequisites, such as whether it should be used before 'updateComponent' or in conjunction with 'createComponent', nor does it specify scenarios where validation is necessary. Without any context on usage, the agent must infer when this tool is appropriate.
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?
The description lacks any behavioral disclosure beyond the basic action. With no annotations provided, it fails to address critical aspects like permissions required, whether deletion is permanent or reversible, impact on linked content, or error conditions. For a destructive operation, this is a significant gap.
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 maximally concise with a single, direct sentence that states the core functionality without unnecessary words. Every element ('Delete', 'a page', 'from AEM') contributes essential information.
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 destructive tool with 2 parameters, 0% schema coverage, no annotations, and no output schema, the description is completely inadequate. It doesn't address safety concerns, parameter meanings, expected outcomes, or error handling that are crucial for proper 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?
With 0% schema description coverage for both parameters, the description provides no information about what 'pagePath' should contain or what the 'force' boolean does. It doesn't explain path format expectations, what 'force' overrides, or any parameter constraints beyond what's in the bare schema.
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 ('Delete') and resource ('a page from AEM'), making the purpose immediately understandable. It distinguishes from siblings like 'deleteAsset' or 'deleteComponent' by specifying 'page', but doesn't explicitly contrast with similar tools like 'deactivatePage' or 'unpublishContent'.
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. With siblings like 'deactivatePage', 'unpublishContent', and 'deleteVersion', there's no indication of prerequisites, consequences, or appropriate contexts for deletion versus other page-modification operations.
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 full burden but only states the action without disclosing behavioral traits. It doesn't mention permissions required, irreversible effects, error handling, or side effects, which is inadequate 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 wasted words, making it highly concise and front-loaded. It efficiently conveys the core action without unnecessary elaboration.
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's destructive nature, no annotations, no output schema, and low schema coverage, the description is incomplete. It fails to address critical aspects like safety, return values, or error conditions, making it insufficient for informed use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter details. It doesn't explain what 'componentPath' represents or the effect of the 'force' parameter, leaving both parameters semantically unclear.
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 states the action ('Delete') and target resource ('a component from AEM'), which is clear but vague. It doesn't specify what type of component or distinguish it from similar deletion tools like deleteAsset or deletePage, leaving ambiguity about 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?
No guidance is provided on when to use this tool versus alternatives like deleteAsset or deletePage, nor any prerequisites or exclusions. The description lacks context for selection among sibling tools, offering minimal 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation ('Get'), but doesn't specify if it requires authentication, has rate limits, returns structured data, or handles errors. For a tool with zero annotation coverage, this is a significant gap in 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 extremely concise with a single, front-loaded sentence that directly states the tool's function. There is no wasted verbiage, making it efficient for quick comprehension, though this brevity contributes to gaps in 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 complexity (a read operation with one parameter), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'status' returns, error conditions, or dependencies, leaving the agent with insufficient context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the undocumented parameter 'workflowId'. It only mentions 'by ID', adding minimal context (e.g., it's an identifier) without explaining format, source, or constraints. This fails to adequately supplement the bare schema.
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 'Get workflow status by ID' clearly states the verb ('Get') and resource ('workflow status'), making the basic purpose understandable. However, it doesn't specify what 'status' entails (e.g., current state, progress, metadata) or distinguish it from sibling tools like 'listActiveWorkflows' or 'getWorkflowModels', leaving room for ambiguity.
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 doesn't mention prerequisites (e.g., needing a valid workflow ID), exclusions, or comparisons to siblings like 'listActiveWorkflows' for broader queries or 'getWorkflowModels' for template details, 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves version history but doesn't specify what the output includes (e.g., list of versions, timestamps, authors), whether it's read-only or has side effects, or any constraints like permissions or rate limits. This leaves significant gaps in understanding the tool's 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, clear sentence with no wasted words, making it easy to parse and understand at a glance. It's appropriately sized for a simple tool and front-loaded with the core purpose.
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 complexity of version history retrieval, lack of annotations, no output schema, and low parameter coverage, the description is incomplete. It doesn't explain what data is returned, how versions are formatted, or any behavioral nuances, making it inadequate for an agent to use the tool effectively without additional context.
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 input schema has 1 parameter with 0% description coverage, and the description only mentions 'content path' without adding details like format, examples, or constraints (e.g., path syntax, required permissions). It fails to compensate for the low schema coverage, providing minimal semantic value beyond the parameter name.
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 'Get version history for a content path' clearly states the action (get) and resource (version history) with a specific scope (content path). However, it doesn't distinguish this tool from potential siblings like 'compareVersions' or 'restoreVersion', which also deal with version-related operations, leaving the exact differentiation unclear.
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 doesn't mention prerequisites, exclusions, or compare it to siblings such as 'compareVersions' or 'restoreVersion', which could be relevant for version management tasks. Usage is implied by the name but not explicitly defined.
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 the full burden of behavioral disclosure. 'Start a new workflow instance' implies a write operation, but it doesn't reveal whether this requires specific permissions, what happens upon starting (e.g., triggers, side effects), rate limits, or error handling. This is a significant gap for a mutation tool with zero annotation coverage.
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, efficient sentence with no wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly, though this conciseness comes at the cost of detail.
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 complexity of starting a workflow (a mutation with 4 parameters), no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It lacks essential details about behavior, parameters, and expected outcomes, making it inadequate for effective tool selection and 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 description coverage is 0%, meaning none of the 4 parameters (model, payloadPath, title, comment) are documented in the schema. The description adds no information about these parameters—it doesn't explain what 'model' or 'payloadPath' refer to, their formats, or examples. This fails to compensate for the low coverage, leaving parameters largely unexplained.
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 'Start a new workflow instance' clearly states the action (start) and resource (workflow instance), which is better than a tautology. However, it doesn't specify what a 'workflow instance' entails or how it differs from sibling tools like 'resumeWorkflow', 'suspendWorkflow', or 'cancelWorkflow', leaving the purpose somewhat vague in context.
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. There are multiple sibling tools related to workflows (e.g., 'resumeWorkflow', 'cancelWorkflow', 'listActiveWorkflows'), but the description doesn't indicate prerequisites, timing, or distinctions, offering no usage 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a mutation action ('suspend') but doesn't specify permissions needed, side effects, reversibility, or response format. This leaves critical behavioral traits undocumented for a tool that likely alters system state.
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, efficient sentence with no wasted words, making it highly concise and front-loaded. Every part of the sentence contributes directly to stating the tool's purpose.
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 complexity of a workflow suspension tool with no annotations, 0% schema coverage, and no output schema, the description is incomplete. It lacks details on behavior, parameters, and expected outcomes, making it inadequate for safe and effective use by an AI 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?
The input schema has 0% description coverage, so parameters 'workflowId' and 'reason' are undocumented. The description adds no semantic information about these parameters, such as what 'workflowId' refers to or how 'reason' is used, failing to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Suspend a workflow instance' clearly states the action (suspend) and target (workflow instance), which is better than a tautology. However, it doesn't distinguish this tool from sibling tools like 'cancelWorkflow', 'resumeWorkflow', or 'completeWorkflowStep', leaving the specific purpose vague relative to alternatives.
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 'cancelWorkflow' or 'resumeWorkflow'. It lacks context about prerequisites, appropriate scenarios, or exclusions, offering only a basic statement of function without usage instructions.
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 the full burden of behavioral disclosure. It mentions 'unpublish', implying a mutation that removes content from a publish environment, but doesn't specify permissions required, whether it's destructive or reversible, rate limits, or what happens to the unpublished content (e.g., moved to draft, deleted). This leaves critical behavioral traits unclear 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and target, making it easy to parse quickly. Every part of the sentence contributes directly to the tool's purpose, achieving optimal 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 complexity of a mutation tool with no annotations, 2 parameters at 0% schema coverage, and no output schema, the description is incomplete. It lacks details on behavior, parameters, return values, and how it fits with sibling tools. For a tool that likely alters content state, this minimal description is insufficient for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It adds no meaning beyond the schema: it doesn't explain what 'contentPaths' are (e.g., file paths, URLs, identifiers) or what 'unpublishTree' does (e.g., unpublish nested content). With 2 parameters and no schema descriptions, the description fails to provide necessary semantic context.
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 states the action ('unpublish') and target ('content from the publish environment'), which is clear but vague. It doesn't specify what 'content' refers to (e.g., pages, assets, components) or how it differs from sibling tools like 'deactivatePage' or 'deletePage', which might have overlapping purposes. The purpose is understandable but lacks specificity and differentiation.
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. For example, it doesn't clarify if 'unpublish' is reversible, if it's for removing content from a live site versus archiving, or how it relates to tools like 'deactivatePage' or 'deletePage'. The description offers no context or exclusions, leaving usage ambiguous.
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 full burden but lacks behavioral details. It doesn't disclose if this is a read-only operation, what the output format might be (e.g., list of strings), error conditions, or any rate limits. The description is minimal and fails to provide necessary context for safe and effective use.
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 that gets straight to the point without unnecessary words. It's front-loaded with the core purpose, though it could benefit from slightly more detail without losing 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 2 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'locales' are, how results are returned, or provide any operational context, making it inadequate for a tool with undocumented inputs and unknown outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter details. It mentions 'site' and 'language master' contextually but doesn't explain what these parameters represent, their expected formats, or examples. This leaves both parameters undocumented beyond their names.
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 ('Get') and resource ('available locales'), specifying the context ('for a site and language master'). It distinguishes itself from siblings like 'fetchLanguageMasters' or 'fetchSites' by focusing on locales, but could be more explicit about what 'locales' entails (e.g., language/country codes).
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 prerequisites (e.g., needing a valid site or language master), exclusions, or how it differs from similar tools like 'fetchLanguageMasters', leaving the agent to infer usage 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 the full burden. It states 'Get' which implies a read operation, but doesn't disclose behavioral traits like permissions needed, rate limits, pagination, or what 'language masters' entails (e.g., data format, size). This leaves significant gaps for a tool with no annotation coverage.
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, efficient sentence with no wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 no annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't explain what 'language masters' are, the return format, or error handling, making it inadequate for a tool that likely retrieves complex data in a content management 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?
Schema description coverage is 0%, so the description must compensate. It mentions 'for a specific site', which adds meaning to the 'site' parameter by indicating it's required and site-specific. However, it doesn't explain the parameter's format, constraints, or examples, providing only basic context.
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 'Get language masters for a specific site' clearly states the action ('Get') and resource ('language masters'), but it's vague about what 'language masters' are and doesn't distinguish this from sibling tools like 'fetchAvailableLocales' or 'fetchSites'. It provides basic purpose but lacks 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. With siblings like 'fetchAvailableLocales' and 'fetchSites', the description doesn't explain if this is for retrieving language-specific content, configurations, or other data, leaving usage unclear.
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 full burden for behavioral disclosure. It mentions 'update' and 'verify' but doesn't specify what verification entails, whether this is a destructive operation, what permissions are required, error handling, or what happens if the component doesn't exist. For a mutation tool with zero annotation coverage, this is insufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a single sentence that states the core functionality. It's front-loaded with the primary action ('update') and includes the verification aspect. While efficient, it could potentially be more structured with separate purpose and behavior statements.
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 2 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain what verification means, what format the paths should be in, what happens on success/failure, or how this differs from other update operations. The context demands more comprehensive documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'componentPath' and 'newImagePath' implicitly but provides no details about format, constraints, or what these parameters represent. The description adds minimal semantic value beyond what can be inferred from parameter names alone.
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 purpose with a specific verb ('update') and resource ('image path for an image component'), and mentions verification. It distinguishes from generic 'updateComponent' by focusing specifically on image paths. However, it doesn't explicitly differentiate from other image-related tools like 'getPageImages' or 'updateAsset'.
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 'updateComponent' or 'updateAsset'. It mentions verification but doesn't specify prerequisites, error conditions, or when this specific tool is preferred over more general update tools. No explicit when/when-not statements are present.
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 full burden but only states the action ('activate/publish') without disclosing behavioral traits like permissions needed, whether it's destructive, rate limits, or what 'activate' entails (e.g., making page live, workflow changes). This leaves critical gaps 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it's front-loaded and appropriately sized for the tool's apparent complexity, earning its place without unnecessary elaboration.
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 no annotations, 0% schema coverage, no output schema, and a mutation tool with 2 parameters, the description is incomplete. It lacks details on behavior, parameters, and output, making it inadequate for safe and effective use by an AI 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 0%, so the description must compensate but adds no parameter details. It doesn't explain what 'pagePath' is (e.g., format, scope) or what 'activateTree' does (e.g., publish child pages). This fails to provide meaning beyond the bare schema.
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 ('activate/publish') and resource ('a single page'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'replicateAndPublish' or 'deactivatePage', which would require explicit comparison for a perfect 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?
No guidance is provided on when to use this tool versus alternatives like 'replicateAndPublish' or 'deactivatePage'. The description implies it's for publishing pages, but lacks context on prerequisites, timing, or exclusions, leaving usage unclear.
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 states 'Cancel' implies a destructive/mutative action, but doesn't disclose behavioral traits like whether cancellation is reversible, what permissions are required, if it affects related resources, or what happens to workflow data. For a mutation tool with zero annotation coverage, this is a significant gap in 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, efficient sentence with zero wasted words. It is front-loaded with the core action and target, making it immediately understandable. Every word earns its place without redundancy or fluff.
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's complexity (destructive operation), lack of annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't cover behavioral implications, parameter meanings, or usage context, leaving significant gaps for an AI agent to understand and invoke the tool 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?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'workflowId' represents (e.g., format, source) or what 'reason' is used for (e.g., optional note for audit). With 2 undocumented parameters, the description fails to provide necessary semantic context beyond the bare schema.
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 ('Cancel') and target ('a workflow instance'), which is specific and unambiguous. It distinguishes from siblings like 'suspendWorkflow' and 'resumeWorkflow' by indicating termination rather than pausing. However, it doesn't explicitly contrast with these alternatives in the text itself.
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 'suspendWorkflow' or 'resumeWorkflow'. The description lacks context about prerequisites (e.g., workflow must be active) or exclusions (e.g., cannot cancel completed workflows). It merely states what it does without indicating appropriate scenarios.
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 the full burden of behavioral disclosure. While 'Create' implies a write operation, it doesn't specify permissions required, whether the creation is reversible (e.g., via 'deleteComponent'), potential side effects, or response format. This leaves significant gaps for a mutation tool with zero annotation coverage.
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, efficient sentence that front-loads the core action and resource without unnecessary words. Every part of the sentence contributes directly to understanding the tool's purpose, 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.
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 5 parameters (0% schema coverage), no annotations, no output schema, and nested objects, the description is incomplete. It lacks details on parameter usage, behavioral traits, and output expectations, making it inadequate for safe and effective tool invocation in this complex context.
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?
With 0% schema description coverage for 5 parameters, the description doesn't add any meaning beyond the schema. It mentions 'on a page', which loosely relates to 'pagePath', but provides no details on what 'componentType', 'resourceType', 'properties', or 'name' represent, failing to compensate for the lack of schema documentation.
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 ('Create') and resource ('a new component on a page'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'createPage' or 'updateComponent', which would require specifying what makes component creation distinct from page creation or component 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. With siblings like 'createPage' (for creating pages) and 'updateComponent' (for modifying existing components), there's no indication of prerequisites, such as needing an existing page, or when to choose this over other creation or update 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Create a new page' which implies a write/mutation operation, but doesn't cover critical aspects like required permissions, whether the operation is idempotent, potential side effects (e.g., triggering workflows), or error conditions. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its 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, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by conveying essential purpose without redundancy.
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 complexity (5 parameters with nested objects, no output schema, and no annotations), the description is insufficiently complete. It doesn't explain what the tool returns, how errors are handled, or the semantics of key parameters like 'properties'. For a creation tool in a content management system, more context about success/failure outcomes and parameter usage is needed.
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?
With 0% schema description coverage for 5 parameters (3 required), the description provides no information about parameters beyond what the schema structure implies. It doesn't explain what 'parentPath', 'template', 'properties', etc., mean in the context of AEM page creation, their formats, or constraints. The description fails to compensate for the lack of schema documentation.
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 ('Create') and resource ('new page in AEM'), making the purpose immediately understandable. It distinguishes itself from siblings like 'deletePage' or 'listPages' by specifying creation. However, it doesn't explicitly differentiate from 'createComponent' or 'createVersion', which are also creation tools in the same system.
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 doesn't mention prerequisites (e.g., needing a parent path or template), exclusions (e.g., when not to create pages), or comparisons to siblings like 'bulkUpdateComponents' or 'uploadAsset' for related operations. Usage is implied but not explicitly 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. It indicates a mutation action ('deactivate/unpublish') but lacks details on permissions required, whether changes are reversible, effects on related content, or error handling. This is insufficient for a mutation tool with zero annotation coverage.
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, efficient sentence that front-loads the core action and resource without any wasted words. It is appropriately sized for the tool's complexity, making it easy to parse quickly.
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 this is a mutation tool with no annotations, 0% schema coverage, and no output schema, the description is incomplete. It lacks crucial details like behavioral traits, parameter meanings, and expected outcomes, which are necessary for safe and effective use by an AI 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 0%, so the description must compensate for undocumented parameters. It mentions 'a single page' which hints at the 'pagePath' parameter, but doesn't explain the 'deactivateTree' parameter at all. The description adds minimal value beyond the schema, failing to fully address the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('deactivate/unpublish') and the resource ('a single page'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'unpublishContent' or 'deletePage', which could have overlapping functionality, so it doesn't reach the highest 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 such as 'unpublishContent' or 'deletePage', nor does it mention prerequisites or exclusions. It merely states what the tool does without contextual usage information.
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 states the tool deletes an asset, implying a destructive mutation, but does not address critical aspects like irreversibility, permissions required, confirmation steps, or error handling. This leaves significant gaps in understanding the tool's behavior and risks.
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 wasted words, making it highly concise and front-loaded. It efficiently communicates the core action without unnecessary elaboration, though this brevity contributes to gaps in 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?
For a destructive tool with no annotations, 0% schema coverage, and no output schema, the description is incomplete. It lacks details on behavioral traits, parameter meanings, return values, and usage context, making it inadequate for safe and effective tool invocation by an 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 0%, so the description must compensate for undocumented parameters. It mentions 'asset' but does not explain the 'assetPath' parameter (e.g., format, examples) or the 'force' parameter (e.g., what it overrides, default behavior). This fails to add meaningful semantics beyond the bare schema.
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 ('Delete') and resource ('an asset from AEM DAM'), making the purpose unambiguous. It distinguishes from siblings like 'deletePage' or 'deleteComponent' by specifying 'asset', but does not explicitly differentiate from similar tools like 'unpublishContent' or 'restoreVersion' in terms of scope or effect.
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 'unpublishContent' for removing access or 'restoreVersion' for recovery. It lacks context on prerequisites, permissions, or scenarios where deletion is appropriate, 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action 'Get text content' but doesn't describe what 'text content' includes (e.g., plain text, formatted text, metadata), how it's retrieved (e.g., from a database, via API), error conditions, or performance aspects like rate limits. This leaves significant gaps for a tool with no annotation coverage.
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, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to scan and understand quickly. Every word earns its place by conveying essential information without redundancy.
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 no annotations, no output schema, and low parameter schema coverage, the description is incomplete. It doesn't cover behavioral traits, parameter details, or return values, which are critical for a tool that retrieves content. This leaves the agent with insufficient information to use the tool effectively beyond basic purpose.
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 input schema has 1 parameter with 0% description coverage, and the description doesn't add any semantic details about 'pagePath'. It doesn't explain what 'pagePath' represents (e.g., a URL, file path, identifier), its format, or examples. With low schema coverage, the description fails to compensate, leaving the parameter poorly documented.
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 'Get' and the resource 'text content from a specific page', making the purpose understandable. It distinguishes from siblings like 'getPageContent' (which might return structured content) and 'getAllTextContent' (which might return all text content without page specificity). However, it doesn't explicitly differentiate from 'getNodeContent' or 'searchContent', which could have overlapping functionality.
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 doesn't mention when to choose this over 'getAllTextContent', 'getPageContent', 'getNodeContent', or 'searchContent', nor does it specify prerequisites like requiring an active page or authentication. The context is implied but not explicit.
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 mentions 'currently running' instances, implying real-time status, but doesn't cover critical aspects like pagination (via the 'limit' parameter), response format, error handling, or authentication needs. This leaves significant gaps for a tool that likely returns dynamic data.
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, clear sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core purpose without unnecessary elaboration.
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's complexity (listing dynamic workflow instances), lack of annotations, 0% schema coverage, and no output schema, the description is insufficient. It doesn't explain what 'currently running' entails, how results are structured, or how to handle the 'limit' parameter, leaving the agent with inadequate information for reliable use.
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 input schema has 1 parameter ('limit') with 0% description coverage, and the tool description provides no information about parameters. Since the schema doesn't explain what 'limit' does (e.g., pagination or max results), the description fails to compensate, leaving the parameter's meaning unclear.
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 ('List') and resource ('currently running workflow instances'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'getWorkflowModels' or 'startWorkflow', which prevents a perfect 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 like 'getWorkflowModels' (which might list workflow definitions) or 'startWorkflow' (which initiates workflows). It lacks context about prerequisites or exclusions, offering only a basic statement of function.
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 states it's a list operation, implying read-only behavior, but doesn't cover critical aspects like pagination, rate limits, authentication needs, or what happens with invalid inputs. The description is too minimal for a tool with parameters and no output schema.
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, efficient sentence with zero waste. It's front-loaded and appropriately sized for a simple tool, though this conciseness comes at the cost of completeness.
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 complexity (3 parameters, no annotations, no output schema), the description is inadequate. It doesn't explain return values, error handling, or parameter details, leaving significant gaps for the agent to operate effectively in a server with many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but fails to do so. It mentions 'site root' which maps to the 'siteRoot' parameter, but doesn't explain 'depth' or 'limit', leaving two of three parameters undocumented. The description adds minimal value beyond the bare schema.
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 ('List') and resource ('pages under a site root'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'listChildren' or 'enhancedPageSearch', which appear to have overlapping functionality for listing content.
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 'listChildren' or 'enhancedPageSearch'. It mentions 'all pages under a site root' but doesn't specify use cases, prerequisites, or exclusions, leaving the agent to infer usage from 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It implies a mutation operation ('undo') but doesn't specify whether this is reversible, what permissions are required, what happens to related data, or what the response looks like. The description lacks critical behavioral context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single, clear sentence with no wasted words. It's front-loaded with the core purpose and appropriately sized for what it communicates.
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, 0% schema description coverage, and no output schema, the description is inadequate. It doesn't explain the parameter, behavioral implications, error conditions, or what constitutes success. Given the complexity of undoing changes in a content system, more context is needed.
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 has 0% description coverage, so the single parameter 'jobId' is completely undocumented in the schema. The description provides no information about this parameter—what it represents, where to find it, or its format. This leaves a significant gap in understanding how to invoke the tool correctly.
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 ('undo') and target ('last component changes'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from potential alternatives like 'restoreVersion' or explicitly define what constitutes 'component changes' versus other types of changes in the system.
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 'restoreVersion' or 'cancelWorkflow', nor does it mention prerequisites, constraints, or typical scenarios for its application. The agent must 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 provided, the description carries full burden but lacks behavioral details. It implies a mutation ('Update'), but doesn't disclose permissions needed, whether changes are reversible, side effects (e.g., versioning, workflows triggered), or error handling. For a mutation tool with zero annotation coverage, this is a significant gap in 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, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word contributes directly to stating the tool's purpose.
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 a mutation tool with 4 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't cover parameter meanings, behavioral traits, usage context, or return values. For this complexity level, the description should provide more guidance to be adequately helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'assetPath' is, what 'metadata' object should contain, how 'fileContent' and 'mimeType' interact, or which parameters are optional. With 4 parameters and low schema coverage, the description fails to provide needed semantics.
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 resource ('an existing asset in AEM DAM'), making the purpose unambiguous. It distinguishes from siblings like 'uploadAsset' (creates new) and 'deleteAsset' (removes), but doesn't explicitly differentiate from other update tools like 'updateComponent' or 'updateImagePath' beyond the asset focus.
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 prerequisites (e.g., asset must exist), when to use 'uploadAsset' for new assets instead, or how it differs from 'updateComponent' or 'updateImagePath' for related operations. The description only states what it does, not when to choose it.
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 states 'Update' implying a mutation, but doesn't mention permissions, side effects, reversibility, or response format. This is inadequate for a mutation tool with zero annotation coverage.
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, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly.
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's complexity (mutation with 2 parameters, nested objects, no output schema, and no annotations), the description is insufficient. It lacks details on behavior, parameters, and output, failing to provide a complete picture for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'component properties' but doesn't explain what 'componentPath' or 'properties' entail, their formats, or constraints, adding minimal value beyond the schema.
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 ('component properties in AEM'), making the purpose understandable. However, it doesn't distinguish this from sibling tools like 'bulkUpdateComponents' or 'updateAsset', which would require more specificity about scope or 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?
No guidance is provided on when to use this tool versus alternatives like 'bulkUpdateComponents' or 'createComponent'. The description lacks context about prerequisites, typical scenarios, or exclusions, leaving usage unclear.
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 full burden but only states the action without behavioral details. It doesn't disclose permissions required, rate limits, file size constraints, or what happens on success/failure, which is critical for a mutation tool like upload.
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, efficient sentence with no wasted words, making it easy to parse. It's front-loaded with the core action, though this brevity contributes to gaps in 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?
For a mutation tool with 5 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It lacks details on behavior, parameters, and expected outcomes, failing to provide adequate context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter details. It doesn't explain what 'parentPath', 'fileContent', or other parameters mean, leaving semantics unclear beyond the schema's basic types.
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 ('upload') and resource ('new asset to AEM DAM'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'updateAsset' or 'deleteAsset' beyond the basic action, missing explicit comparison.
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 'updateAsset' or 'deleteAsset'. The description lacks context about prerequisites, such as needing an existing parent path or handling of duplicates, leaving usage unclear.
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 states the tool retrieves text content but doesn't mention whether it's read-only, safe, requires permissions, handles errors, or returns structured data. For a tool with zero annotation coverage, this leaves significant 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 a single, efficient sentence that front-loads the core purpose. Every word contributes to understanding what the tool does without unnecessary elaboration.
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 lack of annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain what 'all text content' means in practice, how it's structured, or any limitations, which is inadequate for a tool with potential 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?
The description doesn't add any parameter-specific information beyond what the input schema provides (a single 'pagePath' parameter). With 0% schema description coverage, the baseline is low, but since there's only one parameter and its purpose is implied by the tool name, the description doesn't compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get all text content') and resource ('from a page'), specifying what content types are included (titles, text components, descriptions). However, it doesn't differentiate from sibling tools like 'getPageTextContent' or 'getPageContent', which appear to serve similar purposes.
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 'getPageTextContent' or 'getPageContent' from the sibling list. It lacks context about prerequisites, exclusions, or typical use cases.
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 full burden but only states what is retrieved, not behavioral aspects like permissions needed, rate limits, response format, or whether it's a read-only operation. It lacks critical context for safe invocation.
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, efficient sentence with no wasted words, clearly front-loading the core functionality. It's appropriately sized for the tool's apparent 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?
Given no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't address return values, error conditions, or behavioral traits, leaving significant gaps for a tool that likely returns complex content.
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 0% description coverage, but the description adds no parameter details beyond implying 'pagePath' is needed. It doesn't explain what a pagePath is, its format, or constraints. Baseline 3 is appropriate as the single parameter is straightforward, but minimal value is added.
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 'Get' and resource 'content from a page', specifying it includes 'Experience Fragments and Content Fragments'. This distinguishes it from sibling tools like getPageTextContent (text only) or getPageProperties (properties only), though it doesn't explicitly contrast with them.
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 getAllTextContent, getPageTextContent, or getNodeContent. The description implies comprehensive content retrieval but doesn't specify use cases or prerequisites.
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 the full burden of behavioral disclosure. It states what the tool does but doesn't describe how it behaves: for example, it doesn't specify the return format (e.g., list of image URLs or metadata), error handling for invalid paths, permissions required, or whether it's a read-only operation. This leaves significant gaps for an agent to understand the tool's 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, efficient sentence that front-loads the core purpose without unnecessary words. Every part of the sentence contributes directly to understanding the tool's function, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (retrieving images from a page, potentially including fragments), lack of annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't address return values, error conditions, or behavioral nuances, leaving the agent with insufficient information to use the tool effectively beyond its basic purpose.
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 one parameter with 0% description coverage, so the description must compensate. It implies the parameter is a page path but doesn't add details like format (e.g., absolute path), examples, or constraints. This provides minimal semantic value beyond the schema, aligning with the baseline for incomplete 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 clearly states the verb ('Get') and resource ('all images from a page'), including the scope of 'those within Experience Fragments'. It distinguishes from siblings like 'getPageContent' or 'getPageTextContent' by focusing specifically on images. However, it doesn't explicitly contrast with 'scanPageComponents' which might also retrieve images, preventing a perfect 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 like 'scanPageComponents' or 'getPageContent'. It lacks context about prerequisites, such as whether the page must exist or be accessible, and doesn't mention any exclusions or specific 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?
No annotations are provided, so the description carries full burden. It states the tool 'scan[s] a page to discover', implying a read-only operation, but doesn't disclose behavioral traits like whether it requires authentication, has rate limits, returns structured data, or handles errors. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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, efficient sentence that front-loads the core purpose ('Scan a page to discover all components and their properties') with zero wasted words. Every part of the sentence contributes directly to understanding the tool's function.
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 complexity of scanning pages for components, lack of annotations, no output schema, and low parameter coverage, the description is incomplete. It doesn't explain what 'components' mean in this context, the format of returned properties, or any behavioral aspects like performance or limitations, making it inadequate for confident use.
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 1 parameter with 0% description coverage, and the tool description doesn't add any parameter-specific information. It mentions 'pagePath' contextually but doesn't explain its format, constraints, or examples. With low schema coverage, the description fails to compensate, resulting in minimal added value beyond the bare schema.
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 ('scan') and target ('a page') with the goal of 'discover[ing] all components and their properties'. It distinguishes from obvious siblings like 'getPageContent' or 'getPageProperties' by focusing on component discovery rather than content retrieval. However, it doesn't explicitly differentiate from all possible siblings like 'listChildren' or 'enhancedPageSearch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. The description implies usage for component discovery on a page, but doesn't specify prerequisites, exclusions, or compare it to siblings like 'getPageContent', 'listChildren', or 'enhancedPageSearch' that might overlap in functionality.
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 the full burden of behavioral disclosure. It states 'Get all available sites' but does not specify if this is a read-only operation, what permissions are needed, how results are returned (e.g., pagination, format), or any rate limits. This is inadequate for a tool with zero annotation coverage.
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, efficient sentence with no wasted words. It is front-loaded and directly states the tool's purpose, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It does not explain behavioral traits like safety, response format, or error handling. For a tool with no structured data to rely on, this minimal description fails to provide sufficient context for effective use.
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 input schema has no parameters (parameter count: 0), and schema description coverage is 100%, so the description does not need to compensate for missing param info. The description adds value by clarifying the resource ('sites in AEM'), which is not in the schema, but this is minimal since the schema is empty.
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 'Get' and the resource 'all available sites in AEM', making the purpose understandable. However, it does not explicitly differentiate from sibling tools like 'listPages' or 'listChildren', which might also retrieve site-related data, leaving some ambiguity in 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 versus alternatives. With many sibling tools that could involve site data (e.g., 'listPages', 'searchContent'), there is no indication of context, prerequisites, or exclusions, leaving usage unclear.
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 states it 'gets' data, implying a read-only operation, but doesn't disclose behavioral traits like whether it requires authentication, returns structured data, has rate limits, or if it's idempotent. This leaves significant gaps for a tool with no annotation coverage.
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, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly.
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 complexity of a tool that retrieves system-level data, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'MCP methods' entails (e.g., if it returns tool names, metadata, or capabilities) or the format of the returned list, leaving the agent with insufficient context.
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?
With 0 parameters and 100% schema description coverage, the schema fully documents the lack of inputs. The description doesn't add parameter details, but since there are no parameters, a baseline of 4 is appropriate as no compensation 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 clearly states the verb ('Get') and resource ('list of available MCP methods'), making the purpose understandable. However, it doesn't distinguish itself from potential siblings like 'getStatus' or 'getTemplates' that also retrieve system information, missing full differentiation.
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. With many sibling tools for retrieving various data (e.g., 'getStatus', 'fetchSites', 'listPages'), the description lacks context on its specific use case, such as for discovering server capabilities or debugging.
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 the full burden of behavioral disclosure. It only states what the tool does ('Get all available workflow models') without mentioning permissions, rate limits, pagination, or response format. For a tool with zero annotation coverage, this is a significant gap in 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, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by conveying essential information without 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?
Given the tool has 0 parameters, no annotations, and no output schema, the description is minimally adequate but lacks depth. It states the purpose but doesn't cover behavioral aspects like what 'available' means, response format, or error handling. For a simple retrieval tool, it's passable but could be more informative to fully guide the agent.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here, but it also doesn't compensate for any gaps since there are none. A baseline of 4 is given as it meets expectations for a parameterless tool.
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 ('Get') and resource ('all available workflow models'), making the purpose immediately understandable. However, it doesn't differentiate from potential sibling tools like 'listActiveWorkflows' or 'getTemplates', which might also retrieve workflow-related data, so it doesn't achieve full sibling differentiation.
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. With siblings like 'listActiveWorkflows' and 'getTemplates' present, there's no indication of whether this tool retrieves metadata, active instances, templates, or something else, leaving the agent to guess based on 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Resume') but doesn't disclose critical traits such as whether this requires specific permissions, if it's idempotent, what happens on success/failure, or any rate limits. For a mutation tool (implied by 'Resume') with zero annotation coverage, this is a significant gap in transparency beyond the basic action.
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, efficient sentence ('Resume a suspended workflow instance') that is front-loaded with the core action and resource. There is zero waste or redundancy, making it highly concise and well-structured for quick understanding.
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's complexity (a mutation operation with no annotations, no output schema, and 1 undocumented parameter), the description is incomplete. It lacks details on behavioral traits, parameter semantics, expected outcomes, or error handling. While concise, it doesn't provide enough context for safe and effective use by an AI agent, especially compared to more comprehensive sibling tools in the list.
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 1 parameter with 0% description coverage, so the schema provides no semantic context. The description adds no information about the 'workflowId' parameter, such as its format, source, or constraints. However, with only one parameter, the baseline is higher; the description implies the parameter identifies a suspended workflow instance but doesn't elaborate, resulting in minimal added value beyond the schema's structural definition.
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 'Resume a suspended workflow instance' clearly states the verb ('Resume') and resource ('a suspended workflow instance'), making the purpose immediately understandable. It distinguishes from siblings like 'startWorkflow', 'cancelWorkflow', and 'suspendWorkflow' by specifying it acts on already-suspended instances. However, it doesn't explicitly contrast with 'completeWorkflowStep' or 'listActiveWorkflows', which slightly limits differentiation.
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 by indicating it resumes 'suspended' workflows, suggesting it should be used when a workflow is in a suspended state. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'cancelWorkflow' or 'startWorkflow', nor does it mention prerequisites (e.g., needing a valid workflow ID from 'listActiveWorkflows' or 'suspendWorkflow'). The context is clear but lacks detailed exclusions or named alternatives.
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 and adds valuable behavioral context: 'with validation and rollback support' discloses safety features (validation prevents errors, rollback enables recovery), which is crucial for a mutation tool. It doesn't detail permissions, rate limits, or response format, but the added safety info is significant.
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, efficient sentence that front-loads the core purpose ('Update multiple components in a single operation') and adds key behavioral traits ('with validation and rollback support'). Every word earns its place with no redundancy or fluff.
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 mutation tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It covers purpose and some safety behaviors but misses parameter explanations, error handling details, and output expectations. It's minimally adequate but has clear gaps given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but fails to do so. It mentions 'validation' and 'rollback' which loosely relate to 'validateFirst' and 'continueOnError', but doesn't explain the three parameters (updates, validateFirst, continueOnError) or their semantics, leaving them undocumented. This is inadequate given the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Update multiple components in a single operation' specifies the verb (update) and resource (components), with 'multiple' and 'single operation' distinguishing it from the sibling 'updateComponent'. However, it doesn't explicitly contrast with all potential alternatives like batch operations in other tools.
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 needing to update multiple components at once, as opposed to the sibling 'updateComponent' for single updates. It doesn't provide explicit when-not-to-use guidance, prerequisites, or comparisons to other bulk operations like 'bulkUpdateAssets' if they existed, leaving some context gaps.
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:

[![aem-mcp-server MCP server](https://glama.ai/mcp/servers/indrasishbanerjee/aem-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/indrasishbanerjee/aem-mcp-server)

Score Badge

Copy to your README.md:

[![aem-mcp-server MCP server](https://glama.ai/mcp/servers/indrasishbanerjee/aem-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/indrasishbanerjee/aem-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/indrasishbanerjee/aem-mcp-server'

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