The agent-native cloud: database, functions, AI, storage, computers. 51 tools, one API key.
Scored across 53 tools
Tools are grouped by product domain and most are clearly distinct (db_query vs db_schema vs db_pii, storage_upload vs storage_download). The main overlaps are execution-flavoured tools — scalix_sandbox_run vs scalix_computer_exec, and scalix_fn_deploy/invoke vs scalix_run_deploy — which an agent could plausibly confuse despite descriptions that clarify when to use each.
Strong, predictable pattern throughout: scalix_<domain>_<verb> in snake_case (scalix_db_query, scalix_computer_stop, scalix_storage_upload). The few outliers like scalix_status and scalix_crew_board_post still fit the prefix+domain convention and remain unambiguous.
At 53 tools the surface is heavy even for a multi-product cloud platform, spanning roughly 16 domains and burdening an agent's selection space. Many tools are well-argued individually, but the set exceeds what a single server should reasonably expose.
Core create/read/execute paths exist across domains, but lifecycle coverage is uneven: scalix_project_create notes API keys are issued 'separately' yet no API-key tool exists, and KV, functions, cron, domains, builds and events all lack delete or list counterparts. These gaps force agents into dead ends on cleanup and discovery tasks.
Run AI inference on Scalix AI. Sends a prompt and returns the model's response in the OpenAI-compatible chat-completions format; tokens are billed to the project's credit pool. Discover available model IDs with scalix_ai_models.
Inputs: prompt (required), model, system, max_tokens, +1 more.
List the AI models available to the project — virtual tiers and the pass-through catalog model IDs — for use in scalix_ai_infer.
Inputs: no named parameters.
Configure end-user authentication for the project — require MFA, require email confirmation, and set the allowed auth providers. Needs an admin API key: organization admin scope is never delegated to a connected app, so this tool fails on an OAuth connection.
Inputs: mfa_enabled, allowed_providers, require_email_confirmation.
Create a new container image build from a Git repository or Dockerfile.
Inputs: name (required), git_url (required), branch, dockerfile.
Get the status and logs of a build.
Inputs: build_id (required).
Get or create a persistent Linux machine by name. Idempotent — calling it again with the same name returns the existing machine rather than creating another, so it is safe to retry. Unlike a sandbox, the disk survives stop/start and is only erased by scalix_computer_delete.
Inputs: name (required), vcpus, region, disk_gb, +2 more.
Permanently delete a persistent Linux machine AND its disk. This cannot be undone — use scalix_computer_stop if you may want the files back.
Inputs: id (required).
Run a command inside a persistent Linux machine and wait for it to finish. Returns exit code, stdout and stderr. The machine must be running.
Inputs: id (required), command (required), cwd, env, +2 more.
List your persistent Linux machines with their status, address and resource shape.
Inputs: no named parameters.
Read a text file out of a persistent Linux machine.
Inputs: id (required), path (required).
Replace the ssh keys authorised for root on a persistent Linux machine. This is how you revoke: send the list without the key you want gone, and on a running machine it stops working immediately. Sending an empty list removes every key. Not a patch — whatever you send becomes the whole list, so read the current keys from scalix_computer_list first if you mean to add one.
Inputs: id (required), ssh_keys (required).
Start a stopped persistent Linux machine. Same disk, same address.
Inputs: id (required).
Stop a persistent Linux machine. The disk and the network address are kept, so starting it again returns the same files at the same address. Stop machines you are done with — a stopped machine costs only its disk.
Inputs: id (required).
Write a text file into a persistent Linux machine. Use this instead of shelling out with cat/echo — no quoting to get wrong.
Inputs: id (required), path (required), content (required), mode.
Post a note to the crew's notice board for other members and the human to see. The board is news, not knowledge: set ttl_seconds so routine updates expire on their own, pin only what every future task must see, and set owner_member_id to hand work off to a specific member. Notes cannot be edited from here — post a correction instead.
Inputs: body (required), crew_id (required), pinned, ttl_seconds, +2 more.
Read a crew's notice board: every pinned note plus the newest unpinned ones, current as of this call. The board is the crew's shared coordination state — read it before starting work so you act on the latest news, and post what teammates need to know with scalix_crew_board_post.
Inputs: crew_id (required).
List your crews with their ids and names. A crew is a team of AI members that share a notice board; use the crew id with the board tools.
Inputs: no named parameters.
Create a cron schedule to run a function or webhook on a timer.
Inputs: name (required), expression (required), action_type (required), config.
Apply a database migration by version number.
Inputs: version (required), tenant_id (required).
Analyze a SQL query and return optimization suggestions including index recommendations and query rewrites.
Inputs: sql (required).
List all columns classified as containing personally identifiable information (PII).
Inputs: no named parameters.
Execute a SQL query against the project database. Returns columns, rows, row count, and cost breakdown. Destructive statements (DROP/TRUNCATE/bulk DELETE) require a two-step confirmation: the first call returns code CONFIRMATION_REQUIRED with a confirmation_token — re-call with that value in confirm_token to execute.
Inputs: sql (required), params, timeline_id, confirm_token.
Get the relationship map showing how tables are connected via foreign keys.
Inputs: no named parameters.
Get the full database schema including all tables, columns, types, and relationships.
Inputs: no named parameters.
Search for columns by name or type across all tables.
Inputs: query (required).
Get detailed information about a specific database table including columns, indexes, and foreign keys.
Inputs: table (required).
Translate a plain-language question into a candidate SQL query using pattern-matching against the live schema (no AI model — simple questions only: counts, averages, filtered selects on a named table). Returns the SQL without executing it, with a confidence score; low confidence means the table was guessed. Review the statement and tables_used, then run it with scalix_db_query. For complex questions, read scalix_db_schema and write the SQL directly.
Inputs: question (required).
Add a custom domain to the project. Returns DNS records to configure.
Inputs: domain (required).
List all custom domains and their SSL/verification status.
Inputs: no named parameters.
Verify DNS configuration for a custom domain and provision SSL certificate.
Inputs: domain (required).
Publish an event to a topic. Provide an event_type (a short name for the kind of event, e.g. 'user.created') and the data payload.
Inputs: data (required), topic_id (required), event_type (required).
List the event-bus topics in the project, with each topic's ID and name. Use this to find or verify a topic_id before publishing with scalix_events_publish; publishing to a non-existent topic fails.
Inputs: no named parameters.
Deploy a Scalix Function — serverless, per-request billed, running in isolated microVMs — from a container image. Invoke it with scalix_fn_invoke once deployed.
Inputs: name (required), image (required), region, runtime, +1 more.
Invoke a deployed function with a JSON payload.
Inputs: function_id (required), data.
List all deployed serverless functions.
Inputs: no named parameters.
Read a single value from the project's key-value store by exact key. Returns the stored value, or a not-found error if the key does not exist or its TTL has expired. Use scalix_kv_list to discover keys by prefix first.
Inputs: key (required).
List keys in the key-value store, optionally filtered by prefix.
Inputs: prefix.
Set a key-value pair with optional TTL.
Inputs: key (required), value (required), ttl.
Create a new project within an organization. Returns the project ID, name, and slug. Issue an API key for the new project separately. Needs an admin API key: organization admin scope is never delegated to a connected app, so this tool fails on an OAuth connection.
Inputs: name (required), slug (required), org_id (required).
List every project in an organization, with each project's ID, name, and slug. Use this to resolve a project ID before calling project-scoped tools. org_id is optional: omit it to list the projects of the organization the API key belongs to (resolved via GET /v1/me). Needs an admin API key: organization admin scope is never delegated to a connected app, so this tool fails on an OAuth connection.
Inputs: org_id.
Permanently delete a Scalix Run service. This cannot be undone: it stops the running instances, releases the public HTTPS URL, erases any attached volumes and discards every revision, so scalix_run_rollback cannot bring it back afterwards. To stop paying for an idle service without losing it, set min_instances to 0 with scalix_run_scale instead.
Inputs: id (required).
Deploy a long-running container service on Scalix Run from a container image. Creates a new service, or a new revision of an existing service with the same name, with health checks, a public HTTPS URL, and autoscaling between min_instances and max_instances (min 0 = scale-to-zero when idle). Billed per vCPU-hour while instances run. Roll back a bad revision with scalix_run_rollback.
Inputs: name (required), image (required), env, port, +4 more.
List all deployed container services in the project.
Inputs: no named parameters.
Roll a Scalix Run service back to an earlier revision — omit 'revision' to return to the immediately previous one. Traffic switches to the target revision; the replaced revision is kept and can be redeployed later. Use scalix_run_list to see services and their current revisions.
Inputs: id (required), revision.
Change the autoscaling bounds of an existing Scalix Run service without redeploying it. Raising min_instances keeps instances warm (no cold starts, higher cost); min_instances 0 enables scale-to-zero when idle. Takes effect immediately. Find service IDs with scalix_run_list.
Inputs: id (required), max_instances, min_instances.
Execute code in an isolated sandbox. Supports Python, JavaScript, TypeScript, and Bash. Returns stdout/stderr, the probed interpreter version, and any files the code wrote (base64, under size/count caps).
Inputs: code (required), language (required), files, packages, +1 more.
Get the current health status of the Scalix Cloud platform including all service components.
Inputs: no named parameters.
Create a new Scalix Storage bucket in the project (S3-compatible object storage). Bucket names must be unique within the project. Setting public=true makes every object in the bucket readable without authentication — leave it false (the default) and use presigned URLs for private sharing. Public buckets double as static websites: upload index.html and serve it from the project's store subdomain at https://{slug}.store.scalix.world/buckets/{bucket}/objects/ (directory requests serve index.html; a 404.html object is served as the error page).
Inputs: name (required), bucket, public.
Permanently delete a storage bucket and every object in it. Irreversible.
Inputs: bucket (required), name.
Permanently delete an object (key) from a storage bucket. Irreversible.
Inputs: key (required), bucket (required), name.
Download an object from storage. Returns the content as base64.
Inputs: key (required), bucket (required), name.
List storage buckets, or list objects in a specific bucket with optional prefix filter.
Inputs: name, bucket, prefix.
Upload content to object storage. Provide the content as a base64-encoded string.
Inputs: key (required), bucket (required), content (required), name, +1 more.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Backend for AI agents: one batched tool over ~668 actions (hosting, storage, auth, payments).
The cloud for agents. Tools for AI agents to register, build, and deploy other agents. Zero human required.
One API key, dozens of capabilities for your AI agent. Zero provider auth.
Deploy and manage your apps, databases, storage, and scheduled jobs from your AI agent
Add one secure layer between your agents and this server.
