Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.amps.ai/llms.txt

Use this file to discover all available pages before exploring further.

You want your LLM to read and control devices on Amps. The Amps API is built for that, and the MCP surface gives you the on-ramp. Two parts make it work. The Amps API is self-describing: every response carries the schema that drives the next request. An agent reads one device, knows what it can do, and builds the next call without device-specific code. The same envelope drives generative UI: components are dumb, props lift straight from the response, one renderer covers every device.

​
Two MCP servers

Two surfaces, two jobs. Wire one, the other, or both.

Documentation MCP

Grounds your agent in the canonical vocabulary, the API contract, and the worked recipes. Hosted at https://docs.amps.ai/mcp. Live.

Execution MCP

Lets your agent call the Amps API on behalf of an authenticated user. Distributed as @amps-ai/mcp over npm. Coming soon.
The Documentation MCP is for reasoning: the agent searches the docs, reads the canonical recipes, learns the right verb to use. The Execution MCP is for action: the agent fires the call, reads the lifecycle, surfaces the result. The split matters. A coding agent that needs to write integration code only wants the docs surface. A user-facing agent that schedules charges and pushes battery actions needs both, or it’s flying blind on the contract.

​
The pattern: one envelope drives both

Every Amps response carries enough information for an agent to:
  1. Reason about what’s possible. A device read returns its supported commands, the parameters each command accepts with bounds and units, and the execution shapes (immediate, scheduled, windowed) that work. No second fetch to a /capabilities endpoint. The contract for that specific device ships in the same body as its state.
  2. Build the next request without ambiguity. Numeric parameters are Quantity envelopes carrying both value and unit. Send { "value": 80, "unit": "percent" }, not bare 80. The unit is part of the type, so a UI component can switch on it at the type layer.
  3. Self-correct from a rejection. A 422 returns the device’s current capability snapshot in the error details, in the same shape the GET returns. The agent rebuilds the body from the snapshot and retries. One round trip, no human in the loop.
The same envelope is also the input to the UI. A Quantity shape renders as a <Gauge>. A capability map renders as a <CapabilityControls> component. An error envelope renders as an <ErrorAlert>. The agent picks the primitive based on the response shape, the chat layer routes, the components stay dumb. This is what makes the surface mixed-mode. The user types natural language. The model plans tool calls. The UI streams placeholders while the calls fire. Real cards swap in when responses arrive. Destructive calls (push, cancel) gate behind a confirmation primitive that the user clicks. The whole flow is observable, auditable, and built on a contract the agent can introspect.

Self-describing responses

How capability introspection drives both reasoning and request building. The patterns work against any well-defined REST surface; Amps ships them by design.

Dynamic UI rendering

Shape-to-primitive mapping. One renderer covers every device family in the canonical model.

Confirmation gates

The destructive-action safety pattern. Push and cancel never free-fire from the model.

Documentation MCP

Plug an agent into the docs corpus. Search and shell-style query. Live.