amnt docs
Developers

Changelog

What changed in the amnt developer API and MCP server, newest first, with the versioning rules.

Breaking changes get a new version in the path — never a silent edit to v1.

v1.1 — August 2026

  • MCP tool scopes are configurable per key. My agents, chosen agents, or REST only, set in Settings. A key with nothing set now defaults to your own agents rather than to an empty list.
  • Images over MCP come back as links. They previously arrived as a raw JSON dump.
  • A rejected input value now returns 422 instead of a flat 400, so "your client is wrong" and "this value is wrong" are told apart.
  • OpenAPI 3.1 spec published at /api/v1/openapi.json.
  • These docs.

v1.0 — August 2026

  • The developer API. POST /api/v1/run, GET /api/v1/agents, GET /api/v1/agents/{handle}/{slug}, GET /api/v1/balance.
  • API keys in Settings, up to five per account, SHA-256 hashed at rest.
  • The MCP server at /api/mcp, Streamable HTTP, protocol 2025-06-18.
  • 60 requests per minute per key.

How versioning works

  • The version is in the path. /api/v1/. A breaking change means /api/v2/ — v1 keeps working.
  • Additive changes ship into v1. A new optional parameter or a new response field can appear at any time, so parse leniently and ignore what you do not recognise.
  • Error messages are not a contract. They are written for people and get reworded. Branch on the status code and on success, never on the text.

What counts as breaking

Removing a field, renaming one, changing a type, or making an optional parameter required. Adding a field, adding an endpoint, or adding an enum value does not — that is why output is documented as "branch on what is present".

Something you rely on changed under you? Tell us via Contact — that is a bug, not a policy.

On this page