Laptop Part Finder

Resolve a vague part request

resolve_request

Read-only

Entry point for a vague natural-language repair need you will answer, e.g. "my T490 battery is dying". Use search_parts instead for keyword/exploratory browsing without committing to one clarifying question. Use get_part instead for an exact OEM part number. Use get_model_parts instead when you already have a model slug. A part number in query returns status resolved with that part and next = get_part_fits (type ignored). Otherwise type, if given, overrides any type word in query; else the type word is used; the rest must name one model. resolved: the model, candidate_count, first 10 candidates (compact), and next = get_model_parts with model and type (asks which part if type is missing). needs_clarification: ONE clarifying_question to ask instead of guessing (5G vs Wi-Fi, Intel vs AMD, generation, touch), up to 40 candidate models, next = retry with the chosen slug. not_found has fit_status no_documented_fit (no document, not incompatibility); did_you_mean offers a spelling fix to retry, never auto-applied.

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": {
      "query": "<query>"
    },
    "name": "resolve_request"
  }
}

Input Schema

Name	Required	Description	Default
`type`	No	Optional part type, case-insensitive, as listed by get_coverage, e.g. "Battery", "Screen", "Keyboard", "Power Adapter", "SSD", "Memory". Overrides a type word in query; omit it to use the type word, or to be asked which part.
`query`	Yes	Required. The user's words (max 200 characters): a model plus part, or an OEM part number with or without dashes, e.g. "T490 battery", "surface pro 11 screen", "L40094001", "01FR025".

Output Schema

Name	Required	Description
`kind`	No
`mode`	No
`next`	No
`part`	No
`match`	No
`model`	No
`query`	Yes
`status`	Yes
`license`	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
`part_type`	No
`terms_url`	No
`brand_note`	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.
`attribution`	No
`request_url`	No
`suggestions`	No
`absence_note`	No
`data_revision`	No
`confidence_doc`	No
`candidate_count`	No
`clarifying_question`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 10, 2026

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

Changed2 schema fields changedNov 4, 2026

changedInput schema / properties / query / description

Previous value: -"e.g. \"T490 battery\", \"surface pro 11 screen\", \"L40094001\""New value: +"Required. The user's words (max 200 characters): a model plus part, or an OEM part number with or without dashes, e.g. \"T490 battery\", \"surface pro 11 screen\", \"L40094001\", \"01FR025\"."

changedInput schema / properties / type / description

Previous value: -"Optional part type, e.g. Battery, Screen, Keyboard, Power Adapter, SSD, Memory (as in get_coverage part_types). Overrides any type word in query and limits candidates to that type; omit it and a type word in query is used, else the result asks which part."New value: +"Optional part type, case-insensitive, as listed by get_coverage, e.g. \"Battery\", \"Screen\", \"Keyboard\", \"Power Adapter\", \"SSD\", \"Memory\". Overrides a type word in query; omit it to use the type word, or to be asked which part."

Changed1 schema field changedNov 4, 2026

changedOutput schema / properties / status / enum

Previous value: -[
-  "resolved",
-  "needs_clarification",
-  "not_found"
-]New value: +[
+  "resolved",
+  "needs_clarification",
+  "not_found",
+  "did_you_mean"
+]

Changed1 schema field changedNov 3, 2026

changedInput schema / properties / type / description

Previous value: -"Optional part type, e.g. Battery"New value: +"Optional part type, e.g. Battery, Screen, Keyboard, Power Adapter, SSD, Memory (as in get_coverage part_types). Overrides any type word in query and limits candidates to that type; omit it and a type word in query is used, else the result asks which part."

Changed1 schema field changedNov 1, 2026

addedOutput schema / properties / part / properties / display_name

Added value: +{
+  "description": "Short human label; not an identifier",
+  "type": [
+    "string",
+    "null"
+  ]
+}

