> ## 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. # Working with agents > Wire agents into Amps with two MCP servers. Ground them in the docs corpus. Drive UIs from self-describing API responses. Mixed-mode, agent-native. 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. Grounds your agent in the canonical vocabulary, the API contract, and the worked recipes. Hosted at `https://docs.amps.ai/mcp`. Live. 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 ``. A capability map renders as a `` component. An error envelope renders as an ``. 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. ## What to read next How capability introspection drives both reasoning and request building. The patterns work against any well-defined REST surface; Amps ships them by design. Shape-to-primitive mapping. One renderer covers every device family in the canonical model. The destructive-action safety pattern. Push and cancel never free-fire from the model. Plug an agent into the docs corpus. Search and shell-style query. Live.