PC Compatibility Checker
Verify hardware compatibility via Newegg's MCP endpoints over HTTP using standard JSON-RPC. Use the
tool to call the endpoints — no MCP client registration required.
This skill does one thing: route the user's parts through Newegg's PC Builder compatibility
endpoint and report what it says. It does not recommend new builds from scratch — that is outside
scope.
Agent Execution Rules
- Reply in the user's language. Detect the language of the user's question and produce the
entire response in that language — headings, explanations, fix proposals, everything. Chinese
question → Chinese reply. English question → English reply. Japanese question → Japanese reply.
Do not mix unless the user mixes first. The only exception is that raw data (item numbers,
model names, the original English string in parentheses) stays as-is.
- Do not guess compatibility from your own hardware knowledge. That is the exact failure mode
this skill exists to prevent.
- Do not ask for clarification when the user already gave you the parts. Infer item numbers /
names from their message and call immediately.
- Use the tool to run the curl commands below.
- On curl failure or invalid JSON, report the error directly. Do not fall back to your own
knowledge to produce a verdict.
Endpoints
Required header on every request: all calls to
apis.newegg.com/ex-mcp/...
must carry
x-skill: newegg-pc-compatibility-checker
in addition to
. It identifies the calling skill to the endpoint — include it even when you assemble a request by hand rather than copying an example below.
| Purpose | Endpoint |
|---|
| Compatibility check | https://apis.newegg.com/ex-mcp/endpoint/ext-pc-builder
|
| Product search | https://apis.newegg.com/ex-mcp/endpoint/product-search
|
product-search is only needed when the user gives you a model name without an item number —
it resolves
. When the user already gave item numbers, go straight to
pc-builder.
The flow
Step 1 — Get every part as an item number
Look at what the user provided:
- They gave item numbers (e.g. ) → use them directly and skip straight to Step
2. No lookup needed. Always use the short hyphenated format (), never the
long URL form ().
- They gave model names (e.g. "Ryzen 9 9950X3D" + "ASUS B760M-AYW WIFI D4") → call
product-search once per part (in parallel) to resolve each name into an .
- Mixed → only search for the parts that do not already have item numbers.
product-search returns
directly in the short-hyphenated format — that is everything
you need to hand to pc-builder. Do not call any other endpoint for the name → item-number step.
If a search returns multiple candidates, pick the one whose
most closely matches
the user's wording. Only ask the user to disambiguate when it is truly ambiguous (e.g. "DDR4 or
DDR5 version of this kit?"). Do not ask three clarifying questions when one will do.
If product-search returns for a part, do NOT silently substitute a similar part and
proceed. The correct action is:
- Tell the user plainly that the part was not found in Newegg's catalog (likely out of stock or
not carried). Name the specific part the user asked for.
- Offer to try a close substitute and describe what the substitute would be (same platform /
generation / price tier), but wait for the user's confirmation before calling pc-builder
with the substitute.
- If the user declines the substitute, stop. Do not fabricate an item number from your own
knowledge — pc-builder will reject it and the verdict will be meaningless.
Silently swapping in a different part is a worse failure mode than reporting the search gap,
because the user will not realize the final compatibility report is about a part they did not ask
about.
Step 2 — Call pc-builder once with every item
Call
with a
space-separated list of short-hyphenated item numbers in a
single
string. Do not call pairwise — pc-builder accepts the full set and computes
conflicts internally.
curl -sS -X POST "https://apis.newegg.com/ex-mcp/endpoint/ext-pc-builder" \
-H "Content-Type: application/json" \
-H "x-skill: newegg-pc-compatibility-checker" \
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "comboCompatibleAll",
"arguments": {
"businessId": 2,
"itemNumber": "<ITEM1> <ITEM2> <ITEM3>"
}
}
}'
- is always (fixed).
- is a space-separated string of short-hyphenated item numbers — e.g.
.
If the call returns a tool-not-found error, first run
to discover the correct tool
name:
curl -sS -X POST "https://apis.newegg.com/ex-mcp/endpoint/ext-pc-builder" \
-H "Content-Type: application/json" \
-H "x-skill: newegg-pc-compatibility-checker" \
-d '{"jsonrpc":"2.0","id":0,"method":"tools/list"}'
pc-builder response shape
Parse the path:
response → result.content[0].text → (parse as JSON) → verdict
Fields on the verdict object:
| Field | Description |
|---|
| → all parts compatible. → at least one conflict |
| Present only when . One entry per conflicting pair |
incompatibleItems[].itemNumber
| One side of the conflict |
incompatibleItems[].relatedItemNumber
| The other side of the conflict |
incompatibleItems[].reason
| Single summary line of the conflict |
incompatibleItems[].uncompatibleInfo
| Usually duplicates |
incompatibleItems[].reasonTraces[]
| Array of every specific rule that failed. Always read this, not just |
Step 3 — Report the verdict honestly
If : Say so plainly, list what was checked, and stop. Do not invent
caveats from your own knowledge.
Exception — PSU wattage disclosure. pc-builder's rules cover sockets, chipsets, memory type,
physical fit, and electrical interfaces — but they
do not validate that a PSU's wattage meets
the GPU manufacturer's recommended minimum. So a 750W PSU paired with an RTX 5090 will return
even though Nvidia recommends 1000W.
Whenever a PSU is among the checked items AND
, append one neutral line to
the report:
⚠️ pc-builder does not verify PSU recommended wattage against the GPU's requirements. Please
cross-check your PSU against your GPU manufacturer's official wattage recommendation before
assembling.
This is not "adding a caveat from your own knowledge" — it is a known, documented limitation of
the MCP, and the user needs to know the compatibility engine's scope.
If : Walk through
one entry at a time. For each
entry:
- Refer to the two conflicting items using whatever the user gave you in their original
question:
- User gave model names → use those names (e.g. "Ryzen 9 9950X3D ↔ ASUS B760M-AYW").
- User gave bare item numbers → use the item numbers (e.g. "19-113-938 ↔ 13-144-674").
- User gave a mix → use names where they gave names, item numbers where they gave item
numbers. Do not do a lookup just to pretty-print.
- List every entry in — not just . Each trace is a separate failed
rule and the user deserves to see all of them.
- Translate each into the user's language (per the top-level "Reply in the user's
language" rule), with the original English string in parentheses for reference. The MCP
returns slightly stilted English (
"doesn't support with Socket AM5"
) that reads better
translated — but the user still benefits from seeing the original so they can look up the
exact rule if needed.
Step 4 — Suggest a fix and re-verify
After explaining the conflict, propose a concrete fix:
- Socket / chipset / DDR-generation mismatch → swap the smaller/cheaper side (usually the
motherboard or RAM, not the CPU).
- PSU undersized vs GPU → suggest a specific replacement PSU.
- Physical fit (case clearance, cooler height) → swap a part of the same category.
Use
product-search to find the replacement part, then
call pc-builder again with the
updated item list to verify. Do not declare the fix valid from your own reasoning — re-run
pc-builder. Iterate until
or the user changes scope.
Response format
Use this structure when reporting the verdict to the user:
Compatible:
## Compatibility check: ✅ Compatible
Checked:
- <user's name for item 1> (<item number>)
- <user's name for item 2> (<item number>)
- ...
All parts are compatible according to Newegg PC Compatibility Checker.
Incompatible:
## Compatibility check: ❌ Incompatible
**Conflict 1: <name1> ↔ <name2>**
- <reasonTraces[0]>
- <reasonTraces[1]>
- ...
**Conflict 2: ...**
### Suggested fix
<specific replacement part with item number>
### Re-verification
[call pc-builder again → report new isCompatible]
All headings, labels, and explanations in the response template above must be translated into
the user's language. The English text shown in the template is a structural placeholder — do not
ship English section headers (
,
, etc.) to a
non-English-speaking user.
Hard rules
- Item numbers go to pc-builder in short hyphenated format (), not the long form
().
- Never claim compatibility without an from pc-builder. No verdicts
derived from your own knowledge. Ever.
- Never claim incompatibility without an from pc-builder. Even for
"obvious" cases (AMD CPU + Intel motherboard), still call pc-builder so the user sees the
authoritative verdict and the specific reasons.
- Read , not just — the array has more detail than the summary string.
- Reuse whatever the user gave you when reporting conflicts — names if they gave names, item
numbers if they gave item numbers. Do not run extra lookups to pretty-print.
- Re-verify after any fix by calling pc-builder again with the updated set.
Out of scope
- Building a new PC from scratch when the user has not picked specific parts. Tell them this skill
is for verifying parts they already have in mind, and answer their build-recommendation question
normally without this skill.
- Recommending parts based on price / performance opinions when the user only asked about
compatibility. Stay focused on the compatibility question.
- Inventing compatibility rules pc-builder did not return. If the MCP says valid, do not add fake
caveats; if invalid, do not expand on reasons it did not give.
Common pitfalls
- Doing extra lookups to translate item numbers into names when the user already gave you
item numbers and will recognize them. Wasteful and slow — just report what the user gave you.
- Translating only and ignoring — the user loses information about
every failed rule.
- Using the long-form item number (). pc-builder expects the short form.
- Skipping pc-builder for "obvious" cases like AMD CPU + Intel motherboard. The whole point of
the skill is that the verdict comes from the MCP, not from you.
- Suggesting a fix without re-verifying — every proposed swap must go through pc-builder again
before being presented as a solution.
- Silently substituting a part when product-search returns 0 results. If Newegg does not have
the exact part the user asked about, you must tell the user and ask — not quietly proceed with
a similar part. The final verdict must always be about the parts the user actually asked about.
- Omitting the PSU wattage disclaimer when reporting an build that
includes a PSU. pc-builder does not check that the PSU is big enough for the GPU; tell the user
that explicitly instead of letting them assume the green check covers it.
Edge cases
- HTTP error or curl failure: Report status code and body. Do not retry silently and do not
fall back to your own compatibility knowledge.
- in response: Display to the user.
- empty but : Treat as an upstream bug — tell the
user the service returned an inconsistent response and ask them to retry.
- pairs the same with multiple s: Report
each pair separately; do not collapse them.