Changed1 schema field changedOct 31, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "absence_note": {
+      "type": "string"
+    },
+    "attribution": {
+      "type": "string"
+    },
+    "brand_note": {
+      "type": "string"
+    },
+    "candidate_count": {
+      "type": "integer"
+    },
+    "candidates": {
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "clarifying_question": {
+      "type": "string"
+    },
+    "confidence_doc": {
+      "type": "string"
+    },
+    "data_revision": {
+      "type": "string"
+    },
+    "fit_status": {
+      "description": "Present when there is no fit or no result: LPF has no OEM document for it. Never means incompatible.",
+      "enum": [
+        "no_documented_fit"
+      ],
+      "type": "string"
+    },
+    "kind": {
+      "enum": [
+        "part_number",
+        "concept"
+      ],
+      "type": "string"
+    },
+    "license": {
+      "type": "string"
+    },
+    "match": {
+      "type": "string"
+    },
+    "message": {
+      "type": "string"
+    },
+    "mode": {
+      "enum": [
+        "no_match"
+      ],
+      "type": "string"
+    },
+    "model": {
+      "properties": {
+        "manufacturer": {
+          "type": "string"
+        },
+        "name": {
+          "type": "string"
+        },
+        "slug": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "slug"
+      ],
+      "type": "object"
+    },
+    "next": {
+      "type": "object"
+    },
+    "part": {
+      "properties": {
+        "api_url": {
+          "type": "string"
+        },
+        "brand": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "lpf_url": {
+          "type": "string"
+        },
+        "name": {
+          "type": "string"
+        },
+        "part_number": {
+          "type": "string"
+        },
+        "source_url": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "type": {
+          "type": "string"
+        },
+        "url": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "part_number"
+      ],
+      "type": "object"
+    },
+    "part_type": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "query": {
+      "type": "string"
+    },
+    "request_url": {
+      "type": "string"
+    },
+    "status": {
+      "enum": [
+        "resolved",
+        "needs_clarification",
+        "not_found"
+      ],
+      "type": "string"
+    },
+    "suggestions": {
+      "properties": {
+        "browse_models_url": {
+          "type": "string"
+        },
+        "closest_models": {
+          "items": {
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "request_url": {
+          "type": "string"
+        },
+        "tips": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        }
+      },
+      "type": "object"
+    },
+    "terms_url": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "status",
+    "query"
+  ],
+  "type": "object"
+}

AddedOct 31, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only declare readOnly/non-destructive/closed-world; the description goes far beyond by enumerating the three outcome statuses and what each carries. It adds genuinely non-obvious semantics: not_found's fit_status=no_documented_fit means "no document, not incompatibility", did_you_mean is never auto-applied, and needs_clarification returns exactly ONE question with up to 40 candidate models.

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

Conciseness3/5

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

Purpose and sibling routing are front-loaded correctly and most content earns its place, but the status/outcome section is compressed into run-on fragments ("resolved: the model, candidate_count, first 10 candidates...") that are dense to parse. Separating the outcome contract into clearly delimited lines would cost nothing and improve scanability.

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?

Despite an output schema existing, the description still documents the status branches and the required follow-up call for each, which is exactly what an agent needs to plan a multi-step interaction. Combined with the model-resolution rules and clarification policy, nothing material is missing for correct invocation.

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 the baseline is 3, but the description adds precedence rules the schema does not state: an explicit type overrides a type word in the query, otherwise the type word is used, and the remainder must name exactly one model. It also states that a part number in the query causes type to be ignored, which is a resolution behavior not visible in the schema.

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?

The description states the specific verb and resource: an entry point that maps a vague natural-language repair need onto a model/part, with a concrete example ("my T490 battery is dying"). It actively distinguishes itself from search_parts, get_part, and get_model_parts by naming the condition that selects each, so an agent can route without opening another 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?

It gives explicit when-to-use and when-not-to-use guidance: search_parts for keyword/exploratory browsing, get_part for an exact OEM number, get_model_parts when a model slug is already known. It also states the fallback that a part number in the query still resolves (routing to get_part_fits), so the overlap with get_part is disclosed rather than left ambiguous.

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?