Turn hardware documentation into a working communication layer in minutes. APIS generates the device-side code and the matching host-side API together, so any MCP-compatible AI agent or application can call your hardware directly.
Keeping device-side code and host integration code in sync requires constant manual effort. Each change on one side risks breaking the other. With APIS, both sides regenerate from the same source when the interface changes.
Calling a device function from an AI agent or application requires a structured, callable interface. Without one, engineers write the mapping layer by hand for every device. APIS generates that layer automatically from your hardware description.
Older industrial devices use bus protocols that modern software cannot reach directly. Replacing the hardware is expensive. APIS wraps the existing device in a standard interface, making it callable from any application or AI agent without touching the hardware.
Paste a text prompt, upload a requirements document, or provide an existing hardware description file—ARM SVD register map, CAN DBC database, or CANopen EDS file. APIS generates a JSON interface definition. You review and refine it before generating the output. The definition supports sized integers, floats, booleans, characters, and arrays of those types.
{
"interface": "MotorController",
"version": "1.0.0",
"methods": [
{ "name": "set_velocity", "params": [{ "name": "rpm", "type": "i32" }], "returns": "i32" },
{ "name": "get_status", "params": [], "returns": "i32" },
{ "name": "emergency_stop", "params": [], "returns": "i32" }
]
}
APIS generates the device-side communication layer in C/C++ and the host-side API in C or Python—both from the same JSON definition. The host library exposes functions that map directly to device functions. No translation layer to write. No mapping to maintain. Device and host verify their interface version at connection time; a mismatch returns an explicit error before any data is exchanged.
import apis_motor_controller as motor try: device = motor.connect("tcp://192.168.1.42:1234") except motor.VersionMismatchError: # device and host interfaces differ — regenerate before connecting raise
The generated Python host library is ready to use in any application. If you are connecting an AI agent, APIS also generates an MCP server that wraps the same library and exposes every device function as a callable tool. Claude Desktop, LangChain, LlamaIndex, and any other MCP-compatible agent work without additional integration code.
# Option A — use the Python API directly status = device.get_status() result = device.set_velocity(rpm=1500) # → 1500 i32 # Option B — connect an AI agent via the generated MCP server # 1. Discover device functions exposed by APIS as MCP tools tools = await mcp.list_tools() # → set_velocity, get_status, emergency_stop # 2. Agent decides autonomously which device function to call response = ollama.chat( model="llama3.2", messages=[{"role": "user", "content": "Set motor velocity to 1500 rpm"}], tools=tools ) # 3. Execute whatever the model decided to call on the device for call in response["message"]["tool_calls"]: await mcp.call_tool(call["function"]["name"], call["function"]["arguments"])
Generate the device-side test communication layer and the matching host testing API from the same definition. Both ends stay in sync. The host orchestrates multi-step test sequences, with an engineer-defined recovery handler on the device at each step.
Generate the device-side communication layer and a complete MCP server from a hardware description. Any MCP-compatible AI agent can discover and call your hardware without custom integration code.
Wrap legacy controllers, PLCs, and industrial devices in a standard software API without replacing the hardware. Connect equipment running older protocols to modern analytics and automation systems.
One JSON interface definition produces the device-side communication layer and the host API. When the interface changes, both ends regenerate from the same source. No manual synchronisation, no drift between device and host.
Device and host each carry the interface version. A mismatch at connection time returns an explicit error before any data is exchanged. Neither side operates on a mismatched interface.
Multi-step operations are composed as a chain on the host, serialized, and sent to the device in one transfer. The device executes each step in sequence without host involvement. Each step carries an engineer-defined recovery handler that runs on the device at the point of failure.
Hardware faults return typed error responses with a code and a description. Application and agent logic can branch on specific error codes without parsing strings or catching generic exceptions.
The interface supports callable methods and push streams. A stream delivers samples from device to host at the declared rate—no polling loop, no round-trip per sample.
APIS logs call timing, payload sizes, sampling frequencies, and failures across sessions. The analytics module runs locally as a host-side process—no external service required. It surfaces specific findings: redundant calls, oversized buffers, and measurable power waste.
Resilient command chains · Analytics — in active development.