Apex Log MCP Server

A Model Context Protocol (MCP) server that gives AI assistants tools to analyze Salesforce Apex debug logs — surfacing performance bottlenecks, slow methods, and governor limit usage.

Give your AI assistant — Claude, Copilot, or any MCP-compatible client — the ability to parse Apex debug logs and surface the performance insights that matter. Instead of scrolling through thousands of log lines, ask your assistant to find what's slow and why.

Powered by the same powerful log parser as the Apex Log Analyzer VS Code extension used by thousands of Salesforce developers.

Quick Start | What You Can Do | Token Cost | Tools Reference | Configuration | How It Works | Documentation | Contributing | Contributors | License

Quick Start

Requirements: Node.js 22 or later.

The apexlog_execute_anonymous tool additionally needs an org authenticated with the Salesforce CLI.

Add to your MCP client configuration (claude_desktop_config.json, VS Code mcp.json, etc.):

{
  "mcpServers": {
    "apex-log-mcp": {
      "command": "npx",
      "args": ["-y", "@certinia/apex-log-mcp"]
    }
  }
}

That's it. Open a conversation and ask your AI assistant to analyze an Apex debug log.

Related MCP server: Log Reader MCP

What You Can Do

Ask your AI assistant to work with Apex debug logs using natural language:

• "Give me a summary of this debug log"

• "Show me the 5 slowest methods in the default namespace"

• "Are we approaching any governor limits in this transaction?"

• "Run this Apex against my scratch org and analyze the performance"

Token Cost

Enabling the tools

Every request carries all four tool definitions, whether or not a tool is called. That is the standing cost of having the server connected, and each figure is the whole definition as the client receives it — name, title, description, input schema and annotations together.

Calling a tool

The input side is the same for every analysis tool — a tool name and a log file path, about 15 tokens — so what a call costs is what it returns. Each row is one tool answering one of the logs in tests/eval/fixtures/, beside what 1.x returned for the same log — the same facts, in a cheaper shape.

Tools Reference

All tools return TOON-encoded data, kept deliberately lean to save tokens — without dropping anything you might need to ask about. See Token Cost for what that is worth in practice.

• Every governor limit, debug category and operation column is returned, including the ones at zero. "How many DML statements did this consume?" is answerable from the response, and 0 means none rather than not measured.

• The leanness comes from shape. Data that used to be nested objects is returned as flat tables, which TOON encodes as one header plus one line per row.

• Nothing is reported twice. No prose summary restates the numbers in the table alongside it, and no figure appears in two places.

• Durations are rounded to 3 decimal places (ms) and percentages to 1.

• Only lists of things that happened are omitted when empty — log issues. Nothing to report means the key is absent.

apexlog_list_slow_operations

Rank what an Apex debug log spent its time on by self-execution time — code units, managed packages, methods, queries, searches, DML, flows and workflows in one table, each row with its calls, durations (in ms), database counts and rows. Best for finding what to optimize.

Rows are {kind, name, namespace, callCount, durationTotalMs, durationSelfMs, selfPercentage, soqlCount, dmlCount, soslCount, rowCount, thrownCount}, beside the transaction's durationTotalMs and the returnedSelfPercentage the returned rows account for between them.

kind is one of codeUnit, managedPackage, method, systemMethod, soql, sosl, dml, flow or workflow. A managedPackage row is the time a package spent where the log shows nothing, and is often most of a transaction.

apexlog_get_summary

Get a high-level summary of an Apex debug log: how long the transaction ran (in ms), where the time went by kind of operation, every governor limit it and each namespace consumed, the debug levels it was logged at, and whether the log is complete. Best for a quick overview before deeper analysis.

All thirteen governor limits are listed as {limit, used, max} rows, at zero included, so you can ask what a transaction consumed and get an answer either way. limitsByNamespace adds {namespace, limit, used} rows for each limit a namespace consumed, which is how you see that a managed package spent your CPU time; it names no ceiling, because the parser keeps one ceiling per limit for the whole transaction and it is already in governorLimits.

