DEVELOPER DOCUMENTATION / TYPESCRIPT SDK

The SDK source is public. The hosted contract is ready now.

Working Machines gives agents and applications a structured route to connected software. This guide separates what you can use in production today from the source SDK work that is still being packaged for a branded public release.

Hosted MCPSupported now for compatible agent clients with OAuth.

Hosted HTTP APISupported now for application code with a valid runtime token.

SDK sourcePublic now for review, local development, and contributions.

01 / RELEASE STATUS

Do not install a package that has not been released.

There is not yet a published npm package named @working-machines/sdk. The public repository contains the current TypeScript client source and its existing package identifiers. We will publish a branded package, stable imports, versioned migration notes, and a compatibility guarantee before recommending npm installation.

Use these today

Hosted MCP at https://app.workingmachines.dev/mcp
Hosted HTTP API and authenticated OpenAPI document
SDK source for local runtime development and review

Not released yet

npm install @working-machines/sdk
import { WorkingMachines } from "@working-machines/sdk"
A promise of hosted API compatibility for unreleased SDK imports

02 / CHOOSE YOUR SURFACE

Start with the interface your product actually needs.

MCP is the shortest path for an existing agent. HTTP is the stable choice for server-side applications. The source SDK is the path for contributors and self-hosted runtime teams while the branded hosted SDK is completed.

MCP

For Codex, Claude, ChatGPT, Cursor, and other OAuth-aware MCP clients.

MCP QUICKSTART

HTTP API

For your backend, internal service, or product integration with a runtime token.

HTTP REFERENCE

SDK source

For self-hosted runtime development, source review, tests, and contributions.

OPEN REPOSITORY

03 / HOSTED HTTP

A production-ready path for TypeScript applications.

Call the authenticated HTTP API from your server. Create a runtime API key in the Working Machines console, keep it in server-side environment variables, and send it only to the hosted runtime. Never ship a workspace key in browser code.

TYPESCRIPT / HTTP

const response = await fetch(
  "https://app.workingmachines.dev/v1/actions/github.get_current_user",
  {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.WORKING_MACHINES_TOKEN}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ input: {} }),
  },
);

if (!response.ok) throw new Error(await response.text());
const result = await response.json();

1. Connect accounts

Authorize the provider account in the dashboard before code attempts to execute an Action.

2. Inspect the Action

Use the catalog or Action guide to validate the ID, input shape, scopes, and side effects.

3. Execute and verify

Treat a successful HTTP response as an execution result to inspect, log, and present deliberately.

04 / MCP

Use the same boundary from an agent host.

MCP is the recommended integration for a user-operated agent. The client discovers Working Machines OAuth metadata, sends the user through authorization, and then invokes structured discovery and execution tools on the hosted endpoint.

MCP CONFIGURATION

{
  "mcpServers": {
    "working-machines": {
      "url": "https://app.workingmachines.dev/mcp"
    }
  }
}

For Codex, add the server and complete codex mcp login working-machines. For other clients, use their custom remote MCP connection flow. OAuth-capable clients should prefer OAuth over a copied bearer API key.

05 / SOURCE SDK

Run the source release locally.

The source repository is useful when you are contributing to the client, checking its generated types, or running a self-hosted runtime. It is not an instruction to depend on an unpublished Working Machines package in your production application.

SOURCE SETUP

git clone https://github.com/working-machines-lab/working-machines-sdk.git
cd working-machines-sdk
bun install
bun run check

What the check verifies

The SDK check runs linting, TypeScript validation, package builds, unit tests with coverage, and package type-resolution tests. Use it before opening a pull request or changing the runtime client contract.

READ THE SOURCE README

06 / EXECUTION BOUNDARY

The client requests work; Working Machines controls execution.

Use a narrow Action and connection identity for each task. This model avoids handing provider credentials to model context or application code, but it does not remove your responsibility to validate intent and handle returned data safely.

Credentials stay in the runtime

SDK and HTTP callers identify themselves to Working Machines. Provider OAuth tokens and API keys are held by the selected connection and are not returned to your process.

An Action is the contract

Use an Action ID and its input schema. Do not infer provider endpoints or pass a raw browser session into an agent. Inspect the action guide before a write or delete operation.

Connection choice is explicit

A workspace can have more than one account for the same app. Select the intended connection or let the runtime reject an ambiguous request instead of silently using the wrong identity.

Results are still data

The runtime protects credentials; your application remains responsible for displaying, storing, and forwarding action results safely after it receives them.

07 / NEXT STEPS

Build on a documented contract.

Start with the public interface that matches your deployment today. We will update this page when the branded npm package is published, including exact installation, imports, compatibility policy, and migration instructions.

OPEN WORKING MACHINES PLATFORM DOCUMENTATION SDK SOURCE