Expose Crypto KAT Runners as MCP Tools Instead of Pasting Hex

When a Known Answer Test stumbles upon a faulty crypto primitive, the culprit is typically byte-ordering or padding issues. Copying the raw hex data and associated ACVP JSON into a chat window may seem like a quick fix, but it becomes impractical when dealing with large vector files. A reliable foundation must still be established manually.

This involves executing the KAT binary locally, extracting the failing vector ID and byte offset, making the necessary adjustments, and re-running the test. For a single algorithm and a small file, this iterative process is efficient and easy to verify compared to incorporating server code. However, this approach encounters limitations when faced with massive ACVP payloads and repeated runs.

One solution to bridge this gap is to encapsulate the KAT runner within the Model Context Protocol over stdio. This allows the tool to run_crypto_kat(target, algorithm) and return structured status, the failing case ID, and a diff window. To optimize resource usage, it's advisable to implement filtering or paging mechanisms instead of simply dumping the entire file.

The tool outputs should be kept small and typed, including verdict, file, case, expected vs actual slice, and the next command. The agent should be prompted to request additional context explicitly, rather than being inundated with the entirety of the file by default.

The question arises: what workaround do you employ today to handle large KAT vectors without overwhelming the agent with excessive information, while still providing enough details for them to rectify the byte-level bug?