Skip to content

One MCP server, every system Eight tools. Every system.

actionlake is one remote MCP server, with a REST twin, that gives an AI agent eight tools to reach 289,000+ actions across 1,000+ connectors. Credentials stay sealed, every key has a scope and can carry a cap, and every run is written to a hash-chained ledger. Add a hundred systems; the tool list never grows.

100,000 free calls a month. No card, no email, no password: press Start a free sandbox on the next screen and keep the key it shows you.

Or connect from Claude Code - one line, no key needed
claude mcp add --transport http actionlake https://connect.actionlake.com/mcp

01 · The surface

Named for what an agent wants.

Dump three thousand tools on a model and its accuracy falls apart past a few dozen. actionlake gives an agent eight, named for the question it is asking itself. The catalog behind them grows; the surface never does.

What the agent says, and what comes back. Illustrative.
dodo {action: "halopsa.service.ticket.create", input: {…}, intent: "…"}
✓ ticket #48112 created
AL-Calls: 1 · AL-Micros: 300 · AL-Cache: MISS

Only two tools spend money, and they cannot be confused: do is a verb, ask is a question. REST and MCP are one implementation; a test holds them to it.

02 · Do

One exact write.
With a receipt.

A write is never cached and never retried, because a request that might have landed must not be replayed. The response carries its own accounting: calls, cost, cache verdict. The meter is on the call, not discovered on the invoice.

  • Destructive actions need an explicit confirmation
  • Under a human confirm policy the agent cannot confirm itself
  • Every response carries AL-Calls, AL-Micros, AL-Cache
> do halopsa.tickets.create intent: "printer on level 2 at Acme" permitted · confirm not required · 1 callticket.create212 msMISS1 callnever cached · never retried✓ ticket #48112 created · on the recordAL-Calls: 1 AL-Micros: 300 ($0.0003)AL-Cache: MISS
Illustrative run. One write, one upstream call, the headers on the response.

03 · Ask

The answer comes back.
Not the data.

Name the steps and the join. actionlake fetches in parallel, pages to the end, matches the records that belong to the same customer, and returns the answer. 156 shared entities make the join possible: a QuickBooks contact and a HaloPSA client are the same crm.company.

Many systems on the left; one answer on the right. The join lives on a shared entity, never on a guessed field name.
  1. authenticate3 ms
  2. check7 mspermitted
  3. quickbooks · invoices142 msMISS · 1 call · $0.002
  4. connectwise · tickets88 msHIT · 0 calls · free
  5. join on crm.company6 ms4 rows
  6. record2 mssealed
236 ms end to end1 call billed4 clients · $18,340 overdue · 6 tickets
Illustrative run. Our time and the vendor's time are reported separately, never summed.

Rows never enter the model, so the token bill falls with the API bill. Ask the same question again inside the cache window and it costs nothing: no fee, and none of the vendor's rate limit.

04 · Plans

It did it once.
Now it does it
every time.

A plan is a saved, versioned program of steps: actions, joins, loops, sub-plans, waits and approvals. Long runs are durable; they suspend on a wait or an approval and resume where they left off. A schedule runs a pinned version on a cron, under a named key, and never fires twice however many instances are running.

  • Seven step kinds, sub-plans three deep
  • 899 pre-written plans in the store
  • Every run carries the agent's reason, in one sentence
  • Agents and schedules start the work; there are no triggers to wire
0 8 * * 1 every Monday, 08:00 · key billing-agent · version pinnedscheduled
  1. actioninvoices overdue 30d1 call
  2. actionurgent ticketsHIT · free
  3. joinjoin on crm.company4 clients
  4. for_eacheach client0 of 4
  5. actiondraft reminderin the loop
  6. approvalsend 4?waits for a named person
  7. actionsend4 calls
  8. wait7 daysrun suspends
Illustrative run of a saved plan: two fetches in parallel, a join, a loop, an approval that waits, a send, a wait. Every step on the record.

05 · Connectors

A connector is one file.
No code.

