Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@boinc-central-mcp check my latest BOINC Central batch status"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server (stdio) that lets agents see batch status and fetch batch output on BOINC Central without a browser. It works with BUDA (Docker) batches and other remote-submission apps, and with any BOINC project that runs the standard job-submission code.
The server only calls the API BOINC already has, so the server side needs no changes:
What | BOINC endpoint | Auth |
batches, jobs, abort, retire |
|
|
batch output tar |
| web cookie |
Tool | What it returns |
| Your batches, newest first. |
| State, fraction done, job counts ( |
| One row per job: id, name, status, canonical instance, CPU time. Failed jobs also carry exit codes and error flags. |
| A job's instances and their states. With |
| Writes |
| Destructive. Aborts the batch. You must pass |
| Destructive. The server deletes the batch's collected output at once. You must pass |
The read-only tools carry readOnlyHint, and the two destructive ones carry
destructiveHint.
The RPC API does not give per-job sent or received times, so these figures come from what the API does give:
batch_turnaround_s is the finish time minus the submit time. For a running batch,
it is the time elapsed so far.
median_turnaround_s is the batch field the web page labels "Median turnaround
time" (expire_time). BUDA leaves it unset, so for BUDA batches it is usually
null.
runtime_sample gives median run times of completed jobs.
median_job_turnaround_s is the median of received time minus sent time over the
canonical instances. It appears only when the server reports those times, which
needs the proposed BOINC change on the
remote-batch-output-auth
branch.
Related MCP server: mcp-drone-mcp
Get your account key, the authenticator. Log in to BOINC Central and open Your account → Account keys (https://boinc.berkeley.edu/central/weak_auth.php). Copy the value shown under "Your account key is:". Do not copy the weak account key below it, because the RPC API does not accept the weak key.
Put the key in the key file and lock it down.
mkdir -p ~/.config/boinc-central
( umask 077; pbpaste > ~/.config/boinc-central/authenticator ) # or use an editor
chmod 600 ~/.config/boinc-central/authenticatorThe server refuses to read the file if group or others can read it.
BOINC_CENTRAL_AUTH_FILE=/path/to/file points the server at another file. Only a
path is accepted: the key itself is never taken from a tool argument or an
environment variable value. The server also removes the key from any error text
before an agent can see it.
Register the server with Claude Code.
claude mcp add boinc-central -s user -- \
uvx --from git+https://github.com/ispacex/boinc-central-mcp boinc-central-mcpTo run from a local checkout instead:
claude mcp add boinc-central -s user -- \
uv run --directory ~/work/math/boinc-central-mcp boinc-central-mcpBOINC_CENTRAL_URL (default https://boinc.berkeley.edu/central/) points the
server at another BOINC project.
Your account needs remote-submission access (a user_submit record), which every
account that can submit BUDA jobs has.
uv run pytestThe tests use recorded-format XML fixtures (tests/fixtures/) and an
httpx.MockTransport, so they need neither network access nor a key. They pass with
mcp 1.x (FastMCP) and 2.x (MCPServer, the renamed FastMCP).
There is no RPC for submitting BUDA batches. buda_submit.php is a web form that
authenticates by cookie. It submits in two steps:
Upload the batch .zip to your sandbox (sandbox.php, action=upload_file,
multipart).
Request buda_submit.php?action=submit&app=…&batch_file=…&max_runtime_days=…&exp_runtime_days=…&cmdline=….
This runs create_work with BUDA's sub_appname and templates.
The generic submit_batch RPC does not set those up. A submit_buda_batch tool could
drive the two web steps with the same auth cookie. A cleaner route is a
submit_buda_batch RPC upstream in BOINC.
MIT, see LICENSE.
DESTRUCTIVE: abort the batch on BOINC Central: every job without a result is cancelled (unsent instances dropped) and the batch goes to state "aborted". Cannot be undone. Call only when the user explicitly asked to abort this batch, and pass confirm=true.
Inputs: batch_id (required), confirm. Returns: object
Jobs of a batch with their status (done, in_progress, unsent, failed),
canonical instance id, CPU time of done jobs, and exit status / error
flags of failed ones. Filter by status; paginate with limit/offset.
Inputs: batch_id (required), limit, offset, status. Returns: object
Status of one batch: state, fraction done, job counts (done, in_progress, unsent, failed), times and turnaround.
Turnaround: the RPC API gives no per-job sent/received times, so
batch_turnaround_s is completion - submission for a finished batch (or
elapsed time so far), and median_turnaround_s is the batch field the web
page labels "Median turnaround time" (expire_time; usually unset for
BUDA, then null). If the server reports per-job sent/received times,
median_job_turnaround_s is their median. Set runtime_sample=N (<= 50) to also fetch N completed
jobs and report the median elapsed and CPU run time of their canonical
instances (one extra request per job).
Inputs: batch_id (required), runtime_sample. Returns: object
Download the batch's output ("Get tarred output files", get_output3.php) as dest_dir/batch_.tar. Returns the path, size and number of files in the tar, never the contents. With extract=true also unpacks it into dest_dir/batch_/. Works for batch-collect apps such as BUDA; the server allows one download of a batch at a time.
Inputs: batch_id (required), dest_dir (required), extract. Returns: object
One job (workunit): its instances and their states, and, if job_name
is given (from batch_jobs), the exit status, elapsed/CPU time and the last
stderr_tail characters of stderr of its canonical (or a failed)
instance.
Inputs: job_id (required), job_name, stderr_tail. Returns: object
List the account's batches (newest first). Retired batches are not
returned by the server. Optional state filter: init, in_progress,
complete, aborted. app_name is "buda" for BUDA (Docker) batches.
Inputs: state. Returns: result
DESTRUCTIVE: retire the batch on BOINC Central: the server immediately deletes the batch's collected output (results/<batch_id>, i.e. what download_batch_output fetches), cancels its unsent jobs and hides it from listings. Download the output first. Call only when the user explicitly asked, and pass confirm=true.
Inputs: batch_id (required), confirm. Returns: object
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 7 tools
The batch-level reads (list_batches, batch_status, batch_jobs) are cleanly separated by scope, and job_details clearly drills into a single workunit. The only mildly confusable pair is abort_batch vs retire_batch, since both are destructive and both cancel unsent jobs, though the descriptions spell out the difference (state change vs output deletion).
Half the tools follow a verb_noun pattern (list_batches, download_batch_output, abort_batch, retire_batch) but the rest are bare noun phrases (batch_status, batch_jobs, job_details), and one is singular/plural inconsistent with the others (job_details vs batch_jobs). It is still readable but the convention is mixed.
Seven tools is well within a comfortable range and each one covers a distinct step: discovery, status, per-job inspection, output retrieval, and the two terminal destructive actions. Nothing looks redundant or missing for the stated batch-management purpose.
The read/inspect/download/teardown lifecycle is well covered, including output extraction and runtime sampling. However, there is no way to create or submit a batch, and no way to cancel or retry an individual failed job, so an agent cannot drive the full batch lifecycle end to end.
Run and manage H Company's Computer-Use Agents from any MCP client.
Remote MCP for Android CLI agent build gate, structured receipts, audit logs, and reviewer-ready evi
Manage brainCloud apps, cloud code, hooks and servers; API lookups to help generate client code.
Dispatch and track Alchemist Cloud tickets, watch deploys, read logs, and query your project DB.
