Laptop Part Finder

Get part details

get_part

Read-only

Fetch the full record for one exact OEM part number: specs, description, verification, every source URL, and fitted models. Use get_part_fits instead when you only need the list of models it fits. Use check_part_fits instead for yes/no against specific models (or several part numbers at once). Use search_parts instead for keyword/fuzzy text. Use resolve_request instead for a vague repair need. Matching order: exact number, then ignoring case/dashes/spaces, then leading zeros, then retired numbers (returns the current record with a superseded note). Several matches return status ambiguous with candidates. Not found is an error result (LPF has no document, not incompatibility).

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": {
      "part_number": "<part_number>"
    },
    "name": "get_part"
  }
}

Input Schema

Name	Required	Description	Default
`client`	No	Optional: your agent or app name (letters and digits), used only for anonymous usage counts.
`part_number`	Yes	Required. OEM part number (FRU, spare or Dell P/N), with or without dashes or spaces, e.g. "01FR025", "7K4PW", "L78555-005".

Output Schema

Name	Required	Description
`url`	No
`fits`	No
`name`	No
`note`	No
`type`	No
`brand`	No
`match`	No
`query`	No
`specs`	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
`sources`	No
`buy_links`	No
`fit_count`	No
`terms_url`	No
`candidates`	No
`confidence`	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.
`source_url`	No
`superseded`	No
`attribution`	No
`description`	No
`part_number`	No
`absence_note`	No
`checked_date`	No
`display_name`	No	Short human label; not an identifier
`source_title`	No
`data_revision`	No
`source_detail`	No
`verified_date`	No
`confidence_note`	No
`confidence_tier`	No
`normalized_from`	No
`verification_basis`	No
`verification_level`	No
`source_document_url`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 11, 2026

changedOutput schema / anyOf

Previous value: -[
-  {
-    "required": [
-      "part_number",
-      "fits",
-      "sources"
-    ]
-  },
-  {
-    "required": [
-      "status",
-      "candidates"
-    ]
-  }
-]New value: +[
+  {
+    "required": [
+      "part_number",
+      "fits",
+      "sources"
+    ]
+  },
+  {
+    "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

addedOutput schema / properties / confidence_tier

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

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 / fits / items / properties / confidence_tier

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

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"
+}

Changed1 schema field changedNov 4, 2026

changedInput schema / properties / part_number / description

Previous value: -"Required. OEM part number, with or without dashes or spaces, e.g. \"7K4PW\" or \"01FR025\""New value: +"Required. OEM part number (FRU, spare or Dell P/N), with or without dashes or spaces, e.g. \"01FR025\", \"7K4PW\", \"L78555-005\"."

AddedNov 3, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description layers on real behavioral context: the normalization matching cascade (case/dashes/spaces, leading zeros, retired numbers), the ambiguous-status-with-candidates outcome for multiple matches, and the fact that not-found is an error rather than an incompatibility signal.

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?

Purpose is front-loaded in the first clause, followed by routing and then matching behavior — a sensible order with no filler sentences. It runs as a single dense block without separators, which makes the matching-order rules slightly harder to scan than they could be.

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?

An output schema exists, so return-shape explanation is unnecessary; the description instead covers the things the schema cannot — matching fallbacks, ambiguity handling, and failure semantics. Nothing an agent needs to call this correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so both parameters are already documented; the description still adds genuine meaning by describing how part_number is matched (exact, then case/dash/space-insensitive, then leading zeros, then superseded numbers). This exceeds the baseline, though the underlying field syntax is still the schema's job.

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?

States a specific verb and resource ("Fetch the full record for one exact OEM part number") and enumerates the returned payload (specs, description, verification, source URLs, fitted models), which cleanly separates it from get_part_fits, check_part_fits, search_parts and resolve_request.

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?

Explicitly routes the agent to four named alternatives with the condition that selects each (fits-only list, yes/no model check, keyword/fuzzy text, vague repair need). It effectively declares both when-to-use and when-not-to-use this tool.

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?