We’re building Ever Works in public. Some things may be incomplete, missing, or broken while we continue improving the platform.We’re building Ever Works in public — expect a few rough edges.
Developers · Agent access
Ever Works ships an MCP server that turns the platform API into tools an assistant can call. It reads the API OpenAPI spec at start-up — fetched live in local runs, bundled into the container image for deployed ones — filters it through a curated whitelist of 127 operations, and converts each one into a tool whose parameters, types, and descriptions stay in sync with the API — no hand-maintained tool definitions to drift. Eight more tools are written by hand: the Knowledge Base namespace, repo registration, and a health check.
135 tools in total — 127 derived from the API whitelist, six Knowledge Base tools, plus register_work and ping.
List, create, update, and delete Works; read config, items, categories and tags, and generation history. Regenerate markdown, trigger a website rebuild, or process community pull requests.
Start AI item generation, update existing items with AI, generate Work details from a prompt, and read the generator form schema. Then submit, update, or remove a single item — or extract one straight from a URL.
Deploy a Work to a hosting provider, list the available deploy providers, list the custom domains attached to a Work, and check whether deployment is possible before you spend a run.
Read, update, or cancel the scheduled refresh on a Work, and run one immediately when you do not want to wait for the next tick of the cadence.
List comparisons for a Work, read one with its markdown body, auto-generate the next one, generate one for two specific items, or delete one.
The whole lifecycle, verb for verb: create, pause, resume, complete, clone, and run a Mission now; create, refresh, dismiss, build, retry, rebuild, and accept Ideas; attach a Work to a Mission with a typed relation. Every route is ownership-gated server-side.
List plugins, read one, enable or disable it, and update its settings — plus account-wide usage and spend across every Mission, Idea, and Work in one call.
Tasks are the units of work an Agent executes. List and create them, move one through its state machine, dispatch a batch, read the PR status, the diff, the chat and the spend, add assignees, reviewers and approvers, and relate one Task to another.
The Inbox is where agents ask a person for a decision. The tools read and triage it — list it, count the unread, read one, mark it read, archive, unarchive, delete. Answering an item is the approval itself, so that verb is deliberately not a tool.
Goals are outcome-driven autopilot: the platform watches a metric and dispatches Tasks toward a definition of done. Create, read, and update one, sample its metric, activate or pause it, evaluate it now, set its limits, and propose criteria — a person approves those in the app.
Read the nodes you have enrolled, the runner status, and the execution preferences; pin an Agent to a machine, unpin it, or drain a node. The three node-affinity tools are Organization-scoped — they need EVER_WORKS_SCOPE_SLUG set, and answer 400 without it.
List the roster and read one Agent, list its runs and read a single run, kick a run off now or cancel one, pause and resume the Agent, and read its budget.
Read-only by design: list installed packages, the catalog, the available updates, and the conformance findings. Installing a package installs skills — instructions the agent would then follow — so no install verb is exposed over MCP.
kb.list, kb.get, kb.create, kb.update, kb.lock, and kb.unlock address documents by path (brand/voice) as well as by id — lock your brand voice once and no agent run can quietly rewrite it. register_work creates an account and a Work from a repo carrying .works/works.yml, and ping proves the connection with no API call at all.
Open Settings → API Keys in the dashboard and generate a key named after the client. It starts with ew_live_ and is shown once, so copy it immediately — one key per client keeps revocation surgical.
Build once with pnpm build --filter=ever-works-mcp, then start the stdio entrypoint: node apps/mcp/dist/stdio.js, with EVER_WORKS_API_KEY and EVER_WORKS_API_URL set. Prefer a container? ghcr.io/ever-works/ever-works-mcp serves the streamable-HTTP transport on port 3200. The image ships with NODE_ENV=production, so you set EVER_WORKS_MCP_AUTH_MODE explicitly before it starts: per-user-jwt, where each caller sends their own Ever Works JWT in an x-ever-works-jwt header, or shared-key-jwt, which takes Authorization: Bearer with the shared key plus that same JWT.
Paste an mcpServers entry into claude_desktop_config.json, into your project .mcp.json, or into the equivalent config of any MCP-compatible client: command node, args the absolute path to stdio.js, env your key and API URL.
Restart the client and call ping — it answers pong. Then just talk: list my works, generate ten more items, deploy it, set a weekly refresh.
The stdio entrypoint serves no HTTP routes at all — nothing listens on a port, and your API key is the only credential. This is the setup for a laptop and a local client.
The published image always serves the HTTP transport, bundles the OpenAPI spec so it never has to fetch one, and runs with NODE_ENV=production — which means you choose an auth mode explicitly before it will start.
The reference manifests run two replicas behind a /health probe, as a non-root user with every capability dropped, no privilege escalation, and no service-account token mounted.
We run the same server at https://mcp.ever.works/mcp for clients that would rather not host anything. It runs in per-user-JWT mode: send your Ever Works JWT in an x-ever-works-jwt header — an ew_live_ API key is rejected there by design.
A whitelist entry names a method, a path, and a tool name; everything else — the description, the parameters, the validation — is read from the API OpenAPI spec when the server boots. Exposing a new verb is a one-line change plus a rebuild, and an entry whose operation is missing from the spec is skipped with a warning rather than registered half-formed.
The whitelist is a deliberate list, and its gaps are the point. The verbs that answer a human gate are not tools: replying to an Inbox item, resolving a Task escalation, approving a Goal definition of done, the force flag on a Task transition, and the requireAllApprovers field on Task create and update. The API cannot tell an MCP caller holding your key from you, so an Agent bound to this server would otherwise approve its own proposal. Ask over MCP; answer in the dashboard, the REST API, the CLI, or platform chat, which confirms before anything irreversible.
Everything the dashboard does is an authenticated REST call — documented with OpenAPI, callable with an API key, and observable through signed webhooks.
Learn more →Create, generate, deploy and register Works, manage plugins and the knowledge base from your terminal — npm install -g ever-works-cli.
Learn more →Every operation in the dashboard is also a sentence in the chat rail — confirmed before anything destructive, and answered with live charts, tables and boards.
Learn more →Drop in PDFs, Office files, web pages, Notion pages and recordings — and get typed, Git-backed knowledge with hybrid search and answers that cite their sources.
Learn more →Bring a data repository, an awesome-list README, or repositories you already run under management — with config-as-code and a GitHub App.
Learn more →Describe what you want to build. Ever Works researches it, ships it, and keeps it improving — content and code, owned in your own Git.