Tool Reference

Every tool the Duro MCP server exposes. You never call these by name — you describe what you want and the assistant chooses. They're listed here so you know what's possible, and so you can tell what happened after the fact.

Read tools only look. Write tools change something in your library, attributed to you.

Library

Tool		What it does
duro_library_get	Read	Which library the connection is scoped to, and its organization
duro_category_list	Read	Every category in the library — Resistor, PCBA, Fastener, and so on
duro_status_list	Read	Lifecycle statuses and what each maps to (Design, Production, Obsolete…)

Categories and statuses are per-library and configurable, so the assistant reads them rather than assuming. If you ask for "parts in production" and your library calls that status something else, this is how it finds out.

Search

Three tools, in descending order of how often they're the right one.

Tool		What it does
duro_component_search	Read	Natural language. "Resistors in production changed this month"
duro_component_query	Read	The structured query syntax, or a bare keyword
duro_component_list	Read	Exact name, CPN, category, status, or type

duro_component_search is the default. It handles anything conversational, resolves names of people and statuses and categories for you, and understands relative dates.

duro_component_query is for when the search is already precise — type:part status:Design modifiedBy:"Sarah Chen". It parses deterministically, so it's faster and doesn't cost an AI call. A bare word is a text search across name, CPN, and description.

duro_component_list is the cheapest of the three, for when you already have a CPN or a category name in hand.

Reading a search result

Search results carry a search block describing what was actually searched, separate from the rows themselves. It matters more than it sounds like it should.

Both search backends widen a query they can't fully resolve rather than failing it. Ask for parts modified by someone who isn't a member of the library and you don't get an error — you get every part, with a note that the name went unmatched. Ask with a typo in a status name and that condition is dropped, silently returning more than you meant.

So the block reports:

• interpretation — how the query was read, in plain English

• applied — the filters that actually ran

• notice — present only when part of your question didn't land, saying so in words

A good assistant relays the notice before presenting the rows. If yours doesn't, applied is the ground truth: compare it against what you asked for.

An unmatched name is sometimes replaced with the closest one that does exist, not dropped. Asking for "parts modified by John Smith" in a library that has a John Griffin can return John Griffin's parts. The applied list is what tells you — it will name Griffin, not Smith.

Components

Tool		What it does
duro_component_get	Read	Full record for one component, by CPN
duro_component_create	Write	Create a component. Needs a category name
duro_component_update	Write	Update name, description, status, category, attributes, or thumbnail
duro_validate	Read	Run Duro's own validation rules without saving anything

duro_validate runs the same checks the web app runs — field limits, category and status existence, attribute types, name uniqueness, revision format — and returns every problem at once, each with a field path and a fix. Worth asking for explicitly before a bulk change: "validate these 40 rows against duro before creating anything."

Assemblies

Tool		What it does
duro_assembly_list	Read	Components that have a BOM
duro_assembly_bom	Read	Bill of materials for an assembly, with nesting
duro_assembly_link_children	Write	Add child components to an assembly's BOM

Assemblies are components, so everything in the Components section applies to them too. duro_assembly_bom walks the hierarchy — ask for a specific depth if you don't want the whole tree.

Change orders

Tool		What it does
duro_change_order_template_list	Read	The workflow templates this library offers
duro_change_order_list	Read	Change orders, by status or resolution
duro_change_order_get	Read	Full detail — stages, reviewers, items, submission status
duro_change_order_create	Write	Create a change order, in DRAFT
duro_change_order_add_items	Write	Add components to a change order
duro_change_order_submit	Write	Submit for review — DRAFT to OPEN

If your library has more than one workflow template, creating a change order asks you which one rather than guessing. The template decides who reviews the change and what has to be approved before anything releases, and it can't be corrected by editing the change order afterwards — so it's not a decision worth defaulting.

Files and documents

Tool		What it does
duro_file_upload_request	Write	Request signed upload URLs, singly or in batch
duro_file_upload_execute	Write	Upload the file to the signed URL
duro_file_upload_confirm	Write	Confirm the upload completed
duro_document_link_create	Write	Link a document component to a part or assembly
duro_step_file_parse	Read	Read a STEP file's assembly structure, parts, and quantities

Uploading is three steps, and the assistant runs them in order — you just say what to attach. Batches upload in parallel.

duro_step_file_parse reads the file without uploading it, which makes "what's in this STEP file?" answerable before you commit to importing anything.

What isn't here

The MCP server covers component, assembly, change order, and document workflows. Sourcing, webhooks, RBAC administration, and library configuration are API-only for now — see Core Concepts and Advanced Topics.

Anything the assistant can do here, you can do directly against the GraphQL API. The MCP server is a front end to the same API, with the same permissions.