Laptop Part Finder

Get coverage manifest

get_coverage

Read-only

Check in one call whether LPF covers a brand, model, or part type at all, before you search. Use list_models instead to page through models. Use get_model_parts instead for a model's part numbers. Use resolve_request or search_parts instead to find a specific part. Default (summary omitted or false): totals, brands, part types, and every model with its part types and fit counts (~1 MB). summary true: the same without the models list (models_omitted gives the count; ~6 KB) — prefer for brand or part-type questions; use full mode only to look up a specific model. Snapshot at deploy time: generated is the build date; data_revision changes when data or server changes. Not listed means no documented fit, not incompatibility.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_coverage"
  }
}

Input Schema

Name	Required	Description	Default
`summary`	No	Optional, default false. true omits the per-model list (same as REST /api/coverage?summary=1).

Output Schema

Name	Required	Description
`note`	No
`brands`	Yes
`models`	No
`totals`	Yes
`license`	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
`generated`	Yes
`terms_url`	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.
`part_types`	Yes
`attribution`	No
`absence_note`	No
`data_revision`	No
`data_generated`	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

addedInput schema / properties / summary

Added value: +{
+  "description": "Optional, default false. true omits the per-model list (same as REST /api/coverage?summary=1).",
+  "type": "boolean"
+}

changedOutput schema / required

Previous value: -[
-  "generated",
-  "totals",
-  "brands",
-  "part_types",
-  "models"
-]New value: +[
+  "generated",
+  "totals",
+  "brands",
+  "part_types"
+]

AddedNov 1, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=true, openWorldHint=false, destructiveHint=false; the description goes well beyond that. It discloses payload sizes (~1 MB vs ~6 KB), snapshot semantics (generated is the build date, data_revision changes on data or server changes), and an interpretation caveat that absent data means no documented fit rather than incompatibility.

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?

Tightly packed with zero filler, and the core purpose and size caveats are front-loaded. It is a single dense run-on block of em-dash clauses, however, so the mode selection and snapshot notes would scan faster as separate sentences.

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 values need no explanation, and the description still covers mode selection, payload sizes, data freshness, and the negative-result interpretation caveat. Nothing an agent needs to call this correctly or read its output 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% and the single parameter's meaning is already documented, so the baseline is 3. The description adds real value by quantifying the size tradeoff and prescribing when to prefer summary=true versus full mode, though it does not restate the exact omission contract more precisely than the schema does.

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 ('Check ... whether LPF covers a brand, model, or part type at all') plus the timing constraint ('before you search'). It immediately distinguishes itself from all four named siblings, so an agent can route correctly 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?

Explicitly names alternatives with the condition that selects each: list_models for paging models, get_model_parts for part numbers, resolve_request/search_parts for a specific part. It also gives when-to-use guidance between the two output modes (summary preferred for brand/part-type questions, full mode only for a specific model lookup).

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?