Parses Node/V8 and browser stack traces: at fn (file:line:col), at async, eval at, [cause] chains, AggregateError [errors] lists and error properties such as code: 'ENOENT'. Minified frames are flagged as unmappable; node_modules frames are marked as library code.
Part of the JVM parser: handles Exception in thread, Caused by:, Suppressed: chains and ... N more elision by reconstructing the elided frames from the enclosing trace, plus module prefixes (java.base/, app//) and logback ~[jar:ver] suffixes, with JDK/framework frames separated from application frames.
Parses .NET stack traces: at Ns.Class.Method() in file:line N, ---> inner exceptions, AggregateException inner exception lists and async state-machine frames, resolving the root cause and the innermost application frame.
Parses Python 3.8–3.13 tracebacks: __cause__/__context__ chains and ExceptionGroup/TaskGroup trees (reduced to a single root cause), ^^^^/~~~~ caret ranges, SyntaxError caret lines, [Previous line repeated N more times] and add_note() lines. Frames are classified as application code vs. site-packages vs. stdlib so the innermost frame that is actually the user's is highlighted.
Parses Rust panics in both the classic and the 1.73+ message layout, and RUST_BACKTRACE short and full forms; std/core frames and cargo registry frames are marked as library so the user's own crate frames stand out.
Part of the JVM parser: handles Caused by:/Suppressed: chains and ... N more elision reconstruction, Native Method frames, module prefixes and framework classes, identifying the root cause and the innermost application frame.
Recognizes Vite dev-server URLs in browser stack traces so bundled frames can be matched back onto files under the configured project directory.
Recognizes [webpack](/mcp/servers/integrations/webpack)-internal URLs produced by bundled front-end stack traces and resolves them against the project checkout where possible; minified frames are flagged and cannot be mapped without a source map.
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., "@stacktrace-mcp What's the root cause of this traceback, and which file of mine is at fault?"
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.
Paste a crash. Get the root cause, the line of your code that matters, and a hash that tells you whether you have seen it before.
stacktrace-mcp is an MCP server that turns raw crash output (Python, Node/V8, Java/Kotlin, Go, Rust, .NET) into a compact, correct report, and maps it onto the code in your project.
Existing MCP servers in this space are either narrow or lossy: a paid hosted "log fingerprint" service (Apify Log Fingerprint & Triage), regex-based log analysers that read three languages (log-analyzer-mcp), or crash-dump tooling tied to WinDbg (mcp-windbg). What this one does differently:
Six hand-written parsers, one model. Python chains and ExceptionGroup trees, Node [cause] /
AggregateError, Java Caused by: with ... N more reconstructed, Go goroutine dumps and race
reports, Rust RUST_BACKTRACE, .NET inner exceptions. Every trace gets a root cause, not just a
first line.
Application vs library frames per language (site-packages, node_modules, JDK/framework packages, Go module cache, rustc std, .NET framework), so the innermost frame that is yours is highlighted.
Maps frames onto your checkout even when the trace came from a container (/app/src/x.py vs
./src/x.py), a Windows box, or a webpack bundle, with strict directory-sandbox protection.
Honest about bad input: truncated or garbled traces are parsed as far as possible and flagged PARTIAL with a reason.
Local, free, zero dependencies beyond mcp, linear-time parsing, and every output is
redacted (secrets, emails, IPs, home-directory user names) by default.
Related MCP server: ticket-forge
Needs uv. Nothing to clone.
Claude Code
claude mcp add stacktrace -- uvx stacktrace-mcp --dir .Claude Desktop (claude_desktop_config.json)
{
"mcpServers": {
"stacktrace": {
"command": "uvx",
"args": ["stacktrace-mcp", "--dir", "C:\\path\\to\\your\\project"]
}
}
}--dir is the sandbox for map_to_code and find_traces_in_file (repeat it for several
directories). Without it, the pure-text tools (parse_trace, fingerprint, compare_traces,
explain_exception, redact_trace) still work.
"Here is the crash from CI: (paste). What is the root cause and which of my files is responsible?"
"Map this production traceback onto my repo and show me the offending lines."
"Scan logs/app.log and group every stack trace by fingerprint. Which bug happens most, and when did it first appear?"
"Are these two tracebacks the same bug?"
"What does ECONNREFUSED usually mean, and what do I check first?"
"Redact this trace so I can paste it into a ticket."
Tool | What it does |
| Auto-detects the language; returns exception chain with the root cause, frames classified app/library/stdlib/framework/runtime, innermost application frame, fingerprint, PARTIAL notes. |
| Streams a big log (cap 256 MB), finds every trace among normal lines, groups by fingerprint with counts and first/last seen. |
| Stable hash over language + exception types + innermost application frames. Ignores messages, addresses, ids, path prefixes, generated class names and (by default) line numbers. Shows its components. |
| Resolves frames to files under |
| SAME / LIKELY SAME / POSSIBLY related / DIFFERENT with a per-frame diff. |
| About 80 common exceptions: meaning, three most common causes, what to check first. |
| Removes tokens, passwords, JWTs, emails, IPs and home-directory user names. |
All tools except explain_exception take redact (default true).
Python: 3.8-3.13 tracebacks including ^^^^/~~~~ caret ranges, __cause__/__context__
chains, ExceptionGroup/TaskGroup boxes (nested), SyntaxError with caret lines,
KeyboardInterrupt, [Previous line repeated N more times], add_note() lines.
Node/V8 and browsers: at fn (file:line:col), at async, eval at, [cause],
AggregateError [errors], webpack-internal and Vite URLs, minified frames (flagged), props such
as code: 'ENOENT'.
Java/Kotlin/Scala: Exception in thread, Caused by:, Suppressed:, ... 23 more
(the elided frames are copied from the enclosing trace), Native Method, module prefixes
(java.base/, app//), logback ~[jar:ver] suffixes.
Go: panic: (including [recovered] re-panics), fatal error: with runtime stack:,
goroutine dumps with created by, the race detector's WARNING: DATA RACE.
Rust: thread 'x' panicked at in the old and the 1.73+ message layout, RUST_BACKTRACE
short and full forms, std/core frames marked, cargo registry frames marked as library.
.NET: at Ns.Class.Method() in file:line N, ---> inner exceptions, AggregateException
inner exception lists, async state-machine frames.
Trace text is untrusted data.
Nothing in a trace is executed, imported or evaluated.
Input is capped at 5,000,000 characters and 4,000 characters per line; every parser is single-pass and linear time. The test suite feeds each parser pathological shapes (a million open parentheses, 100k repeated headers, quadratic-regex bait) with a time limit.
Paths in traces are data. map_to_code never opens a path taken from a trace: it indexes the
files that actually exist under --dir and matches frames against that index by trailing path
components, so ../../etc/passwd can only ever select a file already inside the sandbox.
Symlinks are resolved with realpath before every read and refused when they leave the sandbox;
symlinked directories are not followed.
find_traces_in_file and map_to_code(project_dir=...) only accept paths inside --dir.
Output is redacted by default. Redaction is pattern based (see redact_trace); it is a safety
net, not a guarantee, so review before publishing. IPv6 coverage is partial (full 8-group,
fe80::, and bracketed forms).
Heuristics decide app vs library: a project vendored into site-packages or node_modules
looks like a library, and a library copied into your tree looks like your code. Minified
JavaScript frames cannot be mapped without a source map. Trace formats evolve; if a real trace
parses wrongly, please open an issue with the (redacted) text.
uv sync --extra test
uv run pytest
uv run ruff check src tests
uv run mypy --strict srcMIT licensed. See also the companion course, stacktrace-mcp-the-hard-way.
Decide whether two traces share a root cause and list the differences by frame.
Reports SAME / LIKELY SAME / POSSIBLY related / DIFFERENT with the fingerprints, the application frames both have, and the frames only one has (same function at a different line is called out as a code change).
Args: a: First trace text (the first trace in it is used). b: Second trace text. redact: Remove secrets etc. from the output (default true).
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | ||
| b | Yes | ||
| redact | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden. It discloses the verdict categories, the reported artifacts (fingerprints and application-frame overlaps), the code-change callout, and that redaction defaults to true, though it does not explicitly state that the operation is read-only or describe any permission needs.
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 front-loaded with the main purpose, then lists output behavior and arguments in a compact Args block. Every sentence contributes useful information without unnecessary repetition.
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 tool has moderate complexity, an output schema, and no annotations; the description covers the purpose, output categories, and all three parameters. It could be slightly more complete by explicitly stating that the operation is read-only or by clarifying expected trace format, but it is otherwise sufficient 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 0%, but the description compensates fully: it explains that 'a' is trace text and only the first trace in it is used, that 'b' is the second trace text, and that 'redact' removes secrets from output with a default of true. This adds clear meaning beyond the bare schema titles A, B, and Redact.
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 and resource: deciding whether two traces share a root cause and listing frame-level differences. It also names the output verdicts (SAME / LIKELY SAME / POSSIBLY related / DIFFERENT), making the tool easy to distinguish from siblings such as parse_trace or fingerprint.
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 makes clear that this tool is for comparing two traces for root-cause similarity and frame differences. It does not explicitly say when to use parse_trace, fingerprint, or redact_trace instead, so the sibling routing guidance is implicit rather than complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain a common exception type: what it means, its three most common causes, what to check first.
Covers about 80 exceptions across Python, Node, Java/Kotlin, Go, Rust and .NET (for example KeyError, ECONNREFUSED, NullPointerException, "concurrent map writes", "unwrap on None", NullReferenceException). Package prefixes are ignored (java.lang.NullPointerException = NullPointerException).
Args: type: Exception name or distinctive message, e.g. "KeyError", "java.lang.OutOfMemoryError", "nil pointer dereference". language: Optional: python, node, java, go, rust or dotnet. Omit to search all.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | ||
| language | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does reasonably well: it discloses coverage (~80 exceptions across six runtimes), name-normalization behavior (package prefixes ignored, with a worked example), and the shape of the answer. It omits the failure mode when a type is unrecognized and any rate/limit or caching behavior.
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 core purpose, then coverage scope, then args in a conventional docstring block. The runtimes-plus-examples list is slightly long but each example teaches name normalization, so little 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?
An output schema exists, so the description needn't detail return values, yet it usefully previews the answer contents. For a 2-param lookup tool this is nearly complete; the only meaningful gap is behavior for exceptions outside the ~80 supported or with an unsupported language value.
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 0%, so the description must compensate, and it does: 'type' is illustrated with three concrete formats including a fully qualified name, and 'language' is given an explicit valid value list (python, node, java, go, rust, dotnet) plus the semantic of omitting it. It falls short of saying what the matching tolerance is, i.e. how distinctive a raw message fragment may be.
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 first sentence gives a specific verb and resource ('Explain a common exception type') and enumerates the return contents: meaning, three most common causes, what to check first. This is clearly distinct from siblings like parse_trace, fingerprint or map_to_code, which operate on traces rather than exception semantics.
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 context is implied rather than stated: the agent can infer this is for interpreting a known exception name or message. It never says when to prefer it over a sibling or what to do when the exception is unknown, though 'Omit to search all' gives clear guidance for the language parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan a log file for every stack trace and group them by fingerprint.
Streams the file (never loads it whole; caps: 256 MB scanned, 1000 distinct groups) and returns the groups sorted by count with first/last seen timestamps (when the lines have ISO timestamps) or line numbers, the exception, and the innermost application frame. The file must be inside the --dir sandbox (relative paths are relative to the first --dir).
Args: path: Log file path, absolute or relative to the sandbox directory. top: How many groups to list (default 15). redact: Remove secrets etc. from the output (default true).
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | ||
| path | Yes | ||
| redact | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so well: it discloses streaming behavior, explicit caps (256 MB scanned, 1000 distinct groups), result ordering by count, and the timestamp-vs-line-number fallback. What it omits is whether the tool is strictly read-only or how it fails on an out-of-sandbox path, but the operational profile is substantially covered.
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 definition is front-loaded with the core purpose and constraints, then breaks parameters into an explicit Args block, so an agent can skim the first sentence and still act. It is slightly longer than necessary given that defaults are restated, but no sentence is 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?
For a file-scanning tool with three parameters and an output schema present, the description supplies the sandbox constraint, resource caps, ordering, and the shape of each group, which is what an agent needs to call it correctly and interpret results. The only meaningful gap is the absence of sibling routing guidance.
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 0%, so the description must compensate, and it does: it explains that path may be absolute or relative to the sandbox directory, that top controls how many groups are listed, and that redact removes secrets from output. Defaults are repeated from the schema, but the semantic meaning of each parameter is clarified beyond the bare titles.
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 opening sentence gives a specific verb and resource ('Scan a log file for every stack trace') plus the transformation performed ('group them by fingerprint'), which cleanly separates it from siblings like parse_trace (single trace) and fingerprint (compute a fingerprint). An agent can select this tool without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a hard prerequisite ('The file must be inside the --dir sandbox') and clarifies path resolution, which is genuinely useful usage context. However, it never says when to prefer this over siblings such as parse_trace or compare_traces, nor when not to use it, so the routing guidance is only implied by the purpose sentence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute a stable fingerprint for each trace in the text.
The hash covers the language, the top-level and root-cause exception types and the innermost application frames (function + file base name). Messages, memory addresses, ids, container-vs-local path prefixes, generated names ($$Proxy123) and, by default, line numbers are ignored, so the same bug on another run, host or commit hashes identically while a different bug does not. The components that went into the hash are listed so a changed fingerprint can be explained.
Args: text: One or more traces (max 5,000,000 characters). include_line_numbers: Also hash line numbers (stricter: edits to the file change the hash). redact: Remove secrets etc. from the output (default true).
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| redact | No | ||
| include_line_numbers | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the whole burden and does so well: it enumerates what is hashed and what is deliberately ignored (messages, addresses, ids, path prefixes, generated names, line numbers), states the stability guarantee, and notes that the hash components are returned so changes can be explained. It also flags the redact default, a behaviorally significant side effect.
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 purpose, then a tight explanatory paragraph, then a compact Args block. Every clause adds usable information about hashing behavior; nothing is redundant padding.
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 three-parameter, no-annotation tool with an output schema, the description covers behavior, inputs, and stability semantics thoroughly. The remaining gap is relative positioning against the sibling tools and any note on result ordering or batching for multi-trace input.
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 0%, so all meaning must come from the description, and it supplies an Args block defining every parameter: text carries a 5,000,000 character cap, include_line_numbers is framed as the stricter mode where file edits change the hash, and redact has an explicit default. This is materially more than the schema titles convey.
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?
A concrete verb and resource ("Compute a stable fingerprint for each trace") plus a precise statement of what the hash covers. It is plainly distinct from parse_trace or redact_trace, which would not describe hashing exception types and frames.
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 gives the operating context (same bug across runs, hosts, or commits hashes identically) which implies its use for deduplication and grouping. It does not explicitly say when to use this instead of compare_traces or parse_trace, and names no exclusions, so it falls short of explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Map the application frames of a trace onto files in the project and show the code.
Works when the trace's paths differ from the local ones: container paths (/app/src/x.py vs ./src/x.py), Windows vs POSIX separators, webpack/vite URLs, Java package paths. Frames are matched on their trailing path components against files that actually exist under the sandbox directory. For each frame it reports FOUND / NOT FOUND / ambiguous, whether the line number exists, the offending line with +-context lines, and warns when the source line recorded in the trace differs from the file (the code changed since the crash). Paths in the trace are treated as data: '../' tricks cannot reach outside --dir and symlinks that resolve outside it are refused.
Args: text: The trace (max 5,000,000 characters). project_dir: Directory to search; must be inside --dir. Default: the first --dir. context: Lines of context before/after the offending line (0-10, default 3). max_frames: Maximum application frames to map (default 8). index: Which trace if the text contains several (0-based). redact: Remove secrets etc. from the output, including source lines (default true).
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| index | No | ||
| redact | No | ||
| context | No | ||
| max_frames | No | ||
| project_dir | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so in detail: matching via trailing path components against real files, FOUND/NOT FOUND/ambiguous outcomes, line-number validation, context lines, and a staleness warning when the trace line differs from the file. It also discloses security behavior — '../' traversal is refused and symlinks resolving outside --dir are rejected — plus default redaction of secrets in output.
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-loads the purpose and behavior before a clearly delimited Args section, so it is easy to scan. It is somewhat long and the path-format enumeration (container paths, Windows/POSIX separators, webpack/vite URLs, Java packages) is dense, but each clause carries real information rather than 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?
Although an output schema exists, the description still explains the report contents (FOUND status, line existence, offending line with context, staleness warning), which is the operationally important part. For a matching tool with path-remapping and security constraints, nothing an agent needs to invoke it correctly is missing.
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 0%, so the description must compensate, and it does: text is capped at 5,000,000 characters, project_dir must lie inside --dir and defaults to the first one, context is bounded 0-10 with default 3, max_frames defaults to 8, index is 0-based for multi-trace input, and redact defaults to true. These meanings and constraints go well beyond the bare typed properties.
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 and object ('Map the application frames of a trace onto files in the project and show the code'), which is clearly distinct from siblings like parse_trace, fingerprint, or explain_exception. An agent can identify the tool's role without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context for when the tool is applicable ('Works when the trace's paths differ from the local ones') with concrete examples of path mismatches. It does not explicitly name sibling alternatives or state exclusions (e.g., when to prefer parse_trace or explain_exception), so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse a pasted stack trace / crash output and explain it.
Auto-detects Python (chained exceptions, ExceptionGroup, SyntaxError), Node/V8 (cause, AggregateError, async frames), Java/Kotlin (Caused by, suppressed, "... N more"), Go (panic, fatal error, goroutine dumps, race reports), Rust (panic + RUST_BACKTRACE) and .NET (inner exceptions). Returns the exception chain with the ROOT CAUSE marked, every frame classified as application vs library/stdlib/framework/runtime, the innermost application frame, and a fingerprint. Truncated or garbled input is parsed as far as possible and flagged PARTIAL with a reason.
Args: text: The raw trace, optionally surrounded by other log lines (max 5,000,000 characters). index: If the text contains several traces, which one (0-based). The report says how many. format: "report" (compact text, default) or "json" (full structure). full: Show every frame instead of collapsing runs of library frames. max_frames: Maximum frames listed for the root cause (default 25). redact: Remove secrets, emails, IPs and home-directory names from the output (default true).
| Name | Required | Description | Default |
|---|---|---|---|
| full | No | ||
| text | Yes | ||
| index | No | ||
| format | No | report | |
| redact | No | ||
| max_frames | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries the full burden and does disclose substantial behavior: auto-detection rules, that the ROOT CAUSE is marked, that frames are classified as application vs library/stdlib/framework/runtime, that a fingerprint is computed, and that truncated or garbled input is parsed as far as possible and flagged PARTIAL with a reason. It stops short of stating that the tool is a pure, side-effect-free analysis of the supplied text (no execution, no external lookups), which would fully close the gap.
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 purpose and output contract before the parameter list, which is the right order. Sentences are dense but purposeful; the parenthetical runtime examples and the Args block repeat some defaults already present in the schema, which is slightly redundant but aids scanning. Minor trimming is possible, but nothing is genuinely 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?
For a six-parameter parsing tool with an output schema, the description covers everything an agent needs: what it detects, what it returns (root cause, frame classification, innermost application frame, fingerprint), how it degrades on bad input, and the meaning of every argument. Return-value explanation is technically unnecessary given the output schema but adds useful orientation rather than harm.
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 0%, so the description must compensate and it does: an Args block defines every one of the six parameters. It gives the max input size for text (5,000,000 characters), explains index as 0-based with the report indicating how many traces exist, supplies the otherwise-missing value set for format ('report' vs 'json' — schema has no enum), clarifies full, and states max_frames default 25 and redact default true with what gets stripped.
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 opens with a specific verb+resource: 'Parse a pasted stack trace / crash output and explain it.' It then enumerates exactly which languages/runtime formats are auto-detected (Python chained exceptions, Node/V8, Java/Kotlin, Go, Rust, .NET), which makes the scope concrete and distinguishes it from siblings like find_traces_in_file (file-based) or explain_exception (single exception).
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 only implied: 'pasted' and 'optionally surrounded by other log lines' hint that this is for raw text blobs rather than files, which is what find_traces_in_file presumably handles, but no sibling is named. There is also no explicit guidance about when to prefer this over explain_exception or compare_traces, and the overlap with redact_trace (via the redact flag) is left unresolved.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove secrets and personal data from a trace or log excerpt, returning the cleaned text.
Removes API keys and tokens (JWT, Bearer, AWS, GitHub, Slack, Stripe, Google, sk-...), password=/token= style values, credentials in URLs, emails, IPv4 and full IPv6 addresses, and user names in home directories (C:\Users\name, /home/name, /Users/name). Safe to run before pasting a trace into a ticket. Every other tool also redacts its output by default.
Args: text: Text to clean (max 5,000,000 characters).
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the operation is purely a read-and-return transform (nothing mutated or destroyed), enumerates exactly which patterns are stripped, and gives a 5,000,000-character input ceiling. It omits any statement about failure modes or what happens to text that partially matches, which keeps it off a 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?
The core action and scope are front-loaded in sentence one, the redaction inventory is packed into a single compact parenthetical, and the practical guidance plus the args note close it out. No sentence is 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?
The tool is a simple one-parameter transform with an output schema, so return values need no explanation and the description correctly says only that cleaned text comes back. Between the annotated behavior, the redaction inventory, and the size limit, an agent has everything needed to call 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 0% and the single property is a bare string, so the description must compensate — and it does, supplying both the meaning ("Text to clean") and a hard limit ("max 5,000,000 characters") that appears nowhere in the schema. That is meaningful semantics added beyond the input schema, though the limit could have stated the consequence of exceeding it.
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 and resource ("Remove secrets and personal data from a trace or log excerpt") and describes the return value ("returning the cleaned text"). The enumerated redaction categories (API keys, JWTs, credentials in URLs, emails, IPs, home-directory usernames) make it unmistakable versus siblings like parse_trace or fingerprint, which do structural work rather than sanitization.
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?
"Safe to run before pasting a trace into a ticket" gives a concrete usage context, and "Every other tool also redacts its output by default" usefully tells the agent this is only needed for raw external text, implicitly scoping out redundant calls. It stops short of naming a specific sibling alternative or an explicit when-not-to-use case, so it lands just below the top band.
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.
v0.1.0compare_tracesexplain_exceptionfind_traces_in_filefingerprintmap_to_codeparse_traceredact_traceScored across 7 tools
Each tool maps to a distinct action in a clear pipeline: parse a trace, fingerprint it, scan a file for traces, map frames to source, compare two traces, explain a named exception type, and redact text. The only near-neighbors (parse_trace vs explain_exception, redact_trace vs the per-tool redact flag) are clearly separated by input type and scope, so misselection is unlikely.
All names are snake_case and almost all follow a verb_noun pattern (parse_trace, compare_traces, map_to_code, redact_trace, find_traces_in_file). The lone outlier is 'fingerprint', which is a bare verb with no object, a minor deviation but still unambiguous.
Seven tools is well within the ideal 3-15 range and each one covers a distinct step in a trace-triage workflow with no filler or redundancy. Nothing feels padded or missing at the count level.
The surface covers the full workflow: parse, stable identity via fingerprint, batch scanning of logs, source mapping, comparison, per-exception guidance, and sanitization. Minor gaps remain, such as no direct way to extract/normalize a single trace out of an arbitrary file path or to persist results, but agents can work around these with parse_trace and find_traces_in_file.
Production errors your coding agent can read: search, stack traces, context, trends, resolve.
Production errors and incidents for your agent: stack traces, breadcrumbs, likely causes, triage.
Analytics and debugging for your MCP server — explore usage and sessions, then root-cause errors.
Exception tracking for .NET. Let your AI coding agent search and triage errors and stack traces.