timeByKind gives {kind, logCategory, operationCount, durationSelfMs, selfPercentage} for every kind apexlog_list_slow_operations ranks. logCategory is the trace category that decides whether the kind reaches the log at all, so a zero can be read: soql 0 beside DB NONE in debugLevels, whose rows are {logCategory, level}, means the queries were not logged, and beside DB FINEST it means none ran.

apexlog_list_limit_risks

List the governor limits an Apex log transaction has nearly consumed — CPU time, heap, SOQL and SOSL queries, DML statements, and the rows each returned or wrote — worst first, with how much of each was used. Best for checking whether a transaction is at risk of failing on a limit.

Rows are {limit, used, max, usedPercentage}. The threshold that produced them is reported alongside, so an empty table reads as "nothing is that far consumed" rather than as a missing answer.

apexlog_execute_anonymous

Executes anonymous Apex code against any authenticated Salesforce org. Saves the resulting debug log to a local file and returns a summary with the file path. Use the file path with apexlog_get_summary, apexlog_list_slow_operations, or apexlog_list_limit_risks for deeper analysis.

debugLevel options — omit to keep the current config, or pass one of:

• "default" — reset every category to its default.

• a log level (e.g. "FINEST") — set every category to that level.

• an object — override specific categories only; the rest keep their defaults:

  { "database": "FINEST", "apexCode": "FINE" }

Valid levels: NONE, ERROR, WARN, INFO, DEBUG, FINE, FINER, FINEST.

Example prompts:

• "Execute this Apex and show me the log: System.debug('Hello');"

• "Run a query for all Accounts and analyze the performance"

• "Execute this Apex with all debug levels set to FINEST"

• "Run this Apex against my QA org with database logging set to FINEST"

Note: Uses the project's default org unless targetOrg is specified. Sandbox, scratch, Developer Edition and trial orgs run without prompting; production orgs are gated — see Production safety. The debug log is saved to a local file (default: .apex-log-mcp/) and the response includes the file path, org username (and alias, if set), org type, and execution summary. Add .apex-log-mcp/ to your .gitignore to avoid committing debug logs.

Configuration

The Quick Start configuration is all you need — all four tools are available by default. The sections below cover the production safety policy and how to change it.

Production safety

apexlog_execute_anonymous runs arbitrary Apex, so before running anything the server identifies what kind of org it is pointed at. It asks the org once per session:

For a production org, the server:

1. Runs it anyway if the server was started with --allow-production-orgs.

2. Otherwise asks you to confirm, if your MCP client supports elicitation. The prompt names the org and shows the Apex.

3. Otherwise refuses, and the error explains both ways to proceed.

An org that cannot be identified is treated as production, so a network or permissions problem can never silently downgrade a production org.

Server flags

For an analysis-only deployment:

{
  "mcpServers": {
    "apex-log-mcp": {
      "command": "npx",
      "args": ["-y", "@certinia/apex-log-mcp", "--no-apex-execution"]
    }
  }
}

How It Works

This server implements the Model Context Protocol (MCP) to expose Apex log analysis as tools that any MCP-compatible AI client can call.

• Runs as a local process — your AI client spawns the server and communicates locally. No network requests, no API keys.

• Uses the same parser as the Apex Log Analyzer VS Code extension — battle-tested parsing of the Apex debug log format.

• Returns structured data — all durations in milliseconds, governor limits as used/max rows, operations with SOQL/DML counts — so your AI assistant can reason about the results.

• Keeps responses lean — TOON tables and no duplicated figures, so more of the context window is left for reasoning. The fields stay, including the ones at zero: see Tools Reference.

• Parses a log once, not once per tool — a summary followed by a deeper analysis of the same file reuses the parse, so a large log is read and parsed one time.

Documentation

• User Guide & Docs

• MCP Specification

Related Projects

• Apex Log Analyzer VS Code Extension — Full-featured Apex log analyzer for VS Code

Contributing

We welcome contributions! Please see our Contributing Guide for details.

• Developing — Set up your development environment

• Code of Conduct — Community guidelines

Contributors

Thanks to our amazing contributors!

License