Which Service Is Truly Agent native

This piece is written before the goods arrive. As of the night of October 19, a 66×60 mm cat feeder control board has been paid for at JLC, and the order with SMT is still waiting for me to confirm component polarity; the enclosure has never been printed, the firmware has never been flashed, and the cat has not eaten a single pellet. So what follows evaluates not "a cat feeder built by an Agent," but the order chain along its path: how far the Agent can walk on its own, and which step requires a human to press the button.

The task was defined as follows: have an Agent team build an automatic feeder for a cat — enclosure, circuit board, firmware, App all included — with the human only confirming at the spending gates. The team's three Agent tracks (circuit, enclosure, firmware + App) run on Z.ai's open-source ZCode, with GLM-5.3 as the model. The board that was ordered is rev A, from my own pipeline: a script generates the spec into a KiCad board, auto-routes, and passes DRC; the ZCode team rebuilt it from the same reference spec in round one, and produced rev B (adding motor current sensing) in round two — rev B was not ordered because LCSC part numbers for the components hadn't been verified. Design and files are in the public repo fxp/cat-feeder (the repo stores only design and files, not payment or production records). Progress on the software side was good; §02 gives the numbers. What truly took time was the segment that turns design into money and into shipping labels.

I measured that segment once. The yardstick was written down before I started; §01 explains it.

Everyone uses the term "Agent native"; first I'll explain how this article uses it.

Consider a few existing formulations. Netlify's Mathias Biilmann proposed AX (Agent Experience), broken into three actions: can the agent discover what the service can do, can it reliably invoke it, and can it recover from errors. Anthropic's engineering blog discusses how to write tools for agents: make a small number of workflow-oriented tools rather than wrapping CRUD, and error messages should tell the agent what to do next. The MCP specification's tools section states that execution errors should use isError to provide feedback that lets the model self-correct, while "there should always be a human in the loop who can reject the call." These three sources describe the same kind of thing: machine-readable contracts, errors that point the way, and explicit human nodes. None provides a certification checklist, and Netlify's framework is still the vendor's framing.

My own yardstick is more homespun. Before starting, I had written a fulfillment interface in the proposal — for a manufacturer to plug in, it would need to implement six verbs: capability query, validation, quoting, order placement (with payment proof), tracking, and cancellation. That was for writing adapters; I didn't expect it to become a yardstick. Later, as orders went out one by one, I added two things learned from the orders: entry point (how to get a key, is there a test environment, do the terms allow machine use) and where the human steps in (payment, legal declaration, quality sign-off).

So the working definition for this article is:

A service is Agent native when every state transition can be completed by a caller with no human interface, relying on public, machine-readable conventions; and the transitions that must be performed by a human — payment, legal commitment, quality sign-off — are written as states in the protocol (a pending order, a checkout link), rather than hidden in some checkbox in the UI.

This is stricter than "has an API," and stricter than "can be automated by a browser." Unfolded into a five-rung ladder:

This is my grading, not an industry standard. The L4 row was written to reflect the best practices I've read, so Slant ranking first involves some circularity; whether it's truly "best" depends on the item-by-item facts in Table 2, not just this level. The six verbs plus two supplements become the columns of each table in §05–§07; §08 switches to a more general question (what has this service prepared for Agents) to measure another batch of platforms.

First I'll present the control group, because every "stuck" later must be viewed against it.

The team is three real Agent tracks (circuit, enclosure, firmware + App), running on ZCode, conversing via a team bus and a versioned shared contract. Numbers from the two real runs:

Round 1 wall-clock: 1,749 s; Round 2: 2,754 s, input 19.2 M tokens, output 0.26 M. The same PCB task was repeated individually five times: GLM-5.3 at reasoningLevel=high routed successfully 5/5, KiCad DRC 0 errors 0 unconnected; the default max tier only 3/5, with both failures due to reasoning timeout — one hitting the 1,500 s ceiling, the other severed by the upstream after 653 s on the first request.

"0 call failures" counts only the calls themselves, excluding domain errors: across those five runs there were 141 MCP calls, about 10% returning domain errors (illegal spec, DRC failure), all understood and fixed by the model — not a single pipeline issue.

