Edge Case Museum MCP server

edge-case-museum

Your code works. Except for these wonderfully terrible inputs.

Part of Pipeworx — an MCP gateway connecting AI agents to 1784+ live data sources. This is an independent, unofficial integration — not affiliated with, endorsed by, or published by the upstream provider.

By Mojibake, creators of Pipeworx.

Tell it what you are building ("username uniqueness", "parse a CSV upload", "store and add up money amounts", "schedule a reminder in the user's timezone") and it hands back the inputs that quietly break that kind of code: the assumption each one breaks, the exact bytes, what goes wrong, why, the safer pattern, and a repro in Python and JavaScript whose output came from actually running it. Then it writes you a test file of those inputs, pointed at your own function.

Three exhibits

Every output below was printed by running the code, by the same harness that checks the whole collection (Python 3.14.2, Node.js v22.22.2).

1. One NaN can leave the rest of your list unsorted

edgecaseget({ id: "nan-in-sort" })

nan = float("nan")
print(sorted([3, nan, 1]))

[3, nan, 1]

console.log([3, NaN, 1].sort((a, b) => a - b));

[ 3, NaN, 1 ]

Not "NaN ends up somewhere odd". The 3 and the 1 are left out of order. Every comparison with NaN is false, so the sort sees NaN as equal to everything. That breaks transitivity (3 "equals" NaN, NaN "equals" 1, so 3 "equals" 1), and the algorithm concludes the list is already sorted. Python promises nothing for inconsistent comparisons. ECMAScript makes the order implementation-defined.

2. "01/01/68" is 2068 in Python and 1968 in Node.js

edgecaseget({ id: "two-digit-year-century-pivot-mismatch" })

for s in ("01/01/49", "01/01/50", "01/01/68", "01/01/69"):
    print(s, "->", datetime.strptime(s, "%m/%d/%y").year)

01/01/49 -> 2049
01/01/50 -> 2050
01/01/68 -> 2068
01/01/69 -> 1969

for (const s of ['01/01/49', '01/01/50', '01/01/68', '01/01/69'])
  console.log(s, '->', new Date(s).getFullYear());

01/01/49 -> 2049
01/01/50 -> 1950
01/01/68 -> 1968
01/01/69 -> 1969

Python follows the POSIX pivot at 69. V8 pivots at 50. The two agree on every two-digit year except 50 through 68, where they are a century apart. Test a handful of dates and you will probably never hit one.

3. Intl says the Iraqi dinar has no decimals. ISO 4217 says it has three.

edgecasesfind({ context: "store and add up money amounts", language: "javascript" })

for (const c of ["USD", "JPY", "BHD", "KWD", "CLF", "IQD", "HUF"]) {
  const digits = new Intl.NumberFormat("en-US", { style: "currency", currency: c })
    .resolvedOptions().maximumFractionDigits;
  console.log(c, digits);
}

USD 2
JPY 0
BHD 3
KWD 3
CLF 4
IQD 0
HUF 0

The first lesson is that amount * 100 is wrong for JPY (a 100x overcharge) and for BHD (a 10x undercharge). The second is quieter: the obvious fix, asking Intl how many decimals a currency has, returns CLDR display data, not ISO 4217. IQD is 3 in ISO 4217 and HUF is 2, and Intl reports 0 for both. Store the exponent your payment processor uses. Don't derive it from a formatter.

And then it writes the test

edgecasestest_file({ context: "parse a CSV upload", language: "python" }) returns a pytest file of eight cases from seven CSV exhibits. Pointed at the parser most of us write first, list(csv.reader(io.StringIO(text))):

PASSED test_edge_case[csv-formula-injection-excel]
PASSED test_edge_case[csv-crlf-trailing-blank-line0]
PASSED test_edge_case[csv-crlf-trailing-blank-line1]
PASSED test_edge_case[csv-quoted-field-with-newline]
PASSED test_edge_case[csv-doubled-quote-escaping]
PASSED test_edge_case[csv-quoted-field-with-comma]
FAILED test_edge_case[csv-utf8-bom-first-header]
FAILED test_edge_case[csv-semicolon-delimited-european-excel]
2 failed, 6 passed

Shortened. The full README is on GitHub.