boinc-central-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BOINC_CENTRAL_URL | No | Base URL of the BOINC project to query. Defaults to https://boinc.berkeley.edu/central/. | https://boinc.berkeley.edu/central/ |
| BOINC_CENTRAL_AUTH_FILE | No | Path to the file containing your BOINC Central account key (authenticator). Defaults to ~/.config/boinc-central/authenticator. Only a path is accepted; the key itself is never taken from an environment variable value or tool argument. | ~/.config/boinc-central/authenticator |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_batchesA | List the account's batches (newest first). Retired batches are not
returned by the server. Optional |
| batch_statusA | 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_jobsB | 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 |
| job_detailsA | One job (workunit): its instances and their states, and, if |
| download_batch_outputA | 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. |
| abort_batchA | 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. |
| retire_batchA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
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.