Outputs were independently verified after the fact, without trusting the Agent's own reports: kicad-cli pcb drc on the exported board gave 0 errors 0 unconnected; firmware host tests 21 items 517 assertions passed, pio run compiled; App on simulator 33/33. Never flashed, never on a real phone; enclosure assembly checks used a box-estimation method, and of 32 parts, 30 had estimated dimensions. DRC passing doesn't mean the circuit is correct: a local small model reversed an LED on the first try, and DRC reported nothing.

These numbers make one point: when the counterparty is kicad-cli, headless Blender, PlatformIO, or similar local tools, the Agent almost never gets stuck. Their common trait: file in, file out, exit code speaks — no account, no money, no legal consequences. KiCad's official entry point for automation follows the same pattern: kicad-cli is primarily for reading and exporting; the IPC API in KiCad 9 and 10 can only connect to a running GUI, and only the PCB editor can load plugins. We stayed on the command line throughout; once, opening the KiCad GUI with a button on the real machine, we were blocked by macOS quarantine attributes.

Even the Agent's own "brain" has a step only a human can do: the first spike run exhausted the BigModel account balance (error code 1113), and the re-run happened only after I topped it up.

So when I say "got stuck" later, I always mean this class: has a counterparty, has money, has liability.

JLC is where real money was spent this time. Three orders totaling ¥361.99: one v1 board (no fiducials), one v2 board (with fiducials, prepped for SMT), plus the SMT order attached to v2. The v1 was actually a duplicate order: a board without fiducials won't be converted for SMT by the platform — a rule I discovered only after placing the order.

I first checked every step against the open platform. Interface coverage looks like this:

On the entry-point side there are a few things, each defensible on its own:

• The developer agreement (2024-09-14 version) allows personal registration. After creating an app, the key is shown only once; the caller's IP must be added to a console whitelist, otherwise 403 Request IP source invalid is returned — a home network's outgoing IP change breaks it, and so does using a proxy.
• No test environment: every successful creation is a real order.
• Article 3, §7, item 8 of the agreement requires JLC's consent before using a platform app for profit-making operations; Article 3, §6 prohibits using "JLC" or related names/marks in app names or promotional materials.
• I searched the full agreement text for "automation," "robot," "crawler," "artificial intelligence," "AI," "Agent," "intelligent agent," "script," "batch," "frequency," "rate limiting" — none found. This version has no rules for machine calls, and no rate limits specified.

So the real orders were placed through an Agent-driven browser in my logged-in account. This path worked, and also let me see what "L1" feels like:

• The shipping address popup is a blank iframe in the automated browser; the only workaround is to go to "Address Management" and use "Paste & Recognize" to fill in the district.
• Many controls are <div>s and <span>s, not buttons; popups and onboarding guides swallow clicks; refreshing the page resets the form.
• The header row of the BOM and coordinate Excel files gets treated as a component, producing an "abnormal non-mountable component" error.
• The submission page has a compliance declaration about US export control and sanctions commitments. Opening the reading popup and closing it automatically checks the box; you must manually uncheck it after reading. This declaration is the user's personal legal commitment — my rule is that I must explicitly agree; the Agent must not check it for me.

What bothers me most are two places where "the machine should have spoken, but no one did."

First, component orientation. In JLC's component library, SOT-23 (3-pin) and SOT-223 at 0° differ from KiCad by 180° — visible only in the SMT preview, not caught by DRC, and not exposed in the API. I found Q1 and U2 reversed in the preview, rotated each 180° in the web editor, and only then added offsets for these two footprints in the generator. Whether other footprints have the same offset, I haven't verified — every order requires a human eye on the preview.

Second, "can this design be SMT'd?" This is as clear-cut a validation question as they come, and the answer is a rule written on a help page — yet there's no corresponding endpoint. I paid for a duplicate order because of this.

To be fair, JLC doesn't lack Agent awareness. Its EDA team has put a whole row of Agent-facing things on GitHub: easyeda-client-cli (the client's built-in CLI, runnable as an MCP server), easyeda-api-skill, a WebSocket gateway extension, and a local "order check" extension that runs JLC DFM rules. JLC has done part of the PCB-process validation, placing it in the EDA client's extensions rather than the open platform's endpoints; whether SMT rules (fiducials, component orientation) are covered, I haven't checked.

