Laptop Part Finder

Check a part against models

check_part_fits

Read-only

Yes/no: do these part numbers fit these specific models? Example: "does 01FR025 or 5B10W13905 fit my T490 and T495?". Use get_part_fits instead to list every model one part fits. Use get_model_parts instead for a model's parts. Give part_number, part_numbers, or both (merged, duplicates dropped). At most 100 part×model pairs, else an error result. Parts match as in get_part; models resolve like get_model_parts, once each. One part: results in model order; an unknown part is an error result. Several parts: side-by-side comparison (parts list plus flat results in part-then-model order); unknown or ambiguous parts are flagged in their entry and their rows have fits null. fits true includes constraints, source_url, confidence; fits false is fit_status no_documented_fit (no document, not incompatibility); fits null for an ambiguous or unknown model. Per-row field details are in the output schema.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "models": "<models>"
    },
    "name": "check_part_fits"
  }
}

Input Schema

Name	Required	Description
`client`	No	Optional: your agent or app name (letters and digits), used only for anonymous usage counts.
`models`	Yes	Required. 1 to 20 model slugs or full names, e.g. ["lenovo-thinkpad-t490", "ThinkPad T495"].
`part_number`	No	One OEM part number, with or without dashes or spaces, e.g. "01FR025" or "7K4PW". Give this, part_numbers, or both.
`part_numbers`	No	Several OEM part numbers to compare, e.g. ["01FR025", "5B10W13905", "L78555-005"]. Merged after part_number; parts x models must be at most 100.

Output Schema

Name	Required	Description
`url`	No
`mode`	No
`name`	No
`note`	No
`type`	No
`brand`	No
`match`	No
`parts`	No
`query`	No
`status`	No
`api_url`	No
`license`	No
`lpf_url`	No
`message`	No
`outcome`	No	Always present. One field to branch on for every tool: found \| no_documented_fit (identified, but no OEM-documented fit; never means incompatible) \| needs_clarification (ask the user; see clarifying_question/candidates) \| not_found (nothing LPF covers matches). Full contract: /api/states
`results`	No
`terms_url`	No
`candidates`	No
`fit_status`	No	no_documented_fit: there is no fit or no result: LPF has no OEM document for it. Never means incompatible. not_asserted: a did-you-mean suggestion; no fit claim is made.
`fits_count`	No
`part_count`	No
`source_url`	No
`attribution`	No
`part_number`	No
`absence_note`	No
`display_name`	No	Short human label; not an identifier
`checked_count`	No
`data_revision`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 11, 2026

changedOutput schema / anyOf

Previous value: -[
-  {
-    "required": [
-      "part_number",
-      "results"
-    ]
-  },
-  {
-    "required": [
-      "parts",
-      "results"
-    ]
-  },
-  {
-    "required": [
-      "status",
-      "candidates"
-    ]
-  }
-]New value: +[
+  {
+    "required": [
+      "part_number",
+      "results"
+    ]
+  },
+  {
+    "required": [
+      "parts",
+      "results"
+    ]
+  },
+  {
+    "required": [
+      "status",
+      "candidates"
+    ]
+  },
+  {
+    "properties": {
+      "outcome": {
+        "const": "not_found"
+      }
+    },
+    "required": [
+      "outcome",
+      "data_revision",
+      "message"
+    ]
+  }
+]

changedOutput schema / properties / status / enum

Previous value: -[
-  "ambiguous"
-]New value: +[
+  "ambiguous",
+  "not_found"
+]

Changed5 schema fields changedNov 10, 2026

changedInput schema / properties / part_numbers / description

Previous value: -"Several OEM part numbers to compare, e.g. [\"01FR025\", \"01AV489\", \"L78555-005\"]. Merged after part_number; parts x models must be at most 100."New value: +"Several OEM part numbers to compare, e.g. [\"01FR025\", \"5B10W13905\", \"L78555-005\"]. Merged after part_number; parts x models must be at most 100."

changedOutput schema / properties / fit_status / description

Previous value: -"Present when there is no fit or no result: LPF has no OEM document for it. Never means incompatible."New value: +"no_documented_fit: there is no fit or no result: LPF has no OEM document for it. Never means incompatible. not_asserted: a did-you-mean suggestion; no fit claim is made."

changedOutput schema / properties / fit_status / enum

Previous value: -[
-  "no_documented_fit"
-]New value: +[
+  "no_documented_fit",
+  "not_asserted"
+]

addedOutput schema / properties / outcome

