The SFCC Development MCP Server provides comprehensive tools for Salesforce B2C Commerce Cloud (SFCC) development, offering AI assistants and developers structured access to documentation, best practices, system object definitions, and log analysis.
Core Capabilities:
• SFCC Documentation Access: Retrieve detailed class information (properties, methods, descriptions), search for classes/methods by name, access raw documentation, and view complete lists of available SFCC classes
• Best Practices Consultation: Access guides for cartridge creation, OCAPI/SCAPI hooks, SFRA controllers, custom endpoints, performance, and security; search across all guides for specific topics; view detailed reference tables for hook endpoints and extension points
• System Object Definitions (requires OAuth credentials): Explore system objects (Product, Customer, Order), retrieve detailed attribute definitions including custom attributes and constraints, search site preferences across sites and preference groups, and discover attribute categories
• Log Analysis (requires credentials): Retrieve latest error/warning/info messages, get log activity summaries, search for specific patterns, and list available log files with metadata
• AI Assistant Enhancement: Provides structured data to improve AI accuracy and reduce hallucination for SFCC development tasks
Configuration Options: Supports documentation-only mode (no credentials required) and full mode (with SFCC credentials for advanced log analysis and system object features).
Provides comprehensive tools for Salesforce B2C Commerce Cloud (SFCC) development including log analysis and monitoring, SFCC API documentation querying, system object definitions access, and best practices guides for OCAPI hooks, SCAPI hooks, SFRA controllers, and custom endpoints
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SFCC Development MCP Server show me the SFRA controller best practices"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An AI-powered Model Context Protocol (MCP) server that provides comprehensive access to Salesforce B2C Commerce Cloud development tools, documentation, and runtime diagnostics.
🔍 Complete SFCC Documentation Access - Search and explore all SFCC API classes and methods
🏗️ SFRA Documentation - Enhanced access to Storefront Reference Architecture documentation
🧱 ISML Template Reference - Complete ISML element documentation with examples and usage guidance
📊 Log Analysis Tools - Real-time error monitoring, debugging, and job log analysis for SFCC instances
⚙️ System Object Definitions - Explore custom attributes and site preferences
🧪 Script Debugger - Execute and inspect script-debugger endpoints in credentialed mode, including custom trigger URLs/paths for non-default storefront routes
🚀 Cartridge Generation - Automated cartridge structure creation with workspace-bound path safety (writes stay inside workspace roots, or current working directory fallback when roots are unavailable; home-directory fallback is blocked)
🧩 Agent Skill Bootstrap - Install or merge AGENTS.md and bundled skills into the current project or a temp directory for AI assistants
✅ Tool Argument Validation - Runtime schema validation enforces required fields, type checks, enum constraints, integer/numeric bounds, and strict unknown-key checks for object schemas (top-level and nested) before handler execution
⏱️ MCP Progress + Cancellation - Tool calls honor request cancellation signals and emit out-of-band notifications/progress updates when clients provide a progressToken
Related MCP server: MCP Salesforce Server
{
"mcpServers": {
"sfcc-dev": {
"command": "npx",
"args": ["sfcc-dev-mcp"]
}
}
}{
"mcpServers": {
"sfcc-dev": {
"command": "npx",
"args": ["sfcc-dev-mcp", "--dw-json", "/path/to/your/dw.json"]
}
}
}Create a dw.json file with your SFCC credentials. You can use either auth mode (or both):
Basic auth: username + password
OAuth: client-id + client-secret
Optional storefront auth (for script debugger trigger on Basic-Auth storefronts): storefrontUsername + storefrontPassword
{
"hostname": "your-instance.sandbox.us01.dx.commercecloud.salesforce.com",
"username": "your-username",
"password": "your-password",
"storefrontUsername": "your-storefront-basic-user",
"storefrontPassword": "your-storefront-basic-password",
"client-id": "your-client-id",
"client-secret": "your-client-secret"
}At least one complete credential pair is required when hostname is set.
If credentials are provided, hostname is also required.
Simply open a VS Code workspace that contains a dw.json file - the server will automatically discover and use it:
{
"mcpServers": {
"sfcc-dev": {
"command": "npx",
"args": ["sfcc-dev-mcp"]
}
}
}The server discovers SFCC credentials in this order (highest priority first):
Priority | Source | Description |
1 |
| Explicit path to dw.json file |
2 | Environment variables |
|
3 | MCP workspace roots | Automatically discovers dw.json in your VS Code workspace folder(s), and refreshes when the client sends |
Note: The server no longer searches the current working directory by default, as MCP servers often start with
cwdset to the user's home directory. The MCP workspace roots mechanism provides reliable project context.
Mode | Tools Available | SFCC Credentials Required |
Documentation-Only | 18 tools | ❌ No |
Full Mode | 40 tools | ✅ Yes |
Perfect for learning and development, no SFCC instance required:
Complete SFCC API documentation (5 tools)
SFRA documentation (5 tools)
ISML template documentation (5 tools)
Cartridge generation (1 tool, writes constrained to workspace roots/cwd)
Agent instruction bootstrap (2 tools) to copy/merge AGENTS.md and skills, or disable future prompts
Complete development experience with live SFCC instance access:
All documentation-only features (18 tools)
Real-time log analysis and job logs (13 tools)
System object definitions (6 tools)
Code version management (2 tools)
Script debugger operations (1 tool)
This server is built around a capability-gated, modular handler architecture that cleanly separates tool routing from domain logic:
Tool Schemas (src/core/tool-schemas/): Modular, category-based tool definitions (documentation, SFRA, ISML, logs, job logs, system objects, cartridge, code versions, agent instructions, script debugger). Re-exported via tool-definitions.ts.
Server Orchestration Modules (src/core/server-tool-catalog.ts, src/core/server-tool-call-lifecycle.ts, src/core/server-workspace-discovery.ts): Keeps server.ts focused by extracting capability-aware tool catalog logic, tools/call lifecycle (progress/cancellation/preflight), and workspace roots reconfiguration flow.
Tool Argument Validator (src/core/tool-argument-validator.ts): Enforces runtime argument shape at the MCP boundary for all tools (required fields, primitive/object/array types, enum checks, integer/numeric ranges, string patterns/length, and strict unknown-key checks for object schemas at top-level and nested levels) before tool dispatch.
OCAPI Query Coverage (src/core/tool-schemas/shared-schemas.ts): Shared search schemas include text_query, term_query, bool_query, filtered_query, and match_all_query so MCP boundary validation aligns with supported OCAPI query patterns.
Handlers (src/core/handlers/): Each category has a handler extending a common base for timing, structured logging, and error normalization, with config-driven wiring via ConfiguredClientHandler to reduce repetitive boilerplate (e.g. log-handler, docs-handler, isml-handler, system-object-handler).
Clients (src/clients/): Encapsulate domain operations (OCAPI, SFRA docs, ISML docs, modular log analysis, script debugger, cartridge generation, agent-instruction sync). Handlers delegate to these so orchestration and computation remain separate.
Services (src/services/): Dependency-injected abstractions for filesystem and path operations — improves testability and isolates side effects.
Modular Log System (src/clients/logs/): Reader (range/tail optimization), discovery, processor (line → structured entry), analyzer (patterns & health), formatter (human output) for maintainable evolution.
Configuration Factory (src/config/configuration-factory.ts): Determines capabilities (canAccessLogs, canAccessOCAPI) based on provided credentials and filters exposed tools accordingly (principle of least privilege).
Shared Credential Validation (src/config/credential-validation.ts): Centralizes auth-pair completeness and hostname-format validation for both dw.json loading and runtime configuration creation.
Call-time Capability Guarding (src/core/server.ts): Rejects execution of tools that are unavailable in the current mode, so hidden tools are not callable via direct tools/call requests.
Call Lifecycle Signals (src/core/server.ts): tools/call handling supports cancellation via request abort signals and emits best-effort progress notifications when the caller provides _meta.progressToken.
Tool Error Sanitization (src/core/tool-error-response.ts): Sanitizes upstream execution errors before returning MCP tool responses, reducing accidental leakage of backend payload details.
Runtime WebDAV Verification (src/core/server.ts): For OAuth-only configurations (client-id/client-secret without username/password), log/job-log/script-debugger tool exposure is gated by a one-time WebDAV capability probe to avoid false-positive tool availability.
CLI Option Helpers (src/config/cli-options.ts): Centralizes command-line parsing and environment credential detection for predictable startup behavior.
Shared Path Security Policy (src/config/path-security-policy.ts): Reuses allow/block path rules across workspace-root discovery and secure dw.json loading.
Shared Abort Utility (src/utils/abort-utils.ts): Centralized timeout and abort-signal composition used by HTTP and debugger clients for consistent cancellation semantics and timer cleanup.
Extensibility: Adding a new tool usually means adding a schema + minimal handler logic (or a new handler if a new domain).
Security: Tools that require credentials are never exposed when capability flags are false.
Testability: Unit tests target clients & modules; integration/MCP tests validate handler routing and response structure.
Performance: Tail log reads + lightweight caching (cache.ts, log-cache.ts) reduce unnecessary I/O.
Add schema to the appropriate file in src/core/tool-schemas/ (or create new file for new category).
Export new schema from src/core/tool-schemas/index.ts if adding a new file.
Implement domain logic in a client/service (avoid bloating handlers).
Extend an existing handler or create a new one if it's a new category.
(Only for a new category) register the new handler inside registerHandlers() in server.ts.
Discover actual response shape with npx aegis query before writing tests.
Add Jest unit tests + YAML MCP tests (docs vs full mode if credentials required).
Update documentation (AGENTS.md + README counts if changed).
For a deeper internal view, see the Development Guide in the docs site.
Choose your preferred AI assistant:
Interface | Best For | Setup Guide |
Claude Desktop | Multi-turn conversations, debugging | |
GitHub Copilot | VS Code integration, inline suggestions | |
Cursor | Modern AI-powered editor |
Tip: Add
-y(or--yes) to suppress the interactive prompt npx shows before downloading a package. This prevents AI clients (Claude Desktop, Copilot, Cursor) from hanging waiting for confirmation.
# Test the server
npx -y sfcc-dev-mcp
# Use with your configuration
npx -y sfcc-dev-mcp --dw-json /path/to/your/dw.jsonnpm install -g sfcc-dev-mcp
sfcc-dev-mcp --dw-json /path/to/your/dw.json# Enable debug mode for detailed logging
npx -y sfcc-dev-mcp --debug
# Or with configuration file
npx -y sfcc-dev-mcp --dw-json /path/to/your/dw.json --debug--debug accepts true/false, 1/0, or yes/no. Invalid values fail fast with a clear error message.
The server writes logs to your system's temporary directory:
macOS: /var/folders/{user-id}/T/sfcc-mcp-logs/
Linux: /tmp/sfcc-mcp-logs/
Windows: %TEMP%\sfcc-mcp-logs\
Log Files Created:
sfcc-mcp-info.log - General application logs and startup messages
sfcc-mcp-debug.log - Detailed debug information (only when --debug is enabled)
sfcc-mcp-error.log - Error messages and stack traces
sfcc-mcp-warn.log - Warning messages
// The exact path varies by system - to find yours:
node -e "console.log(require('os').tmpdir() + '/sfcc-mcp-logs')"This repository now uses Changesets for npm releases.
When a change should ship in a new sfcc-dev-mcp version, add a changeset from the repository root:
npm run changesetCheck pending release state against main before merging:
npm run release:statusThe release workflow on main creates or updates a release pull request from pending changesets. Merging that release pull request publishes the npm package through npm trusted publishing (GitHub Actions OIDC), waits for npm propagation, reruns MCP tests against the published NPX artifact, and then publishes the same version to the MCP Registry.
npm run version-packages also syncs server.json with the package version so validate:server-json keeps passing in the release PR.
Package publication now uses GitHub Actions OIDC trusted publishing, so no separate npm publish secret is required.
You can run the same validation locally:
# Ensure docs-site tool catalog stays in sync with runtime tool definitions
npm run validate:tools-sync
# Ensure docs-site skills catalog stays in sync with bundled skills
npm run validate:skills-sync
# Ensure MCP registry metadata stays in sync with package.json
npm run validate:server-json
# In a separate terminal, start the mock server first for full-mode MCP tests
npm run test:mock-server:start
# Uses latest published version by default
npm run test:mcp:published-npx
# Or pin a specific published version
bash ./scripts/test-published-npx.sh 1.0.21In GitHub Actions, the publish workflow manages the mock server lifecycle automatically.
📚 Complete Documentation - Comprehensive guides and references
Documentation source lives in docs-site-v2/ (VitePress). The legacy React site remains in docs-site/.
Quick Links:
Getting Started - Installation and first-run setup
AI Interface Setup - Configure Claude Desktop, GitHub Copilot, or Cursor
Configuration Guide - SFCC credentials and Data API setup
Available Tools - Complete tool reference
Examples - Real-world usage patterns
Troubleshooting - Common issues and solutions
🧑💻 "Create a new SFCC controller for product search"
🤖 Generates complete controller with proper imports, route handling, and SFRA patterns
🧑💻 "What's wrong with my checkout flow? Check the logs"
🤖 Analyzes recent error logs, identifies issues, and suggests fixes
🧑💻 "Show me how to implement OCAPI hooks for order validation"
🤖 Retrieves related SFCC classes and methods, then proposes a concrete hook implementation patternLocal Development Focus: Designed for individual developer use on local machines
Credential Protection: dw.json files should never be committed to version control
Network Security: All API calls use HTTPS with proper authentication
No Data Storage: Server doesn't persist any SFCC data locally
We're continuously improving the SFCC Development MCP Server with exciting new features planned:
🧠 Smarter Log Fetching - Enhanced log analysis with intelligent filtering, pattern recognition, and contextual error correlation
🚀 Deployment Tools - Integration with SFCC deployment processes and code version management
Have ideas for new features or improvements? We'd love to hear from you!
💡 Feature Requests: Open an issue to discuss your ideas
🐛 Bug Reports: Help us improve by reporting any issues you encounter
🔧 Pull Requests: Contribute code, documentation, or examples
📚 Documentation: Help expand our guides and best practices
Check out our Contributing Guide to get started, or browse our open issues to see where you can help.
Your expertise and feedback make this tool better for the entire SFCC community!
We welcome contributions! Please see our Contributing Guide for details.
This project is licensed under the MIT License - see the LICENSE file for details.
🚀 Ready to supercharge your SFCC development with AI?
Generate a complete cartridge directory structure with all necessary files and configurations. Use this when creating new cartridges to ensure proper organization and include all required components. This tool creates all necessary files directly in the specified target directory, ensuring the cartridge is created exactly where needed in your project structure.
| Name | Required | Description | Default |
|---|---|---|---|
| cartridgeName | Yes | Name of the cartridge (e.g., "plugin_example") | |
| targetPath | No | Target directory path where the cartridge files should be placed. If not specified, files will be placed in the current working directory. Use absolute paths for best results (e.g., "/Users/username/projects/my-sfcc-project/"). | |
| fullProjectSetup | No | Whether to create a complete project setup (package.json, webpack, etc.) or just add a cartridge to existing project structure. Use true for new projects, false to add cartridge to existing projects. Always send the root of the project directory as the targetPath. |
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.
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.
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.
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.
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.
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.
Get a list of all available SFCC best practice and how-to guides. Use this first to discover what guidance is available before implementing any SFCC features. Essential for understanding what best practice resources exist for cartridge creation, hooks, controllers, and custom endpoints
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Get a list of all available SFRA (Storefront Reference Architecture) documentation. Use this to discover what SFRA classes, modules, and models are documented, including Server, Request, Response, QueryString, render module, and comprehensive model documentation for account, cart, products, pricing, billing, shipping, and more. Essential for understanding SFRA architecture and available functionality.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Get a complete best practice and how-to guide with all sections and content. Use this when implementing specific SFCC features like cartridges, ISML templates, OCAPI/SCAPI hooks, SFRA controllers, or custom endpoints. Always consult the relevant guide before writing code to ensure you follow SFCC best practices, security guidelines, and proper architecture patterns.
| Name | Required | Description | Default |
|---|---|---|---|
| guideName | Yes | The guide name (e.g., 'cartridge_creation', 'isml_templates', 'job_framework', 'localserviceregistry', 'ocapi_hooks', 'scapi_hooks', 'sfra_controllers', 'sfra_models', 'sfra_client_side_js', 'sfra_scss', 'scapi_custom_endpoint', 'performance', 'security') |
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.
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.
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.
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.
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.
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.
Get comprehensive hook reference tables showing all available OCAPI or SCAPI hook endpoints and extension points. 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. Essential reference when extending SFCC APIs.
| Name | Required | Description | Default |
|---|---|---|---|
| guideName | Yes | The hook guide name |
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.
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.
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.
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.
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.
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.
Get the complete raw documentation for an SFCC class. Use this when you need comprehensive details about a class including examples, detailed descriptions, and full context. Best for in-depth understanding when the basic class info isn't sufficient.
| Name | Required | Description | Default |
|---|---|---|---|
| className | Yes | The SFCC class name |
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.
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.
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.
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.
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.
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.
Get detailed information about an SFCC class including properties, methods, and description. Use this when you need to understand what a specific SFCC class does, what methods/properties are available, or when implementing features that use SFCC APIs. Essential for cartridge development (controllers, scripts, templates, rest-apis) using the dw.* namespace in the SFCC Rhino environment.
| Name | Required | Description | Default |
|---|---|---|---|
| className | Yes | The SFCC class name (e.g., 'Catalog', 'dw.catalog.Catalog') | |
| expand | No | Whether to include detailed information about referenced types used by this class (default: false) | |
| includeDescription | No | Whether to include the class description in the response (default: true) | |
| includeConstants | No | Whether to include constants in the response (default: true) | |
| includeProperties | No | Whether to include properties in the response (default: true) | |
| includeMethods | No | Whether to include methods in the response (default: true) | |
| includeInheritance | No | Whether to include inheritance hierarchy in the response (default: true) | |
| search | No | Optional search term to filter constants, properties, methods, and inheritance entries. Case-insensitive search across names and descriptions. Only one word at a time (e.g., "get", "create", "order"). Combining multiple words or looking for multiple items at the same time is not supported. |
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.
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.
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.
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.
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.
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.
Get all available SFRA document categories with counts and descriptions. Use this to understand the organization of SFRA documentation and discover what types of functionality are available. Helpful for exploring the full scope of SFRA capabilities.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Get complete SFRA class, module, or model documentation with detailed information about properties, methods, and usage examples. 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. Now supports all 26+ SFRA documents including core classes, product models, order/cart models, customer models, pricing models, and more.
| Name | Required | Description | Default |
|---|---|---|---|
| documentName | Yes | The SFRA document name (e.g., 'server', 'request', 'response', 'querystring', 'render', 'cart', 'product-full', 'account', 'billing', 'shipping', etc.). Use get_available_sfra_documents to see all available options. |
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.
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.
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.
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.
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.
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.
Get SFRA documents filtered by category. Use this to explore documents in specific functional areas like core SFRA classes, product models, order/cart functionality, customer management, pricing, or store models. Perfect for discovering related documentation and understanding functional groupings.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Category to filter by: core (Server, Request, Response, etc.), product (product models), order (cart, billing, shipping), customer (account, address), pricing (price models), store (store models), other (utilities) |
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.
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.
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.
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.
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.
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.
Get a complete list of all available SFCC classes. Use this for exploration and discovery when you need to understand the full scope of SFCC APIs, or when you're new to SFCC development and want to see what's available. Good starting point for understanding the SFCC class hierarchy.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Search across all best practice guides for specific terms, patterns, or concepts. Use this when you need guidance on specific topics like validation, security, performance optimization, error handling, or any development pattern. Perfect for finding relevant best practices without reading entire guides.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term or concept (e.g., 'validation', 'security', 'performance'). Use single words for best results as the API does not support complex queries. |
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.
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.
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.
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.
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.
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.
Search for SFCC classes by name or functionality. Use this when you know part of a class name or need to find classes related to specific functionality (e.g., search 'catalog' to find catalog-related classes). Perfect starting point when you're unsure of the exact class name or exploring available APIs for a feature area.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for class names. Only use one word at a time (e.g., "catalog", "order", "customer"). Combining multiple words or attempting to look for multiple classes at the same time is not supported. |
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.
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.
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.
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.
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.
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.
Search for methods across all SFCC classes by method name. Use this when you know the method name but not which class it belongs to, or when looking for similar methods across different classes. Helpful for discovering all available methods that perform similar operations.
| Name | Required | Description | Default |
|---|---|---|---|
| methodName | Yes | Method name to search for. Only use one word at a time (e.g., "get", "create", "update"). Combining multiple words or looking for multiple methods at the same time is not supported. |
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.
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.
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.
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.
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.
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.
Search across all SFRA documentation for specific terms, concepts, or functionality. Use this when you need to find specific SFRA features, understand how to implement controller patterns, locate model information, or find information about routing, middleware, request handling, response management, cart functionality, product models, or customer management. Enhanced with relevance scoring and categorization.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term or concept (e.g., 'middleware', 'routing', 'render', 'querystring', 'cache', 'cart', 'product', 'billing', 'shipping', 'account', 'pricing') |
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Salesforce-grounded retrieval, diagnoses, and a vetted-Force marketplace for MCP clients.
Plan Salesforce deploys, open pull requests and trigger pipelines from your AI client.
Access and maintain design system docs, tokens, components, skills, and contexts across any project.
Enable AI assistants to interact seamlessly with Feeef e-commerce stores, products, and orders usi…
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