JLCPCB's own two AI design blog posts (September 18, October 14) both discuss how to let an Agent operate the editor; where they mention ordering, it's about exporting Gerber, BOM, and pick-and-place, then uploading to JLCPCB for instant quoting after design verification. Neither post mentions an ordering endpoint.

One layer deeper: EasyEDA's extension API has four ordering methods — placePcbOrder, placeSmtComponentsOrder, placeComponentsOrder, and place3DShellOrder — all marked BETA, "do not use in production." They run the order check first, and if conditions are met, open the order page in a new tab and generate order data; the docs don't say they make payment. The CLI, its --mcp mode, and Skills can all reach them. I haven't run them; these methods would produce real order data. So JLC has connected the Agent to the canvas and to the cashier's door; the quoting and ordering endpoints are on open.jlc.com, which has no CLI, MCP, or Skill.

JLC's open platform itself isn't crude: signatures match the official example byte-for-byte, every response carries a J-Trace-ID, and business error codes are clear. It feels designed for a different kind of caller: someone who knows what they want to order and is willing to fill in the last few steps on the web. The Agent needs the reverse: before knowing the outcome, every step should have a machine-readable answer.

ZaoHaoWu (I also refer to it as Hi3D here; this correspondence was confirmed only by the integration partner — hi3d.ai's homepage brand wall includes ZaoHaoWu's logo, and its static assets are hosted on zaohaowu.net, but there's no official page explaining the relationship. Hi3D itself has a separate self-service developer API, which is a different matter — see §08) is another kind of L2.

A fair disclaimer first: it sells figurines, not manufacturing capability. I'm measuring it because the task needed a high-precision enclosure printing outlet, and it was the only domestic outlet I had with a test environment.

Its strengths are specific. There is an independent test environment (api-test.zaohaowu.com), and the entire path works: Basic auth exchanges for a 24-hour token; image-to-image submission goes from PROCESSING to SUCCESS in about 20 seconds; order/create carries a requestId for idempotency; order/fulfillment/batch queries fulfillment, with order statuses 0–7 and fulfillment statuses each enumerated; after order/cancel, the order reads "closed" and the fulfillment order reads "cancelled." Create, query, cancel — three verbs all passed on the real interface. When errors occur, it also speaks up: a forged image URL is rejected with 1003 Image URL invalid, please upload image first, a non-portrait photo with 5003 Please upload a portrait photo — both with readable reasons.

The gaps are equally specific:

• No quoting endpoint. The price in order/create is pass-through, not validated; prices come from a product catalog provided offline by the vendor. The Agent can't get a bindable "how much will this cost" number.
• Only portrait figurines. There's no field for submitting an STL or 3MF; imageUrl must be an image the vendor itself recognizes — object photos and renderings can't go in. It can't handle the cat feeder enclosure.
• Keys are issued offline: AK/SK, modelId, productId, skuId all are. Test credentials against the production domain return 40001; I still haven't obtained the production set.
• Payment is undocumented; in the test environment, placing an order shows "already paid."
• The API docs are in a Feishu document whose flowcharts are blank. Querying a nonexistent task returns 1000 System exception, not "not found."

I wrote a six-item requirements list for this (printable products with self-submitted models, model submission method, quoting, production credentials, payment method, size and review limits), which I haven't sent yet. Until they reply and I've placed a real order, I won't say "the Agent placed an order through Hi3D's API." All I can say is: in the test environment, create, query, and cancel passed.

The two domestic services side by side form an interesting complement: JLC's capabilities match but its interfaces are incomplete; ZaoHaoWu's interfaces are complete but its capabilities don't match.

Slant 3D is an FDM print farm in Boise, Idaho; its FAQ states that it prints in the US and ships from the US. In my original proposal I noted it as "the only one with self-service key acquisition," wrote an adapter against its OpenAPI, but never called it with a real key, and later didn't include it in the chain: it doesn't do circuit boards, and enclosures are US-shipped FDM. Coming back to read it this time, I found it had already added a second door.

Door one, REST API. The OpenAPI 3.0.3 spec (about forty operations) has this description: "This spec is for automated tools and AI Agents." It includes an x-agent-hints block that compresses the order flow into one line: upload file → draft order → process order → fulfillment → webhook. The draft order is explained as "price first, then process," the process order as "start production and charge," and cancellation is limited to "not yet started." The docs site also says the webhook carries an HMAC-SHA256 signature, retries every minute on failure, up to ten times. Among the manufacturing APIs I've read, this is one of the most complete lifecycles.

Its other side is equally blunt. Keys can only be generated by a human in a web session (POST /apiKey doesn't accept Bearer); once a human binds a card on the account page, POST /orders/{id} charges it in one shot. The spec has no idempotency key and no sandbox. This leaves the gate to the caller: Slant guarantees drafts don't charge; whether to charge is your program's decision.

Door two, public MCP. This is the segment I most want to talk about. https://www.slant3d.com/mcp requires no key, no login. The llms.txt says "AI agents can quote and order real 3D-printed parts in two ways," and the FAQ has a dedicated question: "Can an AI agent order a 3D print?" The answer is Yes.

I had the Agent run a read-only plus quoting test against it (October 20; no order placed, no address or email entered):

1. initialize and tools/list worked normally. 10 tools, each annotated: quote_raw_pricing is read-only; quote_set_quantity is marked as not touching the external world; list_* is marked idempotent.
2. quote_upload_part: upload a self-generated 20 mm cube (base64). One call returned: quote_id, bounding box, volume, and per-unit price, subtotal, setup fee, and lead time for 1, 100, and 1000 units (1 unit 3–5 business days, 100 units 5–7, 1000 units 2–3 weeks), plus print_feedback — running nine checks (mesh, flat orientation, chamfer, bottom text, wall thickness, thin column, spider-like, supports, support area), yielding one severity: warning suggestion to "add 1 mm bottom chamfer," and stating "can be ordered as-is." The response includes both text and structuredContent, plus a next_steps line telling the Agent which tool to call next.
3. quote_set_quantity: change to 5 units, get back new per-unit price and lead time.
4. Error paths: a nonexistent quote_id returns isError: true with just "Unknown quote_id."; an 18-byte garbage STL is rejected at the input validation layer, returning a validation array as-is.

I didn't call quote_shipping_options (requires name, address, email — I don't want to write personal info into a public service) or quote_checkout (requires email, generates a Stripe checkout link). Per their tool descriptions: shipping is saved on the quote; after paying via the checkout link, the order automatically enters the print farm and the customer receives a confirmation email. So shipping and checkout were read from descriptions, not tested.

It got four things right:

• Workflow as the unit, not the endpoint. quote_id threads upload, quantity change, shipping, and checkout into one line — exactly what Anthropic's article means by "make workflow-oriented tools."
• Annotations are part of the contract. Read-only, idempotent, whether it touches the external world — written on the tool, so the client can decide which calls need confirmation popups.
• Validation is structured output. Severity, title, fix suggestions, and an explicit statement that it doesn't block ordering. Compare JLC: the same kind of information there is a paragraph on a help page and marks you need a human to spot in the SMT preview.
• The human step is a step in the protocol. quote_checkout returns a payment link for a human to pay. The Agent knows when to stop and what to hand off to whom.

What it didn't get right: MCP has no tracking or cancellation — those two verbs are only in REST; error messages are too sparse — Unknown quote_id. doesn't tell the Agent what to do next; in the same response, part price $1.37 and per-unit price $2.77 coexist with unexplained field semantics (I couldn't figure out the difference); cancellation and refund rules are scattered across the spec, docs site, and user agreement with wording that is not entirely consistent — the spec says cancel before start, the docs site says cancel triggers refund, the user agreement says fees are non-refundable after start.

And its boundaries: the user agreement is a 2023 short document that doesn't mention API, automation, or AI; materials are PLA, PETG, carbon-fiber PETG, and OPM; printing and shipping are in the US; international shipping I haven't verified.

At this point, two questions have merged into one: at which step does the human appear, and in what form.

On my side I built a gate: the model has no "place order" tool, only quote and prepare-order-card; ordering can only go through an endpoint that issues a confirmation token, binding order intent, quote, vendor, price, file sha256, shipping address, and user; confirmation also requires a fresh WebAuthn (designed as Touch ID; real-device Touch ID not yet verified). This is my design. It requires the other side to hand me something bindable: a quote with an ID, price, and validity period, or a pending-payment order.

What the other side hands over looks like this:

The rightmost column — almost none of the vendors' public materials answer it.

The 2026 payment protocols have already laid the vocabulary. UCP's checkout state has requires_escalation, at which point the merchant must provide a continue_url and at least one message with severity requires_buyer_input or requires_buyer_review: when to stop and hand the link to the buyer is stated by a status field, not by guessing. ACP's session has pending_approval, plus quote_id, purchase_order_number, and payment terms. Stripe's wallet for agents requires the spending reason to be written as human-readable text, pending approval in Link, expiring after 30 minutes, retry with idempotency key, plus a never-charge test mode. The MCP spec also says there should always be a human in the loop who can reject the call. Related background in previous pieces: UCP, Agent Onboarding Gates (identity & payment), Offline Agentic Commerce (physical commerce).

But they all target catalog items: a shopping cart, a final price. In existing flows, I haven't found a "upload file, get price, then approve" custom-part example; ACP's schema has quote_id, UCP allows omitting payment during "generate quote, manage cart" — both leave hooks but no examples. Among the manufacturing service docs I've read, none mentions implementing any of these protocols. Among the services I've read, Slant's path from quote_id to checkout link is the only one that's public, keyless, callable right now, and used for custom parts.

Legal declarations are the other half of the same problem. JLC makes it a UI checkbox — opening and closing the reading popup auto-checks it, turning "read" into "agree," and an Agent in a loop reads it once and signs it. Shapeways goes to the other extreme: the model-upload endpoint has two required boolean fields, hasRightsToModel and acceptTermsAndConditions, for the caller to declare they have rights to the model and accept the terms. Written as fields, a machine can see them — but one line of code makes a commitment on behalf of a human, which is exactly what I want to prohibit. UCP's approach is worth copying: make "requires buyer review" a state; until that state is resolved, the flow doesn't proceed.

One more dimension: the more convenient, the looser. Lining up payment methods, there are three kinds:

• Human pays: link, page, or email (Slant MCP, JLC, PCBWay redirect page, OSH Park, Craftcloud redirect checkout);
• Pre-stored or credit: capped by balance or payment terms (JLCPCB International prepaid balance — inferred from error examples; PCBWay partner account; Craftcloud Net30);
• Card on file, charge on call (Slant REST, Shapeways; Shapeways docs state no spending limit).

The third kind is most convenient for the Agent, and also the loosest delegation. In physical-world APIs, defaults often speak louder than endpoints: Printful v2 makes orders start as drafts, requiring a separate confirm call to charge; Printify's new-store default auto-approves orders after 24 hours, entering production without an API call; Mouser's order endpoint has SubmitOrder=false, returning a summary without submitting. The Agent runtime side is the same: in ZCode's spike, -p mode defaults to yolo — on a disposable mock service, the Agent confirms an order with one curl line; user-level hooks can be bypassed four ways, and the Agent can even modify its own hooks; only the OS sandbox blocked every attempt. So the gate must live in a process the Agent can't reach — you can't rely on the service to place it for you, nor on the runtime.

Among catalog-type physical services, some already expose the full Agent path: Shippo's hosted MCP uses OAuth, no key copying; every docs page has an Agent instruction block; the docs state that buying a shipping label charges the account, and write operations require confirmation before execution. But a shipping label isn't a custom part — there's no "upload geometry, get price" step.

On the domestic payment side, "human pays" is done more thoroughly. Alipay's buyer-side alipay-bot and Skill require the Agent to show the order summary to the user, submit the payment, then stop and wait for the human to pay in the App; the merchant-side restricted key requires the primary account to enable it, uploading a public key requires SMS or payment password, and then checking off the allowed tools — unchecked tools can't be called. "Delegated payment," which lets the Agent directly charge within a pre-authorized limit, has its total, frequency, and validity set by the user in the App first; the Skill notes that contacting BD is required to enable it, still invitation-only. WeChat Pay's "per-transaction confirmation mode" requires a human to scan and enter the payment password for every order; the AI-specific card's funds are isolated from the main account. These two have productized the "pending-approval object" and "spending limit" described earlier.

The two tables below put what I read and tested together. ★ marks what I personally tested or practiced; the rest comes from public materials read on October 20, 2026; docs visible only after login I didn't read — written as "not seen" or "unknown," which doesn't mean they don't exist.

Table 1 · Entry points & contracts

Table 2 · Order lifecycle

Reading these tables, a few observations:

• "Cancel" is the most missing verb. Five of nine rows lack a customer-facing cancel endpoint: JLC, JLCPCB International, Craftcloud, Shapeways, and Slant's MCP.
• Among manufacturing services, the only test environment where the full create-to-cancel lifecycle is confirmed is ZaoHaoWu. PCBWay's help page mentions "test environment" but is unclear; Craftcloud has a flag bit. Catalog services like Lob's test mode commonly have one, so this isn't impossible — manufacturing just mostly hasn't provided one yet.
• A pricing hint. The price JLC's endpoint returns is lower than the web price — an "ordering assistant price" (I won't write the exact number: the developer agreement prohibits using platform data beyond the agreement's purpose; I'd rather be cautious). The seller is willing to discount for the API channel — they just haven't written terms for the Agent as a caller yet.
• Xometry is an interesting contrast. Its developer docs site has llms.txt, every page has a Markdown version, looking Agent-friendly — but it serves the supplier side; the buyer side has no public quoting or ordering API. Protolabs and Fictiv similarly lack public APIs.

The six verbs in §01 were designed for ordering. For a different class of service, the core actions change, and the question can be more general: what has this service prepared for Agents? This edition adds a batch of platforms: the already-mentioned JLC, Tripo3D, Hi3D, and Beisen, plus peers Feishu, DingTalk, Amap, Alipay, and WeChat Pay, and manufacturing-chain services not yet measured — LCSC, Huaqiu, Bambu Lab — with Meshy as a control. All use public materials from October 20, looking at seven things: official CLI, official MCP, official Skill, Agent-facing docs (llms.txt, Markdown), test environment, how write operations are approved, and whether the core action can be completed by the Agent on its own.

Verification was three-layered. For most domains I fetched llms.txt and .well-known manifests; for the main CLIs I checked npm registry info; for Hi3D's hosted MCP I connected and read the tool list — readable without credentials. The rest comes from each service's docs; login-gated docs weren't read, written as "not found" or "unknown."

Table 3 · Agent surfaces (2026-10-20 snapshot)

Levels are rough judgments after reading that day's materials, using the ladder from §01. For the borderline cases, here's the reasoning: DingTalk's docs surface reaches L4, but write operations rely on text conventions, so L3; Alipay's buyer side has per-transaction human payment, the same design as Slant in §05, so L4 — the merchant-side MCP is local and unannotated; Tripo3D lacks OpenAPI and a test environment but still gets L4 because its Agent surface was purpose-built for Agents.

Reading this table, a few observations:

• CLI + Skill + Markdown docs is the default configuration for this batch of platforms; MCP plays a supporting role. Feishu, DingTalk, Beisen, Tripo3D, Meshy, and JLC EDA all have official CLIs or Skills. Beisen has no MCP; Feishu's remote MCP is in beta, covering only cloud docs, and the local version's docs say "not recommended"; Tripo3D's MCP is a CLI subcommand. This is only a one-day snapshot — Beisen's CLI launched in August.
• Agent-facing docs fall into three tiers. The highest is DingTalk: llms.txt's first section is titled "Instructions for AI Agents," requiring the Agent to read skill.md first, stating not to guess endpoints from memory, and to stop and explain if permissions are missing; there's also a Skill discovery entry in agentskills.io format, plus 3,630 Markdown docs. The middle tier is Feishu, Tripo3D, Meshy, Alipay, WeChat Pay: llms.txt plus per-page .md. The lowest tier is JLC, LCSC, Huaqiu, Bambu Lab, Hi3D, Amap: none, or only a marketing blurb. Beisen sits between the middle and lowest: the CLI has an Agent-facing Markdown install guide, but the open platform docs are a web app with no llms.txt.
• "The human step" has five implementations. Feishu makes it a protocol: high-risk write commands return exit code 10 and a confirmation_required JSON; the Skill requires the Agent to show the operation to the user, wait for explicit consent, then add --yes; --dry-run previews without triggering the gate. Beisen's Skill contains the same envelope, but currently every CLI method is read-only — the gate is "reserved." DingTalk's CLI instructions tell the Agent to add --yes to skip confirmation; the constraint lives only as text in skill.md. Tripo3D and Meshy place the human at device-authorization login and top-up, with no per-transaction approval — the spending ceiling is the human's pre-charged balance. Alipay and WeChat Pay go the other way: every transaction is paid by a human in the App. This is the distinction from §06: one is a state, the other is an admonition.
• Test environments are still the minority. Feishu has test enterprises, Alipay has a sandbox, Meshy has a test key, DingTalk has only an "experience org," Hi3D has a trial resource pack; Beisen, Tripo3D, JLC, LCSC, WeChat Pay — not found. The manufacturing side was covered in §07; this side is similar.
• Agent surfaces are often only half-built. Beisen's CLI is entirely read-only; creating positions and scheduling interviews still goes through the old OpenAPI, with keys created by the tenant admin, no approval step, and no sandbox found. Amap's 15 MCP tools are all queries or link generators; ride-hailing requires a human to click. Hi3D has a hosted MCP, but only two tools — submit task and query task — with no annotations; submission deducts credits, and there's no 3D-printing order endpoint. DingTalk's CLI requires admin enablement first.
• Terms lag behind the Agent. DingTalk's developer agreement is from 2023, prohibits crawlers, allows only the functions listed in the docs, and has no AI clause; Tripo3D's terms stop at July 2025; Amap's agreement §3.4 explicitly prohibits use in model or algorithm training; Beisen's open platform agreement I couldn't find. The official CLI is already out, but the terms are still written for humans.
• A word's ambiguity. LCSC's API page is called /agent, and the endpoint path contains wmsc2agent — referring to the customer's business system integration, not an AI Agent.
• Meshy is the most complete in this batch: CLI, MCP, Skill, OpenAPI 3.1, llms-full.txt, test key, and free printability analysis. It's not in the "domestic platforms" list; it's here to give the yardstick an upper bound for comparison.

For service providers (each item has a counterexample from above):

1. Provide an upload endpoint, or allow URLs with hashes, and state the retention period. (JLC only accepts URLs; ZaoHaoWu has no model field)
2. A quote is an object, not a number: ID, validity period, bound file hash and address. (Slant has quote_id; Craftcloud has quoteId and cart expiry; ZaoHaoWu doesn't)
3. Expose validation as an endpoint, with graded output and suggestions; assembly rules count too: fiducials, component orientation. (Slant has print_feedback; JLC's rules are on help pages and in previews)
4. Test environment should follow the same path as production, including ordering and cancellation. (ZaoHaoWu has one; JLC doesn't)
5. Pending approval is a state, with an approval link attached; legal declarations should be "requires buyer review" messages, not checkboxes, and not boolean fields the caller can fill in themselves. (UCP's requires_escalation; counterexamples are JLC's auto-checked checkbox and Shapeways's boolean fields)
6. Cancel and refund are verbs, with fees stated in the response. (JLC's web cancellation incurs an engineering fee, but the endpoint lacks this verb; Slant's three docs are inconsistent)
7. Self-service keys with scope and quota support, not just one all-powerful key. (JLC's IP whitelist blocks outsiders, but also blocks users behind home networks and proxies)
8. Terms should explicitly address machine calls: rate limits, resale, branding, whether results can be used for training. Silence is harder to deal with than refusal. (JLC's agreement says nothing, yet requires consent for profit-making use; DingTalk's 2023 agreement likewise lacks AI clauses; Amap's §3.4 outright prohibits model training)
9. llms.txt should point to APIs, not forms, and speak to the Agent. (JLC's points to the order form; Slant's points to MCP and OpenAPI; DingTalk's first section is "Instructions for AI Agents")
10. Errors should say what to do next. When rejecting a request, tell the caller how to fix it. (Unknown quote_id. and 1000 System exception both fail this)
11. Write-operation gates should be states, not just admonitions. Feishu's high-risk writes return exit code 10 and confirmation_required; Beisen designed the envelope but hasn't shipped write methods; DingTalk's CLI instructions tell the Agent to just add --yes.

For people building Agents:

1. Write your own fulfillment interface as a yardstick first. Whichever verb the adapter lacks, that's the verb the vendor lacks.
2. Don't give the model ordering authority. Bind the gate to the quote, file hash, and address, and place it in a process the Agent can't reach. ZCode's default config doesn't block one curl line. The gate is the verifier, and verifiers are scarcer than generators — this is the main thread of "R&D in the AI Native Era", and this is another instance.
3. Use browser driving only for the last mile, and account for it as L1: log every human intervention. On this chain, I can count at least nine places requiring a human: creating the app and getting the key plus whitelisting, legal declaration, invoice header, top-up, per-transaction amount approval, post-payment polarity confirmation, buying off-the-shelf parts (motor, load cell), assembly, and flashing.
4. Beyond DRC, check vendor rules: fiducials, footprint rotation offsets, LCSC part numbers. DRC 0/0 means the geometry is correct, not the circuit.
5. Treat the vendor's preview as the last gate, especially for polarity and orientation.
6. When choosing a service, look first for CLI, Skill, and .md docs, then for MCP. This is my judgment after reading the §08 batch: the first three are more common, and can be verified locally.

• Didn't reach payment. Slant MCP's shipping and checkout link were only read from descriptions, not tested; on the REST side I have no key and didn't call any login-required endpoint. Whether to spend a few dollars, actually order a small part, and walk through the "human pays" step is the first thing to do next.
• JLC's create-order and progress endpoints were never actually called; they require a public file host and my confirmation for each payment. Whether web-placed orders are queryable via the API was also untested.
• ZaoHaoWu's production environment was never touched; price, shipping, and real fulfillment progress are all unverified; the requirements list for Hi3D hasn't been sent.
• Goods haven't arrived. Board, figurine, enclosure — none in hand, no hardware flashed or powered on. Post-payment DFM polarity confirmation was still pending as of the night of October 19.
• §08 platforms were all read-only on public materials; no registration, no credentialed calls. Hi3D's MCP I only did initialize and tools/list; EasyEDA's place*Order wasn't run; Beisen and Huaqiu's docs are behind gates; DingTalk dws's "official" status is based on DingTalk's own docs — its npm maintainer is a personal email; Feishu's remote MCP is in beta and I couldn't see tool annotations. This section is an October 20 snapshot; these entry points change weekly.
• Login-gated docs I didn't read: JLCPCB International and JLC's field-level docs, PCBWay's actual access requirements, Craftcloud's key source, Mouser and Nexar details are all behind gates. "Unknown" in the tables means genuinely unknown.
• Small sample, only one task tested. One board, one enclosure, one cat; team runs and spike used only GLM-5.3 — Claude or other endpoints weren't run. This is a rating of "entry points," not of delivery quality.
• My grading isn't a standard. With a different yardstick, the ranking could differ.

This piece looks at the service side: whether the entry point is open. The reverse side is covered in a separate piece, "When Can the Agent Move Into the Browser?", which measures how many paths a browser tab lets the Agent walk out through: 14 model endpoints' preflight all passed, but among 31 public URLs only 11 let the page read directly, and installing dependencies and SSH require self-hosted relays. Read together: the service side's entry point may be open, but the Agent side still needs to be able to walk out.

One thing I want to watch for: when the protocols that write "the human" in will first produce a custom-part example.

• My own experiments and probes: team two-round runs and spike report, JLC and ZaoHaoWu order records and endpoint tests, read-only probes of each domain's llms.txt and MCP (October 20). Public parts in fxp/cat-feeder; the rest in private repos.
• Public materials: each service provider's docs, specs, and protocol repos; links in text and tables; read date 2026-10-20 for all. §08's additional platforms were cross-checked against npm registry info and each domain's llms.txt and MCP manifests; evidence compiled in research/03 and research/04 notes.
• Pricing: JLC endpoint-returned price details are not cited; Slant's quote is the public MCP's response to a public quote request.
• This article does not include any order numbers, shipping addresses, phone numbers, outbound IPs, or keys.