Which integrations are available for this server?

Integrates with Hermes Agent as a first-party primitive, providing local compute capabilities via the ae://glocal-agent surface.

How do I use gpu-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@gpu-mcp check GPU utilization" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

gpu-mcp

by MYaelMendez

Overview Schema Related Servers Score Discussions

Python

Local

gpu-mcp

Sovereign local compute over the Model Context Protocol.

gpu-mcp is a zero-dependency (stdlib-only), air-gappable MCP server that exposes your local NVIDIA GPU (CUDA) and Rust → WASM toolchain to any MCP client — Claude Desktop, Cursor, gemini-cli, or Hermes Agent — as protocol-native tools. Nothing leaves the machine: the brain is a local model socket, the hands are local processes.

Canonical scheme (Hermes): ae://glocal-agent (alias +ae://cc, home://).

Tools

tool	what it does
`probe_gpu`	Live `nvidia-smi` telemetry on the local machine
`compile_kernel`	Compile a CUDA matmul kernel with `nvcc` (via MSVC `vcvars64`)
`run_kernel`	Execute the compiled CUDA kernel on the local GPU, host-side timed
`rust_build_wasm`	Compile a Rust crate to `wasm32-unknown-unknown` (local)
`rust_run_wasm`	Run a `.wasm` via `wasmtime` if present; else report capability

Related MCP server: WEATHGARDS

Install

pip install gpu-mcp
# or, from source
git clone https://github.com/MYaelMendez/gpu-mcp && cd gpu-mcp
pip install -e .

Run the server

python -m gpu_mcp                 # stdio MCP server (register this with your client)
python -m gpu_mcp --self-test    # MCP handshake self-check (no GPU required)

Register with an MCP client

Point any MCP client at:

{
  "mcpServers": {
    "gpu-mcp": {
      "command": "python",
      "args": ["-m", "gpu_mcp"]
    }
  }
}

Works with Claude Desktop, Cursor, gemini-cli, and the Hermes Agent ae://glocal-agent surface.

Hermes Agent integration

gpu-mcp is a first-party primitive of the Hermes Agent sovereign stack. In hermes-fork, the VS Code extension bundles it and the conductor resolves ae://glocal-agent → mcp://gpu-mcp. This repo is the canonical, standalone, pip-installable source of truth.

Tests

pytest                              # MCP handshake + offline hands
python -m gpu_mcp --self-test     # quick in-process handshake check

GPU/wasm tool tests exercise real nvidia-smi, nvcc, and cargo when present; they fail loud (not silent) when the local toolchain is missing.

Why

Cloud agents can't give you your own GPU. gpu-mcp is the command-&-control surface for a bounded, offline local agent — your silicon, your weights, your rules. #opensourceware #hermiphicationisinevitable

MIT — © Yael Mendez · æ.store

Available Tools

5 tools

compile_kernelB

Compile a CUDA matmul kernel with nvcc (via MSVC vcvars).

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	kernel name	matmul

TDQS

B3.2/5.0

Behavior2/5

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

The description only states the action and toolchain but does not explain side effects (e.g., files created), required environment (e.g., CUDA toolkit installed), or possible errors. With no annotations, this is insufficient for an agent to understand behavioral impact.

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 with no unnecessary words, clearly stating the action and toolchain.

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

Completeness2/5

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

The description lacks context about outputs, prerequisites, and workflow with sibling tools. It is a bare minimum but not complete for a tool that is likely part of a build-and-run pipeline.

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 schema already describes the parameter name and default. The tool description does not add additional semantics beyond what is in the schema, so it meets baseline but does not improve.

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 specific verb 'compile' and resource 'CUDA matmul kernel', and explains the toolchain (nvcc via MSVC vcvars). It distinguishes from sibling tools like run_kernel and probe_gpu.

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 like run_kernel. No context on expected workflow (compile then run).

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

probe_gpuA

Read live NVIDIA GPU telemetry (nvidia-smi) on the local machine.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

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

No annotations exist, so description carries full burden. It correctly identifies the operation as read-only and live, but does not disclose potential failures (e.g., GPU absence, permission requirements).

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?

Single sentence, no redundancy, every word 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?

Sufficient for a zero-parameter, no-output-schema tool. Could improve by specifying what telemetry metrics are returned, but it is not incomplete.

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?

Zero parameters, baseline of 4. Description adds no additional parameter information, which is acceptable given no parameters.

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 the tool reads live NVIDIA GPU telemetry via nvidia-smi, distinguishing it from sibling tools that compile or run kernels/wasm.

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, nor any preconditions or exclusions.

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

run_kernelB

Run a previously compiled CUDA kernel on the local GPU.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	kernel name	matmul

TDQS

B3.4/5.0

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. It states the basic operation but lacks disclosure of important behavioral traits such as error handling, resource impact, or whether it is destructive.

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 concise and front-loaded with the action. Every word serves a purpose with no unnecessary information.

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

Completeness2/5

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

Given the tool is a simple execution operation, the description lacks details about output, error states, and prerequisites beyond 'previously compiled'. It is incomplete for practical use without additional context.

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 100% with a single parameter 'name' described as 'kernel name'. The description does not add extra meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

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 'Run' and clearly identifies the resource 'previously compiled CUDA kernel' with context 'on the local GPU'. It effectively distinguishes from siblings like compile_kernel.

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 the tool is for running kernels that have already been compiled, contrasting with compile_kernel. However, it does not explicitly state when to use or not use this tool, nor mention alternatives.

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

