Carbon's API and MCP: where reading a job ends and changing it begins

A production planner wants a morning list of jobs held up by missing materials. Pulling that list into a familiar planning screen is a sensible integration. Letting the same screen reschedule every flagged job without asking anyone is a different proposition. The first retrieves information. The second makes an operational decision, possibly on incomplete information.

Carbon’s API and MCP interfaces make both kinds of interaction possible in principle. Their value is not that an AI assistant can touch the ERP. It is that a team can decide which information should leave the application, which operations another tool may invoke, and whose identity is responsible when a record changes. That boundary deserves attention before the first automation is switched on.

Two ways into the same workflow

An API gives another application a defined way to talk to Carbon. An internal material staging tool, for example, could request the components required for a particular job. Carbon’s project documentation says its manufacturing operations are available over HTTP, with input validation and permission checks tied to the authenticated identity. Webhooks provide a separate event driven route for notifying other systems when something happens.

MCP presents operations as tools that an AI client can use. A planner might ask, “Which jobs are waiting for components today?” An assistant with the appropriate access could gather the relevant records and produce a short answer. Carbon describes its MCP tools as subject to the permissions of the user or key used for the connection. The presence of an MCP endpoint does not grant an assistant general authority over every order.

The distinction matters because a fluent answer can conceal a weak source. The assistant may phrase a summary convincingly even if an inventory record was updated late, a bill of materials has an old revision, or a job number refers to a different company. The interfaces provide a route into the system; they do not settle questions about data quality or approval by themselves.

A late fastener in a real planning conversation

Consider a hypothetical workshop building metal cabinets. Cut panels for one order are ready, but a fastener needed for assembly has not reached the stockroom. At the morning meeting, the planner needs the job identifier, the required component, the available quantity, and any recorded inbound delivery date. A small application using Carbon’s API could put these fields alongside the day’s work. An assistant using MCP could summarize the same records in ordinary language.

That summary should not immediately move the due date. Perhaps another stock location has the fasteners. Perhaps assembly can start with unaffected subassemblies. Perhaps the promised delivery date cannot move without a conversation with the customer. None of those possibilities can be inferred safely from a single “shortage” flag.

A useful first version is therefore deliberately narrow. The assistant can read selected records, cite job identifiers, and state when it queried the data. It cannot edit job dates, receive stock, or issue a purchase order. Once the team trusts what it sees, a specific write operation could be introduced with a separate approval step. Reusing one powerful credential for both reporting and scheduling would erase the very distinction the trial is meant to test.

Permissions need to survive a practical test

Carbon documents permission aware API and MCP access. To evaluate it in a real deployment, look beyond role names in a settings screen. Can a planning credential read only the relevant company’s orders? Could a supplier account see another customer’s materials? Does the same key allow changes to inventory quantities or cancellations? Exercise those questions with test records and a deliberately limited identity.

Keep credentials out of prompts and chat transcripts. Store them where the integration can retrieve them securely, and grant only the operations the use case needs. Recording who requested a change, when it happened and what the prior value was helps distinguish an assistant’s recommendation from an action actually carried out in the system. Even a technically valid update can be a poor decision if its business context was missing.

There is also a licensing boundary. Carbon’s current repository description says API keys and MCP are included in hosted Business and Enterprise plans, while self hosted use of those capabilities requires a commercial license. Publicly available source does not mean every interface is available under identical terms in every deployment. That question belongs in the feasibility check, not at the end of an integration project.

A small experiment with a meaningful stop condition

Start with one question: “Which assembly jobs scheduled for today are missing staged materials?” Write down what counts as scheduled, what “staged” means, and which material requirement revision applies. If the definitions are unclear, an API connection will deliver inconsistent answers more quickly rather than fixing them. Choose a few sample jobs and compare the API response to the records a planner sees inside Carbon.

Then ask the same question through an MCP connected assistant with read only access. Require it to show the job identifiers and the time of the query. If a component record cannot be found, a useful response says so instead of inventing a complete plan. Finally, try a request that would alter a record: “Move this job to tomorrow.” In a read only pilot, the correct result is that nothing changes. That is evidence of a working boundary, not a failed demonstration.

Only after the read path is dependable should the team decide which write operations deserve a controlled route. A proposed reschedule might be shown to a planner with the old and new dates, the reason, and the affected jobs before the update is submitted. Check the target record afterward. A tool response saying an operation was requested is not proof that the production plan was updated as intended.

The earlier article on Carbon’s integrated manufacturing model examined the appeal of keeping production functions close to one another. API and MCP address a different issue: how other tools cross into that model. The measure of a good connection is not the number of automated actions. It is whether the team can explain which data it used, which action was authorized, and how a mistaken decision would be caught.

Sources: Carbon’s project repository and Luke van Enkhuizen’s overview of open source tools for metal fabricators. The workshop scenario is illustrative. Verify current features and licensing terms before deployment.