Why can your AI read a datasheet but not order the part? MCP in five minutes

You probably think of your AI assistant as a very well-read intern. It has seen every datasheet, every forum thread, every app note. Ask it anything and it answers.

But an intern who can only talk is a limited intern. Ask it whether a part is in stock today and it cannot know. Ask it to run a simulation and it can only describe one. Ask it to order the parts and it can write you a shopping list.

The thing that turns the intern into someone who can act is a standard way of handing it tools. That standard is the Model Context Protocol, MCP. Here is what it is, in five minutes.

What MCP is

MCP is an open protocol that describes how an AI application (the "client": Claude, Cursor, VS Code) talks to an external program (the "server") that offers it things to use. The server is written once and works with every client that speaks the protocol. Before MCP, every assistant needed its own plugin format, and every tool vendor had to build one integration per assistant.

Think of it as USB for AI tools: the port is standard, the device is up to you.

The three things a server can offer

Tools. Functions the model can call, with a name, a description and typed parameters. "Search parts by specification." "Export a STEP file." "Run a DC operating point analysis." The model reads the description, decides a tool is relevant, fills in the parameters, and the server runs it and returns the result. This is the part that matters most for hardware work.

Resources. Data the model can read: a file, a database row, a document. A server might expose your library of approved parts as a resource so the model can look things up without you pasting them in.

Prompts. Reusable instructions the server suggests, like "review this schematic for power sequencing problems." Less important day to day, but useful when a vendor knows how their tool is best used.

Local and remote servers

A local server is a program on your machine. The client starts it, talks to it over standard input and output, and stops it when you close the session. Good for tools that need your files or your installed software: a server that wraps KiCad's command line, or one that runs your CadQuery scripts.

A remote server runs somewhere else and you talk to it over HTTP (the current transport is called Streamable HTTP). You get a URL and a key. Nothing to install. Good for services: a parts supplier, a simulation farm, a manufacturer's quoting engine. Next Everything is a remote server of this kind.

Why this matters if you build hardware

Because the hard parts of hardware are not in the model's head. They are in the world, and they change.

Stock changes daily. Prices have breaks. Lead times depend on the week. A CAD kernel knows what your model is; the assistant only knows what you told it. A simulator knows whether the bracket holds; the assistant can only guess.

With MCP, the assistant can ask instead of guessing. It can call a parts supplier and get today's stock. It can call a CAD tool and get a real STEP export. It can call a simulator and get a number rather than an opinion. The model's job shifts from "know everything" to "know which tool to call and what to do with the answer," which is what it is actually good at.

The workflow that follows from that is in how to use Claude Code for hardware design.

Which assistants support it

As of October 2026, MCP is supported by the main AI coding and chat tools: Claude (the app), Claude Code, Cursor, OpenAI Codex, Windsurf, VS Code (through Copilot's agent mode), Gemini CLI and Zed. Each has its own way to register a server (a command, a settings file, or a UI) but they all end up at the same place: a server URL or command, and for remote servers, a key in a header.

Security basics

Giving a program the ability to act on your behalf is new territory for most engineers, so a few rules.

Your API key is a password. It identifies you to the server. Anyone with it can act as you. Keep it in the client's configuration, not in a file you commit, not in a chat message, not in a screenshot. If it leaks, revoke it and make a new one.

Know which tools read and which tools write. A server's tool list tells you. "Search parts" reads. "Quote" reads. "Create checkout" writes something consequential. Most clients ask you to approve each tool call the first time and let you allow read-only tools permanently. Do that for reads; keep approving writes by hand.

Approve payments yourself. A well-designed server never lets the model spend money. It produces a payment link or an order draft, and a human confirms it. If a server offers a tool that pays without you, do not give it a key with access to money.

Remote servers see what you send them. When the model calls a tool with your BOM, your BOM leaves your machine. That is fine for a supplier you have chosen to buy from. It is not fine for a server you have not vetted. Read the privacy terms the same way you would for any vendor.

Prompt injection exists. If a tool returns text, the model reads it, and a malicious result could try to instruct the model. Reputable servers return structured data; still, be suspicious of a tool that returns paragraphs of prose, and keep the human approval on anything that writes.

A three-step example: connecting Next Everything

Next Everything is a remote MCP server that finds and prices every part in a hardware project (electronics, PCBs, 3D prints, CNC parts) and prepares an order you approve. Here is the whole setup for Claude Code; other clients differ only in where you paste the URL and key.

Step 1. Create a free account at nexteverything.io/signup and copy your personal API key. It starts with nx_live_.

Step 2. Register the server once:

claude mcp add --transport http nexteverything https://mcp.nexteverything.io/mcp \
  --header "Authorization: Bearer nx_live_your_key"

Step 3. Ask, from inside your project:

Use Next Everything to find all the parts for this project. I want to build 2.
Quote with the recommended strategy and show me the picklist. Do not check out.

The server exposes six tools: nx_scan_project (reads your repo and builds a BOM), nx_search_parts (live stock and price by part number, spec or description), nx_quote (the full build, shipping and duties included), nx_quote_fabrication (one STEP, STL, DXF or Gerber package by process and material), nx_checkout (a payment link; the agent cannot pay) and nx_track_order. The docs list the parameters.

Five tools read, one writes a payment link you open yourself. That is the pattern to look for in any server that touches money.

One rule for any tool like this: if a call fails, the agent should tell you and retry rather than invent a result. Next Everything returns a clear error code when that happens, so a well-behaved agent never has to guess.

What to try first

Pick one tool you wish your assistant could use and see whether it already has an MCP server. For hardware, the parts step is the easiest win, because it is the one where the model's own knowledge is most often stale. The full ordering walkthrough with a KiCad project is in order parts for a KiCad project from Claude Code. For the thinking behind checking availability while you design rather than after, read design with what you can buy.