Skip to main content
Glama
TomMelt

HPC-MCP

by TomMelt
OverviewSchemaRelated ServersScoreDiscussions
Python

hpc-mcp :zap::computer:

This project provides MCP tools for HPC. These are designed to integrate with LLMs. My initial plan is to integrate with LLMs called from IDEs such as cursor and vscode.

Quick Start Guide :rocket:

This project uses uv for dependency management and installation. If you don't have uv installed, follow installation instructions on their website.

Once we have uv installed we can install the dependencies and run the tests with the following command:

uv run --dev pytest

Adding the MCP Server

Cursor

  1. Open Cursor and go to settings.

  2. Click Tools & Integrations

  3. Click Add Custom MCP

NOTE

This will open your system-wide MCP settings ($HOME/.cursor/mcp.json). If you prefer to set this on a project-by-project basis, then you can create a local configuration using <path/to/project/root>/.cursor/mcp.json.

  1. Add the following configuration:

{
  "mcpServers": {
    "hpc-mcp": {
      "command": "uv",
      "args": [
                "--directory",
                "<path/to>/hpc-mcp",
                "run",
                "src/debug.py"
            ]
    }
  }
}

VSCode

  1. Open command palette (Ctrl+Shift+p) and select MCP: Add Server...

add MCP server

  1. Choose the option command (stdio) since the server will be run locally

  2. Type the command to run the MCP server:

uv --directory <path/to>/hpc-mcp run src/debug.py

  1. Select reasonable name for the server e.g. "HpcMcp" (camel case is a convention)

  2. Select whether to add the server locally or globally.

  3. You can tune the settings by opening setting.json (global settings) or .vscode/setting.json (workspace settings)

add MCP server

Zed

  1. Open Zed and go to settings.

  2. Open general settings CTRL-ALT-C

  3. Under section Model Context Protocol (MCP) Servers click Add Custom Server

  4. Add the following text (changing the <path/to>/hpc-mcp to your actual path)

{
  /// The name of your MCP server
  "hpc-mcp": {
    /// The command which runs the MCP server
    "command": "uv",
    /// The arguments to pass to the MCP server
    "args": [
      "--directory",
      "<path/to>/hpc-mcp",
      "run",
      "src/debug.py"
    ],
    /// The environment variables to set
    "env": {}
  }
}

Test the MCP Server

Test the MCP using our simple example

  • open terminal

  • cd example/simple

  • build the example using make

  • this should generate segfault.exe

  • then type the following prompt into your IDE LLM agent

"debug a crash in the program examples/simple/segfault.exe"

  • this should ask your permission to run debug_crash MCP tool

  • accept and you should get a response like the following cursor-demo

Related MCP server: jlab-mcp

Running local LLMs with Ollama

To run the hpc-mcp MCP tool with a local Ollama model use the Zed text editor. It should automatically detect local running ollama models and make them available. As long as you have installed the hpc-mcp MCP server in zed (see instructions here) it should be available to your models. For more info on ollama integration with zed see zed's documentation.

NOTE

Not all models support calling of MCP tools. I managed to have success withqwen3:latest.

Core Dependencies

  • python

  • uv

  • fastmcp

Available Tools

1 tool
debug_crashC

Debug crashing program and return the stack trace.

ParametersJSON Schema
NameRequiredDescriptionDefault
targetYes
argsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the tool returns a stack trace, which is useful, but fails to describe critical traits like whether it requires specific permissions, if it's read-only or destructive, how it handles errors, or any rate limits. For a tool that interacts with a program (potentially involving execution), this is a significant gap in transparency.

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 that directly states the tool's action and output without any fluff. It is front-loaded with the core purpose, making it efficient for quick understanding. Every word earns its place, adhering to best practices for brevity.

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 complexity (involving program debugging), lack of annotations, and 0% schema description coverage, the description is incomplete. It mentions the output (stack trace), and an output schema exists, which helps, but it misses critical context like behavioral traits and parameter meanings. This makes it minimally adequate but with clear gaps for effective agent use.

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

Parameters2/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 for the lack of parameter documentation. It does not explain what 'target' or 'args' represent (e.g., target could be a file path or process ID, args might be command-line arguments), their formats, or examples. This leaves the parameters largely ambiguous, reducing the tool's usability despite the schema defining their types.

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's purpose with a specific verb ('debug') and resource ('crashing program'), and specifies the output ('return the stack trace'). It distinguishes the action from generic debugging by focusing on crash analysis. However, without sibling tools, differentiation isn't tested, preventing a perfect 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?

The description provides no guidance on when to use this tool versus alternatives, prerequisites, or constraints. It states what the tool does but offers no context for its application, such as when debugging is appropriate or what types of crashes it handles. This lack of usage context limits its helpfulness for an agent.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3/5.0
Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap between tools, as there are no other tools to compare it to. The tool's purpose is clearly defined and distinct by default.

Naming Consistency5/5

Since there is only one tool, naming consistency is inherently perfect—there are no other tools to create inconsistency or mixed conventions. The tool name follows a clear verb_noun pattern.

Tool Count2/5

A single tool is too few for a server named 'HPC-MCP', which suggests a High-Performance Computing domain that typically involves complex workflows like job submission, monitoring, and resource management. This minimal toolset severely limits functionality.

Completeness1/5

The tool surface is severely incomplete for an HPC domain; it only provides a debug function, missing essential operations such as job submission, status checking, file management, and resource allocation, which are core to HPC workflows.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • jlab-mcp

    kdkyum
    F
    license
    A
    quality
    B
    maintenance
    An MCP server that enables LLMs to execute Python code on GPU-accelerated compute nodes within SLURM-managed HPC environments. It bridges local clients to remote clusters by launching JupyterLab sessions via SLURM jobs to facilitate high-performance notebook-based computation.
    7

  • VSCode Debug MCP

    PeakBI
    F
    license
    Not graded
    quality
    A
    maintenance
    An MCP server and VS Code extension that enables AI clients to interactively debug code using breakpoints, execution control, and state inspection. It is language-agnostic and works with any debugger that supports VS Code's launch.json configurations.

  • gdb_mcp

    airfloats
    A
    license
    A
    quality
    D
    maintenance
    An MCP server that enables AI assistants to control GDB debugging sessions, including breakpoint management, thread analysis, and variable inspection, using the GDB/MI protocol.
    22
    1
    MIT

Latest Blog Posts

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/TomMelt/hpc-mcp'

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