Problem
When a required parameter is missing (e.g. accountId), our tools return a successful MCP tool response whose body is a JSON object like {"error":"accountId is required"}. From the MCP client's perspective the call succeeded, so callers (including LLM agents) cannot reliably detect that the request was malformed — they have to introspect the result body and look for an error property.
Observed from a rockbot session calling calendar-mcp:
Tool mcp_invoke_tool returned in 316ms: {"error":"accountId is required"}
This was returned as a non-error response.
Expected behavior
Missing-required-parameter conditions should surface as protocol-level errors (i.e. isError: true on the tool result, or an exception that the ModelContextProtocol SDK translates into an error response), not as successful results with an embedded error string.
Background
Issue #46 added validation for accountId in get_calendar_events, but the implementation just serializes { error = "..." } as the success payload. The same pattern was then propagated to many other tools.
Affected tools
Grep for "accountId is required" shows the pattern in at least:
GetCalendarEventsToolGetCalendarEventDetailsToolDeleteEmailToolGetEmailDetailsToolMarkEmailAsReadToolMoveEmailToolUnsubscribeFromEmailToolGetUnsubscribeInfoToolGetEmailAttachmentToolDeleteContactToolGetContactDetailsToolUpdateContactTool
Other validation paths (e.g. invalid IANA timezone in GetCalendarEventsTool) likely have the same issue.
Suggested fix
- Adopt a consistent error-signaling mechanism for the ModelContextProtocol .NET SDK — e.g. throw
McpException (or whatever the SDK exposes) for argument-validation failures so the framework produces a proper error response.
- Update existing tools to use that mechanism instead of serializing an
error field into the success payload.
- Update the corresponding tests in
CalendarMcp.Tests/Tools/* (currently they assert the JSON-with-error-field shape).
Problem
When a required parameter is missing (e.g.
accountId), our tools return a successful MCP tool response whose body is a JSON object like{"error":"accountId is required"}. From the MCP client's perspective the call succeeded, so callers (including LLM agents) cannot reliably detect that the request was malformed — they have to introspect the result body and look for anerrorproperty.Observed from a rockbot session calling calendar-mcp:
This was returned as a non-error response.
Expected behavior
Missing-required-parameter conditions should surface as protocol-level errors (i.e.
isError: trueon the tool result, or an exception that the ModelContextProtocol SDK translates into an error response), not as successful results with an embedded error string.Background
Issue #46 added validation for
accountIdinget_calendar_events, but the implementation just serializes{ error = "..." }as the success payload. The same pattern was then propagated to many other tools.Affected tools
Grep for
"accountId is required"shows the pattern in at least:GetCalendarEventsToolGetCalendarEventDetailsToolDeleteEmailToolGetEmailDetailsToolMarkEmailAsReadToolMoveEmailToolUnsubscribeFromEmailToolGetUnsubscribeInfoToolGetEmailAttachmentToolDeleteContactToolGetContactDetailsToolUpdateContactToolOther validation paths (e.g. invalid IANA timezone in
GetCalendarEventsTool) likely have the same issue.Suggested fix
McpException(or whatever the SDK exposes) for argument-validation failures so the framework produces a proper error response.errorfield into the success payload.CalendarMcp.Tests/Tools/*(currently they assert the JSON-with-error-field shape).