Start

Agents

App store purchases

Auth

Builds

Credits

Database

Flags

Generated Assets

Hosting

Jobs and cron

Knowledge

Localization

Monitoring

Network

Notifications

Organizations

Queues

Realtime

Runners

Sandboxes

Storage

Webhooks

Workflows

Getting Started

Installation

Authentication

AI Services

KV Store

Overview

Webhooks

Deploy & Infrastructure

Reference

On this page

Run
Configure a client
Core tools
Meta tools
The catalog

Reference

MCP

The whole platform as MCP tools, from the same contracts as the API, the SDKs and the CLI.

Checked 2026-09-28

The Sylphx MCP server is the platform inside an agent: the same methods as the API reference, the CLI, the SDKs and the Terraform provider, served as MCP tools over stdio. Agents and coding assistants connect a client; this page is what it answers with. To use the hosted server instead, see Connect an MCP client.

#Run

Shell

npx @sylphx/mcp
sylphx mcp
cargo install sylphx-mcp && sylphx-mcp

The three run the same server — Node, the operator CLI, or the binary. A client starts it over stdio, so a run line is for trying it by hand: the process reads JSON-RPC on standard input and writes it on standard output.

#Configure a client

JSON

{ "mcpServers": { "sylphx": { "command": "npx", "args": ["-y", "@sylphx/mcp"], "env": { "SYLPHX_API_KEY": "sylphx_sk_…" } } } }

The server reads its key from SYLPHX_API_KEY. Without one, search and describe still answer, and a call explains how to sign in.

#Core tools

26 methods come with a tool of their own — {service}_{collection}_{verb}, or {service}_{verb} for a call a service serves itself — each carrying the request's input schema. The tool's name links to the method it serves:

Tool	Effect	What it does
`access_whoami`	`read`	Returns the caller: the principal and the scope of the key or token that authenticated this request. Clients fill their org, project, and env defaults from it; every valid key may call it, whatever its scopes.
`access_projects_create`	`write`	Creates a project. Access assigns the id.
`agents_agents_create`	`write`	Not available yet. Creates an agent and its version 1.
`agents_agent_sessions_create`	`write`	Not available yet. Starts a session of an agent, pinned to its current version unless `agent_version` names another. Requires a secret key until end-user ownership is implemented. The session starts idle; `:send` starts its first turn.
`agents_agent_sessions_send`	`write`	Not available yet. Sends a user message. On an idle or failed session it starts a new turn; while a turn runs it is refused with `INVALID_STATE` (use `:steer`). The same `Idempotency-Key` returns the same event.
`agents_session_events_list`	`read`	Not available yet. Lists a session's events in sequence order. To follow a session, call again with the filter `sequence > N`, N the last sequence read; `wait` holds the call open until a newer event is appended or the wait ends.
`billing_billing_accounts_get`	`read`	Not available yet. Gets a billing account.
`billing_usage_reports_query`	`read`	Not available yet. Queries usage over any time range, bucketed and grouped: the usage summary the console charts. Reads rollups; never raw events.
`build_builds_get`	`read`	Gets a build.
`build_run`	`write`	Runs one command over an uploaded tree and settles with its exit code, like the local command. A caller that gets a failure before the command started (BUILD_FAILURE_SETUP_FAILED, NO_CAPACITY) may build locally.
`build_image`	`write`	Builds an image, with an SBOM and signed provenance, from a commit or an uploaded tree.
`build_logs_read`	`read`	Reads a page of a build's log lines, oldest first. With `wait`, an empty page on a running build waits up to that long for new lines, so a client follows the log by passing each `next_page_token` back.
`build_cache_env`	`write`	Mints the settings a build that runs elsewhere (a laptop, a CI runner) uses to reach the cache: the sccache, Turbo and crates mirror doors and a short-lived token, as environment variables.
`build_caches_purge`	`destructive`	Empties a build cache and keeps the cache. The undo is that the next build refills it.
`data_databases_create`	`write`	Creates a database. The Operation is done when the controller settles it.
`entitlement_entitlements_get`	`read`	Not available yet. Gets an org's entitlement.
`hosting_services_create`	`write`	Not available yet. Creates a service. The Operation is done when the controller settles it.
`observability_log_entries_query`	`read`	Queries the environment's log entries over a bounded interval; follow a trace with `trace_id = "..."`.
`observability_traces_query`	`read`	Queries the environment's traces over a bounded interval, returning summaries without spans.
`observability_generations_get`	`read`	Gets a generation: one Sylphx AI call.
`observability_generations_list`	`read`	Lists the environment's Sylphx AI calls, newest first, within the trace retention; filter by `request_model`, `outcome`, `api_key`, `start_time`, `tags.<key>` and the other filterable fields.
`workflows_schedule`	`write`	Updates a schedule; with `allow_missing` it creates the schedule when it does not exist, so its short name `schedule` is an upsert by name.
`workflows_start`	`write`	Starts a Run of a Workflow, now or after `start_delay` or at `schedule_time`. `run_id` is the caller's key: the same key and intent return the same Run, a changed intent is refused. An end user's session may call it on a Workflow whose `callers` is `USERS` when the session holds the Workflow's `permission`.
`workflows_signal`	`write`	Sends a named signal to a running Run; a `wait` op for that name resumes with its payload. A signal to a closed Run fails with INVALID_STATE. An end user's session may call it on a Workflow whose `callers` is `USERS` when the session holds the Workflow's `permission`.
`workflows_cancel`	`destructive`	Requests cancellation. Timers and waits stop; a running invocation is not interrupted: the handler receives one final invocation with `cancel: true`, and the Run ends `cancelled` when it answers. An end user's session may call it on a Workflow whose `callers` is `USERS` when the session holds the Workflow's `permission`.
`workflows_result`	`read`	Waits up to `timeout` (at most 60s) for the Run to close, then returns it, closed or not. Its short name is `result`: the closed Run carries the handler's output or error. An end user's session may call it on a Workflow whose `callers` is `USERS` when the session holds the Workflow's `permission`.

#Meta tools

Three tools reach the rest of the platform, whatever its service:

Tool	What it does
`sylphx_search_methods`	Search every Sylphx API method by service, collection, verb, or description.
`sylphx_describe_method`	Return the input JSON Schema, permission, and effect of one method.
`sylphx_call`	Call any Sylphx method by id with arguments matching its input schema. Destructive methods require confirm: true.

#The catalog

sylphx_search_methods searches a catalog of 635 methods — every method this reference documents except the ones the protocol reserves — and each hit carries the id, the tool name, the effect, the scope, the HTTP call and the input schema. sylphx_describe_method returns one entry, and sylphx_call runs one: its arguments are the method's request, so a call an agent makes is the call its page documents, and a destructive one needs confirm: true in the arguments.

The server declares no resources and no prompts: resources/list and prompts/list answer with empty lists, because everything the platform holds is reached by calling a method.

Was this page helpful?

Tell us what is missing, wrong, or unclear — this opens a real inbox.

Send feedback

Platform links