このプロジェクトは、JavaScriptエラーのスタックトレースをソースコードにマッピングし、関連するコンテキスト情報を抽出できるWebAssemblyベースのソースマップパーサーを実装します。開発者はJavaScriptエラーのスタックトレースをソースコードに簡単にマッピングできるため、問題を迅速に特定して解決できます。このドキュメントは、開発者がこのツールをより深く理解し、活用するのに役立つことを目的としています。
注: Node.js 18+のサポートが必要です
オプション1: NPXで直接実行する
npx -y source-map-parser-mcp@latestオプション2: ビルド成果物をダウンロードする
GitHub リリースページから対応するバージョンのビルド成果物をダウンロードし、次のコマンドを実行します。
node dist/main.es.jsシステムランタイムパラメータは、さまざまなシナリオのニーズに合わせて環境変数を通じて柔軟に設定できます。
SOURCE_MAP_PARSER_RESOURCE_CACHE_MAX_SIZE : リソースキャッシュが占有する最大メモリ容量を設定します。デフォルトは200MBです。この値を適切に調整することで、パフォーマンスとメモリ使用量のバランスをとることができます。
SOURCE_MAP_PARSER_CONTEXT_OFFSET_LINE : エラー箇所の周囲に表示するコンテキストコード行数を定義します。デフォルトは1行です。この値を増やすと、より多くのコンテキスト情報が提供され、問題の診断が容易になります。
例：
# 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
スタック解析: 指定された行番号、列番号、ソース マップ ファイルに基づいて、対応するソース コードの場所を解析します。
バッチ処理: 複数のスタック トレースを同時に解析し、バッチ結果を返すことをサポートします。
コンテキスト抽出: 指定された行数のコンテキスト コードを抽出し、開発者がエラーが発生する環境をよりよく理解できるようにします。
operating_guideMCPサービスの利用手順をご確認いただけます。チャットでのやり取りを通じて、MCPサービスの利用方法に関する情報を提供します。
parse_stackスタック トレースとソース マップ アドレスを指定してスタック情報を解析します。
スタック: 行番号、列番号、ソース マップ アドレスなどのスタック情報。
line: 行番号、必須。
column: 列番号、必須。
sourceMapUrl: ソース マップ アドレス (必須)。
{
"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\"}}]"
}
]
}success : 解析が成功したかどうかを示します。
token : 解析が成功したときに返される Token オブジェクト。ソース コードの行番号、列番号、コンテキスト コードなどの情報が含まれます。
error : 解析が失敗したときに返されるエラー情報。
実際のニーズに応じて、システムプロンプトを使用して、モデルにスタック情報の解析方法を指示することができます。セキュリティやパフォーマンス上の理由から、ソースマップをブラウザに直接公開して解析するのではなく、ソースマップのアップロードパスを処理したいチームもあるかもしれません。例えば、パスbar-special.jsをspecial/bar.js.mapに変換する場合などです。このような場合、プロンプトルールを通じてモデルにパス変換を指示することができます。
次に例を示します。
# 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`エラースタック
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)
ツールが次のエラー メッセージを返す場合は、次のようにトラブルシューティングしてください。
パーサー初期化エラー: WebAssembly.instantiate(): 無効な値型 'externref'、--experimental-wasm-reftypes @+86 で有効にしてください
Node.jsのバージョンを確認：Node.jsのバージョンが18以上であることを確認してください。18未満の場合は、Node.jsをアップグレードしてください。
実験的フラグを有効にする: Node.js のバージョンが 18 以上であるにもかかわらず問題が発生する場合は、次のコマンドを使用してツールを起動します。
npx --node-arg=--experimental-wasm-reftypes -y source-map-parser-mcp@latestNode.js と npm がインストールされていることを確認してから、次のコマンドを実行してプロジェクトの依存関係をインストールします。
npm installMCP サーバーを起動するには、次のコマンドを実行します。
npx tsx src/main.tsstack_parser_js_sdk.js : WebAssembly モジュールの JavaScript ラッパー。コア スタック解析機能を提供します。
parser.ts : パーサーのメイン実装。WebAssembly モジュールの初期化、ソースマップ コンテンツの取得、スタック情報の解析を担当します。
server.ts : MCP サーバーの実装。外部呼び出し用のparse_stackツール インターフェイスを提供します。
解析ロジックを変更するには、 parser.tsファイル内のgetSourceTokenメソッドを編集します。
server.tsファイルでは、 server.toolメソッドを使用して新しいツール インターフェイスを追加できます。
ソース マップ ファイル: 指定されたソース マップ ファイルのアドレスにアクセス可能であり、ファイル形式が正しいことを確認します。
エラー処理: 解析中に、ネットワーク エラー、ファイル形式エラー、その他の問題が発生する可能性があります。呼び出しを行うときは適切なエラー処理を実装することをお勧めします。
このプロジェクトを改善するために、Issue および Pull Request による貢献を歓迎します。
このプロジェクトはMITライセンスの下で提供されています。詳細はLICENSEファイルをご覧ください。
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.
v1.0.0lookup_contextoperating_guideunpack_sourcesoperating_guideparse_stackScored across 3 tools
Each 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.
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
Production bugs with replay, network, console and stack, ranked for your coding agent to fix.
