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.

Coming soon. The Execution MCP is in development and will publish to @amps-ai/mcp on npm. The package is not yet listed. The patterns in Building agent UIs work against the Documentation MCP and the REST API directly.
The Execution MCP will let an agent call the Amps API on behalf of an authenticated user. Where the Documentation MCP grounds the agent in how the API works, the Execution MCP grounds the agent in acting on the API.

​
Distribution

The server will publish as the @amps-ai/mcp npm package. Install with npx, run as a stdio process for local agents (Claude Desktop, Cursor, Windsurf, Continue), or run as a hosted HTTP service for multi-tenant integrations (Vercel AI SDK, custom backends). 
// Coming soon: stdio installation in any MCP-aware client
{
  "mcpServers": {
    "amps": {
      "command": "npx",
      "args": ["-y", "@amps-ai/mcp"],
      "env": {
        "AMPS_API_KEY": "sk_live_..."
      }
    }
  }
}

​
Tool surface

Tools generate from the OpenAPI operations. Per resource:
  • list_battery, get_battery, push_battery
  • list_ev_charger, get_ev_charger, push_ev_charger
  • list_hvac, get_hvac, push_hvac
  • list_solar_inverter, get_solar_inverter
  • list_vehicle, get_vehicle
  • get_action, cancel_action
Plus helper tools that compose canonical primitives:
  • wait_for_action(actionId) polls get_action until terminal state, so the agent does not have to manage its own loop.
  • find_device(query) saves the agent a list-then-filter dance when the user names a device by alias rather than ID.
The 501 schedules surface is filtered out until /schedules ships, so the agent never gets a tool that always fails.

​
Auth model

Two layers of identity, one outbound API call. The integrator (you, the developer wiring the agent) holds the Amps API key. That key sits in the MCP server’s environment, never in the model’s context. Per-request, your application forwards the end-user’s identifier to the MCP server in a header. The MCP server proxies both to the Amps API: the API key as x-api-key, the user identity as x-user-id. Amps resolves the user against the integrator’s account and scopes the call accordingly. This means the model never sees a credential. The integrator’s API key stays server-side. End-users authenticate to your application; your application authenticates to Amps. For a hosted multi-tenant deployment, run the MCP server over streamable HTTP. One process serves every user. Per-request headers carry per-user identity. For a single-user local agent, run over stdio with a single user identifier baked into env.

​
Tool naming hygiene

Operation IDs on the Amps API are designed to read cleanly when generated as MCP tools. pushBattery becomes the push_battery tool. cancelAction becomes cancel_action. The agent thinks in canonical verbs that match the docs. The Execution MCP makes the patterns concrete. Each tool result is a canonical envelope, so:

​
What next

Documentation MCP

The companion surface for grounding an agent in the docs corpus. Live.

Self-describing responses

The contract the Execution MCP exposes to the model.

Confirmation gates

Why destructive tool calls do not free-fire from the model.

Canonical actions

The action shape every push tool will accept.