SFCC Development MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
The tools have some overlap that could cause confusion, particularly between get_* and search_* tools (e.g., get_sfcc_class_info vs. search_sfcc_classes) and among documentation retrieval tools (e.g., get_sfra_document vs. get_sfra_documents_by_category). However, descriptions help clarify distinctions, such as get_* for specific retrieval and search_* for broader exploration, preventing complete ambiguity.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, with clear and predictable structures like generate_cartridge_structure, get_available_best_practice_guides, and search_sfcc_classes. There are no deviations in naming conventions, making it easy for agents to parse and understand the tool purposes.
Tool Count4/5
With 15 tools, the count is slightly high but reasonable for a development server covering documentation, best practices, and code generation in the SFCC domain. It includes a mix of generation, listing, retrieval, and search tools, which aligns well with the server's purpose, though it might feel a bit heavy compared to more streamlined sets.
Completeness4/5
The tool surface is largely complete for its domain, covering documentation retrieval, best practices, and code generation for SFCC development. Minor gaps exist, such as the lack of tools for directly modifying or deploying cartridges, but agents can work around these by using the available tools for guidance and structure generation.
Average 4/5 across 15 of 15 tools scored. Lowest: 3.3/5.
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
- Last stable release on April 8, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

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 the tool 'supports all 26+ SFRA documents' and lists categories, but doesn't describe key behaviors like whether it's read-only, what the output format is (e.g., JSON, markdown), error handling, or performance considerations. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise but could be more front-loaded. The first sentence clearly states the purpose, but subsequent sentences repeat similar ideas (e.g., 'Perfect for implementing SFRA-based features') and the list of document types adds bulk without critical information. Some trimming could improve focus without losing value.
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 complexity (retrieving detailed documentation), lack of annotations, and no output schema, the description is incomplete. It covers purpose and usage well but misses behavioral details like output format, error cases, or dependencies (e.g., referencing 'get_available_sfra_documents'). For a documentation retrieval tool, more context on what to expect is needed.
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 'documentName' well-documented in the schema. The description adds minimal value beyond the schema by listing example document names (e.g., 'server', 'cart', 'product-full') and mentioning categories like 'core classes' and 'models', but doesn't provide additional semantics or usage tips for the parameter. Baseline 3 is appropriate given 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 tool's purpose: 'Get complete SFRA class, module, or model documentation with detailed information about properties, methods, and usage examples.' It specifies the verb ('Get') and resource ('SFRA documentation'), though it doesn't explicitly differentiate from siblings like 'get_sfcc_class_documentation' or 'search_sfra_documentation' beyond listing supported document types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'Use this when working with SFRA controllers, middleware, models, or when you need to understand how SFRA components work together. Perfect for implementing SFRA-based features.' It gives practical scenarios but doesn't explicitly state when not to use it or name alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the output as 'complete raw documentation' with 'examples, detailed descriptions, and full context,' which gives some behavioral insight into what the tool returns. However, it lacks details on potential errors, rate limits, authentication needs, or response format, leaving gaps for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, consisting of two sentences that efficiently convey purpose and usage guidelines. Every sentence adds value without redundancy, making it easy to 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 no annotations and no output schema, the description provides adequate context for a simple read operation with one parameter. It explains the tool's purpose and when to use it, but lacks details on output format, error handling, or behavioral traits, which could be important for completeness in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'className' documented as 'The SFCC class name.' The description doesn't add any parameter-specific information beyond what the schema provides, such as format examples or constraints. With high schema coverage, 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 tool's purpose: 'Get the complete raw documentation for an SFCC class.' It specifies the verb ('Get') and resource ('documentation for an SFCC class'), but doesn't explicitly differentiate it from sibling tools like 'get_sfcc_class_info' or 'search_sfcc_classes' beyond mentioning 'complete raw documentation' versus 'basic class info.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: 'when you need comprehensive details about a class including examples, detailed descriptions, and full context' and 'when the basic class info isn't sufficient.' It implies an alternative (e.g., 'basic class info' likely refers to sibling tools), but doesn't explicitly name specific alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions the tool 'gets' documents (implying a read operation), it does not disclose any behavioral traits such as rate limits, authentication needs, pagination, or what the return format looks like. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.
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 appropriately sized and front-loaded, with two sentences that efficiently convey purpose and usage without waste. Every sentence earns its place by providing essential information about the tool's function and context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and a simple single parameter with full schema coverage, the description is adequate but incomplete. It covers purpose and usage well but lacks details on behavioral aspects like return values or operational constraints, which are important for a tool with no structured data to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'category' fully documented in the input schema including its enum values and descriptions. The description adds minimal value beyond the schema by mentioning examples of functional areas, but does not provide additional syntax, format details, or constraints. Baseline score of 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('Get') and resource ('SFRA documents'), and distinguishes it from siblings by specifying filtering by category. It explicitly mentions functional areas like core SFRA classes, product models, etc., making the purpose highly specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('to explore documents in specific functional areas' and 'for discovering related documentation and understanding functional groupings'), but does not explicitly mention when not to use it or name alternative tools. It implies usage for category-based exploration without stating exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what the tool returns (a list of documentation) and its purpose (discovery, understanding architecture), but does not disclose behavioral traits like whether it's read-only, if it requires authentication, rate limits, pagination, or error handling. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core action and purpose. The second sentence elaborates with specific examples, and the third emphasizes importance. While efficient, the final sentence ('Essential for understanding...') could be considered slightly redundant with the first, but overall it's well-structured with minimal waste.
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 complexity (simple list retrieval with 0 parameters) and lack of annotations/output schema, the description is adequate but incomplete. It explains what the tool does and why to use it, but without annotations or output schema, it should ideally disclose more about the return format (e.g., structure of the list, data types) or behavioral constraints to fully compensate for missing structured data.
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 information is needed. The description appropriately adds no parameter details, focusing instead on the tool's purpose and output. This meets the baseline of 4 for zero-parameter tools, as it avoids unnecessary repetition of schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get a list') and resource ('all available SFRA documentation'), distinguishing it from siblings like 'get_sfra_document' (singular) or 'get_sfra_documents_by_category' (filtered). It explicitly lists examples of what's included (classes, modules, models), making the purpose highly specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('to discover what SFRA classes, modules, and models are documented' and 'Essential for understanding SFRA architecture'), but does not explicitly state when not to use it or name alternatives among the many sibling tools. The implied usage is strong but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the tool as a read operation ('Get a complete list'), which is helpful, but lacks details on behavioral traits such as rate limits, pagination, or response format. The description adds some context about being a 'starting point' but doesn't fully disclose operational aspects, making it adequate but with 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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by two sentences explaining usage context. Every sentence adds value without redundancy, making it efficient and well-structured for quick understanding.
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 somewhat complete but could be more robust. It covers purpose and usage but lacks details on output format or behavioral constraints. For a read-only list tool, this is minimally viable but leaves room for improvement in transparency.
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 no parameter documentation is needed. The description does not mention parameters, which is appropriate. Baseline for 0 parameters is 4, as it doesn't need to compensate for any gaps, but it doesn't add extra semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a complete list of all available SFCC classes.' It specifies the verb ('Get') and resource ('SFCC classes'), and distinguishes it from siblings like 'search_sfcc_classes' by emphasizing 'complete list' versus search functionality. However, it doesn't explicitly name the sibling distinction, keeping it at a 4 instead of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'for exploration and discovery when you need to understand the full scope of SFCC APIs' and 'when you're new to SFCC development.' It implies usage as a starting point but does not explicitly state when not to use it or name alternatives like 'search_sfcc_classes,' so it scores a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool's behavioral trait of searching across all guides and hints at efficiency ('without reading entire guides'), but it does not mention other important aspects like response format, pagination, rate limits, or error handling. The description does not contradict any annotations, as there are none.
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 appropriately sized and front-loaded, with the first sentence stating the core purpose and the following sentences adding useful context without redundancy. Every sentence earns its place by clarifying usage and benefits, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (search function with one parameter) and no annotations or output schema, the description is adequate but has gaps. It covers the purpose and usage well but lacks details on behavioral traits like response format or error handling. For a search tool with no structured output information, more completeness would enhance agent understanding.
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 the 'query' parameter well-documented in the schema. The description adds some context by listing example topics ('validation, security, performance optimization, error handling, or any development pattern'), which aligns with the schema's examples. However, it does not provide additional semantic details beyond what the schema already covers, such as query syntax or limitations not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Search across all best practice guides') and resources ('best practice guides'), distinguishing it from siblings like 'get_best_practice_guide' (which retrieves a specific guide) or 'get_available_best_practice_guides' (which lists guides without searching). It explicitly mentions what it searches for ('terms, patterns, or concepts').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use it ('when you need guidance on specific topics like validation, security, performance optimization, error handling, or any development pattern') and why ('Perfect for finding relevant best practices without reading entire guides'). However, it does not explicitly state when not to use it or name alternatives among siblings, such as using 'get_best_practice_guide' for a specific guide instead of searching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It adequately describes the tool's behavior as a read-only information retrieval tool ('Get detailed information'), but lacks details about rate limits, authentication requirements, error conditions, or response format. The mention of 'SFCC Rhino environment' provides some context, but behavioral specifics are minimal.
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 appropriately sized with three sentences that each serve distinct purposes: stating the tool's function, providing usage guidelines, and specifying target use cases. It's front-loaded with the core purpose and avoids redundancy. Minor improvement could be made by slightly tightening the cartridge development examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, 100% schema coverage, but no annotations and no output schema, the description provides adequate context about when and why to use the tool. However, it lacks information about the response format, error handling, or performance characteristics that would be helpful given the tool's complexity and lack of output schema.
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?
With 100% schema description coverage, the baseline is 3. The description doesn't add any parameter-specific information beyond what's already documented in the schema. It mentions the general purpose ('detailed information about an SFCC class') but provides no additional context about parameter usage, interactions, or best practices.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get detailed information') and resources ('SFCC class'), and explicitly distinguishes it from siblings by focusing on class details rather than listing (list_sfcc_classes), searching (search_sfcc_classes), or documentation (get_sfcc_class_documentation). It identifies the exact information returned: properties, methods, and description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('when you need to understand what a specific SFCC class does, what methods/properties are available, or when implementing features that use SFCC APIs') and includes specific use cases ('Essential for cartridge development...'). It implicitly distinguishes from siblings by focusing on detailed class analysis rather than broader searches or listings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that the tool retrieves 'complete' guides with 'all sections and content', which adds useful context about output comprehensiveness. However, it lacks details on potential limitations like response size, error handling, or performance implications, leaving some behavioral aspects unclear.
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 appropriately sized and front-loaded, starting with the core purpose. Both sentences earn their place by clarifying usage and emphasizing importance, though it could be slightly more concise by integrating the recommendation more seamlessly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter, no output schema, no annotations), the description is fairly complete. It explains what the tool does, when to use it, and the importance of consulting guides, but lacks details on output format or error cases, which could enhance completeness for a tool without annotations.
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 single parameter 'guideName' with its enum values. The description does not add any parameter-specific details beyond what the schema provides, such as examples of when to choose specific guides, so it meets 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get a complete best practice and how-to guide') and resources ('all sections and content'), and explicitly distinguishes it from siblings by specifying when to use it for SFCC features like cartridges, ISML templates, etc., rather than just listing or searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use this tool ('when implementing specific SFCC features') and includes a strong recommendation ('Always consult the relevant guide before writing code'), which helps differentiate it from sibling tools that might list or search guides without the same emphasis on pre-implementation consultation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the search functionality and use cases but lacks details on behavioral traits like pagination, rate limits, authentication requirements, or error handling. The description doesn't contradict any annotations (since none exist), but it's incomplete for a search tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by specific usage guidelines. Every sentence adds value: the first defines the tool, the second explains when to use it, and the third reinforces its role as a starting point. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (search functionality with one parameter), no annotations, and no output schema, the description is adequate but has gaps. It covers purpose and usage well but lacks behavioral details (e.g., result format, limitations) and output information. It's complete enough for basic use but not for full operational understanding.
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 single 'query' parameter with clear constraints. The description adds some context by mentioning examples like 'catalog', 'order', 'customer' and relating it to functionality exploration, but doesn't provide additional syntax or format details beyond what the schema specifies. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Search for SFCC classes') and resources ('by name or functionality'), distinguishing it from siblings like 'list_sfcc_classes' (which likely lists all classes without filtering) and 'get_sfcc_class_documentation' (which retrieves detailed docs for a known class). It explicitly mentions searching by partial names or functionality areas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'when you know part of a class name or need to find classes related to specific functionality' and 'Perfect starting point when you're unsure of the exact class name or exploring available APIs for a feature area.' It distinguishes this from tools for listing all classes or getting detailed documentation for known classes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only operation by using 'Get' and describes the output format ('categories with counts and descriptions'), but lacks details on behavioral traits like rate limits, authentication needs, or whether the data is cached. The description adds some context about exploring SFRA capabilities but does not fully compensate for the absence of annotations.
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 appropriately sized and front-loaded, with the first sentence stating the core purpose and the following sentences providing useful context without redundancy. Every sentence earns its place by clarifying usage and benefits, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple read operation with no parameters) and the absence of annotations and output schema, the description is reasonably complete. It explains what the tool returns ('categories with counts and descriptions') and its utility for exploration. However, it could be more complete by specifying the output format or any limitations, though the lack of an output schema reduces the burden.
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 the input schema has 100% description coverage (though empty). The description does not need to add parameter semantics, so it appropriately focuses on the tool's purpose and usage. A baseline of 4 is applied as it effectively handles the lack of parameters without unnecessary detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get all available SFRA document categories') and resources ('categories with counts and descriptions'). It distinguishes from siblings like 'get_sfra_documents_by_category' by focusing on metadata about categories rather than documents within them, and from 'get_available_sfra_documents' by targeting categories specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('to understand the organization of SFRA documentation and discover what types of functionality are available'), which helps differentiate it from siblings that retrieve documents or search content. However, it does not explicitly state when not to use it or name specific alternatives, such as using 'get_sfra_documents_by_category' for documents within a category.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the search scope ('across all SFCC classes') and purpose ('discovering all available methods'), but lacks details on output format, pagination, error handling, or performance characteristics. The description adds some context but doesn't fully compensate for the absence of annotations.
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 efficiently structured in three sentences: the core purpose, usage guidelines, and additional context. Each sentence adds distinct value without redundancy. It's front-loaded with the main functionality and appropriately sized for a single-parameter search tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (search across classes), no annotations, and no output schema, the description is adequate but has gaps. It explains what the tool does and when to use it, but doesn't describe the return format, result limitations, or error conditions. For a search tool with no structured output documentation, this leaves some important context unspecified.
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?
Schema description coverage is 100%, so the schema already documents the single parameter 'methodName' with its constraints. The description adds value by explaining the search context ('across all SFCC classes') and use cases, but doesn't provide additional parameter semantics beyond what's in the schema. With 0 parameters beyond the documented one, a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for methods across all SFCC classes by method name.' It specifies the verb ('search'), resource ('methods across all SFCC classes'), and scope ('by method name'), distinguishing it from siblings like 'search_sfcc_classes' or 'get_sfcc_class_documentation' that focus on classes or documentation rather than method discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'Use this when you know the method name but not which class it belongs to, or when looking for similar methods across different classes.' It also clarifies the alternative scenario ('Helpful for discovering all available methods that perform similar operations'), making it clear this is for cross-class method discovery rather than class-level searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it searches 'across all SFRA documentation' (scope), mentions 'relevance scoring and categorization' (ranking/grouping behavior), and implies it returns multiple results rather than single documents. However, it doesn't specify output format, pagination, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences: the first establishes purpose and usage guidelines, the second adds behavioral context. Every sentence adds value, though the list of examples in the first sentence could be slightly more concise while still maintaining clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter search tool with no annotations and no output schema, the description does well by covering purpose, usage guidelines, and key behavioral traits. However, it doesn't describe the output format or structure, which would be helpful given the absence of an output schema.
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% for the single 'query' parameter, so the schema already fully documents it. The description adds no additional parameter information beyond what's in the schema, maintaining the baseline score of 3 for adequate but not enhanced parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Search across all SFRA documentation') and resource ('SFRA documentation'), distinguishing it from siblings like 'search_best_practices' or 'get_sfra_document' by emphasizing comprehensive search across all documentation rather than retrieving specific documents or searching other content types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Use this when you need to find specific SFRA features, understand how to implement controller patterns...') and provides multiple concrete examples of use cases, making it clear this is for broad documentation searches rather than targeted retrieval or other search types offered by siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It effectively discloses key behavioral traits: it creates files directly in the target directory, ensures proper organization, and includes all required components. However, it doesn't mention potential side effects like overwriting existing files or permission 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 appropriately sized with three sentences that each earn their place: stating the purpose, providing usage guidance, and explaining the behavioral outcome. It's front-loaded with the core purpose and avoids unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations and no output schema, the description does well by explaining what the tool does and when to use it. However, it could provide more detail about what 'complete cartridge directory structure' includes or potential error conditions, given the complexity of file generation.
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?
With 100% schema description coverage, the schema already documents all three parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema, so it meets the baseline of 3 without providing extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('generate', 'create') and resources ('cartridge directory structure', 'files and configurations'). It distinguishes itself from sibling tools by focusing on cartridge creation rather than documentation retrieval or searching, which all sibling tools do.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Use this when creating new cartridges') and provides context about ensuring proper organization. It also implicitly distinguishes from siblings by focusing on creation rather than information retrieval, though it doesn't name specific alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the tool's behavior as retrieving a list for discovery purposes, which is clear. However, it lacks details on behavioral traits like response format, pagination, rate limits, or error handling. For a read-only tool with no annotations, this is adequate but leaves 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 front-loaded with the core purpose in the first sentence, followed by usage guidance. Every sentence adds value without redundancy, and it is appropriately sized for the tool's complexity. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is largely complete for its purpose. It explains what the tool does and when to use it. However, without an output schema, it could benefit from mentioning the return format (e.g., list of guide titles or metadata), but this is a minor gap.
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 no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the tool's purpose and usage. A baseline of 4 is applied for zero parameters, as it avoids unnecessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get a list') and resource ('all available SFCC best practice and how-to guides'), distinguishing it from siblings like get_best_practice_guide (which retrieves a specific guide) and search_best_practices (which searches within guides). It explicitly mentions the scope of resources (cartridge creation, hooks, controllers, custom endpoints).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('Use this first to discover what guidance is available before implementing any SFCC features') and its purpose ('Essential for understanding what best practice resources exist'). It distinguishes it from siblings by implying this is for discovery rather than retrieval or search of specific content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates that this is a read-only reference tool ('Get comprehensive hook reference tables'), though it doesn't mention specific behavioral aspects like response format, pagination, or error conditions. The description is accurate but could provide more operational details.
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 efficiently structured with three sentences that each serve distinct purposes: stating the tool's function, providing usage guidance, and emphasizing its importance. There's no wasted verbiage, and the most critical information appears first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's single parameter with full schema coverage and no output schema, the description provides good contextual completeness by explaining when and why to use this tool. However, it could be more complete by mentioning what the output looks like (tables of hook endpoints) or any limitations.
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 the single parameter. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get comprehensive hook reference tables') and resources ('OCAPI or SCAPI hook endpoints and extension points'). It distinguishes this tool from sibling tools by focusing specifically on hook references rather than general documentation or search capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'Use this when implementing hooks to see all available extension points, understand hook signatures, and ensure you're using the correct hook for your use case.' It also positions it as 'Essential reference when extending SFCC APIs,' creating clear context for its application.
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:

[![sfcc-dev-mcp MCP server](https://glama.ai/mcp/servers/taurgis/sfcc-dev-mcp/badges/card.svg)](https://glama.ai/mcp/servers/taurgis/sfcc-dev-mcp)

Score Badge

Copy to your README.md:

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

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