Hybris MCP Server
Integrates with SAP Commerce Cloud (Hybris) to manage product data, orders, and categories, and provides administrative capabilities including FlexibleSearch execution, Groovy scripting, and ImpEx data management.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Hybris MCP Serverrun a FlexibleSearch to find orders created in the last 24 hours"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Hybris MCP Server
MCP (Model Context Protocol) server for SAP Commerce Cloud (Hybris) integration. This server allows AI assistants like Claude to interact with your Hybris instance.
Features
Product Management: Search products, get product details, browse categories
Order Management: View orders and order details
FlexibleSearch: Execute FlexibleSearch queries directly
Groovy Scripts: Run Groovy scripts via the scripting console
ImpEx: Import and export data using ImpEx format
Cron Jobs: List and trigger cron jobs
Cache Management: Clear Hybris caches
Catalog Sync: Trigger catalog synchronization
Health Checks: Monitor system health
Installation
git clone <repository-url>
cd hybris-mcp
npm install
npm run buildConfiguration
Configure via environment variables:
Variable | Required | Description | Default |
| Yes | Base URL of your Hybris instance | - |
| Yes | Admin username (HAC access required) | - |
| Yes | Admin password | - |
| No | OCC base site ID |
|
| No | Product catalog ID |
|
| No | Catalog version |
|
| No | HAC path prefix |
|
Common Configurations
Standard Hybris (localhost):
HYBRIS_BASE_URL=https://localhost:9002
HYBRIS_USERNAME=admin
HYBRIS_PASSWORD=nimdaSAP Commerce Cloud (CCv2):
HYBRIS_BASE_URL=https://backoffice.your-environment.model-t.cc.commerce.ondemand.com
HYBRIS_USERNAME=admin
HYBRIS_PASSWORD=your-password
HYBRIS_HAC_PATH=/hacCustom Site Configuration:
HYBRIS_BASE_URL=https://localhost:9002
HYBRIS_USERNAME=admin
HYBRIS_PASSWORD=nimda
HYBRIS_BASE_SITE_ID=yoursite
HYBRIS_CATALOG_ID=yourProductCatalog
HYBRIS_CATALOG_VERSION=OnlineUsage with Claude Code
Add the MCP server using the CLI:
claude mcp add hybris \
-e HYBRIS_BASE_URL=https://localhost:9002 \
-e HYBRIS_USERNAME=admin \
-e HYBRIS_PASSWORD=nimda \
-- node /path/to/hybris-mcp/dist/index.jsOr manually add to your Claude Code MCP settings (~/.claude.json or project config):
{
"mcpServers": {
"hybris": {
"type": "stdio",
"command": "node",
"args": ["/path/to/hybris-mcp/dist/index.js"],
"env": {
"HYBRIS_BASE_URL": "https://localhost:9002",
"HYBRIS_USERNAME": "admin",
"HYBRIS_PASSWORD": "nimda"
}
}
}
}Usage with Claude Desktop
Add to your Claude Desktop configuration (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"hybris": {
"command": "node",
"args": ["/path/to/hybris-mcp/dist/index.js"],
"env": {
"HYBRIS_BASE_URL": "https://localhost:9002",
"HYBRIS_USERNAME": "admin",
"HYBRIS_PASSWORD": "nimda"
}
}
}
}Usage with Cursor
Add to your Cursor MCP configuration (~/.cursor/mcp.json):
{
"mcpServers": {
"hybris": {
"command": "node",
"args": ["/path/to/hybris-mcp/dist/index.js"],
"env": {
"HYBRIS_BASE_URL": "https://localhost:9002",
"HYBRIS_USERNAME": "admin",
"HYBRIS_PASSWORD": "nimda"
}
}
}
}Usage with Windsurf
Add to your Windsurf MCP configuration (~/.codeium/windsurf/mcp_config.json):
{
"mcpServers": {
"hybris": {
"command": "node",
"args": ["/path/to/hybris-mcp/dist/index.js"],
"env": {
"HYBRIS_BASE_URL": "https://localhost:9002",
"HYBRIS_USERNAME": "admin",
"HYBRIS_PASSWORD": "nimda"
}
}
}
}Usage with VS Code (Copilot/Continue/Cline)
For VS Code extensions that support MCP, add to your workspace .vscode/mcp.json:
{
"servers": {
"hybris": {
"command": "node",
"args": ["/path/to/hybris-mcp/dist/index.js"],
"env": {
"HYBRIS_BASE_URL": "https://localhost:9002",
"HYBRIS_USERNAME": "admin",
"HYBRIS_PASSWORD": "nimda"
}
}
}
}Usage with Zed
Add to your Zed settings (~/.config/zed/settings.json):
{
"context_servers": {
"hybris": {
"command": {
"path": "node",
"args": ["/path/to/hybris-mcp/dist/index.js"],
"env": {
"HYBRIS_BASE_URL": "https://localhost:9002",
"HYBRIS_USERNAME": "admin",
"HYBRIS_PASSWORD": "nimda"
}
}
}
}
}Usage with JetBrains IDEs
For IntelliJ IDEA, WebStorm, PyCharm, and other JetBrains IDEs with AI Assistant, add to your MCP configuration:
macOS/Linux: ~/.config/JetBrains/mcp.json
Windows: %APPDATA%\JetBrains\mcp.json
{
"mcpServers": {
"hybris": {
"command": "node",
"args": ["/path/to/hybris-mcp/dist/index.js"],
"env": {
"HYBRIS_BASE_URL": "https://localhost:9002",
"HYBRIS_USERNAME": "admin",
"HYBRIS_PASSWORD": "nimda"
}
}
}
}Usage with Sourcegraph Cody
Add to your Cody MCP configuration (~/.config/cody/mcp.json):
{
"mcpServers": {
"hybris": {
"command": "node",
"args": ["/path/to/hybris-mcp/dist/index.js"],
"env": {
"HYBRIS_BASE_URL": "https://localhost:9002",
"HYBRIS_USERNAME": "admin",
"HYBRIS_PASSWORD": "nimda"
}
}
}
}Usage with Raycast
Add to your Raycast AI extension MCP settings (~/.config/raycast/mcp.json):
{
"mcpServers": {
"hybris": {
"command": "node",
"args": ["/path/to/hybris-mcp/dist/index.js"],
"env": {
"HYBRIS_BASE_URL": "https://localhost:9002",
"HYBRIS_USERNAME": "admin",
"HYBRIS_PASSWORD": "nimda"
}
}
}
}Generic MCP Configuration
For any other MCP-compatible client, the server uses stdio transport. Run with:
node /path/to/hybris-mcp/dist/index.jsRequired environment variables:
HYBRIS_BASE_URLHYBRIS_USERNAMEHYBRIS_PASSWORD
Available Tools
Administration (HAC) - Full Support
All HAC-based tools work reliably with Basic authentication:
Tool | Description |
| Execute FlexibleSearch queries |
| Run Groovy scripts |
| Import ImpEx data |
| Export data to ImpEx format |
| List cron jobs and their status |
| Trigger a cron job to run |
| Clear Hybris caches |
| Get system information |
| Sync catalog versions |
Product & Catalog (OCC API)
Tool | Description | Notes |
| Check system health | Always works |
| Get detailed product information by code | Works with Basic auth |
| Get category details by code | Works with Basic auth |
| Search for products in the catalog | Requires Solr indexing* |
| List all categories in the catalog | Endpoint may not be exposed* |
Orders (OCC API)
Tool | Description | Notes |
| Get orders for a user | Requires OAuth* |
| Get specific order details | Requires OAuth* |
*See Known Limitations below.
Example Prompts
Search Products
Search for "camera" products in HybrisFlexibleSearch
Run a FlexibleSearch query: SELECT {pk}, {code}, {name[en]} FROM {Product} WHERE {code} LIKE '%camera%'Execute Groovy
Execute this Groovy script to count products:
import de.hybris.platform.core.Registry
def ctx = Registry.getApplicationContext()
def flexibleSearchService = ctx.getBean("flexibleSearchService")
def query = "SELECT COUNT(*) FROM {Product}"
def result = flexibleSearchService.search(query)
println "Total products: ${result.result[0]}"Import ImpEx
Import this ImpEx to create a product:
INSERT_UPDATE Product; code[unique=true]; name[lang=en]; catalogVersion(catalog(id),version)
; testProduct001 ; Test Product ; electronicsProductCatalog:OnlineTrigger Catalog Sync
Sync the electronics catalog from Staged to OnlineKnown Limitations
OCC Order Endpoints Require OAuth
The get_orders and get_order tools require OAuth user authentication, not just Basic auth. These endpoints need a user-specific OAuth token obtained via the password grant flow:
POST /authorizationserver/oauth/token
Content-Type: application/x-www-form-urlencoded
grant_type=password&username=user@example.com&password=secret&client_id=mobile_android&client_secret=secretWorkaround: Use flexible_search to query orders directly:
SELECT {pk}, {code}, {user}, {totalPrice} FROM {Order} WHERE {user} = ?userProduct Search Requires Solr
The search_products tool uses the OCC search endpoint which requires Solr indexing. If your instance uses a different search provider (e.g., Algolia), this endpoint may return empty results.
Workaround: Use flexible_search to query products:
SELECT {pk}, {code}, {name[en]} FROM {Product} WHERE {name[en]} LIKE '%search_term%'Categories Endpoint May Not Be Exposed
The get_categories tool uses an OCC endpoint that may not be exposed in all Hybris configurations.
Workaround: Use flexible_search to query categories:
SELECT {pk}, {code}, {name[en]} FROM {Category} WHERE {catalogVersion} IN (
{{ SELECT {pk} FROM {CatalogVersion} WHERE {version} = 'Online' }}
)Security Notes
Store credentials securely - never commit them to version control
Use environment variables or secure secret management
The server requires HAC admin access for administrative tools
Consider using read-only credentials if you only need OCC API access
Security Considerations
This MCP server provides powerful administrative access to your Hybris instance:
FlexibleSearch: Can query any data including sensitive tables (users, passwords, tokens)
Groovy Scripts: Execute arbitrary code with full system access (file system, network, processes)
ImpEx: Can modify any data in the system including user accounts and permissions
Recommendations:
Use dedicated service accounts with minimal required permissions
Enable audit logging on your Hybris instance to track all operations
Never expose the MCP server to untrusted networks or users
Review all Groovy scripts before execution in production environments
Consider network segmentation to restrict access to HAC endpoints
Development
# Watch mode for development
npm run dev
# Build
npm run build
# Run directly
HYBRIS_BASE_URL=https://localhost:9002 \
HYBRIS_USERNAME=admin \
HYBRIS_PASSWORD=nimda \
npm startTroubleshooting
Connection Issues
Verify your Hybris instance is running and accessible
Check if HAC is enabled and accessible at the configured path
Ensure credentials have admin access to HAC
SSL Certificate Errors
For local development with self-signed certificates:
NODE_TLS_REJECT_UNAUTHORIZED=0 node dist/index.jsWARNING: Never use
NODE_TLS_REJECT_UNAUTHORIZED=0in production environments. This disables TLS certificate validation and exposes you to man-in-the-middle attacks. For production, configure proper SSL certificates.
CSRF Token Errors
The server handles CSRF tokens automatically. If you see CSRF errors:
Check that HAC login is working manually
Verify the HAC path is correct
Try restarting the MCP server to get a fresh session
License
MIT
Available Tools
16 toolsclear_cacheC
Clear the Hybris cache
| Name | Required | Description | Default |
|---|---|---|---|
| cacheType | No | Specific cache type to clear (optional, clears all if not specified) |
TDQS
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. 'Clear' implies a destructive/mutating operation, but the description doesn't specify whether this requires admin permissions, whether it's reversible, what side effects might occur, or any rate limits. It provides minimal behavioral context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple tool with one optional parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a potentially destructive cache-clearing operation with no annotations and no output schema, the description is inadequate. It doesn't explain what 'Hybris cache' refers to, what happens after clearing, whether the operation is synchronous/asynchronous, or what errors might occur. The agent lacks crucial context for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the optional 'cacheType' parameter. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Clear') and target resource ('the Hybris cache'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from potential sibling cache-related tools (none are listed among siblings, but the agent might not know if other cache tools exist).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites, timing considerations, or what effects clearing the cache might have on system performance or data consistency.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
execute_groovyC
Execute a Groovy script in the Hybris scripting console
| Name | Required | Description | Default |
|---|---|---|---|
| script | Yes | Groovy script to execute | |
| commit | No | Whether to commit database changes (default: false) |
TDQS
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 execution but doesn't cover critical aspects like: whether this requires admin permissions, potential side effects on the Hybris system, timeout or resource limits, or what happens when 'commit' is true versus false. The description is minimal and leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a tool with two parameters and clearly front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that executes arbitrary Groovy scripts in a production system with database commit capabilities, the description is inadequate. With no annotations, no output schema, and a potentially dangerous operation, the description should address safety considerations, permission requirements, and expected output format. The current description leaves too many critical questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it doesn't explain script constraints, provide Groovy examples, or clarify the implications of the commit parameter. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Execute') and target ('Groovy script in the Hybris scripting console'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'clear_cache' or 'export_impex', but the specificity of executing Groovy scripts in Hybris provides inherent distinction from most siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, typical use cases, or when other tools might be more appropriate (e.g., using 'flexible_search' for queries instead of custom Groovy scripts).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_impexC
Export data to ImpEx format using a FlexibleSearch query
| Name | Required | Description | Default |
|---|---|---|---|
| flexQuery | Yes | FlexibleSearch query for data to export |
TDQS
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 ('Export data') but doesn't reveal critical traits: whether this is a read-only operation, if it requires specific permissions, what the output looks like (e.g., file format, size limits), or any side effects (e.g., system load). For a tool with no 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.
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 is front-loaded with the core action ('Export data to ImpEx format') and includes the key mechanism. Every part of the sentence earns its place, 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of an export operation with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a file, data stream, or status), potential errors, or integration details. For a tool that likely involves data transformation and output, more context is needed to understand its full scope and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning beyond the input schema. It mentions 'using a FlexibleSearch query', which aligns with the 'flexQuery' parameter described in the schema (100% coverage). However, it doesn't provide additional context such as query syntax examples, valid data scopes, or constraints. With high schema coverage, the baseline is 3, as the description doesn't compensate with extra semantic details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Export') and resource ('data to ImpEx format'), and mentions the mechanism ('using a FlexibleSearch query'). It distinguishes itself from siblings like 'import_impex' by focusing on export rather than import. However, it doesn't explicitly differentiate from other data retrieval tools like 'flexible_search' beyond the output format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., when ImpEx export is needed over other formats), exclusions, or compare it to siblings like 'flexible_search' (which might retrieve data without export) or 'import_impex'. Usage is implied only by the tool's name and description, lacking explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
flexible_searchC
Execute a FlexibleSearch query against the Hybris database. Use FlexibleSearch syntax.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | FlexibleSearch query (e.g., "SELECT {pk}, {code} FROM {Product}") | |
| maxCount | No | Maximum number of results (default: 100) |
TDQS
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 the query syntax but doesn't cover critical aspects like permissions needed, whether this is read-only or can modify data, rate limits, error handling, or what the output looks like. For a database query tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences that directly state the tool's purpose and required syntax. Every word earns its place with zero wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a database query tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, what errors might occur, security implications, or how it differs from sibling query tools. The agent would struggle to use this effectively without trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description adds no additional parameter information beyond what's in the schema, meeting the baseline for high schema coverage but not providing extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Execute a FlexibleSearch query') and target resource ('against the Hybris database'), with specific syntax mentioned. However, it doesn't distinguish this from sibling tools like 'search_products' or 'execute_groovy' that might also query the database.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'search_products' or 'execute_groovy'. The description only states what the tool does, not when it's appropriate or what its limitations are relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_categoriesB
Get the category tree from the product catalog
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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 mentions retrieving a 'category tree' but doesn't specify format, depth, permissions needed, or whether it's cached/live data. For a read operation with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without any fluff or redundancy. It's appropriately sized for a simple, parameterless tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read tool with no output schema, the description is minimally adequate but incomplete. It doesn't explain what a 'category tree' entails (structure, fields) or behavioral aspects like performance or data freshness, leaving the agent to guess about the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (empty schema). The description appropriately doesn't discuss parameters since none exist, maintaining focus on the tool's purpose without unnecessary detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('category tree from the product catalog'), making the purpose understandable. However, it doesn't distinguish this tool from its sibling 'get_category' (singular vs. plural), which could cause confusion about when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_category' or 'search_products'. The description only states what it does, not when it's appropriate or what context it serves.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_categoryC
Get details about a specific category
| Name | Required | Description | Default |
|---|---|---|---|
| categoryCode | Yes | The category code |
TDQS
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 'Get details,' implying a read-only operation, but doesn't address permissions, rate limits, error handling, or what 'details' includes (e.g., fields, format). 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('Get details about a specific category') that is front-loaded and wastes no words. It could be more structured by including key details, but it's appropriately sized for its limited content, earning a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is incomplete. It doesn't explain what 'details' are returned, how errors are handled, or differentiate from siblings. For a read operation with no structured output, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'categoryCode' documented as 'The category code.' The description adds no additional meaning beyond this, as it doesn't explain the parameter's role, format, or examples. With high schema coverage, the baseline is 3, and the description doesn't compensate or add value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose ('Get details about a specific category'), which is clear but vague. It specifies the verb ('Get') and resource ('category'), but doesn't differentiate from sibling tools like 'get_categories' or explain what 'details' entail. It avoids tautology but lacks specificity about scope or content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_categories' (which might list categories) or 'get_product' (which might relate to categories), nor does it specify prerequisites or exclusions. The description implies usage for retrieving category details but offers no contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_cronjobsB
List all cron jobs and their status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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 lists cron jobs and their status, implying a read-only operation, but doesn't disclose behavioral traits like whether it requires authentication, has rate limits, returns paginated results, or what 'status' entails. For a 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('List all cron jobs and their status') with zero waste. Every word earns its place, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks context on behavioral aspects like return format or usage scenarios. Without annotations or output schema, more detail on what 'status' includes would improve completeness, but it's not critically incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info beyond the schema, but with no parameters, the baseline is 4. It appropriately avoids unnecessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('all cron jobs and their status'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'trigger_cronjob', but the verb 'List' versus 'trigger' provides implicit distinction. No tautology or misleading elements are present.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. Sibling tools include 'trigger_cronjob' and 'get_system_info', which might overlap in monitoring contexts, but no explicit when/when-not instructions or prerequisites are mentioned. Usage is implied only by the action 'List'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_orderC
Get details of a specific order
| Name | Required | Description | Default |
|---|---|---|---|
| userId | Yes | User ID or email | |
| orderCode | Yes | Order code/number |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but only states the basic action. It doesn't reveal whether this is a read-only operation, if it requires authentication, what happens with invalid inputs, or the format of returned details, leaving 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence that directly states the tool's purpose without any fluff. It's front-loaded and wastes no words, making it efficient for an agent to parse, 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of retrieving order details (which may involve permissions, error handling, or data formats) and the absence of annotations and output schema, the description is incomplete. It doesn't address behavioral aspects, usage context, or output expectations, making it insufficient for an agent to fully understand the tool's role and limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond what the input schema provides, as schema description coverage is 100% with clear parameter descriptions. The baseline score of 3 reflects adequate parameter documentation solely from the schema, with the description offering no additional context about how parameters interact or their real-world significance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('details of a specific order'), making it easy to understand what the tool does. However, it doesn't distinguish itself from sibling tools like 'get_orders' (which likely lists multiple orders) or 'get_product' (which retrieves product details), missing an opportunity for clearer differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing both userId and orderCode), compare it to 'get_orders' for listing orders, or specify contexts where this tool is appropriate, leaving the agent to infer usage 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.
get_ordersC
Get orders for a specific user
| Name | Required | Description | Default |
|---|---|---|---|
| userId | Yes | User ID or email |
TDQS
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 it 'gets' orders, implying a read-only operation, but doesn't disclose behavioral traits like whether it returns all orders or is paginated, what format the output is in, error conditions, or rate limits. The description is minimal and lacks necessary 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero waste. It's front-loaded with the core purpose and efficiently conveys the essential information without unnecessary details, 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that likely returns complex order data. It doesn't explain what 'orders' entail (e.g., fields, format), potential side effects, or error handling. For a read operation with undocumented behavior, more context is needed to ensure reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the schema fully documenting the 'userId' parameter as 'User ID or email'. The description adds no additional meaning beyond this, as it doesn't explain parameter usage or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('orders'), and specifies the scope ('for a specific user'). It distinguishes from sibling tools like 'get_order' (singular) by implying it retrieves multiple orders. However, it doesn't explicitly differentiate from potential filtering tools like 'search_products' for orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), exclusions, or compare it to siblings like 'flexible_search' or 'get_order'. Usage is implied only by the name and description, with no explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_productB
Get detailed information about a specific product by its code
| Name | Required | Description | Default |
|---|---|---|---|
| productCode | Yes | The product code/SKU |
TDQS
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 retrieving 'detailed information' but does not specify what details are included, whether authentication is required, rate limits, or error handling. This leaves significant gaps for a tool with no structured safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded and wastes no space, 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is minimally adequate. However, it lacks details on return values, error cases, or behavioral traits, which would enhance completeness for an agent's understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'productCode' clearly documented. The description adds no additional meaning beyond the schema, such as format examples or constraints, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('detailed information about a specific product'), making the purpose evident. However, it does not explicitly differentiate this tool from sibling tools like 'search_products' or 'get_categories', which prevents a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'search_products' or 'get_categories'. It lacks context about prerequisites, exclusions, or specific scenarios, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_system_infoB
Get Hybris system information and health status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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 mentions retrieving 'information and health status', which suggests a read-only operation, but doesn't disclose behavioral traits like permissions needed, rate limits, or what specific data is returned. This leaves significant gaps 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.
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 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no annotations, and no output schema, the description is minimally adequate but incomplete. It states what the tool does but lacks details on return values, error conditions, or how it differs from 'health_check', leaving room for improvement in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add param details, but that's appropriate here, warranting a baseline score above minimum viable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'Hybris system information and health status', making the purpose evident. However, it doesn't distinguish this tool from sibling 'health_check', which might overlap in functionality, 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.
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 'health_check'. The description implies a general system info retrieval, but without explicit context or exclusions, usage remains ambiguous relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
health_checkB
Check if the Hybris instance is healthy and reachable
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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 checks health and reachability but lacks details on what 'healthy' entails (e.g., response codes, metrics), whether it's read-only or has side effects, or any rate limits or authentication needs, making it insufficient for a mutation-free tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain what 'healthy' means, what the output might include (e.g., status codes, error messages), or how it integrates with sibling tools, leaving gaps for an agent to understand its full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter semantics, so it meets the baseline of 4 for zero-parameter tools, as there's nothing to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Check') and target resource ('Hybris instance'), focusing on health and reachability. However, it doesn't explicitly differentiate from sibling tools like 'get_system_info', which might also provide health-related data, leaving some ambiguity about uniqueness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing (e.g., before other operations), or how it differs from siblings like 'get_system_info' that might offer overlapping functionality, leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
import_impexC
Import data using ImpEx format
| Name | Required | Description | Default |
|---|---|---|---|
| impexContent | Yes | ImpEx content to import |
TDQS
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 imports data but doesn't describe effects (e.g., whether it overwrites existing data, requires permissions, has side effects like triggering updates, or handles errors). 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.
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 for a simple tool, though it could be more front-loaded with key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a data import tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits, usage context, and 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'impexContent' documented in the schema as 'ImpEx content to import'. The description adds no additional meaning beyond this, so it meets the baseline score of 3 when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Import data using ImpEx format' states the action (import) and the format (ImpEx), but it's vague about what data is being imported or into what system. It doesn't distinguish from sibling tools like 'export_impex' beyond the direction of operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, context for ImpEx imports, or refer to sibling tools like 'export_impex' for related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_productsC
Search for products in the Hybris catalog using a query string
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for products | |
| pageSize | No | Number of results per page (default: 20) | |
| currentPage | No | Page number to retrieve (0-indexed, default: 0) |
TDQS
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 mentions 'using a query string' but doesn't disclose key traits like whether this is a read-only operation, how results are returned (e.g., pagination details beyond schema), performance expectations, or error handling, which are critical 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It front-loads the core purpose ('Search for products') and includes essential context ('in the Hybris catalog using a query string'), 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.
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 3 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on return values (e.g., result format), behavioral constraints (e.g., rate limits), or error cases, leaving significant gaps for the agent to operate effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters like 'query', 'pageSize', and 'currentPage'. The description adds no extra meaning beyond implying a search context, meeting the baseline for high schema coverage without compensating with additional insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search for products') and resource ('in the Hybris catalog'), making the purpose evident. However, it doesn't differentiate from sibling tools like 'get_product' (which likely retrieves a specific product) or 'flexible_search' (which might offer more advanced querying), leaving room for ambiguity in tool selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing a query string, or compare it to siblings like 'get_product' for single-product retrieval or 'flexible_search' for complex queries, 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.
trigger_catalog_syncC
Trigger a catalog synchronization between versions
| Name | Required | Description | Default |
|---|---|---|---|
| catalogId | Yes | Catalog ID to sync | |
| sourceVersion | Yes | Source catalog version (e.g., "Staged") | |
| targetVersion | Yes | Target catalog version (e.g., "Online") |
TDQS
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 triggers synchronization but doesn't disclose behavioral traits like whether this is a read-only or destructive operation, what permissions are required, whether it's asynchronous, what happens on failure, or any rate limits. For a tool that likely modifies system state, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized and front-loaded with the core action. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a tool that likely performs system modifications (synchronization between versions), the description is incomplete. It doesn't explain what synchronization means operationally, what gets updated, potential side effects, or what the user should expect after invocation. This leaves significant gaps for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters with clear descriptions. The description doesn't add any meaning beyond what the schema provides about these parameters. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Trigger') and resource ('catalog synchronization between versions'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'trigger_cronjob' or explain what catalog synchronization entails in this specific system context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites, typical use cases, or when NOT to use it. With sibling tools like 'import_impex' and 'export_impex' that might relate to data management, the lack of differentiation is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trigger_cronjobC
Trigger a cron job to run
| Name | Required | Description | Default |
|---|---|---|---|
| cronJobCode | Yes | Code of the cron job to trigger |
TDQS
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 the action ('trigger') but lacks critical behavioral details: whether this requires admin permissions, if it's synchronous or asynchronous, potential side effects (e.g., system load), error handling, or what happens if the cron job is already running. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded and appropriately sized for the tool's apparent simplicity, 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mutation tool that triggers jobs), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, execution mode, or response format, leaving significant gaps for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'cronJobCode' clearly documented in the schema. The description adds no additional meaning beyond the schema—it doesn't explain what a cron job code is, provide examples, or clarify format. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Trigger a cron job to run' states a clear verb ('trigger') and resource ('cron job'), but it's vague about what 'trigger' entails—does it execute immediately, schedule, or test? It doesn't distinguish from siblings like 'get_cronjobs' (which likely lists cron jobs) or 'trigger_catalog_sync' (a specific type of cron job).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing cron job code), exclusions, or how it differs from sibling tools like 'execute_groovy' (which might run scripts) or 'trigger_catalog_sync' (a specialized cron job).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Most tools have distinct purposes targeting different Hybris resources or operations, though some potential overlap exists between flexible_search and search_products (both search-related) and between health_check and get_system_info (both health/system status). The descriptions help clarify boundaries, but an agent might occasionally need to choose between similar tools.
All tool names follow a consistent verb_noun pattern with snake_case throughout (e.g., clear_cache, execute_groovy, get_categories). The naming is predictable and readable, with no mixing of conventions or styles.
With 16 tools, the count is slightly on the higher side but reasonable for a Hybris server covering cache, scripting, data import/export, search, catalog, orders, cron jobs, and system health. It feels comprehensive without being overwhelmingly bloated, though it borders on the heavy end of well-scoped.
The tool set covers key Hybris operations including data management (import/export, search), catalog and product access, order handling, cron job control, and system monitoring. Minor gaps exist, such as no explicit update or delete tools for resources like products or orders, but agents can likely work around this using other tools like import_impex or groovy scripts.
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Manage your Savanto store from your AI: catalog, content, prompts, and analytics, by chat.
AI-powered commerce API for luxury skincare shopping. Enables AI agents to search products, browse collections, manage shopping carts, and generate checkout URLs for the Regenique Elegance Shopify store.
Manage your NanoCart store from any AI agent: products, orders, coupons, subscribers, reports.
Agentic commerce gateway: discovery, search, checkout across Shopify/Woo/Odoo/PrestaShop.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/bro-unic/hybris-mcp-main'
If you have feedback or need assistance with the MCP directory API, please join our Discord server