MCP endpoint

The API also speaks the Model Context Protocol, so an AI agent can query the platform without anyone writing a client for it.

POST https://api.fieldnode.app/mcp

Protocol revision: 2026-07-28
Server name: fieldnode-di
Authentication: the same PAT, in the same Authorization: Bearer header

server/discover and tools/list answer without a token, so a client can discover the surface before it has one. Every tools/call requires one, and runs as the token's owner with exactly that user's permissions — the same access checks as the REST endpoints, because the tools call the same code underneath rather than looping back through HTTP.

Browser callers are additionally checked against an Origin allow-list. A request with no Origin is not a browser and passes.

Tools

All 11 are read-only, non-destructive and repeatable. There are no write tools today.

Tool	What it does
`search_parts`	Find parts by a substring of their title or external reference — the way in when you have a name rather than an id.
`get_part`	One part by id, optionally with its metadata and attached files in the same call.
`search_rfqs`	Requests for quote your organisation is party to. Filter by role, lifecycle state and free text, or fetch one by id.
`search_offers`	Quotes your organisation is party to. `rfqId` is the step from a request to the quotes it received.
`search_orders`	Orders your organisation is party to. Filter by role, lifecycle state, part or factory, or fetch one by id. Costs are reported from your own side of the order.
`search_factories`	Factories by name, by capability, or by a part they could manufacture.
`search_users`	People in your own organisation, by name or email — the way from a person's name to the user id.
`search_roles`	The roles your organisation defines and the permissions each grants.
`search_audit_log`	Your organisation's audit log — who did what, when, and whether it was allowed. Administrators only.
`get_history`	What changed on one order, RFQ or part, and when — the fields that moved, newest first.
`lookup_reference_data`	Materials, processes, standards, categories, criticalities, manufacturing technologies and UNSPSC categories — each listable as well as resolvable by id.

The set is deliberately smaller than the endpoint list. Batch endpoints have no tool — calling one tool five times costs a model the same as one batch call, so batching would only make the choice of tool ambiguous.

How they compose

"Who could manufacture this part?" is one call: search_factories with the part's partId. The part's own material and technology are read from the part, so the match cannot be widened by leaving something out.

For the manual route, lookup_reference_data exists to turn a name in a prompt into a code the other tools accept. So "who can machine 6061-T6 to AS9100D?" is two calls:

lookup_reference_data with kind: "material" → the code for 6061-T6.
search_factories with view: "CONSUMER", that materialCode, and standardCode: "AS9100D".

Likewise search_parts → get_part, search_parts → search_rfqs with the part's id, search_rfqs → search_offers with the RFQ's id, and search_orders with that same part id for what was actually ordered — which is the whole commercial chain, from a drawing to a delivery.

get_history answers the question none of the others can: a part, an RFQ or an order records where it is, never where it passed through, so "when did this order reach production?" or "what changed on this RFQ last week?" is a history call rather than a second look at the resource. Four things to read its answers with:

It lists only fields this API publishes. A change to something the API withholds is not listed at all, so the history is of the resource as published, not of every write behind it.
BACKFILL is not a creation. Change capture began part-way through the platform's life, and everything older than that carries one synthetic baseline entry dated to its creation. Counting those as creations would report a birth for every resource on the same day.
It does not say who. The capture records the change, not the actor — search_audit_log is what answers "who", for an administrator of your own organisation.
Part history is restricted to the part's owner, which is narrower than reading the part itself: a published part is readable by anyone, but the revisions that led to it were private when they were made.

Read an offer's state before drawing a conclusion from it: a DRAFT the manufacturer has not sent and one the customer REJECTED are very different answers to "did we get a quote?".

search_users only ever searches your own organisation — there is no platform-wide people search. It returns the directory fields any colleague can already see; admin and phone, and the admin, permission and roleId filters, need organisation administration.

search_audit_log is the most sensitive tool here and the most tightly bound: it needs organisation administration for the whole tool rather than for some fields, and it is scoped to your own organisation in the query — there is no organisation argument to widen, in the tool or in the contract.

Roles run in both directions, one per tool, each returning the kind of thing the question asks for: search_roles with userId gives the roles one person holds, and search_users with roleId gives the people holding one role. The catalog itself is open to any member; the mapping needs administration, except a caller asking which roles they themselves hold.

Errors

A bad argument, an unknown id or a resource you may not read comes back as a tool error (isError: true) rather than a protocol error, because those are things a model can read and act on. A bad credential is the exception: it is answered as a transport-level 401, since no rephrasing of the arguments will fix it.