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., "@sfcc-logs-mcp tail the latest error logs for the current SFCC instance"
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.
A production-grade Model Context Protocol (MCP) server that enables AI coding assistants (Claude Desktop, Cursor, Gemini, Claude Code, VS Code Copilot, Windsurf, etc.) to query, tail, search, analyze, and clean Salesforce Commerce Cloud (SFCC / Demandware) logs in real-time over standard I/O (stdio).
🔄 Context-Aware Dynamic Workspace Resolution: Automatically detects the active workspace folder sent during the MCP initialization handshake and walks up the directory tree to find dw.json or .env. Switch between client projects or sandbox environments seamlessly without restarting your MCP server or changing settings.
⚡ Bandwidth-Optimized Range Chunking: Uses HTTP Range headers (bytes=-1MB) over WebDAV to fetch only the trailing chunk of huge log files. Tail multi-gigabyte production logs in milliseconds with minimal bandwidth consumption.
🔍 Multi-File Search & Filtering: Perform case-insensitive regex/text searches across multiple log files filtered by log level (error, warn, info, debug) or target date (YYYYMMDD or today).
⏱️ SFCC Background Job Analytics: Dedicated toolset to inspect cron job logs (job-*), filter entries by severity, and parse step boundaries to construct visual execution timelines (RUNNING, OK, ERROR).
📊 Statistical Log Volume Summaries: Generate high-level audits breaking down active log volume, category distributions, file counts, and newest active files for any given date.
🧹 Log Sanitization: Clean or reset active log files directly from chat to isolate freshly reproduced bugs.
Related MCP server: Local Logs MCP Server
Install globally to make the sfcc-logs-mcp binary available everywhere in your PATH:
npm install -g sfcc-logs-mcpOnce installed globally, you can run:
sfcc-logs-mcp
# or shorthand alias
sfcc-logsnpx sfcc-logs-mcpThe server resolves credentials in the following order of priority:
dw.json (Standard SFCC Tooling Config)Place a dw.json file in your workspace root (or any parent directory):
{
"hostname": "your-sandbox.demandware.net",
"username": "your_webdav_username",
"password": "your_webdav_password",
"webdav_path": "/on/demandware.servlet/webdav/Sites/Logs"
}.env FileAlternatively, define credentials in a local .env file in your project folder:
SFCC_SERVER=your-sandbox.demandware.net
SFCC_USERNAME=your_webdav_username
SFCC_PASSWORD=your_webdav_password
SFCC_WEBDAV_PATH=/on/demandware.servlet/webdav/Sites/LogsSet system environment variables for static single-instance configurations:
DW_WEBDAV_USERNAME=your_webdav_username
DW_WEBDAV_PASSWORD=your_webdav_password
SFCC_SERVER=your-sandbox.demandware.netTool Name | Description | Arguments |
| List all available log files or return the last |
|
| Clean/reset an active log file by replacing it with a timestamped cleared marker. |
|
| Fetch the newest error logs for |
|
| Fetch the newest warning logs for |
|
| Fetch the newest info logs for |
|
| Fetch the newest debug logs for |
|
| Generate a statistical breakdown of log categories, file counts, and sizes. |
|
| Search across multiple log files matching level/date for a text pattern. |
|
| List background cron job log files ( |
|
| Filter background job logs strictly by Job ID/name (e.g. |
|
| Retrieve trailing log entries inside a job log, optionally filtered by severity. |
|
| Search for a text pattern strictly within background job logs. |
|
| Parses job step boundaries to return structured execution timeline & status ( |
|
Add to your claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"sfcc-logs": {
"command": "sfcc-logs-mcp"
}
}
}Add to .cursor/mcp.json in your workspace or global Cursor settings:
{
"mcpServers": {
"sfcc-logs": {
"command": "sfcc-logs-mcp"
}
}
}Configure the stdio server using the globally installed binary:
{
"mcpServers": {
"sfcc-logs": {
"command": "npx",
"args": ["-y", "sfcc-logs-mcp"]
}
}
}You can test and verify all tools interactively using the official @modelcontextprotocol/inspector:
# 1. Interactive Web UI
npx @modelcontextprotocol/inspector sfcc-logs-mcp
# 2. CLI Mode (List tools)
npx @modelcontextprotocol/inspector --cli sfcc-logs-mcp --method tools/list
# 3. CLI Mode (Call a tool)
npx @modelcontextprotocol/inspector --cli sfcc-logs-mcp --method tools/call --tool-name get_latest_error
# 4. Interactive Terminal UI (TUI)
npx @modelcontextprotocol/inspector --tui sfcc-logs-mcp# Clone the repository
git clone https://github.com/nabhat/sfcc-logs-mcp.git
cd sfcc-logs-mcp
# Install dependencies
npm install
# Run unit tests with Vitest & coverage
npm run test
# Lint the codebase
npm run lint
# Compile TypeScript
npm run buildThis project is licensed under the MIT License - see the LICENSE.txt file for details.
Clean/reset a specific SFCC log file by overwriting it with a clean message.
| Name | Required | Description | Default |
|---|---|---|---|
| logFileName | Yes | The exact name of the log file to clean.Required. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states the destructive act of overwriting the file, which is good. However, it lacks details on reversibility, permissions needed, or what happens if the file does not exist. Adequate but not comprehensive.
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?
Single sentence, highly concise, and front-loaded with the key action. Every word earns its place.
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 simple tool with 1 parameter and no output schema, the description covers the essential behavior. It lacks usage guidelines but is otherwise complete. The return value is implied (clean message in file), but the tool's simplicity makes this acceptable.
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 coverage is 100% for the single parameter, and the schema description already specifies it is the exact file name and required. The description adds context about the overall action but no additional nuance for the parameter itself. Baseline 3 is appropriate.
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 clearly states the action (clean/reset), the resource (SFCC log file), and the mechanism (overwrite with a clean message). It is specific and distinguishes from sibling tools like get_latest_error or search_logs, which are read-only.
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 guidance on when to use this tool versus alternatives. Does not mention when not to use, prerequisites (e.g., needing file name), or potential side effects. This leaves the agent to guess context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parses standard SFCC job steps boundries inside the newest job log file, returning a structured steps executioin audit timeline and step statuses (OK/ERROR/RUNNING).
| Name | Required | Description | Default |
|---|---|---|---|
| jobName | No | The optional Job ID/name to target. If omitted, targets the newest active job log. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that it targets the 'newest job log file' and returns a timeline, but does not mention read-only nature, side effects, permissions, or what happens if no log exists. Lacks behavioral context.
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?
Single sentence, but contains typos ('boundries', 'executioin'). Could be more concise and error-free.
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?
No output schema, but description mentions return type (structured timeline and statuses). Lacks detail on format or what 'structured' means. Adequate for a simple tool but could be more informative.
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 coverage is 100% with description of 'jobName' parameter. Description adds value by explaining default behavior (targets newest active log if omitted), which is not obvious from schema alone.
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?
Description clearly states it parses job steps from the newest SFCC job log file and returns a structured timeline with statuses. Verb 'parses' and resource 'job steps' are specific, but does not differentiate from sibling tools like 'search_job_logs' or 'get_job_log_entries'.
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 guidance on when to use this tool vs alternatives. Sibling tools are listed but no explicit instructions on when to prefer this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve trailing log entries inside a specific job log, optionally filtered by severity.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | Optional log level filter (ERROR, WARN, INFO, DEBUG, or "all"). Defaults to "all". | all |
| limit | No | Maximum trailing lines to retrieve. Defaults to 10. | |
| jobName | No | The optional Job ID/name to target. If omitted, targets the newest active job log. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions 'trailing' but does not clarify ordering (chronological?), the starting point from the end of the log, or pagination behavior. It also doesn't explicitly state that omitting jobName targets the newest active job log (this detail is only in the parameter schema). No annotations are present to supplement.
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?
Single sentence that is front-loaded with the core action and resource. Every word contributes meaning; no filler or redundancy.
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?
Given the tool's simplicity (3 optional params, no output schema), the description provides adequate core functionality but lacks context about result ordering and how to differentiate from sibling tools like search_job_logs or get_latest_error. Could be more complete for disambiguation.
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 the baseline is 3. The description adds the notion of 'filtered by severity' which aligns with the level parameter but does not add substantial meaning beyond the schema. The 'trailing' aspect is partially reflected in the limit parameter description.
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 clearly states the verb 'retrieve' and resource 'trailing log entries inside a specific job log', with optional filtering by severity. It distinguishes from siblings like search_job_logs (which likely searches more broadly) and get_latest_error (which returns a single entry).
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 guidance on when to use this tool versus alternatives such as search_job_logs for cross-log search or get_latest_error for a single error. The description does not specify prerequisites or contexts where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the latest Debug logs from the active appserver.Tails the newest debug log file.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Target date string (e.g. "YYYYMMDD" or "today"). Defaults to "today". | today |
| limit | No | The maximum trailing lines to retrieve. Defaults to 10. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read operation ('retrieve', 'tails') but lacks details on side effects, permissions, or whether it is a one-time fetch or streaming. With no annotations, the description carries full burden and is only moderately transparent.
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?
The description is two sentences and mostly efficient, though a minor typo ('appserver.Tails') slightly reduces clarity. Overall, it is appropriately sized and front-loaded.
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?
The description covers the basic purpose but lacks details on output format, pagination, or error scenarios. Given the tool's simplicity and absence of an output schema, it is minimally adequate but not fully complete.
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 coverage is 100%, so parameters are well-documented in the schema. The description adds no additional meaning beyond what the schema provides, meeting the baseline of 3.
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 clearly states it retrieves Debug logs from the active appserver, specifying both verb and resource. However, it does not explicitly differentiate from siblings like get_latest_error or get_latest_warn, relying on naming convention.
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 guidance on when to use this tool vs alternatives. The description fails to mention when not to use it or provide context about log levels or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the latest Error logs from the active appserver.Tails the newest error log file.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Target date string(e.g. "YYYYMMDD" or "today"). Defaults to "today". | today |
| limit | No | The maximum trailing lines to retrieve. Defaults to 10. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose all behavioral traits. It indicates the tool is a read-only operation that tails a log file, but it does not mention whether it is non-destructive, what the 'active appserver' is, or any potential rate limits or performance impacts. It is adequate but lacks depth.
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?
The description consists of two concise sentences with no redundancy. It is efficient, though it could be slightly more structured or front-loaded with the main action.
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?
Given the tool's simplicity (two optional parameters, no output schema, no nested objects), the description provides minimal but adequate context. However, it does not explain the return format or clarify what 'active appserver' means, leaving some ambiguity.
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 parameter descriptions in the schema already provide defaults and format hints. The tool description adds no additional meaning beyond what the schema offers.
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 clearly states the verb 'Retrieve' and the resource 'latest Error logs from the active appserver', and adds 'tails the newest error log file' to specify the operation. However, it does not explicitly distinguish from sibling tools like get_latest_warn or get_latest_info, though the name provides some differentiation.
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 description offers no guidance on when to use this tool versus alternatives such as search_logs or get_latest_debug. No exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the latest Info logs from the active appserver.Tails the newest info log file.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Target date string (e.g. "YYYYMMDD" or "today"). Defaults to "today". | today |
| limit | No | The maximum trailing lines to retrieve. Defaults to 10. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present. The description states 'tails the newest info log file,' which implies a non-destructive read operation, but it does not disclose whether any side effects, authentication requirements, or rate limits exist. For a log retrieval tool, this is minimally adequate.
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?
The description is two sentences, but the second is a fragment ('Tails the newest info log file.'). It is fairly concise, though the information could be combined into one clear sentence without losing meaning.
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?
Given no output schema and simple parameters, the description covers the essential behavior: retrieving latest Info logs by tailing from a specific date. It omits details about the return format but is likely sufficient for a straightforward log retrieval tool.
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?
The input schema has 100% coverage with descriptions for both parameters. The description adds only that the tool 'tails' the log file, which is already implied by the 'trailing lines' term in the schema. Thus, the description provides little additive meaning beyond the schema.
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 clearly states 'Retrieve the latest Info logs from the active appserver' and 'Tails the newest info log file', specifying the log level and source. This distinguishes it from sibling tools like get_latest_error, get_latest_warn, and get_latest_debug which handle different log levels.
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?
Usage is implied by the name and description (for Info-level logs), but there is no explicit guidance on when to use this tool versus alternatives. No exclusions or context-specific advice are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists active background cron job log files (starting with job- prefix) newest first.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum job files to list. Defaults to 10. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions listing active logs and ordering, but fails to define 'active', specify if results include running/completed jobs, or mention any side effects or required permissions.
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?
The description is a single concise sentence that front-loads the key action. It is efficient but could benefit from a brief note on usage or return format without being verbose.
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 simple list tool with one parameter, the description is mostly adequate, but missing details about output format (what fields are returned) and clarification of 'active background cron job' leaves some ambiguity.
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?
The schema covers the limit parameter 100%. The description does not add extra meaning beyond the schema, but since coverage is complete, a baseline of 3 is appropriate.
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 clearly states it lists active background cron job log files with a specific prefix ('job-') ordered newest first, which distinguishes it from siblings like search_job_logs or get_job_log_entries.
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 guidance is provided on when to use this tool versus the many siblings (e.g., search_job_logs, get_job_log_entries). The description implies it's for a quick list but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the latest Warning logs from the active appserver.Tails the newest warn log file.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Target date string (e.g. "YYYYMMDD" or "today"). Defaults to "today". | today |
| limit | No | The maximum trailing lines to retrieve. Defaults to 10. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states 'Tails the newest warn log file', implying a read-only operation, but does not mention potential issues like missing files, rate limits, or side effects. This is insufficient for a tool with no annotations.
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?
The description is two sentences with no unnecessary words. However, there is a missing space between 'appserver.Tails' which slightly harms readability.
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?
Given the simple parameters and no output schema, the description is minimal but covers the basic purpose. It lacks information on return format, error handling, or behavior when no logs exist, which would improve completeness.
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?
The input schema has 100% description coverage for its two parameters, so the description does not need to add meaning. It adds no additional context beyond the schema, meeting the baseline.
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?
Description clearly states the tool retrieves the latest Warning logs, using specific verbs ('Retrieve', 'Tails') and identifies the resource ('Warning logs'). This distinguishes it from siblings like get_latest_error or get_latest_info.
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 usage context is implied by the tool name and siblings (different log levels), but the description lacks explicit guidance on when to use this tool versus alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get SFCC last Log file records. If logFileName is not provided list all available log files. If provided, return the last "count" lines from the file.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | The number of last log lines/records to retrieve.Defaults to 10. | |
| logFileName | No | The name of the log file to retrieve. Keep empty get the list of all log files. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses the conditional behavior (list vs. retrieve) but does not mention that the tool is read-only or any potential side effects. For a simple read tool, this is adequate but not exceptional.
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?
Two sentences, front-loaded with the main action, and no unnecessary words. Every sentence earns its place.
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?
Given the tool's simplicity (2 params, no output schema), the description covers the core behavior. It does not specify the return format (e.g., text lines or JSON), but this is minor and acceptable for a straightforward tool.
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 coverage is 100%, providing baseline of 3. The description adds value by explaining how logFileName toggles between modes and clarifying that count retrieves the last N lines, which goes beyond the schema's simple descriptions.
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 clearly states the tool retrieves SFCC log file records and explains the two distinct behaviors based on whether logFileName is provided. This distinguishes it from siblings focused on specific log levels or search functionality.
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 description implies usage for listing files or retrieving last lines, but it does not explicitly compare to sibling tools or state when not to use this tool. No guidance on prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches for a text pattern strictly inside background job logs.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | Optional log level filter (ERROR, WARN, INFO, DEBUG, or "all"). Defaults to "all". | all |
| limit | No | Maximum matching lines to return. Defaults to 20. | |
| jobName | No | Optional Job ID/name to target. | |
| pattern | Yes | The text pattern to search for (case-insensitive). Required. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It states the search is 'strictly inside background job logs' but does not explain case-insensitivity (though schema says it), return format, pagination, error behavior, or whether it searches multiple files. This minimal transparency forces the agent to rely on assumptions.
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?
The description is a single sentence that is front-loaded with the key action and scope. Every word earns its place, with no redundancy or filler. It is as concise as possible while conveying the core purpose.
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?
Given the lack of output schema and 4 parameters, the description is insufficient. It does not explain what the tool returns (e.g., matching lines, metadata), how 'text pattern' is interpreted (exact, regex?), or how the strict scoping interacts with background job logs. Among many sibling tools, this lack of completeness hampers effective selection and 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 coverage is 100% with each parameter having a description. The description adds no additional parameter semantics beyond what is already in the schema. Baseline 3 is appropriate as the description does not compensate for any gaps, but the schema is self-sufficient.
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 clearly states it searches for a text pattern inside background job logs, with the word 'strictly' emphasizing scope. It distinguishes itself from sibling tools like search_logs (broader) and search_job_logs_by_name (by name) by focusing on pattern search, but could be more explicit about the context of background job logs.
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 description provides no guidance on when to use this tool versus alternatives like search_logs, get_job_log_entries, or search_job_logs_by_name. An agent would have to infer usage from the name and description alone, leading to potential confusion among many log-related sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Filters background job logs strictly by a specific job ID/name (e.g. (CatalogImport).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum job files to list. Defaults to 10. | |
| jobName | Yes | The exact or partial Job ID to search. Required. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only says 'filters' with no disclosure of behavioral traits such as read-only, pagination, or whether it returns latest logs. Full burden on description, which is insufficient.
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?
Single sentence, front-loaded with verb, no wasted words. Could be slightly more structured but overall efficient.
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 high schema coverage, no output schema, and a simple purpose, the description lacks details on return format, limit behavior, or default value. Leaves gaps for an agent.
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 coverage is 100% with descriptions for both parameters. Description adds an example '(CatalogImport)' but does not significantly enhance meaning beyond the schema.
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?
Description clearly states 'Filters background job logs strictly by a specific job ID/name', using a specific verb and resource, and distinguishes from sibling tools like search_job_logs which likely have broader scope.
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?
Implies use case (filtering by job name) but does not explicitly state when to use or not use this tool versus alternatives like search_job_logs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches across multiple log files matching logLevel/date for a specific text pattern.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Target date string (e.g. "YYYYMMDD" or "today"). Defaults to "today". | today |
| limit | No | Maximum matching lines to return. Defaults to 20. | |
| pattern | Yes | The text pattern to search for (case-insensitive). Required. | |
| loglevel | No | Optional log level to restrict search (error, warn, info, debug, or "all"). | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It mentions searching across files but does not describe what is returned (e.g., lines, metadata), side effects, or performance implications. Minimal beyond purpose.
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 sentence of 13 words, no wasted text. Front-loads verb 'Searches' and key constraints.
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 should hint at the return value or structure. It does not. Also no mention of read-only nature, pagination, or scope (e.g., which log files). Incomplete given sibling complexity.
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 covers all 4 parameters with descriptions (100% coverage). The description repeats 'logLevel/date' but adds no new semantics 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?
The description clearly states the tool searches across multiple log files with constraints on logLevel and date for a text pattern. It distinguishes from siblings like 'search_job_logs' by being general rather than job-specific, but could be more explicit.
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 guidance on when to use this tool versus alternatives like 'search_job_logs' or 'get_latest_error'. Missing when-not or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a statistical audit overview of all log files generated on a specific date (clutter categories, active volume, newest active items).
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Target date string (e.g. "YYYYMMDD" or "today"). Defaults to "today". | today |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention if the operation is read-only, safe, or has any side effects. The description focuses on output content but lacks transparency on behavior beyond what is stated.
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?
The description is a single sentence, front-loaded, and concise. It wastes no words but could benefit from a bit more detail without becoming verbose. However, it is efficient for its purpose.
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, and the description does not explain the return structure or format of the statistical overview. Given the lack of annotations and output schema, the description should provide more context about what the agent will receive, such as whether it's a JSON object or a list.
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 coverage is 100% with the 'date' parameter already described well. The description repeats 'on a specific date' but adds no significant additional meaning beyond the schema. Baseline of 3 is appropriate.
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 clearly states the tool retrieves a statistical audit overview of log files for a specific date, listing specific categories. It distinguishes itself from sibling tools (e.g., search_logs, get_latest_error) by focusing on a summary rather than individual logs.
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 description implies using this tool when a statistical summary for a date is needed, but it does not explicitly specify when to use alternatives or provide 'when not' guidance. The context of siblings suggests this is for overview, but explicit guidance is missing.
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.
v1.0.0clean_sfcc_logfileget_job_execution_summaryget_job_log_entriesget_latest_debugget_latest_errorget_latest_infoget_latest_job_log_filesget_latest_warnget_sfcc_logfilesearch_job_logssearch_job_logs_by_namesearch_logssummarize_logsScored across 13 tools
Each tool targets a distinct log operation or type (error, warn, info, debug, job, general). Descriptions clearly differentiate overlapping aspects like search_job_logs vs search_logs.
All tools follow a verb_noun pattern with consistent use of get_, search_, clean_, summarize_. No mixing of conventions.
13 tools is well-scoped for a log management server, covering reading by severity, searching, summarizing, clearing, and job-specific operations without excess.
The toolset covers all major log operations: retrieval by severity, search, summary, file listing, clearing, and job log details. No obvious gaps for the domain.
Plan Salesforce deploys, open pull requests and trigger pipelines from your AI client.
Query application logs, traces, and metrics from your AI coding assistant via Foam's MCP server.
Cross-agent artifact workspace with provenance across Claude Code, Codex, Cursor, LangGraph.
Structured knowledge base for AI agent solutions. Search, explore, and retrieve build logs.
