> For the complete documentation index, see [llms.txt](https://docs.durohub.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.durohub.com/ai-integration/tools.md). # Tool Reference Every tool the [Duro MCP server](/ai-integration/mcp.md) 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](/advanced-topics/search-query-syntax.md), 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. {% hint style="warning" %} 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. {% endhint %} ## 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 | {% hint style="info" %} 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. {% endhint %} ## 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](/core-concepts/components.md) and [Advanced Topics](/advanced-topics/rbac.md). Anything the assistant can do here, you can do directly against the [GraphQL API](/getting-started/introduction.md). The MCP server is a front end to the same API, with the same permissions. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.durohub.com/ai-integration/tools.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.