Each connector is a signed JSON file: every action, its schema, how it authenticates, how it pages, how long an answer may be cached, which hosts it may reach. The server refuses an unsigned or altered file. When a system is missing, your agent points service.draft at the documentation, gets back an authoring kit and a skeleton, validates, tests and publishes, private to you by default.

  • 1,000+ connectors, 289,000+ actions, 4,936 canonical action names, 3,353 shared by two or more
  • Native MySQL, PostgreSQL and Redis: read tier enforced by the database server itself, one statement per call
  • Bring an MCP server; its tools become actions under the same limits and the same record
account{op: "service.draft", docs_url: "https://vendor.example/api-docs"}
  1. service.draftdocs URL → fetched through the egress guard → authoring kit + skeleton
  2. service.validateALCM grammar · every action's schema · allowed hosts
  3. testlive against your sandbox key · only live-tested actions are marked working
  4. publishsigned (Ed25519) · private to your tenant · listed only after review
No connector? Point your agent at the documentation. Illustrative stages; the ops are real.

Counted from the catalogue, 24 October 2026

  • quickbooks
  • netsuite
  • salesforce
  • servicenow
  • hubspot
  • connectwise
  • gusto
  • slack
  • sap
  • fortinet
  • genesys
  • procore
  • harness
  • tp-link
  • infisical
  • sage
  • rubrik
  • oracle
  • blackbaud
  • commvault
  • bitrix24
  • hpe
  • deputy
  • cloudflare
  • adobe
  • crowdstrike
  • simpro
  • netbox
  • telnyx
  • databricks
  • apple
  • delinea
  • acumatica
  • gcore
  • mulesoft
  • All 1,000+ connectors →
  • mysql read tier · one statement per call
  • postgres read-only transaction
  • redis COMMAND INFO flags
  • Your own databases, under the same limits and the same record.

06 · Control

Permitted before.
Priced during.
Recorded after.

A key holds only what it was granted and can hand on only what it holds. Its calls count against every key above it. At the cap the call is refused before it is sent, and costs nothing. One module makes every outbound request; private ranges are refused and redirects are re-checked on every hop.

One vault.

Every credential sealed on arrival under your tenant's own key, AES-256-GCM in an envelope. Unwrapped in memory for one call. Never logged, never returned by any endpoint, never in a prompt.

halopsa api_keytoken redacted
sealed on arrivalAES-256-GCM · tenant key · envelope
agent holds: al_key_desk_agent · never the token

Scope.

Read-only. One system. One action. Or everything. Per key, and a key hands on only what it holds.

keys.create "desk agent"
  allowed_actions: ["read:*", "service.ticket.*"]

Budget.

A cap on every key, in calls. Caps cascade: a child's calls count against every parent. Reserve, then settle. At the cap the call is refused before it is sent, and costs nothing.

orchestrator0 / 5,000
desk-agent0 / 1,000
billing-agent0 / 500
research0 / 250refused before dispatch

Approvals you name.

Per key: which actions wait, and who decides. The run suspends until they do.

doxero.finance.payment.createconfirm_policy: human

Pay $12,400 to Acme Ltd?

intent: the user asked me to settle the approved October invoices

run suspended · waiting for a named person · key billing-agent cannot confirm itself
In the console, or from an emailed signed link.

Check first. check is free, sends nothing, and says what would need a confirmation.

07 · The record

Tamper-evident
by construction.

Each run is a row: who, which action, which connection, cost, cache verdict, timing. Each row stores the hash of the one before it; the chain head is sealed to storage daily. Any run can be checked against its neighbour on its own page. Request and response bodies are kept separately, sealed under your key, for your plan's window, an hour on Free and 30 days on Enterprise, then deleted.

  1. r_84,211desk-agentask · invoices + tickets✓ 4 rows
    prev 7b10…e4c2 · sha256 a3f9…c21e · $0.002
  2. r_84,212desk-agentdo · halopsa service.ticket.create✓ #48112
    prev a3f9…c21e · sha256 0d77…91af · $0.002
  3. r_84,213billing-agentdo · xero finance.payment.create✓ approved
    prev 0d77…91af · sha256 5c2e…77b0 · $0.002
    intent: "the user asked me to settle the approved October invoices"
  4. r_84,214researchdo · hubspot crm.company.listrefused · cap
    prev 5c2e…77b0 · sha256 e91b…04d6 · $0.000
