Hybris 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 Hybris resources or operations, with clear boundaries like flexible_search vs search_products. However, health_check and get_system_info have some overlap in monitoring functionality, which could cause minor confusion.
Naming Consistency4/5
Tools follow a consistent verb_noun naming pattern throughout, such as get_product, search_products, and trigger_cronjob. The only minor deviation is clear_cache, which uses an adjective instead of a verb, but overall the naming is highly predictable and readable.
Tool Count4/5
With 16 tools, the count is slightly high but reasonable for a Hybris server covering cache, scripting, data operations, catalog, orders, and system monitoring. It feels comprehensive without being overwhelming, though it borders on the heavy side.
Completeness4/5
The tool set covers key Hybris domains well, including data import/export, product/category management, order handling, and system operations. Minor gaps exist, such as no update or delete operations for products or orders, but agents can work around these using scripts or other tools.
Average 2.9/5 across 16 of 16 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues 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 status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

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 without behavioral details. It doesn't disclose if this is a destructive operation, requires specific permissions, has rate limits, or what happens on success/failure, which is inadequate for a data import tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it appropriately concise. However, it could be more front-loaded with critical details, but its brevity is a strength given the limited information provided.
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 data import tool with no annotations and no output schema, the description is incomplete. It lacks context on what data is imported, behavioral traits, or return values, failing to compensate for the missing structured information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents the 'impexContent' parameter. The description adds no additional meaning beyond implying the parameter is ImpEx content, meeting the baseline for high schema coverage without extra value.
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 ('import data') and format ('ImpEx format'), which provides a basic purpose. However, it lacks specificity about what data is imported (e.g., products, categories) and doesn't distinguish from sibling tools like 'export_impex', making it 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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing ImpEx content, or compare to siblings like 'flexible_search' or 'trigger_catalog_sync' for data operations, 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 the full burden of behavioral disclosure. It mentions 'Trigger a catalog synchronization', implying a write or update operation, but does not specify if this is destructive, requires authentication, has side effects, or involves rate limits. The lack of details on what happens during synchronization (e.g., overwriting data, merging changes) leaves significant gaps in understanding the tool's behavior, making it inadequate 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Trigger a catalog synchronization between versions'. It is front-loaded with the core action and resource, with no wasted words. However, it could be slightly more informative by including key details like the outcome or constraints, but as is, it achieves conciseness without being overly sparse.
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 synchronization tool with no annotations and no output schema, the description is incomplete. It does not explain what synchronization entails, potential impacts, return values, or error conditions. For a tool that likely modifies data between versions, this lack of context makes it insufficient for safe and effective use, especially compared to sibling tools with clearer purposes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for all three parameters (catalogId, sourceVersion, targetVersion). The description does not add any meaning beyond the schema, such as explaining parameter interactions or providing examples beyond the schema's descriptions (e.g., 'Staged' and 'Online' for versions). Since the schema handles the heavy lifting, the baseline score of 3 is appropriate, as the description offers no additional parameter insights.
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 'Trigger a catalog synchronization between versions', which includes a verb ('Trigger') and resource ('catalog synchronization'), making it clear what action is performed. However, it lacks specificity about what synchronization entails (e.g., data copying, metadata updates) and does not distinguish it from sibling tools like 'import_impex' or 'export_impex', which might involve similar data operations. This results in a vague but understandable purpose.
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, such as needing specific catalog states, or compare it to sibling tools like 'import_impex' for data imports or 'trigger_cronjob' for scheduled tasks. Without any context on usage scenarios or exclusions, the agent must infer when this tool is appropriate, leading to minimal guidance.
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 details, implying a read-only operation, but doesn't specify if it requires authentication, has rate limits, returns structured data, or handles errors. For a tool with no annotations, 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 directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, with no wasted information, 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 simplicity (1 parameter, no output schema, no annotations), the description is incomplete. It doesn't clarify what 'details' include, how it differs from similar tools, or behavioral aspects like error handling. For a tool in a context with many sibling tools, more guidance is needed to ensure correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond what the input schema provides. The schema has 100% description coverage, with 'categoryCode' documented as 'The category code', so the baseline is 3. The tool description doesn't explain what a category code is, its format, or examples, offering no additional value over the 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 retrieving details for a specific category, which is clear but vague. It uses the verb 'Get' and resource 'category', but doesn't specify what details are included or how it differs from sibling tools like 'get_categories' or 'get_product'. The purpose is understandable 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, exclusions, or compare it to sibling tools like 'get_categories' (which might list multiple categories) or 'search_products' (which might involve categories). Usage is implied only by the tool name, with no explicit context provided.
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 ('trigger') but lacks critical details: whether this is a read-only or mutating operation (likely mutating, but unspecified), permission requirements, side effects (e.g., job execution logs, system load), or error handling. 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 extremely concise at four words ('Trigger a cron job to run'), with no wasted language. It front-loads the core action ('trigger') and target ('cron job'), 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 tool's complexity (likely a mutating operation with no annotations or output schema), the description is incomplete. It doesn't explain what happens after triggering (e.g., success/failure response, job status changes) or address behavioral aspects like idempotency or rate limits. For a tool that could impact system operations, this leaves too much undefined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'cronJobCode' documented as 'Code of the cron job to trigger'. The description adds no additional parameter semantics beyond this, such as format examples (e.g., alphanumeric string) or where to find valid codes. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema handles the heavy lifting.
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 'Trigger a cron job to run' clearly states the action (trigger) and target (cron job), making the basic purpose understandable. However, it lacks specificity about what 'trigger' entails (e.g., immediate execution, manual override) and doesn't distinguish this tool from potential siblings like 'get_cronjobs' or 'trigger_catalog_sync', 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., cron job must exist), exclusions (e.g., cannot trigger disabled jobs), or comparisons to sibling tools like 'get_cronjobs' (for listing) or 'trigger_catalog_sync' (for a specific type of job), 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 of behavioral disclosure. While 'Clear' implies a destructive mutation, it doesn't specify whether this requires admin permissions, if it's reversible, what side effects occur (e.g., performance impact), or if it affects all users. For a mutation tool with zero annotation coverage, this is a significant gap in safety and operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words, front-loading the core action and resource. It's appropriately sized for a simple tool with one optional parameter, 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.
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 destructive cache-clearing operation) and the lack of annotations and output schema, the description is incomplete. It doesn't cover behavioral traits like permissions needed, system impact, or what to expect after execution, which are critical 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'cacheType' well-documented in the schema as optional for clearing specific caches or all if unspecified. The description adds no additional parameter semantics beyond what the schema provides, but since the schema is comprehensive, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Clear') and the target resource ('the Hybris cache'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'trigger_catalog_sync' or 'execute_groovy' that might also affect system state, leaving room for ambiguity about when to choose this specific cache-clearing operation.
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 whether it's for debugging, performance tuning, or after configuration changes. It doesn't mention prerequisites, risks, or related tools like 'get_system_info' for checking cache status, leaving the agent with minimal context for decision-making.
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 executing a script but fails to detail critical traits: whether this is a read/write operation (implied by the 'commit' parameter but not stated), potential risks (e.g., database modifications), authentication needs, or output format (e.g., script results or errors). This is inadequate for a tool that could have significant side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part ('Execute a Groovy script in the Hybris scripting console') directly contributes 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 complexity of executing scripts (potentially involving database changes) and the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., script output, success/failure), error handling, or safety considerations, leaving gaps that could hinder effective agent 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?
Schema description coverage is 100%, with both parameters ('script' and 'commit') well-documented in the schema. The description adds no additional meaning beyond implying script execution in a Hybris context, which is already covered by the tool's name and description. Thus, it meets the baseline for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Execute') and resource ('Groovy script in the Hybris scripting console'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'flexible_search' or 'trigger_cronjob' which might also involve script execution or console operations, 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.
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. It doesn't mention prerequisites (e.g., needing access to the Hybris console), exclusions (e.g., not for simple queries), or compare it to siblings like 'flexible_search' for data retrieval or 'import_impex' for data manipulation, leaving the agent without context for decision-making.
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 exports data but doesn't describe what happens during export (e.g., file generation, download process, side effects), permissions required, rate limits, or error handling. This leaves significant gaps for a tool that likely involves data processing and output generation.
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 key information ('Export data to ImpEx format') without unnecessary words. Every part of the sentence contributes to understanding the tool's purpose and method, making it appropriately sized 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 complexity of an export operation with no annotations and no output schema, the description is incomplete. It doesn't explain what the export produces (e.g., file format, location, structure), potential impacts, or how to handle the output. For a tool that likely generates data output, this lack of detail is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal value beyond the input schema, which has 100% coverage. It mentions 'using a FlexibleSearch query', which aligns with the 'flexQuery' parameter description in the schema. However, it doesn't provide additional context like query format examples, export scope, or output details, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Export data') and target format ('to ImpEx format'), with the method specified ('using a FlexibleSearch query'). It distinguishes from sibling tools like 'import_impex' by focusing on export rather than import, but doesn't explicitly differentiate from other data retrieval tools like 'flexible_search' or 'search_products'.
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, when not to use it, or compare it to siblings like 'flexible_search' (which might return data directly) or 'import_impex' (for the reverse operation). The description implies usage for exporting data with FlexibleSearch, but lacks explicit 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 states the tool executes a query but doesn't mention whether it's read-only or mutating, what permissions are required, potential side effects, rate limits, or error handling. This is inadequate for a database query 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 extremely concise with two sentences that directly state the tool's function and syntax requirement. Every word earns its place, and it's front-loaded with the core purpose, making it efficient 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 complexity of a database query tool with no annotations and no output schema, the description is incomplete. It lacks information on return values, error conditions, behavioral traits, and differentiation from siblings. For a tool that could have significant implications (e.g., performance, data access), this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain FlexibleSearch syntax further or provide examples beyond the schema's example). 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.
Purpose4/5
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'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'search_products' or 'execute_groovy' that might also query the database, missing 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. It mentions 'Use FlexibleSearch syntax' as a usage note but doesn't specify contexts, prerequisites, or exclusions compared to siblings like 'search_products' or 'get_product', leaving the agent without clear selection criteria.
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 it 'gets details' without disclosing behavioral traits like authentication needs, error handling, rate limits, or what 'details' includes. It's minimally informative about the tool's 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 with zero waste. It's appropriately sized and front-loaded, clearly stating the tool's 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?
For a read operation with no annotations and no output schema, the description is incomplete. It doesn't explain what 'details' entails, potential response formats, or error conditions, leaving significant gaps for an agent to understand the tool fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (userId and orderCode). The description adds no additional meaning beyond implying these are used to identify a specific order, meeting the baseline for high schema 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 ('details of a specific order'), making the purpose understandable. However, it doesn't distinguish this tool from sibling 'get_orders' (which likely lists multiple orders), 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 like 'get_orders' or 'flexible_search'. The description implies it's for retrieving details of a single order, but doesn't explicitly state this or mention 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves orders, implying a read-only operation, but lacks details on permissions, rate limits, pagination, error handling, or what 'orders' entails (e.g., status, format). This is inadequate for a tool with potential complexity in data retrieval.
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 efficiently conveys the core purpose without unnecessary words. It is front-loaded and easy to parse, though it could be slightly more informative 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 no annotations and no output schema, the description is incomplete. It fails to address key contextual aspects like return format (e.g., list of orders, error cases), behavioral traits (e.g., authentication needs, data scope), or how it integrates with sibling tools. For a data retrieval tool, this leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'userId' documented as 'User ID or email'. The description adds no additional meaning beyond this, such as examples or constraints. Since the schema fully covers the parameter, the baseline score of 3 is appropriate, as the description doesn't enhance but also doesn't detract from 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 ('Get') and resource ('orders'), and specifies the scope ('for a specific user'). It distinguishes from sibling tools like 'get_order' (singular) by implying it returns multiple orders. However, it doesn't explicitly differentiate from potential filtering alternatives or clarify if it returns all orders or a subset.
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 minimal guidance—it indicates the tool is for retrieving orders for a user, but offers no context on when to use it versus alternatives like 'search_products' or 'get_order'. There are no prerequisites, exclusions, or comparisons to sibling tools mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it retrieves 'detailed information' without specifying what that includes, whether it's read-only, requires authentication, has rate limits, or error behaviors. It lacks critical context for a tool that presumably accesses a product database, leaving the agent guessing about operational traits.
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—every word contributes to understanding the tool's purpose. 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 no annotations and no output schema, the description is insufficient for a tool that likely returns complex product data. It doesn't explain what 'detailed information' entails, potential response formats, or error conditions. For a lookup tool in a system with many siblings, 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.
Parameters3/5
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 'productCode' parameter as 'The product code/SKU'. The description adds no additional meaning beyond implying it's used to identify a specific product, which is redundant with the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
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 'detailed information about a specific product', making the purpose unambiguous. It distinguishes from siblings like 'search_products' by specifying retrieval of a single product by code rather than searching. However, it doesn't explicitly contrast with 'get_categories' or 'get_category', which might be similar lookup operations.
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 'search_products' or 'get_category'. It mentions retrieving by 'code' but doesn't clarify if this is the only identifier method or when to choose this over other lookup tools. No prerequisites or exclusions are 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 full burden for behavioral disclosure. It mentions the search functionality but doesn't describe what happens when no results are found, whether the search is case-sensitive, what fields are searched, or any rate limits. For a search 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 states the core functionality without unnecessary words. It's appropriately sized for a straightforward search tool and gets directly to the point.
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 search tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the search returns (product objects, IDs, etc.), how results are sorted, or any limitations of the search functionality. The agent would need to guess about important behavioral aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. The baseline score of 3 is appropriate when the schema does the heavy lifting for parameter 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 ('Search for products') and resource ('Hybris catalog'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_product' or 'flexible_search', which might offer alternative ways to retrieve product 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?
The description provides no guidance on when to use this tool versus alternatives like 'get_product' (for single product retrieval) or 'flexible_search' (which might offer more complex querying). There's no mention of prerequisites, limitations, or typical use cases beyond the basic search 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool lists cron jobs and their status, implying a read-only operation, but doesn't cover critical aspects like whether it requires specific permissions, how it handles errors, if it includes all cron jobs or only active ones, or what the output format looks like. 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 that directly states the tool's function without any unnecessary words. It is front-loaded with the core action ('List all cron jobs and their status'), making it efficient and easy to parse. Every word earns its place by conveying essential information.
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 for a tool that likely returns complex data (cron jobs and their status). It doesn't explain what 'status' entails (e.g., running, scheduled, failed), the scope of 'all' (e.g., system-wide, user-specific), or the response structure. For a read operation with no structured output, more context is needed to use the tool effectively.
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 beyond the schema, but since there are no parameters, this is acceptable. A baseline of 4 is appropriate as the description doesn't need to compensate for any schema gaps.
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 ('List') and resource ('cron jobs and their status'), making it immediately understandable. However, it doesn't distinguish this tool from potential siblings like 'trigger_cronjob' or 'get_system_info', which might also involve cron job operations, leaving some ambiguity about its unique role.
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. For example, it doesn't specify if this is for monitoring status, debugging, or if other tools like 'trigger_cronjob' or 'get_system_info' should be used for related tasks. This lack of context makes it harder for an agent to choose appropriately among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal information. It states what the tool does but doesn't describe how it behaves: no mention of response format (e.g., tree structure, JSON hierarchy), performance characteristics, error conditions, or whether it's idempotent. For a read operation with zero annotation coverage, 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, efficient sentence that communicates the core purpose without unnecessary words. It's front-loaded with the essential information ('Get the category tree') and specifies the source ('from the product catalog'). Every word earns its place, making it maximally concise while remaining clear.
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's simplicity (zero parameters, no output schema, no annotations), the description is minimally adequate. It tells the agent what the tool does but doesn't provide enough context about the return value format or how the category tree is structured. For a tool that presumably returns hierarchical data, more information about the output would be helpful, though the absence of an output schema means the description should ideally compensate more than it does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema has 100% description coverage (though empty). The description appropriately doesn't discuss parameters since none exist. It correctly focuses on the tool's purpose rather than attempting to document non-existent inputs, earning a high baseline score for parameter semantics in this specific case.
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') and resource ('category tree from the product catalog'), making the tool's purpose immediately understandable. It distinguishes itself from siblings like 'get_category' (singular) by implying it retrieves the entire hierarchical structure rather than a single category. However, it doesn't explicitly contrast with other catalog-related tools like 'search_products' or 'trigger_catalog_sync'.
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 this tool is appropriate compared to 'get_category' (for individual categories), 'search_products' (for product-focused queries), or 'trigger_catalog_sync' (for updating catalog data). There's also no indication of prerequisites, dependencies, 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 provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves information and health status, implying a read-only operation, but doesn't specify details like response format, error conditions, or whether it requires authentication. This is a significant gap 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 that directly states the tool's function without any wasted words. It's front-loaded with the core purpose, making it easy to parse and understand quickly.
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's simplicity (0 parameters, no output schema, no annotations), the description is adequate as a basic overview. However, it lacks details on what specific information or health metrics are returned, which would be helpful for an agent to understand the output fully, especially without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The baseline for this scenario is 4, as the description appropriately focuses on the tool's purpose without redundant parameter information.
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') and the resource ('Hybris system information and health status'), making the tool's purpose immediately understandable. It doesn't explicitly differentiate from siblings like 'health_check', but it's specific enough to convey its function without being tautological.
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 'health_check' or other system-related tools. It lacks any context about prerequisites, timing, or exclusions, 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 full burden. It states what the tool does (check health/reachability) but doesn't disclose behavioral traits like what 'healthy' means, what metrics are checked, whether it performs active probing or passive checks, timeout behavior, or authentication requirements.
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 any wasted words. Every word earns its place by specifying the action, target, and what's being assessed.
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's simplicity (0 parameters, no annotations, no output schema), the description is adequate but has gaps. It explains what the tool does but doesn't provide enough context about what constitutes 'healthy' or what the check involves, which would help an agent understand the tool's behavior more completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose. Baseline is 4 for zero-parameter tools.
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 ('check') and resource ('Hybris instance'), specifying it assesses health and reachability. It distinguishes itself from siblings like get_system_info by focusing specifically on health status rather than general system information.
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 context (when you need to verify instance health/connectivity) but doesn't explicitly state when to use this versus alternatives like get_system_info or when not to use it. No explicit alternatives or exclusions are mentioned.
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:

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

Score Badge

Copy to your README.md:

[![hybris-mcp MCP server](https://glama.ai/mcp/servers/Emenowicz/hybris-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Emenowicz/hybris-mcp)

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/Emenowicz/hybris-mcp'

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