The dtu-hpc server provides secure, audited access to the DTU HPC LSF cluster for job submission, monitoring, and management, along with account and file operations. It includes safety features like resource limits, jailed file access, and audit logging.
Connection and account: Check control plane status (hpc_status), list available operations (hpc_operations), view user identity/group/quotas (hpc_whoami, hpc_quota).
Queue and GPU discovery: List queues (hpc_queues), view GPU entitlements and caps (hpc_gpu_entitlement), check current GPU node availability and models per queue (hpc_gpu_nodes, hpc_gpu_models).
Project file management: Upload project files with size limits (hpc_sync_project) and fetch logs or text files (hpc_fetch_log).
Job submission: Render job scripts for preview (hpc_render_job), submit single jobs (hpc_submit_run) or checkpoint-resumed chains (hpc_submit_chain) with resource caps and user confirmation for high-threshold jobs.
Job monitoring and diagnosis: List user's jobs including finished ones (hpc_jobs), get detailed status/history (hpc_job_status, hpc_job_history), see pending reasons (hpc_pending_reason), and check CPU/memory efficiency (hpc_job_efficiency).
Job control and auditing: Cancel jobs (hpc_cancel) and review an audit log of all actions (hpc_audit).
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., "@dtu-hpc Submit a training job on 2 A100 GPUs for 4 hours."
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.
Let your coding agent run your DTU HPC jobs — without ever giving it a shell.
dtu-hpc connects MCP-capable agents (Claude Code, Codex, and others) to the
DTU Computing Center cluster through a small, audited set of operations. You
authenticate once a day; your agent submits, monitors, chains, and diagnoses
LSF jobs while you direct the research. No SSH terminal, no Cisco VPN in your
daily loop, and no interactive shell on the login node — every action the agent
can take is a named, argument-validated operation under limits it cannot
raise.
Because your student account is personally accountable for everything that happens on a shared, rationed cluster — and agents are already being used over raw SSH today, with no guardrails at all. This tool is the safer path for something that is happening anyway:
No shell on the login node. Agents choose from named operations (submit job, check queue, fetch logs). Every argument is validated. There is no "run this command", and agents never supply script text — they send a spec, and the trusted daemon writes the job script itself.
Jailed writes. Agents can only touch approved project folders, with paths re-checked after the server resolves them, so a planted symlink can't escape. Your dotfiles and SSH keys are structurally out of reach.
Hard limits the agent cannot raise. GPUs, cores, memory, walltime, chain length, concurrent jobs, and submissions per hour, enforced inside the credentialed daemon from a file outside your project. Raising one takes a human edit plus a restart.
Audit trail. Every action — including every denied one — is logged locally. You can always answer "what did my agent do on the cluster?"
One kill switch. All access flows through one daemon on your laptop.
Stop it and every agent loses cluster access instantly. (Jobs already queued
keep running on DTU — dtu-hpc down tells you which, so you can cancel them
first if that's what you meant.)
Nothing installed on the cluster. DCC sees ordinary SSH sessions and ordinary, well-formed job submissions. No daemons on login nodes.
No telemetry. This tool never phones home. Your usage data is yours.
Related MCP server: swarm-mcp
DCC runs LSF, which most tutorials (and most LLMs) get wrong — they emit SLURM syntax the cluster rejects, or omit the flags that silently kill jobs at 15 minutes and 1 GB of RAM. The templates here encode the cluster's real rules, including the one that matters most for ML work:
GPU jobs die at 24 hours. dtu-hpc treats longer runs as first-class:
hpc_submit_chain splits a 72-hour training run into three checkpointed,
dependency-linked segments that resume from each other, with LSF signalling
your trainer ten minutes before each kill so it can flush a checkpoint.
Claude Code / Codex agents: disposable, hold no secrets
│ stdio (MCP)
dtu-hpc MCP server stateless adapter
│ loopback + per-run token
dtuhpcd you type your password HERE, once — nowhere else
│ one persistent SSH session
login.hpc.dtu.dk → LSF cluster sees a normal user session# Not on PyPI yet — install from source:
git clone https://github.com/PV-Bhat/dtu-hpc-mcp && cd dtu-hpc-mcp
python -m venv .venv && .venv/Scripts/activate # Linux/macOS: source .venv/bin/activate
pip install -e .
dtu-hpc init # key setup + cluster install + agent config snippetsinit walks you through installing an SSH key on the cluster (you type your
DTU password into OpenSSH's own prompt — this tool never sees it). After that,
the VPN is no longer needed for cluster work.
dtu-hpc up # start the control plane, authenticate once
dtu-hpc status # check it
dtu-hpc audit # see everything your agents did
dtu-hpc down # revoke all agent accessThen talk to your agent:
"Run the GRPO config on 2 A100s with a 4-hour budget, and chase it — if it OOMs, halve the batch size and resubmit."
Being straight about the boundary, because the audience is students staking a real account: a batch job is arbitrary code running as you on a compute node. That is what a batch job is on every cluster. This tool bounds what gets submitted — resources, destinations, rate — and records all of it. It does not sandbox the code inside your job, and an agent that can submit jobs effectively has your Unix account on the compute nodes. The audit log is a plain file, so it is evidence against a confused agent, not a hostile one. Run this with agents you'd trust with your cluster account, and read the log.
The daemon holds the only credential and the only connection. Agents reach it through a token-gated loopback socket and can only invoke allowlisted operations with regex-validated arguments. Writes are confined to declared project roots, re-validated after the server resolves symlinks. Job scripts are rendered by the daemon from a spec — agents never supply shell — and are checked against ceilings held outside the project tree, so a profile an agent can edit cannot raise them. Every operation, parameter, and denial is appended to a local audit log. Killing one process revokes access.
Early but real: read, sync, submit, and chain paths all work and have been exercised against DCC. Five independent code reviews (2026-07) found and fixed a class of bugs where resource limits were enforced in the wrong process; see DESIGN.md §2 for what changed and why.
Known gaps, honestly: there is no durable run ledger yet, so a run's story lives across a manifest, the scheduler, and logs rather than one place. Human approval above thresholds is currently asserted by the agent rather than confirmed through a trusted channel. Artifact fetch (pulling results back) isn't built. There are no tests yet.
Issues and PRs welcome — especially from other DTU students. If you run a
cluster and want a backend for it, lsf.py is the template to copy.
This tool submits standard bsub jobs from a standard SSH session and runs
nothing on your infrastructure. It exists to make agent-assisted usage more
conservative than manual usage: validated scripts, capped resources, no
login-node compute, full local audit. We'd welcome your review of the
operation allowlist — open an issue or reach out.
Login failing? Read docs/AUTH.md first. The short version: outside the DTU VPN the cluster requires an SSH key and your password, so a missing key looks exactly like a wrong password. Turn on the VPN, start the daemon, press Enter at the passphrase prompt, type your DTU password.
Recent control-plane actions, newest last.
Args: limit: How many entries to return.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions ordering and recency but lacks details on time window, permission requirements, rate limits, or whether the tool is read-only. This is insufficient for a tool expected to be safe to invoke.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences. The first sentence states the core functionality, and the second documents the parameter. No redundant or extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description covers the basics but lacks details like the time window of 'recent' actions, whether filtering is possible, or if it requires admin privileges. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the 'limit' parameter as 'How many entries to return,' adding meaning beyond the schema's type and default. This is helpful, though it could note the default value (30) explicitly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves recent control-plane actions ordered newest last. The purpose is identifiable, but it does not differentiate from sibling tools like hpc_operations or hpc_job_history, which may also return recent actions but with different scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., hpc_operations for system operations, hpc_job_history for job-level events). The description does not mention prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel one LSF job. Only cancel jobs this project submitted.
Args: job_id: Numeric LSF job id.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the destructive action and project restriction, but lacks details on error behavior (e.g., if job is not from this project) or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main action and constraint. It could be slightly more structured but is concise and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool that cancels a job, the description is adequate. It covers the essential action and scope. The presence of an output schema (not shown) likely covers return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description adds 'Numeric LSF job id' to the job_id parameter, clarifying that the string should be numeric. This adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool cancels one LSF job and specifies the project constraint. The name 'hpc_cancel' is self-explanatory and distinct from sibling tools like hpc_status or hpc_fetch_log.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the tool can only cancel jobs from the project that submitted it, providing a clear usage condition. However, it does not mention when not to use it or suggest alternatives like checking job status first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a log or small text file from inside the project jail (tail semantics).
Args: path: Absolute remote path, must be under an allowed project root. max_bytes: How much of the end of the file to return (cap 512KB).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| max_bytes | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses read-only behavior, path restriction (must be under project root), a byte cap (512KB), and the tail semantics. It does not cover error handling or permissions, but the disclosed traits are substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a short Args list. Every sentence adds value: the first defines purpose, the second constrains parameters. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description need not detail return values. It adequately covers the two parameters and the tail semantics. Minor omission: error cases or behavior when file not found, but overall complete for the tool's scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description is essential. It adds clear meaning: 'path' is an absolute remote path under allowed project root; 'max_bytes' controls how much of the end to return with a cap. This goes well beyond the schema's type/title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'log or small text file' with 'tail semantics', and 'from inside the project jail' distinguishes it from sibling tools that operate on jobs, quotas, or other resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading file tails via 'tail semantics' and parameter constraints, but does not explicitly state when to use this tool versus alternatives or provide exclusions. The sibling list is diverse, but no guidance on selection is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report which GPU queues this account may submit to, and their caps.
Use this before designing any GPU experiment: walltime ceilings and per-user slot limits determine whether a run must be split into a checkpointed chain.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Implies read-only report but does not explicitly state no side effects, authentication needs, or rate limits. Adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and presence of output schema, the description sufficiently explains the tool's purpose and usage context. Could mention account prerequisites but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters (0 params), so baseline score is 4. Description does not need to add parameter info; schema coverage is 100% trivially.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it reports GPU queues and their caps (limits). Differentiates from sibling tools like hpc_queues (general queues) and hpc_gpu_nodes (specific nodes) by focusing on account entitlements and limits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using this tool before designing GPU experiments, explaining that walltime and slot limits affect checkpointing. Provides clear context but does not list alternatives or exclude other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live GPU models and availability in a queue. Use before A100 jobs: gpua100 mixes 40GB and 80GB nodes and there is NO selector to force 80GB.
Args: queue: GPU queue name (e.g. "gpua100").
| Name | Required | Description | Default |
|---|---|---|---|
| queue | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It reveals that the data is 'Live' (real-time), and it warns about the queue mixture (gpua100 mixes 40GB and 80GB nodes with no selector to force 80GB). This goes beyond the schema to disclose operational context. It does not mention idempotency or error behavior, but for a simple read tool, the key traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence stating purpose and a usage note, followed by the parameter definition. Every sentence adds value (purpose, context, parameter). No fluff. It is front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no nested objects, existence of output schema), the description covers all needed information: what it does, what it returns (models and availability), the parameter, and a usage hint. The output schema handles return value details, so this is complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so by defining the single parameter: 'queue: GPU queue name (e.g. "gpua100")'. This provides a clear description, type, and example, adding full meaning beyond the bare schema. For a one-parameter tool, this is excellent coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool provides 'Live GPU models and availability in a queue,' which clearly indicates it retrieves GPU model information for a given queue. The noun form is acceptable given the tool name, and it distinguishes from siblings like hpc_gpu_nodes by focusing on models rather than node details. However, it lacks an explicit action verb like 'get' or 'list,' so it's not maximally explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises 'Use before A100 jobs' and explains a specific scenario about queue mixing, providing context for when to use the tool. However, it does not explicitly mention alternatives or when not to use this tool. Sibling tools like hpc_gpu_nodes exist but are not compared, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current GPU node availability.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It only states 'Current GPU node availability' without mentioning whether the data is real-time, cached, or any side effects (e.g., read-only). This is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is appropriately sized for a tool with no parameters and a clear purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, output schema exists), the description is nearly complete. It identifies the resource (GPU nodes) and the nature (current availability). While it could specify output structure, the presence of output schema mitigates this need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already covers all semantics. The description adds no additional parameter meaning, but the baseline for 0 parameters is 4, and the description does not mislead. It correctly implies a simple query with no inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Current GPU node availability' clearly indicates the tool retrieves availability status of GPU nodes, distinguishing it from siblings like hpc_gpu_entitlement and hpc_gpu_models. However, it lacks specifics on what 'availability' entails (e.g., counts, node identifiers), which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives such as hpc_gpu_entitlement or hpc_gpu_models, leaving the agent to infer context from tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CPU and memory efficiency of a job vs. what it requested. Check this after every substantial run and tighten the next request accordingly.
Args: job_id: Numeric LSF job id.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must convey behavior. It states it's an efficiency check (read operation) but lacks details on error conditions (e.g., invalid job_id) or whether it works on running/completed jobs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with front-loaded purpose, immediate usage guidance, and clear parameter documentation. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, description does not need to explain return values. It covers key aspects: efficiency metric, when to use, and parameter. Minor omission: no mention of job state prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage (only title for property). Description adds meaning by specifying job_id as 'Numeric LSF job id', which is vital for correct invocation. Could be more detailed about format, but is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides CPU and memory efficiency of a job vs. requested. It is distinct from siblings like hpc_job_status or hpc_job_history which focus on status or history, not efficiency.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to check after every substantial run and tighten next request, giving clear usage context. However, does not mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scheduling history for one job -- why it pended, why it exited.
Args: job_id: Numeric LSF job id.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks behavioral traits beyond the stated purpose. No annotations are provided, so the description carries full burden but does not disclose permissions, side effects, rate limits, or error handling (e.g., for invalid job_id).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus an Args section, no filler. Front-loaded with the main purpose, then parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no annotations, but has output schema), the description is minimally adequate. It explains what the tool returns but lacks context about required permissions, job lifecycle stage (e.g., completed vs running), or side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds 'Numeric LSF job id.' to the parameter, clarifying its type and system context. Since schema coverage is 0%, this provides minimal yet helpful meaning beyond the schema's type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Scheduling history for one job -- why it pended, why it exited.' This specifies the verb (retrieve history) and resource (single job), distinguishing it from siblings like hpc_job_status (current status) or hpc_jobs (list jobs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, when not to use it, or compare to sibling tools like hpc_pending_reason or hpc_job_efficiency.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All of this user's LSF jobs, including recently finished ones.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only mentions 'including recently finished ones,' but fails to clarify what 'recently' means, whether authentication is needed, or if the list is paginated. The behavioral disclosure is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the core action. However, it could benefit from additional structure or detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and an existing output schema, the description is minimal but adequate. It explains the tool's scope (user's jobs) and includes that it covers recently finished ones. Still, it lacks details on sorting, limits, or the definition of 'recently,' which could help the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% coverage, so the description adds no parameter info. Given the schema is exhaustive, a baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists LSF jobs for the current user, including recently finished ones. It specifies the resource (LSF jobs) and the scope (user's jobs). However, it does not explicitly differentiate from sibling tools like hpc_job_status or hpc_job_history, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives. The description does not mention any prerequisites, exclusions, or context for use. For a tool with many siblings, this omission reduces usability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full detail for one job.
Args: job_id: Numeric LSF job id.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Full detail' without specifying what details are included, any side effects, permissions, or limitations. This is insufficient for an agent to understand the tool's behavior beyond its basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two lines with the purpose immediately front-loaded. Every word has a purpose, with no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, output schema present), the description is mostly complete. It states the purpose and the parameter meaning. The output schema handles return value details, so the description is adequate, though it could mention that it provides full job detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema property 'job_id' has only a title 'Job Id' with no description (coverage 0%). The description adds 'Numeric LSF job id', which clarifies the parameter's format (numeric) and system context (LSF), adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Full detail for one job' clearly states the tool's purpose: retrieving detailed information about a specific job. This distinguishes it from siblings like hpc_status (likely overall status) and hpc_jobs (likely listing jobs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'for one job', but does not explicitly mention when not to use or alternatives. The sibling tool names provide context, but the description itself lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every cluster operation the policy layer permits, with parameters.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only says 'list', implying read-only, but does not mention authentication needs, rate limits, or any side effects. The output schema exists but is not referenced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and contains no redundant information. Every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema to explain return values, the description is nearly complete for a simple listing tool. It could mention what the output contains, but the schema covers that. Minor gap: no mention of typical use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters and 100% schema coverage, so baseline is 4. However, the description says 'with parameters', which could be misleading as there are none. This slight inaccuracy reduces the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List every cluster operation the policy layer permits, with parameters.' It specifies the verb 'list' and resource 'cluster operation', and distinguishes from siblings like hpc_submit_run or hpc_cancel by focusing on enumeration of all permitted operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like hpc_audit or hpc_status. It does not mention when not to use or context where another tool is preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Why a pending job is pending, in the scheduler's own words.
Args: job_id: Numeric LSF job id.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It implies a read operation by indicating the tool queries the scheduler's pending reason, but it does not disclose side effects, authorization needs, or whether it is safe to call repeatedly. Given the tool's simplicity, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a clear lead sentence followed by a structured Args block. Every word serves a purpose, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description need not detail return values. It covers the tool's core function and parameter sufficiently for a simple query tool. Minor gap: no mention of error conditions, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an explicit Args section that adds meaning beyond the schema: it specifies that job_id is numeric and an LSF job ID. This compensates for 0% schema coverage and helps the agent provide correct input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to explain why a pending job is pending, using the scheduler's own words. This is a specific verb+resource pairing that distinguishes it from sibling tools like hpc_status and hpc_job_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention context, prerequisites, or when not to use it, leaving the agent to infer from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List LSF queues, or show full limits for one queue.
Args: queue: Optional queue name (e.g. "gpua100"). Omit to list all queues.
| Name | Required | Description | Default |
|---|---|---|---|
| queue | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies read-only behavior (listing or showing limits) with no side effects. However, it does not elaborate on what 'full limits' entails, nor performance or authentication aspects. Adequate but not rich in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus an Args section. It immediately states the core purpose and front-loads the most important information. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, output schema exists), the description is fairly complete. It covers both modes and provides a usage example. It could mention authentication or error cases, but for a basic listing tool this is acceptable. The absence of annotations is partly compensated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates well. It explains the queue parameter is optional, provides an example value ('gpua100'), and clarifies that omission lists all queues. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists LSF queues or shows full limits for one queue. The verb 'list' is specific and the resource 'LSF queues' is unambiguous. It distinguishes two modes: listing all or detailing one. This differentiates it from sibling tools like hpc_jobs or hpc_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives. It explains the queue parameter but offers no scenarios, preconditions, or comparisons with siblings such as hpc_status or hpc_jobs. No explicit when-to-use or when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Storage quotas for home and work3.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose whether this is a read-only operation, authentication requirements, or any side effects. For a query tool, this is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence. No wasted words, but perhaps overly brief for full clarity. Still front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and an output schema available, the description provides minimal context. It names the two quota sources but does not hint at the output structure or edge cases. Adequate for a simple tool but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline 4 applies. The description adds no parameter information, but the schema already reflects zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides storage quotas for two specific directories ('home' and 'work3'). The verb 'quotas' implies querying, which distinguishes it from sibling tools that deal with jobs, audits, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like hpc_audit or hpc_status. The description does not explain context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render the LSF job script a submission WOULD use, without submitting.
Use this to show the human a script before the first run of a new profile.
Args: profile_path: Path to the local profile YAML. run_id: Short identifier for this run (e.g. "exp03"). resource_overrides: Optional JSON object overriding profile resources, e.g. '{"walltime": "04:00", "gpus": 1}'.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | ||
| profile_path | Yes | ||
| resource_overrides | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavioral trait that the tool does not submit the job ('without submitting'). However, it does not describe the output format or any side effects, such as whether the script is printed to stdout or returned as a string. With no annotations provided, the description carries the full burden but lacks some detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using three sentences plus a bullet list for parameters. It is front-loaded with the main purpose, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with an output schema (though not shown), the description covers the essential aspects: purpose, usage, and parameters. It mentions the output is a script, which is sufficient. However, a brief note on the output format (e.g., 'returns the script as a string') would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description fully defines all parameters: profile_path (path to local profile YAML), run_id (short identifier), and resource_overrides (optional JSON object with an example). This compensates completely for the schema gap and adds meaningful context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Render the LSF job script a submission WOULD use, without submitting,' specifying the verb 'render' and the resource 'LSF job script'. It distinguishes from sibling tools like hpc_submit_run by explicitly mentioning it's a dry run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use this to show the human a script before the first run of a new profile.' It implies this tool is for initial validation, not for regular submissions. However, it does not explicitly mention alternatives or when not to use, which would elevate it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether the DTU control plane is authenticated and connected.
Call this first in any session. If it reports the daemon is unavailable, the user must start and authenticate it themselves -- you cannot do it for them.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool is a read-only status check and reveals a key behavioral constraint: if unavailable, the tool cannot fix it. However, it does not explicitly state whether it is non-destructive or mention any side effects, but the nature of a status check makes these implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no redundant words. It front-loads the key purpose in the first sentence, immediately followed by usage guidance and behavioral notes. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists (though not detailed), the description fully covers what the agent needs: what status means, when to call, and what to do with the result. It is complete for a health-check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so baseline is 4. The description does not need to add parameter meanings, and it doesn't repeat schema information. It correctly focuses on purpose and usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks authentication and connection status of the DTU control plane. It uses specific verbs ('Check whether') and identifies the resource ('DTU control plane'), distinguishing it from sibling tools that handle other operations like job submission or auditing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this first in any session,' providing clear when-to-use guidance. It also explains what to do if the daemon is unavailable and notes the tool's limitation that it cannot start or authenticate the daemon, which helps agents decide when to escalate to the user.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a checkpoint-resume chain of dependent jobs for runs longer than the 24h GPU walltime cap. The training command must support --resume-from and checkpoint on SIGUSR2 -- verify this BEFORE submitting.
Args: profile_path: Path to the local profile YAML. run_id: Short identifier; segments become .0, .1, ... project_dir: Local project directory for manifests. segments: Number of walltime-sized segments (total = segments x walltime). resource_overrides: Optional JSON object overriding profile resources. confirmed_by_user: Set ONLY after explicit human approval when above the profile's confirmation thresholds. Chains are always above the 12h default threshold in total, so this usually requires asking.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | ||
| segments | Yes | ||
| project_dir | Yes | ||
| profile_path | Yes | ||
| confirmed_by_user | No | ||
| resource_overrides | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes chain submission and dependency; mentions confirmation thresholds. No annotations, so description carries burden. Lacks failure behavior details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficient front-loaded paragraph explaining purpose and prerequisite, followed by bullet list of args. No redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, prerequisites, parameter details, and confirmation need. Output schema exists for return values, so completeness is high.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning to all 6 parameters: naming convention for segments, required human approval for confirmed_by_user, optional JSON for resource_overrides. 0% schema coverage compensated fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'submit' and specific resource 'checkpoint-resume chain of dependent jobs' for runs >24h. Distinct from siblings like hpc_submit_run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit prerequisite: training command must support --resume-from and SIGUSR2. Implicit context for long runs, but no direct comparison to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a single job from a profile. Caps are enforced; runs above the profile's confirmation thresholds require an explicit yes from the human.
Args: profile_path: Path to the local profile YAML. run_id: Short identifier for this run. Also names the local manifest. project_dir: Local project directory (manifests land in runs//). resource_overrides: Optional JSON object overriding profile resources. confirmed_by_user: Set ONLY after the human explicitly approved an above-threshold run in conversation.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | ||
| project_dir | Yes | ||
| profile_path | Yes | ||
| confirmed_by_user | No | ||
| resource_overrides | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes key behaviors: caps enforcement, confirmation thresholds, and requirement for human approval. With no annotations, this adds necessary context, though it doesn't detail failure modes or default behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise paragraphs: first states purpose and key behavior, second lists parameters with clear explanations. No unnecessary words; front-loaded with critical info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, presence of an output schema, and sibling tools, the description covers all essential aspects: submission process, human-in-loop, parameter purposes, and constraints. An agent can use this correctly without ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully explains all 5 parameters, including the special usage of confirmed_by_user and the optional nature of resource_overrides. This adds significant meaning beyond the schema's titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'submit' and the resource 'a single job from a profile,' differentiating it from sibling hpc_submit_chain. The mention of caps and confirmation thresholds further clarifies the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (submit single job) and provides guidance on the confirmed_by_user parameter. Though it doesn't explicitly list when not to use, sibling names imply alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload the project's source files to its remote root on the cluster.
Run this BEFORE submitting, whenever local code has changed — the connector does not upload anything automatically, and a job will happily run stale code. Source and configs only: files over 4MB are refused, and datasets or model weights must go via the transfer node or be downloaded by the job.
Args: profile_path: Path to the local profile YAML (its sync_include / sync_exclude patterns decide what is sent). project_dir: Local project directory to upload from. dry_run: List what would be uploaded without sending anything.
| Name | Required | Description | Default |
|---|---|---|---|
| dry_run | No | ||
| project_dir | Yes | ||
| profile_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key traits: uploads source/configs only, refuses files >4MB, and dry_run lists without sending. However, lacks details on overwrite behavior, idempotency, or error handling. With no annotations, the description carries full burden and is partially adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise—two sections: a brief purpose/usage paragraph followed by a clean, labeled arg list. Every sentence adds value; no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core usage, parameter roles, and key limitations (file size, dataset handling). With an output schema present but not described, and no annotations, the description is sufficient for an experienced HPC user, but could mention return value or error scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage; the description fully compensates by explaining each parameter's role: profile_path's sync patterns, project_dir as source, and dry_run as a listing mode. This adds essential meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool uploads project source files to the cluster root. It distinguishes itself from related tasks like submission and dataset transfer, but does not explicitly differentiate from sibling tools by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises running before submission after code changes, and notes that the connector doesn't auto-upload. It also clarifies what to exclude (datasets, model weights, large files), providing clear when-to and when-not-to guidance. Misses explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identity, groups, login node and home directory on the DTU cluster.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the full burden. It states the output fields but does not explicitly declare read-only or safe behavior. The name 'whoami' implies no side effects, but the description could be more transparent about being non-destructive and requiring no special permissions. Adequate but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with no wasted words. Front-loaded with key data types. Every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only introspection tool with an output schema, the description is sufficient. It tells exactly what information is returned. It could mention the output schema exists, but that is structured data. Overall complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4 per guidelines. Description adds nothing about parameters, but none are needed. Schema coverage is 100% for zero params, so no gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns identity, groups, login node, and home directory on the DTU cluster. It distinguishes from siblings like hpc_jobs or hpc_quota by specifying the type of information returned. However, it lacks an explicit verb like 'Get' or 'Retrieve', but the noun list is sufficient.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description only states what it returns, not when it is appropriate. Given the sibling tools include many task-specific ones, the agent would benefit from a note like 'Use to get current user context before submitting jobs or checking quotas.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0hpc_audithpc_cancelhpc_fetch_loghpc_gpu_entitlementhpc_gpu_modelshpc_gpu_nodeshpc_job_efficiencyhpc_job_historyhpc_job_statushpc_jobshpc_operationshpc_pending_reasonhpc_queueshpc_quotahpc_render_jobhpc_statushpc_submit_chainhpc_submit_runhpc_sync_projecthpc_whoamiScored across 20 tools
Each tool has a clearly distinct purpose: audit, cancel, status, fetch_log, operations, whoami, quota, queues, gpu_entitlement, gpu_nodes, jobs, job_status, job_history, sync_project, job_efficiency, gpu_models, pending_reason, render_job, submit_run, submit_chain. Even closely related tools like gpu_entitlement, gpu_nodes, and gpu_models address different aspects (permissions, availability, models).
All tools follow the consistent pattern 'hpc_<verb>_<noun>' or 'hpc_<noun>_<verb>' in snake_case, with no mixing of conventions. The prefix 'hpc_' unifies the set and each verb clearly indicates the action.
20 tools cover the major aspects of HPC cluster interaction (authentication, job submission, monitoring, GPU info, file sync, etc.) without being overwhelming. Each tool serves a unique function and the count is well-scoped for the domain.
The tool set provides comprehensive coverage for the HPC workflow: authentication, quota, queues, job lifecycle (submit, cancel, monitor, efficiency), GPU management, file synchronization, and audit. There are no obvious gaps for typical cluster operations.
Hosted MCP server for task-first delegation to remote workstations and workers.
Agent-native collaboration network: orchestrate a team of long-running agents from any MCP client.
Run and manage H Company's Computer-Use Agents from any MCP client.
MCP Server for an Agent Task Marketplace