Chain head sealed · to the bucket, daily · verifiable on any run's page
Illustrative rows. Each stores sha256(prev_hash + row); the chain head is sealed to storage daily.
runr_84,212 · do · halopsa service.ticket.createrequestPOST /api/v1/Tickets {"summary": "Printer on level 2", "client_id": 1182, …} secrets removedresponse201 {"id": 48112, "status": "New", …} bodies cut at 1 MiBsealedunder your tenant key · syd1 bucket · readable by the key that ran it, root, or traces:*
  1. free1 day
  2. starter3 days
  3. pro7 days
  4. team14 days
  5. business30 days
  6. enterprise30 days
Then deleted. The row, its hashes, cost and outcome stay on the record. Illustrative bodies.

Not yet: an anchor outside our own infrastructure, and a whole-chain export. The trust page says so.

08 · Add-on

One address your vendors can allow-list.

One static IPv4 address, private to your account, that every request to your vendors leaves from: HTTPS on ports 443, 80 and 1024 and above, and MySQL, PostgreSQL and Redis on the same ports with the database's own TLS end to end. It fails closed: when the address is unavailable, requests are refused rather than sent from a shared one.

1endpointMCP, with a REST twin on the same code path
8tools, however many systemstwo spend money; six never do
0credentials an agent ever seessealed on arrival, never in a prompt
100%of runs on the recordhash-chained, sealed daily

08Questions

Platform questions, answered.

The eight tools, the controls and the record, in the words an evaluator uses.

What are actionlake's eight MCP tools?

help (orientation), find_actions (search 289,000+ actions), get_action (the schema, cost and an example), do (run one action or several in order), ask (fetch from several systems and join them), check (a free dry run), cost (spend and cap headroom) and account (tenant, keys, connections, plans). Only do and ask are billed.

How is actionlake different from installing many MCP servers?

Each MCP server adds tools, credentials and a new place to audit, and past a few dozen tools agents get worse at choosing. actionlake keeps the agent at eight tools however many systems you connect, holds every credential in one sealed store, applies one set of scopes and caps, and keeps one ledger.

What does ask do that a normal tool call cannot?

ask fetches from several systems in parallel, pages to the end, matches the records that belong to the same customer, and returns only the answer. The rows never enter the model, so the agent's context stays small. In the illustrative run, overdue invoices joined with urgent tickets return 4 clients, not thousands of rows.

How do human approvals work?

Destructive actions need an explicit confirmation, and under the key's human policy the agent cannot give it, so a person approves. Approval rules make chosen actions, or every write, wait for a named person, who decides in the console or from an emailed signed link. The run suspends until that person decides, then resumes.

How do spending caps work?

Every key can carry a cap in upstream calls. A key can mint child keys with a share of its cap, never more, and a child's calls count against every key above it. A call that would pass a cap is refused before it is sent, so it costs nothing.

What is recorded about each action?

Every run writes a ledger row: who ran it, which action, which system, the cost, the outcome and the agent's one-sentence reason. Rows are hash-chained and the chain head is sealed daily, so a change shows. The record is permanent; the agent's reason is kept for 90 days, and request and response traces for your plan's window.

Can actionlake run on a schedule or react to webhooks?

Schedules, yes: any saved plan can run on a cron schedule under its own key and budget. There are no webhooks, event triggers or polling, by design. Agents and schedules start the work; a scheduled plan that asks what changed since its last run covers most trigger cases.

Can I use REST instead of MCP?

Yes. The REST API and the MCP server are one implementation with the same names, the same catalogue and the same receipts, and a test holds them equal. An OpenAPI description is published.

Ask one question across two systems.

100,000 free calls. No card. Hard caps on every key. Cached answers are free.