Skip to main content
Glama
tsmztech

Salesforce MCP Server

salesforce_read_apex_trigger

Retrieve Apex trigger code and metadata from Salesforce to analyze automation logic, review business rules, or troubleshoot workflow issues.

Instructions

Read Apex triggers from Salesforce.

Examples:

  1. Read a specific Apex trigger by name: { "triggerName": "AccountTrigger" }

  2. List all Apex triggers with an optional name pattern: { "namePattern": "Account" }

  3. Get metadata about Apex triggers: { "includeMetadata": true, "namePattern": "Contact" }

  4. Use wildcards in name patterns: { "namePattern": "Account*" }

Notes:

  • When triggerName is provided, the full body of that specific trigger is returned

  • When namePattern is provided, all matching trigger names are returned (without body)

  • Use includeMetadata to get additional information like API version, object type, and last modified date

  • If neither triggerName nor namePattern is provided, all Apex trigger names will be listed

  • Wildcards are supported in namePattern: * (matches any characters) and ? (matches a single character)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
triggerNameNoName of a specific Apex trigger to read
namePatternNoPattern to match Apex trigger names (supports wildcards * and ?)
includeMetadataNoWhether to include metadata about the Apex triggers

Implementation Reference

  • Core handler function that executes the tool logic: queries Salesforce ApexTrigger object for specific trigger body or list matching pattern, handles metadata, formats markdown responses with code blocks or tables.
    export async function handleReadApexTrigger(conn: any, args: ReadApexTriggerArgs) {
      try {
        // If a specific trigger name is provided, get the full trigger body
        if (args.triggerName) {
          console.error(`Reading Apex trigger: ${args.triggerName}`);
          
          // Query the ApexTrigger object to get the trigger body
          const result = await conn.query(`
            SELECT Id, Name, Body, ApiVersion, TableEnumOrId, Status, 
                   IsValid, LastModifiedDate, LastModifiedById
            FROM ApexTrigger 
            WHERE Name = '${args.triggerName}'
          `);
          
          if (result.records.length === 0) {
            return {
              content: [{ 
                type: "text", 
                text: `No Apex trigger found with name: ${args.triggerName}` 
              }],
              isError: true,
            };
          }
          
          const apexTrigger = result.records[0];
          
          // Format the response with the trigger body and metadata
          return {
            content: [
              { 
                type: "text", 
                text: `# Apex Trigger: ${apexTrigger.Name}\n\n` +
                      (args.includeMetadata ? 
                        `**API Version:** ${apexTrigger.ApiVersion}\n` +
                        `**Object:** ${apexTrigger.TableEnumOrId}\n` +
                        `**Status:** ${apexTrigger.Status}\n` +
                        `**Valid:** ${apexTrigger.IsValid ? 'Yes' : 'No'}\n` +
                        `**Last Modified:** ${new Date(apexTrigger.LastModifiedDate).toLocaleString()}\n\n` : '') +
                      "```apex\n" + apexTrigger.Body + "\n```"
              }
            ]
          };
        } 
        // Otherwise, list triggers matching the pattern
        else {
          console.error(`Listing Apex triggers${args.namePattern ? ` matching: ${args.namePattern}` : ''}`);
          
          // Build the query
          let query = `
            SELECT Id, Name${args.includeMetadata ? ', ApiVersion, TableEnumOrId, Status, IsValid, LastModifiedDate' : ''}
            FROM ApexTrigger
          `;
          
          // Add name pattern filter if provided
          if (args.namePattern) {
            const likePattern = wildcardToLikePattern(args.namePattern);
            query += ` WHERE Name LIKE '${likePattern}'`;
          }
          
          // Order by name
          query += ` ORDER BY Name`;
          
          const result = await conn.query(query);
          
          if (result.records.length === 0) {
            return {
              content: [{ 
                type: "text", 
                text: `No Apex triggers found${args.namePattern ? ` matching: ${args.namePattern}` : ''}` 
              }]
            };
          }
          
          // Format the response as a list of triggers
          let responseText = `# Found ${result.records.length} Apex Triggers\n\n`;
          
          if (args.includeMetadata) {
            // Table format with metadata
            responseText += "| Name | API Version | Object | Status | Valid | Last Modified |\n";
            responseText += "|------|------------|--------|--------|-------|---------------|\n";
            
            for (const trigger of result.records) {
              responseText += `| ${trigger.Name} | ${trigger.ApiVersion} | ${trigger.TableEnumOrId} | ${trigger.Status} | ${trigger.IsValid ? 'Yes' : 'No'} | ${new Date(trigger.LastModifiedDate).toLocaleString()} |\n`;
            }
          } else {
            // Simple list format
            for (const trigger of result.records) {
              responseText += `- ${trigger.Name}\n`;
            }
          }
          
          return {
            content: [{ type: "text", text: responseText }]
          };
        }
      } catch (error) {
        console.error('Error reading Apex triggers:', error);
        return {
          content: [{ 
            type: "text", 
            text: `Error reading Apex triggers: ${error instanceof Error ? error.message : String(error)}` 
          }],
          isError: true,
        };
      }
    }
  • Tool schema definition including name, detailed description with examples, and inputSchema for parameters: triggerName, namePattern, includeMetadata.
    export const READ_APEX_TRIGGER: Tool = {
      name: "salesforce_read_apex_trigger",
      description: `Read Apex triggers from Salesforce.
      
    Examples:
    1. Read a specific Apex trigger by name:
       {
         "triggerName": "AccountTrigger"
       }
    
    2. List all Apex triggers with an optional name pattern:
       {
         "namePattern": "Account"
       }
    
    3. Get metadata about Apex triggers:
       {
         "includeMetadata": true,
         "namePattern": "Contact"
       }
    
    4. Use wildcards in name patterns:
       {
         "namePattern": "Account*"
       }
    
    Notes:
    - When triggerName is provided, the full body of that specific trigger is returned
    - When namePattern is provided, all matching trigger names are returned (without body)
    - Use includeMetadata to get additional information like API version, object type, and last modified date
    - If neither triggerName nor namePattern is provided, all Apex trigger names will be listed
    - Wildcards are supported in namePattern: * (matches any characters) and ? (matches a single character)`,
      inputSchema: {
        type: "object",
        properties: {
          triggerName: {
            type: "string",
            description: "Name of a specific Apex trigger to read"
          },
          namePattern: {
            type: "string",
            description: "Pattern to match Apex trigger names (supports wildcards * and ?)"
          },
          includeMetadata: {
            type: "boolean",
            description: "Whether to include metadata about the Apex triggers"
          }
        }
      }
    };
  • src/index.ts:257-268 (registration)
    Server request handler registration: switch case that validates arguments and delegates to handleReadApexTrigger.
    case "salesforce_read_apex_trigger": {
      const triggerArgs = args as Record<string, unknown>;
      
      // Type check and conversion
      const validatedArgs: ReadApexTriggerArgs = {
        triggerName: triggerArgs.triggerName as string | undefined,
        namePattern: triggerArgs.namePattern as string | undefined,
        includeMetadata: triggerArgs.includeMetadata as boolean | undefined
      };
    
      return await handleReadApexTrigger(conn, validatedArgs);
    }
  • src/index.ts:45-63 (registration)
    Registers the READ_APEX_TRIGGER tool in the server's listTools response.
    server.setRequestHandler(ListToolsRequestSchema, async () => ({
      tools: [
        SEARCH_OBJECTS, 
        DESCRIBE_OBJECT, 
        QUERY_RECORDS, 
        AGGREGATE_QUERY,
        DML_RECORDS,
        MANAGE_OBJECT,
        MANAGE_FIELD,
        MANAGE_FIELD_PERMISSIONS,
        SEARCH_ALL,
        READ_APEX,
        WRITE_APEX,
        READ_APEX_TRIGGER,
        WRITE_APEX_TRIGGER,
        EXECUTE_ANONYMOUS,
        MANAGE_DEBUG_LOGS
      ],
    }));
  • Helper function to convert wildcard patterns (*, ?) to SQL LIKE patterns for querying trigger names.
    function wildcardToLikePattern(pattern: string): string {
      if (!pattern.includes('*') && !pattern.includes('?')) {
        // If no wildcards, wrap with % for substring match
        return `%${pattern}%`;
      }
      
      // Replace * with % and ? with _ for SQL LIKE
      let likePattern = pattern.replace(/\*/g, '%').replace(/\?/g, '_');
      
      return likePattern;
    }
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 describes key behaviors: returning full body vs names only based on parameters, wildcard support in patterns, and metadata inclusion. It doesn't mention rate limits, authentication needs, or error handling, but covers the core operational behavior well for a read operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and appropriately sized. It starts with a clear purpose statement, follows with practical examples, and ends with explanatory notes. Every sentence adds value—no fluff or repetition. The examples are concise and illustrative, making it easy to understand without being verbose.

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 read tool with no annotations and no output schema, the description does a good job of completeness. It explains what the tool does, how to use parameters, and what to expect in return. It could improve by mentioning output format or error cases, but given the context, it provides sufficient guidance for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds value by explaining how parameters interact (e.g., triggerName returns body, namePattern returns names only) and providing usage examples, but doesn't add significant semantic meaning beyond what's in the schema. 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: 'Read Apex triggers from Salesforce.' This is a specific verb+resource combination that distinguishes it from siblings like salesforce_write_apex_trigger (write vs read) and salesforce_read_apex (general Apex vs triggers specifically). However, it doesn't explicitly contrast with salesforce_query_records or salesforce_search_all for data retrieval.

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 usage guidance through examples and notes. It specifies when to use triggerName vs namePattern, when includeMetadata is appropriate, and what happens when no parameters are provided. The examples illustrate different scenarios, and the notes clarify behavioral outcomes, making it clear when to choose this tool over alternatives.

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/tsmztech/mcp-server-salesforce'

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