srunx

by ksterx

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: v4.2.0
Disambiguation5/5
Each tool targets a distinct resource and action. Job management tools (submit, list, status, cancel, logs) are clearly separated, and workflow tools (create, validate, get, run, list) are also distinct. The sync/inspect pair has a clear read-only vs. mutating distinction.
Naming Consistency5/5
Tool names follow a consistent verb_noun pattern: get_*, list_*, submit_*, cancel_*, run_*, create_*, validate_*, sync_*, inspect_*. There is a minor mix of 'get' and 'list' for retrieval, but this is a common and clear distinction.
Tool Count5/5
15 tools is at the upper edge of the ideal range but each tool covers a needed operation for SLURM job management, workflow handling, file sync, and configuration. No tool feels redundant or unnecessary.
Completeness5/5
The set provides full lifecycle coverage: jobs can be submitted, monitored, cancelled, and logged; workflows can be created, validated, read, executed, and listed; file sync includes preview and delete protection; resources and config are inspectable. No obvious dead ends.
Average 4/5 across 15 of 15 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 15 commits in the last 12 weeks
- Last stable release on August 18, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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 fully disclose behavioral traits. It only mentions listing all users and the transport parameter, but omits whether the operation is read-only, idempotent, or if there are any side effects or rate limits.
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 very concise, with two sentences that efficiently convey purpose and the key parameter. It is front-loaded and avoids unnecessary words.
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, one-parameter tool with an output schema, the description covers the main points. However, it lacks explicit statements about safety, idempotency, or whether the tool can be invoked without side effects, which is important for an AI 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?
With 0% schema description coverage, the description adds significant value for the only parameter, explaining its role as a cluster selector with explicit values ('local' or SSH profile). This compensates for the lack of schema-level documentation.
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 SLURM jobs in the queue, using 'like squeue' to reinforce behavior. It distinguishes from siblings like get_job_status by noting 'all users', but could explicitly differentiate further.
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 provides guidance on the transport parameter (local vs remote), but does not indicate when to use this tool over alternatives like cancel_job or get_job_status, nor when not to use it.
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, so description must disclose behavior. It omits key traits like if submission is synchronous/asynchronous, job lifecycle effects, error handling, or if it returns a job ID. The description focuses on parameters, not behavioral 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 a readable parameter list preceded by a clear summary. It is not overly verbose, but is somewhat lengthy due to 16 parameters. Front-loaded with the purpose, which is good.
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 (context signals), return values are covered. The description covers all 16 parameters with brief explanations, addresses local vs remote submission via 'transport', and includes defaults. Missing some context like default for work_dir, but overall sufficient for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain parameters. It adds one-line explanations (e.g., 'Shell command to execute', 'Job name for identification'), which is helpful but minimal. Some parameters like 'nodelist' just repeat the parameter name. Overall, adds some value beyond schema types.
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 starts with 'Submit a SLURM job', a specific verb+resource, and the parameter list makes it distinct from sibling tools like cancel_job or get_job_logs.
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 siblings. It does not mention whether to use submit_job for batch jobs, interactive jobs, or alternatives like run_workflow.
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. It only states the tool reads and parses, but does not disclose read-only nature, error behavior (e.g., missing file), or whether it accesses local/remote storage.
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 concise with a one-line summary followed by an Args section. It is front-loaded and has no wasted words, though additional context could be added without significant bloat.
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 has only one parameter and an output schema exists, the description covers the basic purpose. However, it lacks context on error handling, read-only behavior, and potential side effects, making it only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description adds 'Path to the YAML workflow file' to the parameter 'yaml_path', which adds meaning beyond the schema's type definition, but the parameter is simple and no additional constraints or formats are given.
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 parse') and resource ('workflow YAML file') and outcome ('returning its full structure'). This distinguishes it from siblings like validate_workflow or create_workflow.
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 when needing the full structure of a specific workflow file, but provides no exclusions or alternative tools. It does not explicitly say when not to use it vs other workflow tools.
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, and the description only states the tool's action without disclosing any behavioral traits such as auth requirements, error handling, or what happens when logs are unavailable. The description does not fill the gap left by missing annotations.
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 core purpose is front-loaded in the first line. The parameter list is clear but could be more concise; it restates some schema information. Overall, it is short and functional.
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 an output schema present, the description does not need to detail return values. It covers the main inputs adequately but omits edge cases or behavior for missing logs, which is acceptable for a focused tool. Completeness is moderate.
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 has 0% description coverage, but the description adds meaningful context for each parameter: job_id is a SLURM job ID, job_name helps locate files, and transport specifies local vs remote clusters. This compensates well for the schema's lack of detail.
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 begins with a clear verb and resource: 'Get stdout/stderr logs for a SLURM job.' It immediately distinguishes itself from sibling tools like get_job_status or list_jobs by specifying logs retrieval.
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 explains the parameters and their roles but does not explicitly state when to use this tool versus alternatives or any prerequisites. It provides implicit context but lacks formal guidance.
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 carry the full behavioral disclosure. It mentions cancellation but does not describe side effects (e.g., incomplete output), idempotency, required permissions, or behavior if job is already finished.
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 lines plus an Args section. Every sentence adds value, and there is no redundant or extraneous information.
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 cancellation tool with an output schema (not shown), the description covers basic purpose and parameters. However, it lacks usage guidelines and behavioral transparency, making it moderately complete.
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 explains both parameters: job_id as 'SLURM job ID' and transport as cluster selector with valid values. This adds meaning beyond the schema, though format validation (e.g., job_id pattern) is missing.
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 'Cancel' and resource 'SLURM job', with scope 'running or pending'. It distinguishes from sibling tools like submit_job, list_jobs, etc., which focus on other actions.
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 provides guidance on the transport parameter (local vs remote SSH), but does not explicitly state when to use this tool versus alternatives, such as when a job is already completed or prerequisites for remote cancellation.
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 full burden for behavioral disclosure. The description states 'Get' which implies read-only, but does not explicitly confirm no side effects, required permissions, rate limits, or data volume. The description is minimal on behavior beyond the basic function.
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 concise, with a clear first sentence stating the purpose. The parameter details are included efficiently. However, the Args section is embedded in the description text, which is acceptable but slightly repetitive. No unnecessary 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 the tool has only two optional parameters and an output schema exists (so return values are covered), the description is fairly complete. It explains how to specify partition and cluster. However, it does not mention usage patterns like checking before submit, which could enhance context. Still, it's sufficient for an AI agent to understand the tool's inputs.
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 effectively adds meaning: partition is explained as a specific partition to check (default all) and transport as a cluster selector with options for local or remote via SSH profile. This goes beyond the raw schema and provides clear actionable guidance.
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 gets current GPU and node resource availability on the SLURM cluster. It uses a specific verb ('Get') and resource ('GPU and node resource availability'), and the sibling tool list includes other operations like job management and workflow creation, so this tool is distinct.
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 provides some guidance via parameters (partition and transport) but does not explicitly state when to use this tool versus alternatives like get_config or list_jobs. It implies usage for checking resource availability before job submission, but lacks direct when-not-to-use or alternative recommendations.
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 adds behavioral context by stating it scans for YAML files with 'name' and 'jobs' keys, which implies filtering. However, it does not explicitly state that the operation is read-only or mention any side effects. Since no annotations are provided, the description bears the full burden, and this is a moderate effort but lacks explicit safety indicators.
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 with three sentences: the first states the purpose, the second explains the filtering, and the third clarifies the parameter. Every sentence adds value, and there is 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?
Given that an output schema exists, the description does not need to detail return values. It covers the main input and behavior. However, it is silent on whether the search is recursive or handles symlinks. For a simple list tool, this is adequate but could be more precise.
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, so the description must compensate. It adds meaning by explaining that the 'directory' parameter is the 'Directory to search for workflow files (default: current directory),' which goes beyond the schema's type and default. This provides the agent with the purpose of the parameter effectively.
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 workflow YAML files in a directory,' specifying the verb ('list'), resource ('workflow YAML files'), and scope ('in a directory'). This distinguishes it from sibling tools like create_workflow, run_workflow, or validate_workflow, which have different purposes.
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 any prerequisites, exclusions, or context where other tools might be more appropriate. The agent receives no help in deciding between listing workflows and, say, viewing a specific workflow or submitting a job.
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 the burden. It states 'Get' which implies a read-only operation, but does not explicitly confirm safety, side-effect-freeness, or any other behavioral traits. Minimal transparency beyond the obvious.
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, clear sentence that directly states the tool's purpose. Every word is necessary, and it is front-loaded with the key action and resource.
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 zero parameters, no annotations, and the presence of an output schema (which covers return values), the description is entirely sufficient for a simple getter. It is complete for the tool's complexity.
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, and the input schema coverage is 100%. According to guidelines, 0 parameters yields a baseline score of 4. The description does not need to add parameter details since none exist.
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 uses a specific verb ('Get') and clearly identifies the resource ('srunx configuration') with additional detail about contents ('resource defaults and environment settings'). This distinguishes it from sibling tools like get_resources or get_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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies it is for retrieving configuration, but with sibling tools like get_resources also available, clear differentiation is missing.
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 provided, so description carries full burden. It discloses the validation checks performed, but does not describe output format or side effects. Output schema exists but description could add context on return values.
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?
Description is concise (two paragraphs, 4 lines) with front-loaded purpose. No redundant information.
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?
Tool is simple with one parameter and output schema exists, but description does not explain what the output looks like (e.g., success/failure, error details). This gap reduces completeness despite schema coverage.
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%, so description must compensate. It provides a clear parameter description: 'Path to the YAML workflow file to validate'. This adds meaningful context beyond the schema's type-only 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?
Description clearly states the tool validates a workflow YAML file for correctness, listing specific checks (YAML syntax, job structure, dependency resolution, circular dependency detection). This distinguishes it from siblings like run_workflow or create_workflow.
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?
Usage is implied (before running a workflow) but no explicit guidance on when to use vs alternatives like run_workflow or create_workflow. No exclusions or prerequisites mentioned.
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 the full burden. It does not disclose whether the operation is read-only, requires authentication, or has any side effects. Given that there is an output schema (from context), the return format is not required, but behavioral traits are still lacking.
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 with two sentences plus a bullet list. The first sentence clearly states the tool's purpose, and the parameter details are directly relevant. No unnecessary 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?
With 2 parameters and an output schema, the description is sufficiently complete. It explains how to specify job_id and transport, and the output schema covers return values. It lacks example usage but is adequate for a simple status-check tool.
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 fully explains both parameters: job_id is 'SLURM job ID to check' and transport is described with specific usage options (local vs. SSH profile). This adds significant meaning beyond the raw 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 'Get the status of a specific SLURM job' with a specific verb (get) and resource (status of a specific SLURM job). It distinguishes from siblings like list_jobs or cancel_job by focusing on a single job's status.
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 guidance on the transport parameter: 'omit / “local” for local SLURM, or an SSH profile name to query that remote cluster.' This helps the agent decide when to use local vs. remote. However, no direct comparison with sibling tools 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?
With no annotations, the description carries the full burden. It discloses that the tool lists profiles and shows specific fields, but does not mention side effects, authentication needs, or error scenarios. For a simple read operation, this is adequate but minimal.
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, 20 words, front-loaded with the main action. Every sentence adds value without repetition.
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 zero parameters and an output schema (not shown but exists), the description is complete: it names the returned fields and the tool's scope. No further details are 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?
The tool has no parameters, so the baseline is 4. The description adds no parameter info, which is acceptable as none is needed.
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 'list' and the resource 'SSH connection profiles for remote SLURM clusters', distinguishing it from sibling tools that deal with jobs, workflows, or configuration.
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 use for viewing profiles, and no sibling tool performs this function, so explicit alternatives are unnecessary. However, it lacks explicit when-to-use or when-not-to-use guidance.
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 and discloses key behaviors: creates a YAML file, supports DAG dependencies, retry settings, resource specs, and environment configuration. It doesn't explicitly state file overwriting behavior or required permissions, but covers many aspects.
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 well-structured with a summary line and detailed Args section. It front-loads the purpose and each sentence adds value. However, it could be slightly more concise by grouping related details (e.g., dependency types) without losing clarity.
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 complexity of the tool (5 parameters including a nested jobs array) and the presence of an output schema, the description covers inputs comprehensively but omits some behavioral details like error handling or file overwrite policy. It is largely sufficient for correct agent usage.
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?
Since schema description coverage is 0%, the description compensates thoroughly: it explains the structure of the 'jobs' array, required and optional fields, example syntax for dependencies, and other parameters like 'args' and 'default_project'. This adds substantial 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 creates a SLURM workflow YAML file, specifies it generates a DAG workflow definition for use with run_workflow, and distinguishes from sibling tools like run_workflow or validate_workflow by its creation role.
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 explains that the output is executable with run_workflow, implying when to use this tool (before running). However, it lacks explicit guidance on when not to use it or comparisons with alternatives like validate_workflow or direct submission.
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, so description carries full burden. It discloses dependency-based execution order, parallel independent jobs, rejection of python: prefix in args, and sweep orchestration behavior. Missing details on auth or rate limits, but covers key behavioral traits.
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?
Efficiently structured with a one-sentence summary followed by parameter explanations. Every sentence adds value; no redundant text despite covering 9 parameters.
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 output schema present, return values are likely covered. Description explains sweep response (sweep_run_id). For normal execution, it does not detail return, but schema fills gap. Overall complete for a complex tool.
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 description must compensate. It does so thoroughly, explaining each parameter's purpose, constraints (e.g., mount requires SSH transport), and behavior (e.g., dry_run shows without executing).
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 begins with a clear verb and resource: 'Execute a SLURM workflow from a YAML file.' It distinguishes from siblings like validate_workflow, create_workflow, and submit_job by focusing on execution with dependency ordering.
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?
It explains when to use parameters like from_job, to_job, single_job, dry_run, transport, mount, and sweep, and describes dependency ordering. However, it does not explicitly state when NOT to use this tool vs. alternatives like validate_workflow or submit_job.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it excels: it declares read-only behavior, explains the max_paths cap behavior (counts stay exact, list omitted), clarifies the effect of exclude patterns ('invisible to this inspection and protected from a mirror's deletions'), and details the stale-upload semantics including the failure case (stale_uploads_unknown_reason).
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 lengthy but well-structured: bold key concepts, clear headings for args and returns, and each paragraph addresses a distinct concern (read-only, candidates, stale uploads, exclusion). The core purpose is front-loaded. While it is verbose, no sentences are wasted; it earns its length for a complex inspection tool.
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?
Even though an output schema exists (per context signal), the description explicitly lists every return field and their meaning, explains edge cases (stale_uploads_known false, max_paths omission, exclusion invisibility), and provides fallback guidance. For a tool with this complexity, the description leaves nothing an agent needs to know to call and interpret it 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 fully explain parameters. It does: transport is described as an SSH profile name with no implicit fallback, mount is tied to that profile, and max_paths is given with its cap behavior (counts exact, list omitted if exceeded). This adds meaning far beyond the simple schema definitions.
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 opens with a precise verb+resource ('Report what syncing a mount would change') and immediately distinguishes itself from sync_files by stating it cannot answer what is on the cluster that no longer exists locally. This makes the tool's unique purpose unmistakable and differentiates it from siblings.
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?
It explicitly states when to call ('before a sync you are unsure about'), how to call safely ('Call it freely'), and provides a decision rule: check stale_uploads_known first, and fall back to reading the full candidate list if it is false. It also names sibling tools like list_ssh_profiles for parameter guidance, covering both when and how to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure and exceeds it. It explains that files deleted locally persist on the cluster, that the tool does not report them, that delete destroys remote-only data, that dry_run does not touch the cluster, that max_delete counts both files and directories, and even documents the whitespace limitation on reported filenames. This is exceptionally transparent.
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 long but every sentence earns its place. It is front-loaded with a summary sentence, then structured into Args and Returns sections. The use of bold for delete and clear unit explanations makes it scannable. The length is justified by the tool's complexity and safety implications. It could not be meaningfully shortened without losing crucial detail.
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?
For a tool with five parameters, a destructive delete mode, and nuanced return counts, the description covers all necessary context: parameter choices, return value meanings, count unit differences, and edge-case behavior. Even with an output schema, this description enriches the semantics and leaves no obvious gap for an agent to misuse the tool.
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 description coverage is 0%, so the description fully compensates. Each of the five parameters is explained with real semantics: transport must be an SSH profile (no local-to-local, 'local' rejected), mount must be pre-registered, dry_run is a no-touch preview, delete is destructive and mirrors, and max_delete counts entries with a clear unit definition. This adds meaning far beyond the plain 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 opens with a specific verb and resource: 'Sync a configured mount from this machine to a remote SLURM cluster.' It explicitly notes it copies new and changed files only, distinguishing it from inspect_mount (which lists stale files) and from list_ssh_profiles (which discovers mounts). This clearly separates it from sibling tools.
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 provides explicit usage guidance: call inspect_mount to identify stale files rather than enabling delete=True, call list_ssh_profiles to see profiles and their mounts, prefer dry_run first when unsure, and always before delete=True. It also warns to leave delete off unless the user explicitly asks for a mirror. This is strong when-to-use/when-not-to guidance.
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:

[![srunx MCP server](https://glama.ai/mcp/servers/ksterx/srunx/badges/card.svg)](https://glama.ai/mcp/servers/ksterx/srunx)

Score Badge

Copy to your README.md:

[![srunx MCP server](https://glama.ai/mcp/servers/ksterx/srunx/badges/score.svg)](https://glama.ai/mcp/servers/ksterx/srunx)

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/ksterx/srunx'

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