rust_build_wasmB

Compile a Rust crate to wasm32-unknown-unknown (local).

ParametersJSON Schema

Name	Required	Description	Default
`crate_dir`	Yes	path to cargo crate

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. Only states 'compile' and 'local', but does not disclose side effects, prerequisites (e.g., target installed), or output details.

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?

Single concise sentence with no filler. Appropriate length given simplicity.

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

Completeness2/5

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

Tool is simple but lacks output description. No mention of what is produced (e.g., .wasm file), which is needed since no output schema exists.

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 100% for the single parameter 'crate_dir'. Description adds no additional 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?

Clearly states verb 'Compile', resource 'Rust crate', target 'wasm32-unknown-unknown', and location 'local'. Distinguishes from siblings like rust_run_wasm and compile_kernel.

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?

Implied usage (build before run), but no explicit when-to-use or when-not-to-use compared to alternatives. No exclusion statements.

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

rust_run_wasmA

Run a .wasm via wasmtime if present; else report capability.

ParametersJSON Schema

Name	Required	Description	Default
`wasm_path`	Yes	path to .wasm

TDQS

A3.8/5.0

Behavior3/5

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

The description discloses a key behavioral trait: runs only if wasmtime is present, otherwise reports capability. However, no details on permissions, side effects, or what 'report capability' entails, and there are no annotations to supplement.

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?

Single sentence, no redundancy, essential information front-loaded. Every word earns its place.

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 tool with one parameter and no output schema, the description covers the main purpose and a key behavioral nuance. Could mention requirement for wasmtime, but overall adequate.

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?

With 100% schema coverage, the description adds no additional meaning beyond the schema's 'path to .wasm'. Baseline score of 3 is appropriate.

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 verb 'Run' and resource '.wasm via wasmtime', and distinguishes from sibling tools that compile or build. The conditional 'if present; else report capability' adds specificity.

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 over siblings like compile_kernel or run_kernel. The name implies it's for running WASM, but no alternatives or exclusions are mentioned.

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

A3.5/5.0

Disambiguation3/5

The GPU tools (compile_kernel, run_kernel, probe_gpu) are distinct from the Rust/WASM tools (rust_build_wasm, rust_run_wasm), but the mixing of two unrelated domains under the 'gpu-mcp' name creates confusion about which tool to use for a given task.

Naming Consistency4/5

All tools follow a verb_noun pattern (e.g., compile_kernel, probe_gpu), but the Rust tools include a 'rust_' prefix while the GPU tools do not, introducing a minor inconsistency.

Tool Count5/5

With only 5 tools, the number is well-suited for a focused MCP server. Each tool serves a specific purpose without unnecessary redundancy.

Completeness3/5

The GPU toolset covers compilation, execution, and monitoring, but lacks features like device management or memory operations. The Rust/WASM subset is minimal and feels like an afterthought, leaving both domains incomplete.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

mcp A
io.github.Massed-Compute
Massed Compute MCP — GPU inventory, VM lifecycle, billing, SSH keys, and setup recipes.
Cloud Platforms Virtualization
2
Reasoning Commons
io.github.chenyuan35
AI Reasoning Cache & Consensus Layer with 11 MCP tools via Streamable HTTP.
AI & Machine Learning Knowledge & Memory Autonomous Agents
2
TitanStore Commerce MCP A
io.github.Fish-Tacos
MCP commerce surface for compute credits, API keys, GPU instances, and cloud storage.
Cloud Platforms E-commerce & Retail
52
Workflow A
io.github.Jonnyton
Create, browse, remix, collaborate on, and run durable AI workflow nodes from MCP hosts.
Autonomous Agents App Automation Workplace & Productivity
21

Related MCP Servers

mcp-gpu-server
Monitoring Observability
mesutoezdil
A
license
A
quality
D
maintenance
Exposes NVIDIA GPU metrics (info, utilization, VRAM, temperature) via MCP tools for real-time querying from AI assistants.
Updated 4 months ago (2026-05-03 13:54 UTC)
5
MIT
WEATHGARDS
Virtualization OS Automation Monitoring
liambuild
F
license
Not graded
quality
D
maintenance
Exposes MCP tools that enable remote LLMs to query local Docker containers, OS processes, and system services in real time.
Updated 3 months ago (2026-06-04 21:45 UTC)
Local AI MCPofficial
AI & Machine Learning Developer Tools
TMHSDigital
A
license
A
quality
A
maintenance
Unified MCP server for managing local model runtimes (Ollama, LM Studio, etc.), enabling provider-agnostic discovery, lifecycle management, hardware-fit checks, and delegated inference.
Updated 12 days ago (2026-08-23 11:03 UTC)
16
763
Creative Commons Attribution Non Commercial No Derivatives 4.0 International
CodexPro Runtime
File Systems Command Line Developer Tools
Menglook
A
license
B
quality
B
maintenance
A local, evidence-driven MCP runtime and control plane for open-source maintainers that provides workspace-bounded tools including controlled file operations, command execution, validation primitives, durable execution records, and human review workflows via stdio and Streamable HTTP transports.
Updated a month ago (2026-08-03 18:34 UTC)
33
MIT

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/MYaelMendez/gpu-mcp'

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

gpu-mcp

Tools

Install

Run the server

Register with an MCP client

Hermes Agent integration

Tests

Why

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Local AI MCPofficial

Latest Blog Posts

MCP directory API