Apex Log MCP Server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| apexlog_list_slow_operationsA | Rank what an Apex debug log spent its time on by self-execution time, or on the heap it retains - code units, methods, queries, searches, DML, callouts, flows and workflows in one table, each row with its calls, durations, database counts and rows, so the caller can see what to optimize and why, beside the query optimizer's plan for the queries among them. |
| apexlog_get_summaryA | Get a high-level summary of an Apex debug log: how long the transaction ran, where the time went by debug log category and the level each was logged at, every governor limit it and each namespace consumed, whether the log is complete, the exceptions and flow errors it raised, and what ended the transaction if it failed. Best for a quick overview. |
| apexlog_list_limit_risksA | List the governor limits an Apex log transaction has nearly used up - CPU time, heap, SOQL queries and rows, SOSL queries, DML statements and rows, callouts and every other limit - worst first, with how much of each was used |
| apexlog_search_eventsA | Search the events of an Apex debug log in log order: what the code printed (USER_DEBUG), validation rules, statements, or every event under one method. For plain text in the saved .log, grep is cheaper; use this for event types, nesting, or without a shell. Text past 400 characters is elided; ask for one event by eventIndex to read up to 30,000. |
| apexlog_list_org_logsA | List the debug logs stored in a Salesforce org, with how many match. Pass ids to apexlog_get_org_logs to download them. |
| apexlog_get_org_logsA | Download debug logs from a Salesforce org, by id or the newest N, and return each saved file's path, which the analysis tools accept. |
| apexlog_create_trace_flagA | Trace a user, class or trigger in a Salesforce org until the trace flag expires. A user's flag stores each transaction they run as a debug log, which can fill log storage; a class or trigger flag only sets that code's levels. Refused if one of its log type exists. Leaves a debug level in the org. |
| apexlog_execute_anonymousA | Execute anonymous Apex in a Salesforce org as the targetOrg user; DML commits unless the run fails. Saves the debug log and returns its path for the analysis tools. With no active trace flag, adds one for the run, deleted after, and a debug level, left in the org. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
The tools are mostly clearly separated by resource and action: listing versus downloading org logs are distinct, and the analysis tools each target a different view of a log. Some overlap remains between get_summary, list_slow_operations, list_limit_risks, and search_events, since all analyze the same log artifact, but their descriptions make the intended use cases reasonably clear.
Every tool uses the same apexlog_ prefix followed by a consistent snake_case verb_noun pattern, such as apexlog_get_org_logs, apexlog_list_slow_operations, and apexlog_search_events. The naming is predictable throughout.
Eight tools is well scoped for an Apex log retrieval and analysis server. Each tool covers a distinct part of the workflow: obtaining logs, executing Apex, creating trace flags, and analyzing different aspects of a log.
The surface covers the core lifecycle well: listing and downloading logs, producing logs via anonymous Apex or trace flags, and several rich analysis views. Minor gaps exist around explicit trace-flag cleanup or log deletion, but agents can work around these with the available operations.