Reject empty customer and product searches in Part 6 MCP tools

[jongalloway]

Issue type

bug

Requested priority

P2 - A workaround exists, an optional path is broken, or significant drift exists

Workshop area

Part 6 - Enhanced MCP Server

Summary

The Part 6 customer-order and product-inventory tools treat an empty search string as a valid match. Because every .NET string contains string.Empty, an empty customer query returns John Doe and an empty product query returns Camping Tent instead of reporting invalid input or no match.

The server builds and valid structured MCP calls pass, so the defect is isolated to input validation and false-positive results.

Attendee or instructor impact

Part 6 teaches structured business integrations. Returning an arbitrary first record for missing search input demonstrates unsafe tool behavior and can cause an agent to present unrelated customer or inventory data as if it matched the request.

Attendees may encounter this through incomplete model-generated arguments or manual MCP calls. There is no reliable workaround other than ensuring every caller supplies a non-empty value.

Reproduction or proposed change

1. Build and run Part 06 - Enhanced MCP Server/ContosoOrdersMcpServer/.
2. Initialize the MCP stdio session and call tools/list.
3. Call the customer-search tool with an empty customer name.
4. Observe that it returns John Doe because the matching logic uses Contains with an empty string.
5. Call the product-inventory tool with an empty product name.
6. Observe that it returns Camping Tent for the same reason.

Add explicit validation before performing partial matching:

• reject null, empty, and whitespace-only customer names;
• reject null, empty, and whitespace-only product names;
• return the repository's structured validation/no-match shape rather than throwing or silently choosing the first record;
• keep case-insensitive partial matching for meaningful non-empty input.

Add protocol-level regression cases so both empty and whitespace-only values are covered.

Expected outcome

Missing or whitespace-only search arguments produce an explicit structured validation or no-match response. Valid full and partial customer/product searches retain their current behavior and never return unrelated first records.

Validation

• Build a scratch copy in Release with zero warnings.
• Call each affected tool with "" and confirm it does not return a business record.
• Call each affected tool with whitespace-only input and confirm the same behavior.
• Confirm valid exact searches still return the expected records.
• Confirm valid case-insensitive partial searches still work.
• Extend and run tests/McpStructuredOutputTests with the invalid-input cases.
• Confirm the MCP process continues serving subsequent requests after validation failures.
• Run the transitive vulnerability audit.

Dependencies and related issues

Related to #656, which tracks scenario coverage and inconsistent sample order data in the same bonus part. This issue is intentionally focused on invalid-input handling and false-positive disclosure of unrelated records.