Added value: +{
+  "description": "Always present. One field to branch on for every tool: found | no_documented_fit (identified, but no OEM-documented fit; never means incompatible) | needs_clarification (ask the user; see clarifying_question/candidates) | not_found (nothing LPF covers matches). Full contract: /api/states",
+  "enum": [
+    "found",
+    "no_documented_fit",
+    "needs_clarification",
+    "not_found"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / results / items / properties / confidence_tier

Added value: +{
+  "enum": [
+    "green",
+    "yellow",
+    "red"
+  ],
+  "type": "string"
+}

Changed10 schema fields changedNov 4, 2026

changedInput schema / properties / part_number / description

Previous value: -"Required. OEM part number, with or without dashes or spaces, e.g. \"01FR025\" or \"7K4PW\"."New value: +"One OEM part number, with or without dashes or spaces, e.g. \"01FR025\" or \"7K4PW\". Give this, part_numbers, or both."

addedInput schema / properties / part_numbers

Added value: +{
+  "description": "Several OEM part numbers to compare, e.g. [\"01FR025\", \"01AV489\", \"L78555-005\"]. Merged after part_number; parts x models must be at most 100.",
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 20,
+  "minItems": 1,
+  "type": "array"
+}

changedInput schema / required

Previous value: -[
-  "part_number",
-  "models"
-]New value: +[
+  "models"
+]

changedOutput schema / anyOf

Previous value: -[
-  {
-    "required": [
-      "part_number",
-      "results"
-    ]
-  },
-  {
-    "required": [
-      "status",
-      "candidates"
-    ]
-  }
-]New value: +[
+  {
+    "required": [
+      "part_number",
+      "results"
+    ]
+  },
+  {
+    "required": [
+      "parts",
+      "results"
+    ]
+  },
+  {
+    "required": [
+      "status",
+      "candidates"
+    ]
+  }
+]

addedOutput schema / properties / mode

Added value: +{
+  "enum": [
+    "multi"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / part_count
```
Added value: +{
+  "type": "integer"
+}
```

addedOutput schema / properties / parts

Added value: +{
+  "items": {
+    "properties": {
+      "candidates": {
+        "items": {
+          "type": "object"
+        },
+        "type": "array"
+      },
+      "fits_count": {
+        "type": "integer"
+      },
+      "match": {
+        "type": "string"
+      },
+      "name": {
+        "type": "string"
+      },
+      "part_number": {
+        "type": "string"
+      },
+      "part_query": {
+        "type": "string"
+      },
+      "results": {
+        "items": {
+          "type": "object"
+        },
+        "type": "array"
+      },
+      "status": {
+        "enum": [
+          "found",
+          "ambiguous",
+          "not_found"
+        ],
+        "type": "string"
+      },
+      "type": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "part_query",
+      "status"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / results / items / properties / part_number
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
addedOutput schema / properties / results / items / properties / part_query
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / properties / results / items / properties / status / enum

Previous value: -[
-  "ambiguous",
-  "not_found"
-]New value: +[
+  "ambiguous",
+  "not_found",
+  "part_ambiguous",
+  "part_not_found"
+]

AddedNov 4, 2026

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), yet the description still adds substantial behavior: a 100 part×model pair cap that errors, error-result semantics for unknown parts in single-part mode, and flagged-but-non-error handling in multi-part mode. It also explains that fits=false means no documented fit rather than incompatibility, and that fits null means ambiguous or unknown — genuinely useful beyond the annotations. A 5 is not warranted mainly because return-format detail is deferred wholesale to the output schema rather than adding anything the schema lacks.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the yes/no answer and the routing guidance before the mechanics, which is the right order. The tail is dense with semicolon-chained clauses, but nearly every clause carries real information; trimming would cost accuracy rather than save waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

All required parameters are documented in the schema, an output schema exists and is correctly deferred to, and the description still covers the edge cases an agent must anticipate (pair cap, unknown vs ambiguous parts, fits null). Nothing needed to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, and the description adds only modest extra meaning: that part_number and part_numbers are merged with duplicates dropped, and that parts×models must not exceed 100. It does not explain the model slug resolution rules beyond a pointer to get_model_parts, so it stays near baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource framing ("Yes/no: do these part numbers fit these specific models?") plus a concrete example question, and explicitly distinguishes itself from get_part_fits and get_model_parts. An agent can select it without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names both key alternatives and the exact condition each covers: get_part_fits for listing every model one part fits, get_model_parts for a model's parts. This is explicit when-not guidance, not implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Laptop Part Finder tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?