adityamparikh opened a new issue, #213:
URL: https://github.com/apache/solr-mcp/issues/213
### Problem
The MCP annotation layer reports the **root cause's** message as the tool
error
text. `AbstractSyncMcpToolMethodCallback` walks `getCause()` to the root and
uses
that message for the `CallToolResult`, and `toolCallExceptionClass` defaults
to
`Exception`, so this applies to every tool call:
```
catch (Exception e) {
if (toolCallExceptionClass.isInstance(e)) // defaults to Exception
return createSyncErrorResult(e); // →
findCauseUsingPlainJava(e).getMessage()
}
```
Any `new SomeException("context", cause)` therefore loses `"context"` — the
client sees only the root's message. #212 fixes this for `SearchService`,
where
the wrapper carried the remediation hints and losing them left clients with
no
next step. Four sites remain on `main`:
- `config/JsonResponseParser.java:102` — `"Failed to parse Solr JSON
response"`
- `indexing/SolrUpdateXml.java:77` — `"Failed to parse XML document"`
- `indexing/documentcreator/JsonDocumentCreator.java:124` — `"Failed to
parse JSON document"`
- `indexing/documentcreator/MarkdownDocumentCreator.java:141` — `"Failed to
parse markdown document"`
### Why the fix differs from #212
In `SearchService` the wrapper carried the actionable content and the root
carried raw Solr text, so the wrapper had to win. Here it is the other way
around: Jackson's `Unexpected character ('}' (code 125)) at line 3` or a SAX
parse location is exactly what tells the model how to fix its document, while
`"Failed to parse JSON document"` alone is not actionable.
So these should keep the root's detail and regain the lost context by
folding it
into the message, then drop the cause for the same reason:
```java
throw new DocumentProcessingException(
"Failed to parse JSON document: " + e.getMessage());
```
with the original logged server-side, since the chain no longer carries it.
`MarkdownDocumentCreator.java:231` (`"SHA-256 MessageDigest not available"`)
is
deliberately excluded — that is a JVM-invariant failure, not a
client-correctable
one.
### Suggested verification
Service-layer assertions cannot observe this: they inspect the exception
object,
which is where the wrapper message still looks correct. The regression has
to be
pinned at the MCP boundary, as `searchFailureIsAnActionableMcpToolError`
does in
#212 — assert that an `index-documents` call with malformed input returns a
tool
error naming both the format and the parser's detail.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
