datasheet-lens

Overview Schema Source Related Servers Discussions Admin

adopt_part

Add a selected distributor part to the project: stores its datasheet and purchase source, flags lifecycle warnings, and prepares confirmed CAD updates.

Instructions

Take a part that find_parts or search_distributors found: add its datasheet (one in the store, else a download: the site of the manufacturer first), add the part to the store and to the user project, and save the purchase source (the source and its part number; for JLCPCB the library class) in the store and in the project file. Use it when the user selects a candidate. The result gives the lifecycle state of the manufacturer from the distributors with a key: a WARNING (obsolete, last time buy, not for new designs) goes to the user, also when the source has stock. Then project_sync copies the datasheet into the project folder. The element map builds in the background. Read the values that the design needs in the datasheet and save them with save_fact. When no URL gives the datasheet (a login, a captcha), the result gives the URLs and the inbox folder of the project: give them to the user. A part with a new MPN becomes a new project part: to replace a project part (a replacement of project_availability), first the user agrees and the CAD project changes, then project_update_part(mpn, new_mpn), then adopt_part. The manufacturer of the part comes from its datasheet, not from the distributor: when the tool cannot read it, or the two names differ, the result asks (ASK THE USER) and adds nothing. A purchase source is added, not replaced: project_remove_source removes a wrong one. The CAD BOM is the master: write the change that the user confirmed into the CAD project too (MPN, MPN_Confirmed, Value_Confirmed, LCSC, Manufacturer, Distributor; kicad-workbench: set_symbol_fields), then project_check.

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": {
      "source": "<source>"
    },
    "name": "adopt_part"
  }
}

Input Schema

Name	Required	Description
`mpn`	No	The MPN, in place of number: the source must have one part for it.
`base`	No	The base part of the datasheet, for example TLV755P for TLV75533PDBVR. Empty: the MPN.
`path`	No	A folder of the user project (default: the working folder of the server). The project file datasheet-lens.toml is in it or in a parent folder.
`number`	No	The part number of the source: a DigiKey number, a JLCPCB C number (C47616) or a Mouser number, as find_parts or search_distributors give it. Give number or mpn, not both.
`source`	Yes	digikey, jlcpcb or mouser.
`category`	No	The function of the part, for example MOSFET or LDO.
`manufacturer`	No	The manufacturer as the datasheet names it, from the user. Give it only when a result of adopt_part asks for it (ASK THE USER).
`manufacturer_confirmed`	No	True when the user read page 1 of the datasheet and confirms the given manufacturer, for example the maker of a module whose datasheet names the maker of its chip more often: the tool does not compare it with the text of the PDF. Give it only when the user confirms it.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.6.0Nov 10, 2026

addedInput schema / properties / manufacturer

Added value: +{
+  "default": "",
+  "description": "The manufacturer as the datasheet names it, from the user. Give it only when a result of adopt_part asks for it (ASK THE USER).",
+  "title": "Manufacturer",
+  "type": "string"
+}

addedInput schema / properties / manufacturer_confirmed

Added value: +{
+  "default": false,
+  "description": "True when the user read page 1 of the datasheet and confirms the given manufacturer, for example the maker of a module whose datasheet names the maker of its chip more often: the tool does not compare it with the text of the PDF. Give it only when the user confirms it.",
+  "title": "Manufacturer Confirmed",
+  "type": "boolean"
+}

Addedv0.5.0Nov 7, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the full load and does well: it discloses writes to both the store and the project file, datasheet download side effects, background element-map construction, lifecycle WARNING propagation, and failure paths (login/captcha URLs handed to the user, manufacturer mismatch causing an ASK THE USER with nothing added). It is weaker on idempotency and conflict handling, e.g. what happens when the same part is adopted twice or when project fields already hold different values.

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?

It is front-loaded correctly with the action, then usage, then behavior, and each paragraph is on-topic. However it sprawls into downstream workflow instructions (element map, save_fact, project_sync, set_symbol_fields, project_check) that inflate the text and dilute the core contract, and several run-on sentences are hard to parse.

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

Completeness4/5

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

For an eight-parameter mutation tool with no annotations, it covers prerequisites (project file datasheet-lens.toml in the path or a parent), side effects, ambiguity handling, and handoffs to the next tools. The existence of an output schema means return values need not be spelled out, though the description still describes the WARNING and ASK THE USER results usefully.

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 already 100%, so the schema documents each parameter; the description adds workflow meaning instead, most notably that manufacturer should only be supplied when a prior result asks for it, and that the manufacturer is derived from the datasheet rather than the distributor. The number-vs-mpn exclusivity and default path behavior are left to the schema, which is acceptable at this coverage level.

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 opens with a concrete verb and resource: take a part found by find_parts or search_distributors, add its datasheet, add the part to the store and project, and save the purchase source. It names the sibling tools it depends on and the one it must be sequenced after (project_update_part), so an agent can place it precisely in the workflow.

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 states the trigger explicitly ('Use it when the user selects a candidate') and gives the exclusion path for replacing an existing part, including the required ordering: user agreement, CAD change, project_update_part, then adopt_part. It also names project_remove_source as the correct tool for removing a wrong source, since adopt only adds.

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