boinc-central-mcp

Overview Schema Source Related Servers Discussions Admin

batch_jobs

Read-onlyIdempotent

Retrieve jobs in a batch with status, CPU time, and exit/error flags; filter by status and paginate to inspect progress or failures.

Instructions

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "batch_id": "<batch_id>"
    },
    "name": "batch_jobs"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No
`offset`	No
`status`	No
`batch_id`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 25, 2026

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuinely useful behavior: which fields are populated depends on job status (CPU time only for done, error flags only for failed), which an agent cannot infer from the schema. It says nothing about ordering, result limits, or what happens when the batch id is invalid.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: the first front-loads what the tool returns, the second covers filtering and pagination. Nothing is padded, though the inline status enumeration in the first sentence duplicates the enum half a line later.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-shape explanation is not required, and the filter/pagination contract is stated. Still missing for a paged, batch-scoped read: ordering of results, what happens with an unknown or retired batch, and the meaning of the required batch_id.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description carries real weight and it does explain the two non-obvious parameters: `status` as a filter (with its four values echoed) and limit/offset as pagination. It leaves batch_id unmentioned and does not note defaults (200/0) or whether status accepts only one value, so the gap is only partly filled.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource precisely (jobs of a given batch) and enumerates what each record carries: status, canonical instance id, CPU time for done jobs, exit status/error flags for failed ones. That is enough to separate it from siblings like list_batches and job_details, though the verb ('list/fetch') is only implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states that you can filter by `status` and paginate with limit/offset, which implies the usage pattern for a paged job listing. It never says when to prefer this over job_details for a single job, or when batch_status is the better entry point, so no explicit routing guidance is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server