The Source Map Parser MCP Server maps JavaScript error stack traces to source code locations using WebAssembly for debugging. With this server, you can:
Parse individual or batch error stack traces from minified/obfuscated code
Map traces to original source code by providing line numbers, column numbers, and Source Map URLs
Extract context lines around error locations for better debugging insight
Configure runtime parameters like cache size and context line offset
Get usage instructions for the MCP service
Parses JavaScript error stack traces using Source Maps to map them back to the original source code, providing context information and line details to help developers locate and fix issues.
Implements WebAssembly-based Source Map parsing to efficiently process JavaScript stack traces and extract relevant context information from source code.
Click on "Install 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., "@Source Map Parser MCP Server parse this stack trace and show me the original source code"
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.
This project implements a WebAssembly-based Source Map parser that can map JavaScript error stack traces back to source code and extract relevant context information. Developers can easily map JavaScript error stack traces back to source code for quick problem identification and resolution. This documentation aims to help developers better understand and use this tool.
Note: Requires Node.js 20+ support
Option 1: Run directly with NPX
npx -y source-map-parser-mcp@latestOption 2: Download the build artifacts
Download the corresponding version of the build artifacts from the GitHub Release page, then run:
node dist/main.es.jsYou can embed the tools into your own MCP server process and customize behavior.
Install:
npm install source-map-parser-mcpMinimal server (TypeScript):
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
import {
registerTools,
Parser,
type ToolsRegistryOptions,
} from 'source-map-parser-mcp';
const server = new McpServer(
{ name: 'your-org.source-map-parser', version: '0.0.1' },
{ capabilities: { tools: {} } }
);
// Optional: control context lines via env
const options: ToolsRegistryOptions = {
contextOffsetLine:
Number(process.env.SOURCE_MAP_PARSER_CONTEXT_OFFSET_LINE) || 1,
};
registerTools(server, options);
// Start as stdio server
const transport = new StdioServerTransport();
await server.connect(transport);
// If you need programmatic parsing without MCP:
const parser = new Parser({ contextOffsetLine: 1 });
// await parser.parseStack({ line: 10, column: 5, sourceMapUrl: 'https://...' });
// await parser.batchParseStack([{ line, column, sourceMapUrl }]);This project ships both ESM and CJS builds and a single bundled TypeScript declaration file.
Build outputs:
ESM: dist/index.es.js
CJS: dist/index.cjs.js
CLI entry: dist/main.es.js
Types: dist/index.d.ts (single bundled d.ts)
Quick build locally:
npm install
npm run buildUsing types in your project:
import {
Parser,
registerTools,
type ToolsRegistryOptions,
} from 'source-map-parser-mcp';System runtime parameters can be flexibly configured through environment variables to meet the needs of different scenarios
SOURCE_MAP_PARSER_RESOURCE_CACHE_MAX_SIZE: Sets the maximum memory space occupied by resource cache, default is 200MB. Adjusting this value appropriately can balance performance and memory usage.
SOURCE_MAP_PARSER_CONTEXT_OFFSET_LINE: Defines the number of context code lines to display around the error location, default is 1 line. Increasing this value provides more context information, facilitating problem diagnosis.
Example:
# Set 500MB cache and display 3 lines of context
export SOURCE_MAP_PARSER_RESOURCE_CACHE_MAX_SIZE=500
export SOURCE_MAP_PARSER_CONTEXT_OFFSET_LINE=3
npx -y source-map-parser-mcp@latestRelated MCP server: Error Debugging MCP Server
Stack Parsing: Parse the corresponding source code location based on provided line number, column number, and Source Map file.
Batch Processing: Support parsing multiple stack traces simultaneously and return batch results.
Context Extraction: Extract context code for a specified number of lines to help developers better understand the environment where errors occur.
Context Lookup: Look up original source code context for specific compiled code positions.
Source Unpacking: Extract all source files and their content from source maps.
operating_guideGet usage instructions for the MCP service. Provides information on how to use the MCP service through chat interaction.
parse_stackParse stack information by providing stack traces and Source Map addresses.
stacks: Stack information including line number, column number, and Source Map address.
line: Line number, required.
column: Column number, required.
sourceMapUrl: Source Map address, required.
{
"stacks": [
{
"line": 10,
"column": 5,
"sourceMapUrl": "https://example.com/source.map"
}
]
}{
"content": [
{
"type": "text",
"text": "[{\"success\":true,\"token\":{\"line\":10,\"column\":5,\"sourceCode\":[{\"line\":8,\"isStackLine\":false,\"raw\":\"function foo() {\"},{\"line\":9,\"isStackLine\":false,\"raw\":\" console.log('bar');\"},{\"line\":10,\"isStackLine\":true,\"raw\":\" throw new Error('test');\"},{\"line\":11,\"isStackLine\":false,\"raw\":\"}\"}],\"src\":\"index.js\"}}]"
}
]
}lookup_contextLook up original source code context for a specific line and column position in compiled/minified code.
line: The line number in the compiled code (1-based), required.
column: The column number in the compiled code, required.
sourceMapUrl: The URL of the source map file, required.
contextLines: Number of context lines to include (default: 5), optional.
{
"line": 42,
"column": 15,
"sourceMapUrl": "https://example.com/app.js.map",
"contextLines": 5
}{
"content": [
{
"type": "text",
"text": "{\"filePath\":\"src/utils.js\",\"targetLine\":25,\"contextLines\":[{\"lineNumber\":23,\"content\":\"function calculateSum(a, b) {\"},{\"lineNumber\":24,\"content\":\" if (a < 0 || b < 0) {\"},{\"lineNumber\":25,\"content\":\" throw new Error('Negative numbers not allowed');\"},{\"lineNumber\":26,\"content\":\" }\"},{\"lineNumber\":27,\"content\":\" return a + b;\"}]}"
}
]
}unpack_sourcesExtract all source files and their content from a source map.
sourceMapUrl: The URL of the source map file to unpack, required.
{
"sourceMapUrl": "https://example.com/bundle.js.map"
}{
"content": [
{
"type": "text",
"text": "{\"sources\":{\"src/index.js\":\"import { utils } from './utils.js';\\nconsole.log('Hello World!');\",\"src/utils.js\":\"export const utils = { add: (a, b) => a + b };\"},\"sourceRoot\":\"/\",\"file\":\"bundle.js\",\"totalSources\":2}"
}
]
}success: Indicates whether the parsing was successful.
token: The Token object returned when parsing is successful, containing source code line number, column number, context code, and other information.
error: Error information returned when parsing fails.
According to actual needs, you can use system prompts to guide the model on how to parse stack information. For security or performance reasons, some teams may not want to expose Source Maps directly to the browser for parsing, but instead process the upload path of the Source Map. For example, converting the path bar-special.js to special/bar.js.map. In this case, you can instruct the model to perform path conversion through prompt rules.
Here is an example:
# Error Stack Trace Parsing Rules
When performing source map parsing, please follow these rules:
1. If the URL contains `special`, the file should be parsed into the `special/` directory, while removing `-special` from the filename.
2. All source map files are stored in the following CDN directory:
`https://cdn.jsdelivr.net/gh/MasonChow/source-map-parser-mcp@main/example/`
## Examples
- Source map address for `bar-special.js`:
`https://cdn.jsdelivr.net/gh/MasonChow/source-map-parser-mcp@main/example/special/bar.js.map`Error Stack
Uncaught Error: This is a error
at foo-special.js:49:34832
at ka (foo-special.js:48:83322)
at Vs (foo-special.js:48:98013)
at Et (foo-special.js:48:97897)
at Vs (foo-special.js:48:98749)
at Et (foo-special.js:48:97897)
at Vs (foo-special.js:48:98059)
at sv (foo-special.js:48:110550)
at foo-special.js:48:107925
at MessagePort.Ot (foo-special.js:25:1635)
If the tool returns the following error message, please troubleshoot as follows:
parser init error: WebAssembly.instantiate(): invalid value type 'externref', enable with --experimental-wasm-reftypes @+86
Check Node.js Version: Ensure Node.js version is 20 or higher. If it's lower than 20, please upgrade Node.js.
Enable Experimental Flag: If Node.js version is 20+ but you still encounter issues, use the following command to start the tool:
npx --node-arg=--experimental-wasm-reftypes -y source-map-parser-mcp@latestEnsure Node.js and npm are installed, then run the following command to install project dependencies:
npm installRun the following command to start the MCP server:
npx tsx src/main.tsstack_parser_js_sdk.js: JavaScript wrapper for the WebAssembly module, providing core stack parsing functionality.
parser.ts: Main implementation of the parser, responsible for initializing the WebAssembly module, retrieving Source Map content, and parsing stack information.
server.ts: Implementation of the MCP server, providing the parse_stack tool interface for external calls.
To modify the parsing logic, edit the getSourceToken method in the parser.ts file.
In the server.ts file, new tool interfaces can be added using the server.tool method.
Source Map Files: Ensure that the provided Source Map file address is accessible and the file format is correct.
Error Handling: During parsing, network errors, file format errors, and other issues may be encountered; it's recommended to implement proper error handling when making calls.
Contributions via Issues and Pull Requests are welcome to improve this project.
This project is licensed under the MIT License. See the LICENSE file for details.
This tool looks up original source code context for a specific line and column position in compiled/minified code.
line: The line number in the compiled code (1-based)
column: The column number in the compiled code
sourceMapUrl: The URL of the source map file
contextLines (optional): Number of context lines to include before and after the target line (default: 5)
A JSON object containing the source code context snippet with file path, target line info, and surrounding context lines
Returns null if the position cannot be mapped
| Name | Required | Description | Default |
|---|---|---|---|
| line | Yes | The line number in the compiled code (1-based) | |
| column | Yes | The column number in the compiled code | |
| sourceMapUrl | Yes | The URL of the source map file | |
| contextLines | No | Number of context lines to include (default: 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It mentions the return value includes a JSON object or null if unmappable, but does not disclose side effects, authentication needs, or error handling behavior for invalid input or network issues.
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 concise, well-structured with markdown headings and a clear list of parameters. Every sentence adds value, though the parameter descriptions could be omitted since they duplicate the schema.
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 lookup tool without output schema, the description adequately covers purpose, parameters, and return behavior including null case. It lacks error scenarios and relation to sibling tools, but is sufficient for basic usage.
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 parameter descriptions. The tool description largely repeats those descriptions but adds the default value for contextLines and includes a Returns section not present in the schema. It adds minimal new 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 the tool looks up original source code context for a specific line and column in compiled code. It identifies the exact action and resource, and implicitly distinguishes from siblings like parse_stack and unpack_sources through its unique focus on source map lookups.
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 its siblings (parse_stack, unpack_sources). It doesn't mention any context or prerequisites, leaving the agent without clear decision criteria for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This tool allows you to parse error stack traces by providing the following:
A downloadable source map URL.
The line and column numbers from the stack trace.
The tool will map the provided stack trace information to the corresponding source code location using the source map. It also supports fetching additional context lines around the error location for better debugging.
stacks: An array of stack trace objects, each containing:
line: The line number in the stack trace.
column: The column number in the stack trace.
sourceMapUrl: The URL of the source map file corresponding to the stack trace.
ctxOffset (optional): The number of additional context lines to include before and after the error location in the source code. Defaults to 5.
A JSON object containing the parsed stack trace information, including the mapped source code location and context lines.
If parsing fails, an error message will be returned for the corresponding stack trace.
| Name | Required | Description | Default |
|---|---|---|---|
| stacks | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the return format and error handling, but does not disclose any behavioral traits like side effects, rate limits, or authentication requirements. The description is adequate but not rich.
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 well-structured with a header, explanation, parameter list, and return section. It is somewhat verbose but each part contributes to clarity. It is front-loaded with the purpose, making it easy to scan.
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 annotations and output schema, the description covers the tool's purpose, parameters, return values, and error behavior. It is missing explicit usage guidelines and a note on sibling differentiation, but overall provides sufficient context for an agent to use the tool effectively.
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 provides descriptions for all three fields in stacks, giving high coverage. The description adds value by explaining the optional 'ctxOffset' parameter and its default, which is not present in the schema. This enriches understanding beyond the 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?
The description clearly states the tool parses error stack traces using source maps to map to source code locations. It is specific and distinct from the sibling tools 'lookup_context' and 'unpack_sources', but does not explicitly differentiate itself.
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 explains what the tool does and its parameters, but it does not provide explicit guidance on when to use this tool versus the siblings or what prerequisites are needed. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This tool extracts all source files and their content from a source map.
sourceMapUrl: The URL of the source map file to unpack
A JSON object containing:
sources: Object with source file paths as keys and their content as values
sourceRoot: The source root path from the source map
file: The original file name
totalSources: Total number of source files found
| Name | Required | Description | Default |
|---|---|---|---|
| sourceMapUrl | Yes | The URL of the source map file to unpack |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains the output format (JSON with sources, sourceRoot, etc.) but does not mention side effects, permissions, error handling, or rate limits. For a read-only tool, this is adequate but minimal.
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?
Very concise: one heading, a brief description, and a bulleted return list. Every sentence adds value. Information is front-loaded and well-organized.
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, the description fully explains the return format. The single parameter is described. The tool is simple and the description is complete for an agent to understand and invoke it correctly.
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 one parameter, and the description restates 'sourceMapUrl' but adds no extra meaning beyond the schema. However, it does detail the return structure, which adds context. 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 it extracts all source files and content from a source map, using specific verb 'extract' and resource 'source map sources'. It distinguishes from siblings like 'lookup_context' and 'parse_stack' by focusing on source map unpacking.
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. Description lacks context about prerequisites, limitations, or when not to use it. Sibling tools are not compared.
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. Dates show when Glama detected each change.
v1.0.0lookup_contextoperating_guideunpack_sourcesoperating_guideparse_stackEach tool has a clear, distinct purpose: lookup_context maps a single position to source context, parse_stack processes multiple stack entries, and unpack_sources extracts all source files. There is no overlap or ambiguity between them.
All tool names follow a consistent verb_noun pattern in snake_case: lookup_context, parse_stack, unpack_sources. The naming is predictable and easy to understand.
With 3 tools, the server is focused and each tool serves a core need in source map parsing. While the count is small, it is appropriate for the domain; adding a validation or metadata tool could be beneficial but not necessary.
The toolset covers the primary tasks: single position mapping, stack trace parsing, and source extraction. Minor gaps exist (e.g., no direct source map metadata or validation), but the core functionality is well-covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Session replays, JS errors, funnel drop-offs and revenue-loss diagnostics.
Investigate errors, track deployments, analyze performance, and manage application monitoring
Track errors, manage performance alerts, and configure dashboards and monitors
Deterministic context layer for your codebase: change impact, blast radius, answers with receipts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/MasonChow/source-map-parser-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
