dtu-hpc

by PV-Bhat

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
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).
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 3.9/5 across 20 of 20 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 12 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![dtu-hpc-mcp MCP server](https://glama.ai/mcp/servers/PV-Bhat/dtu-hpc-mcp/badges/card.svg)](https://glama.ai/mcp/servers/PV-Bhat/dtu-hpc-mcp)

Score Badge

Copy to your README.md:

[![dtu-hpc-mcp MCP server](https://glama.ai/mcp/servers/PV-Bhat/dtu-hpc-mcp/badges/score.svg)](https://glama.ai/mcp/servers/PV-Bhat/dtu-hpc-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/PV-Bhat/dtu-hpc-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server