Skip to main content
Glama
Sign In
SheetsData MCP

SheetsData MCP

by octoco-ltd
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Compare Parts

compare_parts
Read-onlyIdempotent

Compare 2-5 electronic part numbers side by side to see specs, pricing, stock, lifecycle, and datasheet status, helping validate component choices in one call.

Instructions

Costs 2¢ per call. Compares 2-5 parts you already know side by side in one call (find candidates with search_parts or find_alternative first). Returns each part's details (per-provider specs, price breaks and links, the cached datasheet summary), a comparison table of parameters × parts built from each part's own provider data, and per-part flags: lifecycle (obsolete, NRND, last-time-buy), stock, datasheet_status, and resolved_as when a lookup landed on a different MPN. compact=true returns only the flags and the table, a much shorter answer; add include_summaries=true for the summaries. Never starts extraction: prefetch_datasheets first if you need summaries. If any input is not a real part number, the whole call is rejected with a 'rejected' map; a valid MPN no provider knows still gets a column, with an error. Example: compare_parts(['TPS54302', 'LM2596', 'MP2359']) datasheet_status: 'ready' → read it; 'extracting' / 'queued' / 'pending' / 'resolving' → poll check_extraction_status; 'not_extracted' → prefetch_datasheets; 'no_source' / 'unsupported' → request_datasheet_upload. Full list in the server instructions.

Input Schema

NameRequiredDescriptionDefault
compactNoReturn the shorter answer: per-part flags and the comparison table, without per-provider detail or summaries. Default false: the full answer.
part_numbersYes2-5 parts. Specific manufacturer part number (MPN) or LCSC number (e.g. 'TPS54302DDCR', 'C2837938'). Not a value ('100nF'), description or reference designator ('R1').
include_summariesNoWith compact=true, also return each part's cached datasheet summary (about 2-4k characters each). The full answer always has them.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.4.0
    • addedInput schema / properties / compact
      Added value: +{
+  "default": false,
+  "description": "Return the shorter answer: per-part flags and the comparison table, without per-provider detail or summaries. Default false: the full answer.",
+  "type": "boolean"
+}
    • addedInput schema / properties / include_summaries
      Added value: +{
+  "default": false,
+  "description": "With compact=true, also return each part's cached datasheet summary (about 2-4k characters each). The full answer always has them.",
+  "type": "boolean"
+}
    • changedInput schema / properties / part_numbers / description
      Previous value: -"2-5 specific manufacturer part numbers or LCSC numbers to compare head-to-head. Must be real MPNs — the call is rejected upfront if any entry is a value, description, or reference designator."New value: +"2-5 parts. Specific manufacturer part number (MPN) or LCSC number (e.g. 'TPS54302DDCR', 'C2837938'). Not a value ('100nF'), description or reference designator ('R1')."
  2. Changed1 schema field changedv1.3.2
    • changedInput schema / properties / part_numbers / description
      Previous value: -"List of 2-5 specific manufacturer part numbers to compare. Not values or descriptions."New value: +"2-5 specific manufacturer part numbers or LCSC numbers to compare head-to-head. Must be real MPNs — the call is rejected upfront if any entry is a value, description, or reference designator."
  3. First observedv1.0.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive, open-world, so the bar is lower; the description still adds real behavioral context beyond them: a 2¢ per-call cost, the all-or-nothing rejection of non-MPN inputs, the error column for valid-but-unknown MPNs, the resolved_as flag when a lookup lands on a different MPN, and the fact that it never itself starts extraction.

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?

Long but front-loaded: cost, then what it does, then the return shape, then the routing table, then the compact/mode behavior. Nearly every clause is actionable, though the routing enumeration is dense enough that it could be tightened without losing information.

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?

No output schema exists, yet the description fully characterizes the return payload (per-provider specs, price breaks and links, cached datasheet summary, a parameters × parts table, and per-part lifecycle/stock/datasheet_status/resolved_as flags) plus the mode variants, so an agent knows both when and what to expect.

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; however the description adds meaning the schema does not, notably that include_summaries only applies with compact=true and that compact mode still retains the flags and comparison table. It restates the 2-5 bound and the 'not a value/reference designator' constraint that the schema already gives, so it does not reach 5.

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 ('Compares 2-5 parts ... side by side in one call') and explicitly scopes it to parts you already know, naming search_parts and find_alternative as the candidate-discovery siblings. An agent can distinguish this from every sibling without opening a 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?

Gives explicit when-to-use and prerequisites: find candidates with search_parts/find_alternative first, prefetch_datasheets before expecting summaries. It also routes on results (datasheet_status 'ready' → read it; 'extracting' → poll check_extraction_status; 'not_extracted' → prefetch_datasheets; 'no_source' → request_datasheet_upload), which is unusually actionable.

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

Deploy Server

Other Tools