Skip to main content
Glama
certinia

Apex Log MCP Server

Official
by certinia
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Execute Anonymous Apex

apexlog_execute_anonymous
Destructive

Execute anonymous Apex in a Salesforce org and save the debug log for analysis. Manages trace flags and debug levels so you can profile performance and governor limits.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
apexNoThe anonymous Apex to execute, or use apexFilePath
outputDirNoLog directory (default: .apex-log-mcp/ in the first client root, else cwd)
targetOrgNoAlias or username of the target Salesforce org. Uses the project default if not specified.
debugLevelNoThis run's log levels. Omit for the user's trace flag levels, else the defaults; "default" forces the defaults; a bare level sets every category; an object sets the named categories over the defaults. Defaults: apexCode, apexProfiling, visualforce, workflow FINE; callout, system, validation DEBUG; database FINEST; nba, wave INFO.
apexFilePathNoAbsolute path to a file of anonymous Apex

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv2.0.2
    • changedInput schema / properties / apex / description
      Previous value: -"The anonymous Apex to be executed"New value: +"The anonymous Apex to execute, or use apexFilePath"
    • addedInput schema / properties / apexFilePath
      Added value: +{
+  "description": "Absolute path to a file of anonymous Apex",
+  "type": "string"
+}
    • changedInput schema / properties / debugLevel / description
      Previous value: -"Trace flag log levels. \"default\" restores the defaults; a bare level sets every category to it; an object sets only the categories named and leaves the rest unchanged. Defaults: apexCode, apexProfiling, visualforce, workflow FINE; callout, system, validation DEBUG; database FINEST; nba, wave INFO."New value: +"This run's log levels. Omit for the user's trace flag levels, else the defaults; \"default\" forces the defaults; a bare level sets every category; an object sets the named categories over the defaults. Defaults: apexCode, apexProfiling, visualforce, workflow FINE; callout, system, validation DEBUG; database FINEST; nba, wave INFO."
    • changedInput schema / properties / outputDir / description
      Previous value: -"Directory to save the debug log file. Defaults to .apex-log-mcp/ in the project root."New value: +"Log directory (default: .apex-log-mcp/ in the first client root, else cwd)"
    • removedInput schema / required
      Removed value: -[
-  "apex"
-]
  2. Addedv2.0.1

TDQS

A4.3/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations by disclosing that DML commits unless the run fails, that a trace flag is auto-created and deleted after the run, and that a debug level is left behind in the org. These side effects are exactly what an agent needs before invoking a destructive, non-idempotent tool.

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

Conciseness4/5

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

Front-loads the core action and mutation consequence in the first sentence, with side effects second. The final clause ('adds one for the run, deleted after, and a debug level, left in the org') is slightly compressed and takes a re-read, but no sentence is filler.

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?

Covers mutation semantics, org side effects, and the return value (log path) despite no output schema. It stops short of describing failure behavior such as compile errors or whether logs are still saved on failure, which matters for a destructive execution tool.

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 parameters like debugLevel, outputDir, and apexFilePath are already fully documented. The description adds only one semantic nugget – that the debug level persists in the org – which is useful but marginal against the schema's own detail, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Execute anonymous Apex in a Salesforce org') plus execution identity ('as the targetOrg user'), which no sibling provides. An agent can distinguish it from apexlog_get_org_logs or apexlog_create_trace_flag without opening the schema.

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?

Implies the workflow by saying it 'returns its path for the analysis tools,' routing the agent to the summary/search/limit-risk siblings for follow-up. It does not explicitly state when *not* to use it or when to prefer pre-existing logs via apexlog_get_org_logs, so exclusions are absent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools