EightyOne capabilities

Every operation EightyOne exposes to code and agents. Each is one capability: the REST API (/api/v1, OpenAPI at /api/v1/openapi.json) and the MCP server (/mcp) are generated from these definitions, so they cannot disagree.

• MCP: read capabilities only for now. A capability is either a listed tool or reached through capabilities_search / capabilities_call; an agent sees only what its credential may run.

• Auth: Authorization: Bearer <API key> (or X-API-Key). The key's company is the company; a key acts as its owner, narrowed to the key's permissions.

• Errors: RFC 9457 application/problem+json with a stable code.

• Writes: send Idempotency-Key: <unique> to make a retry safe (24 h). Where marked, Prefer: dry-run runs the write, rolls it back and returns the planned changes.

Account

me.get: Who am I

The caller: the user this credential acts as, the company it is bound to, how it is calling (REST or MCP; human, agent or service account) and the permissions it actually has here (the union of the user's roles' groups ∩ the credential's permissions). Call it first to know what you can do.

REST: GET /api/v1/me · Permission: any member of the company · Effect: read · MCP: tool me_get

Output

Guides

guide.get: Read a guide

EightyOne concepts and how to read the data: the glossary, downtime, maintenance, production, inventory, quality, commissioning, what deserves attention, and this company's own guidance (topic "company"). Without a topic, lists the topics. Read the glossary before working on an unfamiliar area.

REST: GET /api/v1/guides · Permission: any member of the company · Effect: read · MCP: tool guide_get

Input

Output

guidance.list: List company guidance for agents

What the company's administrators tell every AI agent: company-wide guidance and notes on specific machines, work centers, products and task types, with any thresholds they set.

REST: GET /api/v1/guidance · Permission: any member of the company · Effect: read · MCP: via capabilities_call

Output: { data, pagination }, each item:

guidance.set: Set company guidance for agents

Write the guidance agents get for the company, or for one machine, work center, product or task type. Replaces that subject's text; the previous version is kept in the audit log. Every agent connected to the company follows it.

REST: PUT /api/v1/guidance · Permission: ai_guidance:manage · Effect: write · Idempotency-Key: accepted · Dry run: supported · MCP: no

Input

Output

guidance.delete: Remove company guidance for agents

Remove the guidance for the company or one subject. The audit log keeps what it said.

REST: DELETE /api/v1/guidance · Permission: ai_guidance:manage · Effect: destructive · Idempotency-Key: accepted · Dry run: supported · MCP: no

Input

Tasks

tasks.list: List tasks

Tasks, newest first. Everything in EightyOne is a task (work-order operations, maintenance, inspections, NCRs, approvals…). Open tasks only unless a status is given or includeCompleted=true. Without the 'See all tasks' permission you see only tasks assigned to you, plus your teams' tasks with 'See tasks for my team'.

REST: GET /api/v1/tasks · Permission: any member of the company · Effect: read · MCP: tool tasks_list

Input

Output: { data, pagination }, each item:

tasks.get: Get a task

One task by its id.

REST: GET /api/v1/tasks/:id · Permission: any member of the company · Effect: read · MCP: tool tasks_get

Input

Output

tasks.create: Create a task

Create a task of a task type, exactly as the dashboard does: the type's defaults apply (SLA due date, default assignee, transit, created-as-ready), and the task.created webhook fires. Needs 'Create tasks' unless the type is user-generated.

REST: POST /api/v1/tasks · Permission: any member of the company · Effect: write · Idempotency-Key: accepted · Dry run: preview (checks the change and lists its effects, without making it) · MCP: tool tasks_create

Input

Output

tasks.update: Update a task

Change a task, with the dashboard's rules: status changes need 'Change task status from mobile' (assignees may still complete their own work), reassigning needs 'Reassign tasks', blocked tasks can't progress, producing tasks complete with goodQuantity / scrapQuantity (counts during the run: tasks_record_counts), maintenance types may need failure codes (problemCodeId, causeCodeId, remedyCodeId) to complete, 'incomplete' needs a reason and can create a follow-up (createFollowUp), 'declined' needs a reason. Tasks sent to a partner only accept details, dueDate and priorityId.

REST: PATCH /api/v1/tasks/:id · Permission: any member of the company · Effect: write · Idempotency-Key: accepted · Dry run: preview (checks the change and lists its effects, without making it) · MCP: tool tasks_update

Input

Output

tasks.record_counts: Record production counts

Add good and scrap quantities to a running work-order operation or producing task, as operators do from the app. Counts add up and feed OEE; the output posts to stock once, when the task completes. To count at completion instead, pass goodQuantity / scrapQuantity to tasks.update with the status.

REST: POST /api/v1/tasks/:id/counts · Permission: any member of the company · Effect: write · Idempotency-Key: accepted · Dry run: supported · MCP: tool tasks_record_counts

Input

Output

tasks.connect: Connect two tasks

Link two tasks. 'dependency': the second waits for the first. It can't progress until the first is done, and goes back to open if it was already ready or dispatched (it becomes ready if the first is already done). 'follow': only records that the second follows the first. Connections are removed in the dashboard.

REST: POST /api/v1/tasks/:from/connections · Permission: any member of the company · Effect: write · Idempotency-Key: accepted · Dry run: supported · MCP: tool tasks_connect

Input

Output

tasks.delete: Delete a task

Delete a task, as the dashboard does: a task you sent to a partner withdraws the handoff; a task a partner sent you can't be deleted (decline it instead).

REST: DELETE /api/v1/tasks/:id · Permission: tasks:delete · Effect: destructive · Idempotency-Key: accepted · Dry run: not supported · MCP: no

Input

tasks.get_form: A task's form

The fields a task's form records, in order: type, whether it's required, the choices of a select, the limits of a measurement, whether a condition hides it, and the current answer. Answer them with tasks_submit_form.

REST: GET /api/v1/tasks/:id/form · Permission: any member of the company · Effect: read · MCP: tool tasks_get_form

Input

Output

tasks.submit_form: Fill in a task's form

Answer a task's form fields by title (tasks_get_form lists them), and optionally complete the task (status done or submitted) or mark it incomplete, as the app does. Completing needs every required field; measurements outside their limits open an NCR; machine-status fields set the machine's status. Counts and failure codes go with the completion, as in tasks_update. Preview it first.

REST: POST /api/v1/tasks/:id/form · Permission: any member of the company · Effect: write · Idempotency-Key: accepted · Dry run: preview (checks the change and lists its effects, without making it) · MCP: tool tasks_submit_form

Input

Output

Task types

task_types.list: List task types

The company's task types: the templates every task is created from (work orders' operations, maintenance, NCRs, inspections, approvals…), alphabetically. Use a type's id as typeId when creating a task.

REST: GET /api/v1/task-types · Permission: any member of the company · Effect: read · MCP: tool task_types_list

Input

Output: { data, pagination }, each item:

task_types.get: Get a task type

One task type by its id.

REST: GET /api/v1/task-types/:id · Permission: any member of the company · Effect: read · MCP: tool task_types_get

Input

Output

Teams

teams.list: List teams

The company's teams, alphabetically, with their members' personnel ids. A task belongs to its task type's team: team members with 'See tasks for my team' see those tasks and can take them in the field.

REST: GET /api/v1/teams · Permission: any member of the company · Effect: read · MCP: via capabilities_call

Output: { data, pagination }, each item:

teams.create: Create a team

Create a team, optionally with its members. Point task types at it to give it work.

REST: POST /api/v1/teams · Permission: settings:manage · Effect: write · Idempotency-Key: accepted · Dry run: supported · MCP: no

Input

Output

teams.update: Update a team

Rename or recolor a team, or replace its members (memberIds). Only the fields sent change. Members see the team's tasks at once.

REST: PATCH /api/v1/teams/:id · Permission: settings:manage · Effect: write · Idempotency-Key: accepted · Dry run: supported · MCP: no

Input

Output

teams.delete: Delete a team

Delete a team and its memberships. Refused while a task type still belongs to it: move those types to another team (or none) first.

REST: DELETE /api/v1/teams/:id · Permission: settings:manage · Effect: destructive · Idempotency-Key: accepted · Dry run: supported · MCP: no

Input

Clients

clients.list: List clients

The company's clients (the customers whose sites and SSUs work happens at), newest first. Filter by name or active flag.

REST: GET /api/v1/clients · Permission: any member of the company · Effect: read · MCP: tool clients_list

Input

Output: { data, pagination }, each item:

clients.get: Get a client

One client by your id for it.

REST: GET /api/v1/clients/:id · Permission: any member of the company · Effect: read · MCP: tool clients_get

Input

Output

clients.create: Create a client

Create a client with your own id for it (used to address it afterwards). Fires the client.created webhook.

REST: POST /api/v1/clients · Permission: clients:manage · Effect: write · Idempotency-Key: accepted · Dry run: supported · MCP: no

Input

Output

clients.update: Update a client

Change any of a client's fields; only the fields sent change.

REST: PATCH /api/v1/clients/:id · Permission: clients:manage · Effect: write · Idempotency-Key: accepted · Dry run: supported · MCP: no

Input

Output

clients.delete: Delete a client

Delete (archive) a client. Its history is kept.

REST: DELETE /api/v1/clients/:id · Permission: clients:manage · Effect: destructive · Idempotency-Key: accepted · Dry run: supported · MCP: no

Input

SSUs

ssus.list: List SSUs

The company's SSUs (sub-site units: machines, assets, locations within a site), newest first.

REST: GET /api/v1/ssus · Permission: any member of the company · Effect: read · MCP: tool ssus_list

Input

Output: { data, pagination }, each item:

ssus.get: Get an SSU

One SSU by its external id, with the company's guidance note on it for agents (if any): read it before drawing conclusions about this machine.

REST: GET /api/v1/ssus/:id · Permission: any member of the company · Effect: read · MCP: tool ssus_get

Input

Output

ssus.update: Update an SSU

Change an SSU's name, image, active flag, default flag or location. Making it the default unsets the default on the other SSUs of its sites.

REST: PUT /api/v1/ssus/:id · Permission: clients:manage · Effect: write · Idempotency-Key: accepted · Dry run: supported · MCP: no

Input

Output

Inventory

line_items.find_ssu_by_barcode: Find the SSU holding a scanned unit

Resolve a scanned line-item barcode to the SSU (machine / location) whose storage unit holds it. 404 when the unit, its storage unit or that storage unit's SSU is unknown.

REST: GET /api/v1/line-items/ssu · Permission: any member of the company · Effect: read · MCP: tool line_items_find_ssu_by_barcode

Input

Output

stock_transactions.list: Export stock movements

The stock movement ledger (consumption, receipts, transfers, shipments), newest first, for pull-based ERP sync. Quantities only.

REST: GET /api/v1/stock-transactions · Permission: inventory:view · Effect: read · MCP: tool stock_transactions_list

Input

Output: { data, pagination }, each item:

inventory.stock_levels: Stock on hand

Goods on hand per product and storage site (up to 2000 rows), by the same rule reordering uses: good stock only (not the bads bin), not counting stock held by a partner. Filter by product id, SKU or storage site.

REST: GET /api/v1/inventory/stock-levels · Permission: inventory:view · Effect: read · MCP: tool inventory_stock_levels

Input

Output: { data, pagination }, each item:

inventory.reorder_suggestions: Reorder suggestions

Products below their minimum or at their dynamic reorder point (lead time × measured consumption), with the suggested quantity and vendor. Quantities and days only.

REST: GET /api/v1/inventory/reorder-suggestions · Permission: products:view · Effect: read · MCP: tool inventory_reorder_suggestions

Output: { data, pagination }, each item:

storage_units.list: List storage units

Where stock sits: each storage unit (shelf, rack, bay, dock…) with its storage site and whose it is: warehouse or site (the company's own), client, personnel (a technician's van), customer_consigned, partner.

REST: GET /api/v1/storage-units · Permission: inventory:view · Effect: read · MCP: tool storage_units_list

Input

Output: { data, pagination }, each item:

storage_units.get: What's in a storage unit

A storage unit and everything in it: per product, bin (goods / bads / quarantine), lot and serial.

REST: GET /api/v1/storage-units/:id · Permission: inventory:view · Effect: read · MCP: tool storage_units_get

Input

Output

stock.transfer: Move stock

Move stock between storage units, or between bins in one unit, as the dashboard's transfers do: name the product by SKU, and the lot or serial when it's tracked. It can't move more than is there. Needs 'Manage inventory'.

REST: POST /api/v1/stock/transfers · Permission: inventory:manage · Effect: write · Idempotency-Key: accepted · Dry run: preview (checks the change and lists its effects, without making it) · MCP: tool stock_transfer

Input

Output

purchase_orders.list: List purchase orders

Purchase orders (purchase requests): vendor, status, and each line's product, quantity ordered and received. Quantities only: EightyOne holds no prices.

REST: GET /api/v1/purchase-orders · Permission: any member of the company · Effect: read · MCP: tool purchase_orders_list

Input

Output: { data, pagination }, each item:

purchase_orders.receive: Receive against a purchase order

Book what arrived: per PO line, the quantity and the storage unit it goes to (with the lot for lot-tracked products). An inspection plan for the product or vendor puts it in quarantine and opens an inspection task. Can't receive more than ordered. Needs 'Receive inventory'. Preview it first.

REST: POST /api/v1/purchase-orders/:id/receive · Permission: inventory:receive · Effect: write · Idempotency-Key: accepted · Dry run: preview (checks the change and lists its effects, without making it) · MCP: tool purchase_orders_receive

Input

Output

customers.list: List customers

A factory's customers, who shipments go to: name, reference and ship-to address.

REST: GET /api/v1/customers · Permission: inventory:view · Effect: read · MCP: tool customers_list

Output: { data, pagination }, each item:

shipments.list: List shipments

Shipments to customers, newest first: draft (being prepared), shipped or cancelled.

REST: GET /api/v1/shipments · Permission: inventory:view · Effect: read · MCP: tool shipments_list

Input

Output: { data, pagination }, each item:

shipments.get: Get a shipment

A shipment with its lines.

REST: GET /api/v1/shipments/:id · Permission: inventory:view · Effect: read · MCP: tool shipments_get

Input

Output

shipments.create: Prepare a shipment

Draft a shipment to a customer: per line the SKU, quantity and the storage unit it ships from (and the lot for lot-tracked products). Nothing leaves stock until shipments_ship. Factories only. Needs 'Manage inventory'.

REST: POST /api/v1/shipments · Permission: inventory:manage · Effect: write · Idempotency-Key: accepted · Dry run: supported · MCP: tool shipments_create

Input

Output

shipments.ship: Ship it

Confirm a draft shipment left: each line's goods come out of stock, written to the customer. For a customer that is an EightyOne company, the goods arrive in their transit. Refused if any line lacks the stock, names a lot that isn't available, or takes another customer's consigned stock. Needs 'Manage inventory'. Preview it first.

REST: POST /api/v1/shipments/:id/ship · Permission: inventory:manage · Effect: write · Idempotency-Key: accepted · Dry run: preview (checks the change and lists its effects, without making it) · MCP: tool shipments_ship

Input

Output

shipments.cancel: Cancel a draft shipment

Cancel a shipment that hasn't shipped. Nothing moves: a draft holds no stock. Needs 'Manage inventory'.

REST: POST /api/v1/shipments/:id/cancel · Permission: inventory:manage · Effect: write · Idempotency-Key: accepted · Dry run: supported · MCP: tool shipments_cancel

Input

Output

inventory_counts.list: List cycle counts

Cycle counts, newest first: which storage unit, status (draft, in_progress, completed = finalized and waiting to be reconciled, reconciled) and totals. inventory_counts_get shows the lines and discrepancies.

REST: GET /api/v1/inventory-counts · Permission: inventory:view · Effect: read · MCP: tool inventory_counts_list

Input

Output: { data, pagination }, each item:

inventory_counts.get: Get a cycle count

A cycle count with its lines: expected (on hand by the system), counted, the discrepancy once finalized, and whether stock moved while it was open (a reason to recount rather than adjust).

REST: GET /api/v1/inventory-counts/:id · Permission: inventory:view · Effect: read · MCP: tool inventory_counts_get

Input

Output

inventory_counts.create: Start a cycle count

Open a count of one storage unit. It snapshots what the system expects there, and when the company has an inventory task type it also creates the count task operators fill in from the app. Needs 'Manage inventory'.

REST: POST /api/v1/inventory-counts · Permission: inventory:manage · Effect: write · Idempotency-Key: accepted · Dry run: supported · MCP: tool inventory_counts_create

Input

Output

inventory_counts.record_lines: Record counted quantities

Add what someone counted to an open count, by SKU (and bin, lot or serial where it matters). Quantities add to what was already counted for that line, as in the dashboard. Then finalize it. Needs 'Manage inventory'.

REST: POST /api/v1/inventory-counts/:id/lines · Permission: inventory:manage · Effect: write · Idempotency-Key: accepted · Dry run: supported · MCP: tool inventory_counts_record_lines

Input

Output

inventory_counts.finalize: Finish a cycle count

Close counting: each line's expected quantity becomes what's on hand now, discrepancies are computed, and anything on hand the count never saw becomes a line counted 0. Nothing is posted to stock until it's reconciled. Needs 'Manage inventory'.

REST: POST /api/v1/inventory-counts/:id/finalize · Permission: inventory:manage · Effect: write · Idempotency-Key: accepted · Dry run: supported · MCP: tool inventory_counts_finalize

Input

Output

inventory_counts.reconcile: Post a cycle count to stock

Decide each line of a finalized count and post it. accepted: stock becomes the counted quantity; adjusted: becomes adjustedQuantity; ignored (and any line not listed): stock stays as the system has it. Every write-off needs an adjustment reasonCodeId (reason_codes_list kind adjustment). Needs 'Manage inventory' and 'Adjust inventory'. Preview it first: it lists each addition, write-off and bin move.

REST: POST /api/v1/inventory-counts/:id/reconcile · Permission: inventory:manage + inventory:adjust · Effect: write · Idempotency-Key: accepted · Dry run: preview (checks the change and lists its effects, without making it) · MCP: tool inventory_counts_reconcile

Input

Output

Production

work_orders.list: List work orders

The company's work orders, newest first, optionally by status. Use for ERP pull-sync or to see what production is working on.

REST: GET /api/v1/work-orders · Permission: production:view · Effect: read · MCP: tool work_orders_list

Input

Output: { data, pagination }, each item:

work_orders.get: Get a work order

One work order with its operations (the traveler's tasks) and their status.

REST: GET /api/v1/work-orders/:externalId · Permission: production:view · Effect: read · MCP: tool work_orders_get

Input

Output

work_orders.release: Release a work order

Release a draft work order to the floor: one operation task per routing step, each on the only machine of its work center when there is just one, with the type's parameters pinned and later steps waiting for gates. Needs 'Release work orders'. Preview it with dryRun first: it lists the operations it creates.

REST: POST /api/v1/work-orders/:externalId/release · Permission: work_orders:release · Effect: write · Idempotency-Key: accepted · Dry run: preview (checks the change and lists its effects, without making it) · MCP: tool work_orders_release

Input

Output

work_orders.upsert: Create or update a work order (ERP orders in)

Idempotent on externalSystemId: a new id creates a draft order; re-sending updates it while it is still a draft and is a no-op afterwards. Lands on the product's released routing when there is exactly one. Release it with work_orders.release.

REST: POST /api/v1/work-orders · Permission: production:manage · Effect: write · Idempotency-Key: accepted · Dry run: supported · MCP: no

Input

Output

work_orders.batch_upsert: Create or update many work orders

Upsert up to 500 orders; each succeeds or fails on its own (results in input order).

REST: POST /api/v1/work-orders/batch · Permission: production:manage · Effect: write · Idempotency-Key: accepted · Dry run: supported · MCP: no

Input

Output

Webhooks

webhooks.list: List webhooks

The company's webhook subscriptions.

REST: GET /api/v1/webhooks · Permission: api_keys:view · Effect: read · MCP: via capabilities_call

Input

Output: { data, pagination }, each item:

webhooks.event_types: List webhook event types

Every event a webhook can subscribe to, with what triggers it.

REST: GET /api/v1/webhooks/events · Permission: api_keys:view · Effect: read · MCP: via capabilities_call

Output

webhooks.create: Create a webhook

Subscribe a URL to events. Deliveries are Standard Webhooks messages signed with EightyOne's Ed25519 key: verify them with the public keys at /api/v1/webhook-signing-keys. There is no secret to store.

REST: POST /api/v1/webhooks · Permission: webhooks:manage · Effect: write · Idempotency-Key: accepted · Dry run: not supported · MCP: no

Input

Output

webhooks.get: Get a webhook

One webhook subscription.

REST: GET /api/v1/webhooks/:id · Permission: api_keys:view · Effect: read · MCP: via capabilities_call

Input

Output

webhooks.update: Update a webhook

Change a webhook's name, URL, events, headers or active flag.

REST: PATCH /api/v1/webhooks/:id · Permission: webhooks:manage · Effect: write · Idempotency-Key: accepted · Dry run: not supported · MCP: no

Input

Output

webhooks.delete: Delete a webhook

Remove a webhook subscription.

REST: DELETE /api/v1/webhooks/:id · Permission: webhooks:manage · Effect: destructive · Idempotency-Key: accepted · Dry run: not supported · MCP: no

Input

webhooks.delivery_logs: Webhook delivery log

Recent deliveries of one webhook with their status, response and timing.

REST: GET /api/v1/webhooks/:id/logs · Permission: api_keys:view · Effect: read · MCP: via capabilities_call

Input

Output: { data, pagination }, each item:

webhooks.test: Send a test event

Queue a test delivery to THIS webhook only: a signed message of type webhook.test, to check your endpoint and its signature verification.

REST: POST /api/v1/webhooks/:id/test · Permission: webhooks:manage · Effect: write · Idempotency-Key: not accepted · Dry run: not supported · MCP: no

Input

Output

webhooks.retry_delivery: Retry a delivery

Re-send one logged delivery of this webhook.

REST: POST /api/v1/webhooks/:id/logs/:logId/retry · Permission: webhooks:manage · Effect: write · Idempotency-Key: not accepted · Dry run: not supported · MCP: no

Input

Output

Partner network

handoffs.send: Send a task to a partner company

Hand one of your tasks to another EightyOne company (by its short name, or a partner subcontractor). The partner gets its own copy; your people come off the task. Goods can travel with it (items), and a data-request task carries the scopes it asks for.

REST: POST /api/v1/handoffs · Permission: handoffs:send · Effect: write · Idempotency-Key: accepted · Dry run: supported · MCP: tool handoffs_send

Input

Output

handoffs.list: List handoffs

Tasks you sent to, or received from, partner companies (newest first, up to 500).

REST: GET /api/v1/handoffs · Permission: handoffs:send · Effect: read · MCP: via capabilities_call

Input

Output: an array of

handoffs.get: Get a handoff

One handoff from your side.

REST: GET /api/v1/handoffs/:id · Permission: handoffs:send · Effect: read · MCP: via capabilities_call

Input

Output

handoffs.timeline: Handoff timeline

What happened on a handoff, in order; your own people are named, the partner's are not.

REST: GET /api/v1/handoffs/:id/timeline · Permission: handoffs:send · Effect: read · MCP: via capabilities_call

Input

Output: an array of

handoffs.decline: Decline a received handoff

Decline a task a partner sent you, with a reason they will see.

REST: POST /api/v1/handoffs/:id/decline · Permission: handoffs:send · Effect: write · Idempotency-Key: accepted · Dry run: supported · MCP: tool handoffs_decline

Input

Output

handoffs.withdraw: Withdraw a sent handoff

Take back an active handoff you sent; the partner's copy is removed.

REST: DELETE /api/v1/handoffs/:id · Permission: handoffs:send · Effect: destructive · Idempotency-Key: accepted · Dry run: not supported · MCP: no

Input

partner_deliveries.list: List partner deliveries

Goods sent to or received from partner companies, from your side.

REST: GET /api/v1/partner-deliveries · Permission: handoffs:send · Effect: read · MCP: via capabilities_call

Input

Output: an array of

partner_deliveries.get: Get a partner delivery

One delivery from your side.

REST: GET /api/v1/partner-deliveries/:id · Permission: handoffs:send · Effect: read · MCP: via capabilities_call

Input

Output

partner_deliveries.receive: Receive a partner delivery

Book goods a partner sent you into stock, line by line (damaged quantities go to the bads bin), optionally reporting the rest missing.

REST: POST /api/v1/partner-deliveries/:id/receive · Permission: handoffs:send + inventory:receive · Effect: write · Idempotency-Key: accepted · Dry run: supported · MCP: tool partner_deliveries_receive

Input

Output

data_packages.list: List data packages

Traceability data packages you released to, or received from, partners.

REST: GET /api/v1/data-packages · Permission: handoffs:send · Effect: read · MCP: via capabilities_call

Input

Output: an array of

data_packages.get: Get a data package

A data package's content, with short-lived links to its photos.

REST: GET /api/v1/data-packages/:id · Permission: handoffs:send · Effect: read · MCP: via capabilities_call

Input

Output

Analytics

analytics.overview: Factory performance overview

Headline numbers for a window: total downtime, failures, average availability and OEE, and how many machines are monitored. unavailableMetrics names OEE factors with no source data yet. Start here, then drill into analytics.downtime / analytics.reliability.

REST: GET /api/v1/analytics/overview · Permission: insights:view · Effect: read · MCP: tool analytics_overview

Input

Output

analytics.downtime: Downtime by machine

Time each machine (SSU) spent DOWN or in MAINTENANCE in the window, most first, with how many times it entered that state. For the reasons, follow up with downtime_events.list (reason-coded stoppages) or storylines.ssu (the machine's story).

REST: GET /api/v1/analytics/downtime · Permission: insights:view · Effect: read · MCP: tool analytics_downtime

Input

Output: { data, pagination }, each item:

analytics.reliability: Machine reliability (MTTR / MTBF)

Per machine: failures (entries into DOWN), mean time to repair and mean time between failures, in seconds, most failures first.

REST: GET /api/v1/analytics/reliability · Permission: insights:view · Effect: read · MCP: tool analytics_reliability

Input

Output: { data, pagination }, each item:

analytics.oee: OEE by machine

Overall equipment effectiveness per machine: availability, performance and quality (0–1) with good / scrap quantities. A factor is null when its source data is missing (no routed work, no counts).

REST: GET /api/v1/analytics/oee · Permission: insights:view · Effect: read · MCP: tool analytics_oee