altengine

Published · altengine team

altengine Is Now Built for AI Agents First: Every Service as an MCP Tool

As of today, the front door to altengine is an MCP server. Point Claude Code, claude.ai, Claude Desktop or any other MCP client at https://api.altengine.net/mcp and the agent can do what you would otherwise do in the console: create a datastore, write the row-level rules, deploy a function on a schedule, push a built site live, and read what failed. The REST API underneath has not changed. What changed is which surface we design for first.

Why flip the lead

When we launched, the pitch was simple managed services over clean HTTP, and the console was where you set things up. Since then the way a new service gets its first call has changed. Increasingly it is not a developer reading a quickstart but an agent sitting next to one, in an editor or a chat window, that was asked for a waitlist page or a nightly export and needed somewhere to put the data.

That agent does not want a console. It wants a tool it can call, an error it can read, and a credential that cannot do more than the person meant it to. So that is now the thing we build first, and the console, the CLI and the REST docs follow from it. It is the same platform. The order of the home page is what moved.

What "agent-first" means in practice

Every service is reachable as tools, and the set is the console's own capabilities: instances, then the work inside them.

  • Instances. create_instance, get_instance_config, patch_instance_config, delete_instance, for every service: search, datastore, channel, auth, functions, blob, containers, automation and static.
  • Datastore and Search. Put, get, query and delete documents; run grouped aggregates; declare an index; read a search schema.
  • Auth. Create and disable users, set claims, and read or replace the access rules that let a browser call Datastore and Channel directly as the signed-in user.
  • Channel and Blob. Publish a message, list rooms, check presence; put, get, list and publish files, or sign an upload link for a client.
  • Functions, Containers, Static. Deploy a version, list versions, read error groups, roll back; start a job, tail its logs, cancel it; deploy a directory and make any deployment live.
  • Automation. Enrol a machine, read a recording of somebody doing the task, inspect the live desktop, save the script and put it on a schedule. That one has its own walkthrough.

Connecting is one line. For Claude Code:

claude mcp add --transport http altengine https://api.altengine.net/mcp

Then /mcp inside Claude Code, sign in, and pick two things on the consent screen: which organization the connection acts on, and whether it gets read, write or full access. A hosted client such as claude.ai takes the same URL as a connector. An unattended client, where nobody is there to click allow, uses an API key with MCP / AI agent access switched on:

{
  "mcpServers": {
    "altengine": {
      "url": "https://api.altengine.net/mcp",
      "headers": { "Authorization": "Bearer ae_..." }
    }
  }
}

A session, start to finish

Here is the shape of the first thing most people ask an agent for. The agent calls whoami and learns the organization, its access level and how many instances it may create. It reads the scaffold-backendless-app prompt, which lays out the order: a datastore instance, an auth instance, rules on the auth instance that scope each user to their own rows, a function for the one thing a browser must not do, and a static instance for the built site.

Then it does those things, in that order, with create_instance, auth_set_rules, functions_deploy and static_deploy. Before it writes a datastore query it reads docs://datastore/query, because the query language is App Engine's and a model that has not read it will invent SQL. When it is done it hands you a URL. Nothing in that loop needed the console, and nothing in it could touch your billing.

If you would rather it rehearse first, the local emulator serves the same endpoint at http://127.0.0.1:9191/mcp with the same tool names and argument spellings. Point the agent there while altengine dev is running, let it make its mistakes against localhost, then run the identical sequence against your organization.

What makes a tool surface an agent can actually drive

An API an agent can call is not the same as one it can call correctly on the first try. Most of the work of the last few months went into the second thing, and it is worth being specific about what that meant.

  • Names, not ids. Anywhere a tool asks for an instance, the name from list_instances is accepted. An agent should not have to carry an opaque id between calls, and it tends to lose them when it does.
  • A wrong argument is an error. The server refuses a call carrying an argument it does not recognise and names the valid ones. It never ignores the stray field and returns an answer that looks right. That one rule removes a whole class of silent failures where the agent believes it set something it did not.
  • The docs ship inside the server. MCP resources cover the search and datastore query languages, how an access level and row rules combine, the function handler shape and the automation script API. The agent reads them on demand instead of guessing from training data that predates the product.
  • Prompts for the work whose order matters. Three of them: scaffold a backend-less app, add a scheduled job, automate a desktop task. Each is a plan, not a template.
  • Stateless calls. Every call carries its own credential and is answered on its own. There is no session to keep alive, so a long pause in a chat costs nothing and a reconnect is not a thing.
  • Config patches that say what changed. patch_instance_config merges top-level fields and reports back which ones actually changed, so the agent can tell a no-op from a write.

None of this is exotic. All of it is the difference between an agent that finishes and one that loops.

What a person keeps

The part we were most careful about is the part the agent cannot reach. The MCP surface covers building, not governance. There is no tool for billing, for members and invitations, for creating API keys, or for closing an organization, and there is no access level or key scope that produces one. That holds at full. The consent screen cannot grant it and a key cannot be minted with it.

Inside what the agent can do, there are three more lines:

  • Destructive tools such as deleting documents, users or an instance need an explicit confirm: true argument on top of the access level.
  • A connection is tied to one organization and is re-checked against your membership on every call. Revoke it in Settings → Connected applications and the next call fails; leave the organization and it stops working immediately, not when a token happens to expire.
  • Looking at a live desktop on an automation machine needs a developer window that an organization owner opens, which expires on its own within the hour, and the machine shows a notice on its screen the whole time it is open.

A key can be cut finer than a signed-in connection: scopes per area, each at read, write or full, and data access through the key's ordinary grants, so an agent that should only ever touch one instance gets a key pinned to that instance.

What it costs

Tool calls are metered at $0.02 per 1,000. Connecting, listing tools, reading resources and getting prompts are free. The work a tool does bills to its own service at the normal rate, exactly as the same operation over REST would, so a datastore_query costs the datastore reads it performs plus the per-call fee. Calls are rate-limited to 600 per minute per organization. In practice an agent session of a few hundred calls costs well under a cent, and the first $3 of usage each month is free across everything, with no card to start. The rates are on the pricing page.

What did not change

Everything the agent builds runs on the same REST API your own code calls, and that API is unchanged. Search and Channel still keep App Engine's semantics over REST/JSON. Datastore still takes any JSON object and serves every query from an index. Auth still hands a browser a short-lived identity token that goes straight to Datastore and Channel under row-level rules. If you never connect an agent, nothing on this page affects you, and the console is exactly where you left it.

What will change is this blog. The posts so far were written for a developer evaluating a managed service by hand. The ones that follow will be written for the person who points an agent at the platform and wants to know what it can do, what it will get wrong, and what it must never be allowed to do. That is who we think is reading now.

Where to start

  1. Create an organization in the console. No card is needed.
  2. Add https://api.altengine.net/mcp to your client and sign in, or create a key with MCP access for anything unattended.
  3. Ask for something small. Let the agent call whoami first; it stops the guessing.

The full tool list, the resources and prompts, and the exact scope each automation tool needs are in the MCP server reference.

Start free in the console

← Back to the blog