This server gives AI assistants tools to analyze Salesforce Apex debug logs, surfacing performance bottlenecks, slow methods, and governor limit usage.
Analyze Apex Log Performance (analyze_apex_log_performance): Rank methods in an Apex debug log by self-execution time, returning method names, durations (in ms), SOQL/DML counts, and optimization recommendations. Supports filtering by namespace, minimum duration, and limiting results.
Get Apex Log Summary (get_apex_log_summary): Retrieve a high-level overview of an Apex debug log, including total execution time, method count, SOQL/DML totals, governor limits, and active namespaces — ideal for a quick assessment before deeper analysis.
Find Performance Bottlenecks (find_performance_bottlenecks): Check whether a transaction is approaching Salesforce governor limits (flags usage above 80%), analyzing CPU time, SOQL/DML limits, query rows, and method execution patterns by namespace. Supports focused analysis types: cpu, database, methods, or all.
Execute Anonymous Apex (execute_anonymous): Execute Apex code against an authenticated Salesforce org, save the debug log, and provide a summary for subsequent detailed analysis with other tools. (Described in the README but may not be present in the current server schema.)
Provides tools to analyze Salesforce Apex debug logs for performance bottlenecks, slow methods, and governor limit usage, and allows executing anonymous Apex against Salesforce orgs.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Apex Log MCP Server Find the top 5 slowest methods in this debug log and their durations"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP Server to Analyze Salesforce Apex debug logs from your AI assistant. Finds slow methods, governor limit risks, and where a transaction spent its time.
Instead of scrolling thousands of log lines, ask what's slow and why. Uses the same parser as the Apex Log Analyzer VS Code extension.
Requires Node.js 22 or later. Add this to your MCP client config (claude_desktop_config.json, VS Code mcp.json, and so on):
{
"mcpServers": {
"apex-log-mcp": {
"command": "npx",
"args": ["-y", "@certinia/apex-log-mcp"]
}
}
}Then ask your assistant to analyze a log. apexlog_execute_anonymous also needs an org authenticated with the Salesforce CLI.
Related MCP server: Log Reader MCP
"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"
Keeping the server connected costs ~1,232 tokens, 0.6% of a 200K context. See Token Cost.
The analysis tools take an absolute path to a .log file.
Every tool returns one flat table, encoded as TOON. Nothing is repeated, and nothing is dropped to save space.
A 0 means none, not "not measured". Only what did not happen is left out: fatal errors, lost log content, query plans. Durations are in milliseconds to 3 decimal places, percentages to 1.
The server runs as a local process started by your client over stdio, no network calls and no API keys. Each log is parsed once, so follow up questions are faster.
Ranks what a log spent its time on by self time - code units, methods, queries, searches, DML, flows and workflows in one table.
A default response returns:
capturedAt - {debugCategory, level}
operations - {debugCategory, type, name, namespace, callCount, durationTotalMs, durationSelfMs, durationSelfMaxMs, selfPercentage, soqlCount, dmlCount, soslCount, rowCount, thrownCount}
queryPlans - {operationRow, leadingOperationType, relativeCost, cardinality, sObjectCardinality}
Each response also gives durationTotalMs for the whole transaction, returnedSelfPercentage for the share these rows account for, and matchedCount for the rows that matched before paging.
durationSelfMaxMs is the slowest single call in a grouped row. Read it against durationSelfMs to tell one bad call from many small ones. It is absent when the row is already one call.
Two columns say what a row is, both taken straight from the log:
debugCategory - what Salesforce stamped on the event. It decided whether the event was logged at all, and it is the spelling apexlog_execute_anonymous takes.
type - the event type. The category cannot imply it: SOQL_EXECUTE_BEGIN, SOSL_EXECUTE_BEGIN and DML_BEGIN all sit under database.
Watch for ENTERING_MANAGED_PKG. It is time a package spent where the log shows nothing, and it is often most of a transaction.
sortBy: "heapSelfNetBytes" ranks by retained heap instead of time, adding that column and returnedHeapPercentage. Both are absent otherwise. The figure is signed, so a row that released more than it took reads below zero. Heap is logged only at apexCode FINER and above, so check the apexCode row of capturedAt before trusting a zero.
capturedAt gives the level each category in the returned rows was logged at.
queryPlans is what the query optimizer decided about the queries behind those rows. A relativeCost above 1 means it will not treat the query as selective. Plans are absent when the log explained none, because explain lines need database FINEST.
operationRow points at a row of operations, counting from 1. Under a namespace, callerNamespace or debugCategory grouping a row is not one query, so the plan carries the query text in name instead.
Parameter | Type | Required | Description |
| string | Yes | Absolute path |
| string[] | No | Rank only these debug log categories |
| string[] | No | Rank only these log event types, e.g. SOQL_EXECUTE_BEGIN, DML_BEGIN, METHOD_ENTRY |
| string[] | No | Rank only these namespaces |
| number | No | Drop operations below this self time (default: 0), whichever sortBy is used |
| number | No | Page size (default: 10); fewer if the page would be too large |
| number | No | Ranked rows to skip (default: 0). Advance it by the rows you got, which can be fewer than limit. |
| string | No | Fold repeats into one row; default name. callerNamespace attributes platform DML to the package that drove it. debugCategory folds a namespace's event types together and so states no type or name. none ranks each call on its own. A grouped durationTotalMs is what the transaction takes back if the group never runs - never sum it across rows. |
| string | No | Default durationSelfMs. heapSelfNetBytes adds that column. |
How long the transaction ran, where the time went, what it consumed, and whether the log is complete. Start here.
fatalErrors - {message, frames}
governorLimits - {limit, used, max}
limitsByNamespace - {namespace, limit, used}
categories - {debugCategory, level, operationCount, durationSelfMs, selfPercentage}
All thirteen governor limits are listed, zeros included.
limitsByNamespace shows what each namespace consumed. This is how you see a managed package spending your CPU time. It has no ceiling column, because a ceiling is per limit for the whole transaction and already sits in governorLimits.
categories covers all eleven, each with the level it was captured at, because the level is what a zero means:
database,NONE,0 - the queries were not logged.
database,FINEST,0 - no queries ran.
dataAccess,"",0 - the log's header declared no level for it, which most logs do not.
dataAccess, wave and validation are always zero. No timed event carries them.
truncated says whether the log is complete. In a partial log, every figure is a floor. Where the platform cut it, truncatedBy says how - skipped-lines for a hole, max-size for a missing tail - and skippedBytes says how much went. Both are absent when a log merely stops mid-frame.
thrownCount counts the exceptions thrown, zero included.
fatalErrors appears once per failure that ended the transaction, with the innermost three frames and a trailing … where there were more. It is the only field that says a transaction did not finish, because a fatal error need not breach any limit.
Parameter | Type | Required | Description |
| string | Yes | Absolute path |
The governor limits nearest their ceiling, worst first.
capturedAt - {debugCategory, level}
atRisk - {limit, used, max, usedPercentage}
threshold is reported beside the rows, so an empty table means nothing reached it rather than that the answer is missing.
capturedAt gives the level that gated each returned limit. Every limit but heap comes from apexProfiling; heapSize comes from apexCode.
Parameter | Type | Required | Description |
| string | Yes | Absolute path |
| number | No | Report a limit once it is this percentage consumed (default: 80) |
Runs anonymous Apex against an authenticated org, saves the debug log locally, and returns the path. Pass that path to any analysis tool.
The response also gives the org username, its alias if set, the org type, and a summary of the run. Logs go to .apex-log-mcp/ by default - add it to your .gitignore. Production orgs are gated: see Production safety.
Parameter | Type | Required | Description |
| string | Yes | The anonymous Apex to be executed |
| string | No | Alias or username of the target Salesforce org. Uses the project default if not specified. |
| string | No | Directory to save the debug log file. Defaults to .apex-log-mcp/ in the project root. |
| string | object | No | 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. |
An object debugLevel looks like this:
{ "database": "FINEST", "apexCode": "FINE" }Levels are 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"
Every request carries all four tool definitions, whether you call them or not. Each figure below is a whole definition: name, title, description, input schema and annotations.
Tool | Tokens |
| ~530 |
| ~407 |
| ~150 |
| ~145 |
Total | ~1,232 (0.6% of a 200K context), -19% vs 1.x ~1,529 |
Only the total compares with 1.x: per tool it would compare different tools, since apexlog_list_slow_operations replaced one that took three selection parameters and ranked methods where this one takes eight and ranks every timed event.
A call itself is about 15 tokens - a tool name and a log path - so what a call costs is what it returns.
Cost does not grow with the log size. The figures below are measured against a 40 KB slice of the Apex Log Analyzer sample log. On the full 19.7 MB original, apexlog_get_summary returns ~374 tokens instead of ~364, and apexlog_list_limit_risks the same ~35.
Tool | Response | 1.x | Change |
| ~325 | ~293 | +11% |
| ~396 | ~408 | -3% |
| ~35 | ~84 | -58% |
The Quick Start config gives you all four tools.
apexlog_execute_anonymous runs arbitrary Apex, so the server identifies the org before running anything:
Org type | Identified by | Behaviour |
|
| Runs |
|
| Runs |
| Not a sandbox, has a trial expiry | Runs |
| Developer Edition | Runs |
| Anything else | Confirmation required |
| The org could not be queried | Confirmation required |
For a production org, --allow-production-orgs runs it anyway. Otherwise the server asks you to confirm, naming the org and showing the Apex. That needs a client that supports elicitation; without one the call is refused, and the message names both ways to proceed. Each confirmation authorizes one run.
An org that cannot be identified is treated as production, so a network or permissions problem can never quietly downgrade one.
Flag | Description |
| Treat production orgs like any other - no confirmation, no refusal. Only set this if production targets are intentional. |
| Refuse every Apex execution. The tool stays visible so agents know it exists. The three analysis tools are unaffected. |
For an analysis-only deployment:
{
"mcpServers": {
"apex-log-mcp": {
"command": "npx",
"args": ["-y", "@certinia/apex-log-mcp", "--no-apex-execution"]
}
}
}Apex Log Analyzer VS Code Extension - the full log analyzer for VS Code
See the Contributing Guide, Developing to set up your environment, and the Code of Conduct.
BSD 3-Clause. Copyright © Certinia Inc. All rights reserved.
Execute a snippet of anonymous Apex against an authenticated Salesforce org (via SF CLI). Saves the resulting debug log to a local file and returns a summary with the file path, which the analysis tools accept. Production orgs require per-call user confirmation or the --allow-production-orgs server flag.
| Name | Required | Description | Default |
|---|---|---|---|
| apex | Yes | The anonymous Apex to be executed | |
| outputDir | No | Directory to save the debug log file. Defaults to .apex-log-mcp/ in the project root. | |
| targetOrg | No | Alias or username of the target Salesforce org. Uses the project default if not specified. | |
| debugLevel | No | 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructive/openWorld/non-idempotent, so the safety profile is covered. The description adds real behavioral value on top: it writes a debug log to a local file, returns a summary containing that path, and requires confirmation or a server flag for production orgs. It omits whether execution runs with the authenticated user's permissions and how failures surface, keeping it below 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: what it does, what it returns, and the production caveat. Front-loaded with the action and no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers action, execution context, side effect (local log file), return contract, and the production-org gate. No output schema exists, yet the description explains the return shape adequately, and the 100%-covered input schema handles parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema itself documents apex, outputDir default, targetOrg fallback, and the full debugLevel semantics including category defaults, so the baseline is 3. The description adds no parameter-level detail beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Execute a snippet of anonymous Apex') and the mechanism ('via SF CLI'), and distinguishes itself from the siblings by noting the returned file path is what 'the analysis tools accept'. An agent can tell this is the producer tool and the others are consumers without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear situational context: run ad-hoc Apex against an authenticated org, with an explicit prerequisite for production orgs (per-call confirmation or the --allow-production-orgs server flag). It never names an alternative tool or says when NOT to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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, and what ended the transaction if it failed. Best for a quick overview.
| Name | Required | Description | Default |
|---|---|---|---|
| logFilePath | Yes | Absolute path |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered. Beyond that, the description adds real behavioral value: it discloses that the log may be incomplete, that limits are broken out per namespace, and that the terminating cause is reported on failure. It does not mention failure modes for an invalid path or log size constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the verb and resource, then a single dense enumeration of the returned content, closed by a short use-case tagline. The long middle clause is list-like but every item maps to real output content, so nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must carry the return-value burden, and it does so thoroughly by naming each summary component. With annotations covering the safety profile and the sole parameter fully documented, the only gap is error behavior for a missing or unreadable log file.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With a single parameter at 100% schema coverage ('Absolute path'), the schema already carries full documentation. The description adds no path format, encoding, or locality detail beyond what the schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('Apex debug log summary') and enumerates exactly what the summary contains: transaction duration, time by debug category and level, governor limits per namespace, completeness, and failure cause. It contrasts implicitly with the list_* siblings by framing itself as a 'high-level summary' and 'quick overview' rather than an enumeration, but it never names the alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Best for a quick overview' gives a clear use context, but there is no explicit when-not guidance and no sibling is named (apexlog_list_limit_risks and apexlog_list_slow_operations are left for the agent to reason about). The usage signal is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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
| Name | Required | Description | Default |
|---|---|---|---|
| threshold | No | Report a limit once it is this percentage consumed (default: 80) | |
| logFilePath | Yes | Absolute path |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds useful behavioral context beyond annotations: results are sorted worst-first and report how much of each limit was used, though it omits pagination, auth, or log-file handling details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with zero filler. The dash-separated list efficiently enumerates limit types, and the trailing clause covers ordering and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, read-only analysis tool with fully described schema parameters and annotations covering safety, the description explains what is listed and how it is ordered. It lacks usage guidance relative to sibling tools, but otherwise supplies enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are fully documented in the schema itself. The description's phrase 'nearly consumed' loosely frames the threshold parameter, but adds no syntax, default, or format detail beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (governor limits an Apex log transaction has nearly consumed), enumerates the limit types, and specifies ordering (worst first) and usage detail. It does not explicitly distinguish itself from sibling tools such as apexlog_list_slow_operations or apexlog_get_summary, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use, when-not, or alternative-tool guidance is provided. The purpose implies risk analysis of an Apex log, but the agent receives no explicit condition for choosing this tool over get_summary or list_slow_operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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, 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.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Rank only these log event types, e.g. SOQL_EXECUTE_BEGIN, DML_BEGIN, METHOD_ENTRY | |
| limit | No | Page size (default: 10); fewer if the page would be too large | |
| offset | No | Ranked rows to skip (default: 0). Advance it by the rows you got, which can be fewer than limit. | |
| sortBy | No | Default durationSelfMs. heapSelfNetBytes adds that column. | |
| groupBy | No | Fold repeats into one row; default name. callerNamespace attributes platform DML to the package that drove it. debugCategory folds a namespace's event types together and so states no type or name. none ranks each call on its own. A grouped durationTotalMs is what the transaction takes back if the group never runs - never sum it across rows. | |
| minSelfMs | No | Drop operations below this self time (default: 0), whichever sortBy is used | |
| namespace | No | Rank only these namespaces | |
| logFilePath | Yes | Absolute path | |
| debugCategory | No | Rank only these debug log categories |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful output context (rows carry calls, durations, database counts and rows, plus the optimizer plan for queries), but says nothing about permissions, log-file prerequisites, or how pagination interacts with ranking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence that front-loads the ranking dimension and then the row contents. It is long but every clause carries information; it would be tighter with the output-shape detail folded into a structured return description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must describe the return shape, and it does: a single table of ranked rows with calls, durations, database counts/rows, plus the query optimizer plan. What is missing is the framing around the two sort modes and how the plan column appears per query.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all nine parameters are already documented in the schema, including the groupBy folding caveat and the heapSelfNetBytes column behavior. The description's mentions of self-execution time and retained heap map onto sortBy but add no syntax or format detail beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Rank') and resource ('what an Apex debug log spent its time on'), and enumerates the covered event families (code units, methods, queries, searches, DML, flows, workflows). An agent can tell this is a ranked-hotspot report tool, but the description never distinguishes itself from siblings like apexlog_list_limit_risks or apexlog_get_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The closing clause 'so the caller can see what to optimize and why' implies the optimization-diagnosis use case, but there is no explicit when-to-use, when-not-to-use, or named alternative such as apexlog_get_summary for a high-level view. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v2.0.1analyze_apex_log_performanceapexlog_execute_anonymousapexlog_get_summaryapexlog_list_limit_risksapexlog_list_slow_operationsfind_performance_bottlenecksget_apex_log_summaryv1.0.0analyze_apex_log_performancefind_performance_bottlenecksget_apex_log_summaryScored across 4 tools
apexlog_execute_anonymous is clearly distinct as the only execution tool, and the three analysis tools are separated by focus (governor limits vs. time/heap ranking vs. overall summary). There is some genuine overlap since get_summary also reports time-by-category and per-namespace governor limits, which can shadow the two specialized list tools, but the descriptions explicitly frame one as a quick overview and the others as ranked deep-dives.
All four tools share the consistent 'apexlog_' namespace prefix and follow a clean verb_noun pattern (list_limit_risks, list_slow_operations, get_summary, execute_anonymous). The convention is predictable and readable across the whole set.
Four tools is a lean but mostly well-scoped surface for a focused Apex log analysis server, with each tool earning its place. It sits slightly on the thin side since a single execution tool feeds three analysis tools.
The server covers execution plus three angles of analysis, but there is no tool to retrieve or list existing debug logs already on the org, and no way to search/compare logs or run direct queries. Agents who need a log they did not just generate via execute_anonymous have no path, which is a notable gap.
The Polar Signals MCP server enables AI assistants to connect directly with performance profiling data, allowing users to analyze application performance through natural language queries. Key capabilities include querying CPU performance and memory usage, exploring profiling metadata like profile types and labels, and providing AI-driven code optimization suggestions directly within development environments like Claude Code or Cursor.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Analytics and debugging for your MCP server — explore usage and sessions, then root-cause errors.
Query application logs, traces, and metrics from your AI coding assistant via Foam's MCP server.
