Skip to main content
Glama

Extract a datasheet into a component twin

datasheetvend_build_component_twin
Read-only

Extract a datasheet with DatasheetVend Fast Extraction and return its Unified Component Model (UCM) digital twin in one call. Fast Extraction runs once for every requested module, and the modules' facts combine into one twin, filed where they belong: pins, whole_part (temperatures, absolute limits, package, ordering code), interfaces_rails, registers and checks — every fact with a check ('passed', 'needs_review', 'disagrees', 'failed_sanity_check') and, where recorded, its datasheet page. Returns the same ucm_twin_v1 view as datasheetvend_get_component_twin, with every section unless you ask for sections, one pin or a search, plus an extraction block: the engine, rescued_features (modules Fast Extraction could not complete at turbo speed that the standard deep engine extracted instead, slower for just those modules -- still billed and still in the twin), the modules NEITHER engine could extract (no credits charged for those), the credits charged and stored=false. Treat facts that did not pass as unverified and cite their page. The twin is NOT saved to your account: datasheetvend_get_component_twin and the dashboard will not find it, and calling again extracts and bills again. Needs a DatasheetVend API key. Costs the requested modules' credits: pinout (1 credit), absolute_max (2 credits), pin_cautions (2 credits), logic_levels (2 credits), thermal (2 credits), timing (2 credits), register_map (3 credits), peripheral_matrix (2 credits), power_battery (1 credit), part_decoder (2 credits), cad_normalized (1 credit, extracted as footprint); all of them 20 credits.

Input Schema

NameRequiredDescriptionDefault
pinNoOne pin by number, name or alternate function (for example '27', 'PC4' or 'SDA'): every fact that reaches it — its own and those of its rails and interfaces.
searchNoOnly facts whose parameter, symbol, statement or node contains this text, case-insensitive (for example 'storage temperature' or 'TWCR'). With no sections given, searches pins, whole_part, interfaces_rails and registers.
modulesNoTwin modules to extract and combine: pinout, absolute_max, pin_cautions, logic_levels, thermal, timing, register_map, peripheral_matrix, power_battery, part_decoder, cad_normalized. Omit for all of them. Each costs its module credits.
partNameNoOptional part number / MPN to target in a datasheet that covers several parts.
sectionsNoParts of the twin to include besides the summary: pins, whole_part, interfaces_rails, registers, checks. Omit, with no pin or search, for every section — this twin is not stored, so there is no second read.
max_factsNoCap on facts returned across the pin and sections (default 200). `truncated` says when it was reached.
only_passedNoOnly facts that passed every check. Default false: every fact comes with its check.
documentPathYeshttps:// URL to the datasheet PDF. The remote /api/mcp endpoint accepts ONLY https:// URLs (it downloads them).

Output Schema

NameRequiredDescriptionDefault
pinYesThe requested pin with the facts that reach it, or null when no pin was asked for.
partYes
checksYes
countsYes
placesYes
contractYesContract id: ucm_twin_v1
sectionsYesThe requested sections: pins, whole_part, interfaces_rails, registers, checks — facts with their check and, where recorded, their page.
warningsYes
datasheetYes
truncatedYes
built_fromYes
extractionYesThe Fast Extraction run behind this twin
how_to_readYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond annotations: discloses per-module credit costs, that the twin is not saved (stored=false, dashboard won't find it), repeat calls re-extract and re-bill, rescued_features behavior, and that unextractable modules cost nothing. This is rich behavioral context an agent needs and annotations don't provide.

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?

Front-loaded with the core action and the 'not saved / re-bills' warning, and dense with useful detail. It is long and somewhat run-on in the credit enumeration, but nearly every sentence carries actionable 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?

With an output schema present, the description needn't explain returns, yet it still summarizes the extraction block and checks. Combined with billing and non-persistence disclosures, an agent has everything needed to invoke correctly.

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 baseline is 3; the description adds real value by mapping module names to credit costs and explaining max_facts/truncated and only_passed semantics. It adds meaning beyond the schema without fully restating each parameter.

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 ('Extract a datasheet... return its Unified Component Model (UCM) digital twin in one call') and explicitly positions it against the sibling datasheetvend_get_component_twin. An agent can tell it produces a one-shot twin versus reading a stored one.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clear context: use modules to pick what to extract, omit for all; use get_component_twin to read a stored twin instead. It doesn't explicitly route against the many datasheetvend_extract_* siblings (e.g., when to use this instead of calling extract_pinout individually), leaving some inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources