Skip to content

fix: surface real tool errors instead of empty messages - #168

Open
royalpinto007 wants to merge 1 commit into
qdrant:masterfrom
royalpinto007:fix/empty-errors
Open

fix: surface real tool errors instead of empty messages#168
royalpinto007 wants to merge 1 commit into
qdrant:masterfrom
royalpinto007:fix/empty-errors

Conversation

@royalpinto007

Copy link
Copy Markdown

Problem

Both qdrant-store and qdrant-find could surface completely empty errors in
MCP clients. In Claude Desktop this looked like:

Error calling tool 'qdrant-find':

with nothing after the colon (see #151).

Root cause

The tool functions called the Qdrant connector directly and let any exception
bubble up raw. FastMCP formats a failed tool call as
Error calling tool '<name>': <str(exception)>. When the underlying exception
has an empty string representation, for example a bare AssertionError or any
error raised without a message, str(exception) is empty, so the client
receives a message with an empty tail and the user has no idea what went wrong.

Fix

qdrant-store and qdrant-find now catch backend failures and re-raise them as
ToolError with an always non-empty, informative message. A small
describe_exception helper includes the exception type and its message, and
falls back to the class name when the message is blank, so an empty error can no
longer reach the client. Real messages such as "connection refused" continue to
propagate unchanged.

Tests

Adds tests/test_error_surfacing.py, which drives both tools through an
in-memory FastMCP client and asserts that a real, non-empty error propagates,
plus unit tests for the helper. Full suite passes (30 tests).

Closes #151

Tool calls raised the underlying exception directly. When an exception
had an empty string representation, such as a bare AssertionError or an
error raised without a message, FastMCP formatted the response as
"Error calling tool 'qdrant-find': " with nothing after the colon, so
clients like Claude Desktop showed an empty error.

The qdrant-store and qdrant-find tools now catch backend failures and
re-raise them as ToolError with an informative, always non-empty message
that includes the exception type and, when available, its message. A
describe_exception helper guarantees the fallback to the class name when
the message is blank.

Adds regression tests that drive the tools through an in-memory FastMCP
client and assert a real, non-empty error propagates.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Both tools return empty errors in Claude Desktop

1 participant