Skip to main content
Glama
taurgis

SFCC Development MCP Server

by taurgis

get_sfra_document

Retrieve detailed SFRA documentation for classes, modules, and models to understand properties, methods, and implementation examples for SFCC development tasks.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
documentNameYesThe 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.

Implementation Reference

  • The handler configuration for the 'get_sfra_document' tool, including defaults, input validation (requires 'documentName' string), execution logic that fetches the document via SFRAClient and throws if not found, and logging message.
    get_sfra_document: {
      defaults: (args: ToolArguments) => args,
      validate: (args: ToolArguments, toolName: string) => {
        ValidationHelpers.validateArguments(args, CommonValidations.requiredString('documentName'), toolName);
      },
      exec: async (args: ToolArguments, context: ToolExecutionContext) => {
        const client = context.sfraClient as SFRAClient;
        const result = await client.getSFRADocument(args.documentName as string);
        if (!result) {
          throw new Error(`SFRA document "${args.documentName}" not found`);
        }
        return result;
      },
      logMessage: (args: ToolArguments) => `SFRA doc ${args.documentName}`,
    },
  • The tool schema definition including name, description, and inputSchema requiring 'documentName' as a string.
    {
      name: 'get_sfra_document',
      description: '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.',
      inputSchema: {
        type: 'object',
        properties: {
          documentName: {
            type: 'string',
            description: '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.',
          },
        },
        required: ['documentName'],
      },
    },
  • The core helper method getSFRADocument that loads the SFRA document from filesystem, uses caching, path validation, and falls back to metadata if full content fails. Called by the tool handler.
    async getSFRADocument(documentName: string): Promise<SFRADocument | null> {
      // Normalize document name for consistent lookup
      const normalizedDocumentName = documentName.toLowerCase();
    
      // First try to get from metadata cache
      const metadata = await this.getSFRADocumentMetadata(documentName);
      if (!metadata) {
        return null;
      }
    
      // If the content is already loaded, return it
      if (metadata.content?.trim()) {
        return metadata;
      }
    
      // Otherwise, load the full content
      try {
        const filePath = await this.validateAndConstructPath(documentName);
        const content = await fs.readFile(filePath, 'utf-8');
    
        const fullDocument: SFRADocument = {
          ...metadata,
          content,
        };
    
        // Update cache using normalized name
        this.documentsCache.set(normalizedDocumentName, fullDocument);
        return fullDocument;
      } catch (error) {
        this.logger.error(`Error loading full SFRA document ${normalizedDocumentName}:`, error);
        return metadata; // Return metadata even if content loading failed
      }
    }
  • Private helper method getSFRADocumentMetadata that extracts metadata (title, description, sections, type, category, properties, methods) from the markdown file, with caching and parsing logic.
    private async getSFRADocumentMetadata(documentName: string): Promise<SFRADocument | null> {
      // Normalize document name for consistent caching and lookup
      const normalizedDocumentName = documentName.toLowerCase();
    
      // Check if we already have this document cached
      if (this.documentsCache.has(normalizedDocumentName)) {
        return this.documentsCache.get(normalizedDocumentName)!;
      }
    
      try {
        const filePath = await this.validateAndConstructPath(documentName);
        const stats = await fs.stat(filePath);
    
        // Check if we have a cached version that's still valid
        const cacheKey = `sfra:metadata:${normalizedDocumentName}`;
        const cached = this.cache.getFileContent(cacheKey);
        if (cached) {
          const cachedData = JSON.parse(cached);
          if (cachedData.lastModified && new Date(cachedData.lastModified) >= stats.mtime) {
            return cachedData;
          }
        }
    
        // Read only the first part of the file to extract metadata
        const content = await fs.readFile(filePath, 'utf-8');
        const lines = content.split('\n');
    
        // Extract title
        const titleLine = lines.find(line => line.startsWith('#'));
        const title = titleLine?.replace(/^#+\s*/, '').trim() ?? this.formatDocumentName(normalizedDocumentName);
    
        // Determine type based on title and content
        const type = this.determineDocumentType(title, content);
    
        // Determine category - use normalized name for consistent mapping
        const category = (CATEGORY_MAPPINGS[normalizedDocumentName] || 'other') as SFRADocument['category'];
    
        // Extract description (first substantial paragraph after title)
        const description = this.extractDescription(lines, title);
    
        // Extract sections (## headers)
        const sections = lines
          .filter(line => line.startsWith('##'))
          .map(line => line.replace(/^##\s*/, '').trim())
          .filter(section => section.length > 0);
    
        const document: SFRADocument = {
          title,
          description,
          sections,
          content, // Keep full content for now, optimize later if needed
          type,
          category,
          filename: `${normalizedDocumentName}.md`,
          lastModified: stats.mtime,
          ...(type === 'class' || type === 'model' ? {
            properties: this.extractProperties(lines),
            methods: this.extractMethods(lines),
          } : {}),
        };
    
        // Cache the metadata using normalized name
        this.cache.setFileContent(cacheKey, JSON.stringify(document));
        this.documentsCache.set(normalizedDocumentName, document);
    
        return document;
      } catch (error) {
        this.logger.error(`Error loading SFRA document metadata ${normalizedDocumentName}:`, error);
        return null;
      }
    }
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.

Install Server

Other Tools

Latest Blog Posts

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