de en es ja ko ru zh

jungle-grid-mcp-server

Name: jungle-grid-mcp-server
Author: Jungle-Grid

Official

by Jungle-Grid

Overview Schema Related Servers Score Discussions(1)

TypeScript

Remote

Jungle Grid MCP-Server

Führen Sie Jungle Grid GPU-Workloads von MCP-fähigen KI-Hosts wie Claude Desktop, Cursor, Windsurf und dem MCP Inspector aus.

Der Server läuft lokal über stdio und leitet Tool-Aufrufe mit Ihrem API-Schlüssel an die Jungle Grid REST-API weiter.

Anforderungen

Node.js 18 oder neuer
Ein Jungle Grid API-Schlüssel
Optional: JUNGLE_GRID_API_URL für einen selbst gehosteten Orchestrator

Für den vollständigen Übermittlungs-Workflow benötigt der API-Schlüssel jobs:write. Dieser Bereich erlaubt das Schätzen, Übermitteln, Abfragen, Abbrechen und Abrufen von Protokollen für Jobs, die dem Konto des Schlüssels gehören. list_jobs erfordert weiterhin jobs:read.

Related MCP server: clausius

Schnellstart

JUNGLE_GRID_API_KEY=jg_... npx -y @jungle-grid/mcp

Unter Windows PowerShell:

$env:JUNGLE_GRID_API_KEY = "jg_..."
npx -y @jungle-grid/mcp

Der Server verwendet stdio, daher scheint ein erfolgreicher manueller Start auf MCP-Nachrichten zu warten. Wenn JUNGLE_GRID_API_KEY fehlt, wird er mit einer klaren Fehlermeldung beendet.

Claude Desktop

Fügen Sie dies zu claude_desktop_config.json hinzu und starten Sie Claude Desktop anschließend vollständig neu.

{
  "mcpServers": {
    "junglegrid": {
      "command": "npx",
      "args": ["-y", "@jungle-grid/mcp"],
      "env": {
        "JUNGLE_GRID_API_KEY": "jg_..."
      }
    }
  }
}

Windows-Konfigurationspfad:

%APPDATA%\Claude\claude_desktop_config.json

macOS-Konfigurationspfad:

~/Library/Application Support/Claude/claude_desktop_config.json

Cursor oder Projekt-MCP-Konfiguration

Für eine eingecheckte Projektkonfiguration sollten Sie das Committen von Geheimnissen vermeiden. Platzieren Sie den API-Schlüssel in der Umgebung, die zum Starten von Cursor verwendet wird, und halten Sie die Konfiguration frei von Geheimnissen.

{
  "mcpServers": {
    "junglegrid": {
      "command": "npx",
      "args": ["-y", "@jungle-grid/mcp"]
    }
  }
}

Für eine lokale, nicht committete Konfiguration können Sie den Schlüssel direkt einfügen:

{
  "mcpServers": {
    "junglegrid": {
      "command": "npx",
      "args": ["-y", "@jungle-grid/mcp"],
      "env": {
        "JUNGLE_GRID_API_KEY": "jg_..."
      }
    }
  }
}

Selbst gehosteter Orchestrator

JUNGLE_GRID_API_URL ist standardmäßig auf https://api.junglegrid.dev eingestellt. Überschreiben Sie dies, wenn Ihr Host einen anderen Orchestrator aufrufen soll.

{
  "mcpServers": {
    "junglegrid": {
      "command": "npx",
      "args": ["-y", "@jungle-grid/mcp"],
      "env": {
        "JUNGLE_GRID_API_KEY": "jg_...",
        "JUNGLE_GRID_API_URL": "https://your-orchestrator.example.com"
      }
    }
  }
}

Tools

estimate_job: Schätzung von GPU-Stufe, Region, Dauer und Kreditkosten.
submit_job: Übermittlung eines asynchronen GPU-Workloads mit optionalen environment-Werten.
get_job: Abrufen des aktuellen Job-Status und der Details.
list_jobs: Auflisten der letzten Jobs für das authentifizierte Konto.
cancel_job: Abbrechen eines ausstehenden, in der Warteschlange befindlichen oder laufenden Jobs.
get_job_logs: Abrufen von stdout, stderr und Exit-Informationen.
stream_job_logs: Live-Streaming von Protokollen bis zum Abschluss oder Timeout.
list_job_artifacts: Auflisten der verwalteten Artefakte, die für einen Job hochgeladen wurden.
get_artifact_download_url: Erstellen einer signierten Download-URL für ein verwaltetes Artefakt.

Echtzeit-Job-Muster

Verwenden Sie submit_job, um die Arbeit zu starten, stream_job_logs für die Live-Ausgabe und anschließend list_job_artifacts nach Abschluss, um gespeicherte Dateien abzurufen.

{
  "command": ["python", "-c", "import os; exec(os.environ['CODE'])"],
  "environment": {
    "CODE": "import os, json\nos.makedirs('/workspace/artifacts', exist_ok=True)\nwith open('/workspace/artifacts/output.json','w') as f:\n    json.dump({'status':'ok'}, f)"
  }
}

Dies ist das empfohlene Muster, wenn die eigentliche Python-Nutzlast zu lang ist, um bequem in das command-Array zu passen.

Für verwaltete Jobs erstellt Jungle Grid automatisch /workspace/artifacts und lädt alle dort geschriebenen regulären Dateien hoch. Benutzer müssen keine signierten Upload-URLs erstellen oder Endpunkte für den Artefakt-Abschluss manuell aufrufen.

Lokale Entwicklung

npm install
npm run build
JUNGLE_GRID_API_KEY=jg_... node dist/index.js

Untersuchen Sie den Server mit dem MCP Inspector:

JUNGLE_GRID_API_KEY=jg_... npx @modelcontextprotocol/inspector node dist/index.js

Veröffentlichung

Überprüfen Sie das Paket vor der Veröffentlichung:

npm run build
npm pack --dry-run

Veröffentlichen Sie das scoped Paket öffentlich:

npm publish --access public

Fehlerbehebung

JUNGLE_GRID_API_KEY environment variable is required: Fügen Sie den Schlüssel zum env-Block der Host-Konfiguration oder zu der Umgebung hinzu, die den Host startet.
Tools erscheinen nicht: Beenden Sie den MCP-Host vollständig und öffnen Sie ihn nach dem Bearbeiten der Konfiguration erneut.
Alte Paketversion: Fixieren Sie eine Version in der Konfiguration, zum Beispiel ["@jungle-grid/mcp@0.1.0"], oder leeren Sie den npx-Cache.
API-Aufrufe schlagen fehl: Bestätigen Sie, dass der Schlüssel gültig ist und JUNGLE_GRID_API_URL auf den Orchestrator zeigt, den Sie verwenden möchten.

Mitwirkende gesucht

Wir öffnen den Jungle Grid MCP-Server für Mitwirkende, die sich für KI-Agenten, MCP, Entwicklertools und Workload-Ausführung interessieren.

Gute erste Bereiche:

Dokumentation verbessern
Beispiel-Prompts hinzufügen
Tests für MCP-Tool-Handler hinzufügen
Docker-Unterstützung hinzufügen
GitHub Actions verbessern
Integrationsbeispiele erstellen

Beginnen Sie mit Issues, die als good first issue gekennzeichnet sind.

Available Tools

8 tools

cancel_jobB

Destructive

Cancel an existing Jungle Grid job. This may stop active execution and prevent further outputs.

ParametersJSON Schema

Name	Required	Description	Default
`jobId`	Yes
`reason`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes

TDQS

B3.2/5.0

Behavior3/5

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

The description confirms destructive behavior ('may stop active execution'), aligning with annotations (destructiveHint=true). However, it does not elaborate on side effects like loss of outputs or irreversibility beyond what annotations provide.

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, front-loaded with the verb 'Cancel'. No unnecessary words; every part serves the purpose.

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 2-parameter tool with an output schema, the description is minimal but adequate. Could mention success/error behavior or state requirements for the job to be cancelable.

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

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explain the parameters 'jobId' or 'reason'. The description adds no meaning beyond the schema's property names and 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 clearly states the action 'Cancel an existing Jungle Grid job' with a specific verb and resource. It distinguishes from siblings as the only cancel-related tool among list, get, submit, and estimate tools.

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 submitting a new job or estimating. The description lacks explicit context for when cancellation is appropriate.

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

estimate_jobA

Read-only

Estimate routing, capacity source, and expected cost for a proposed Jungle Grid workload without submitting it.

ParametersJSON Schema

Name	Required	Description
`workload`	Yes
`model_size`	No	Optional model size in GB.
`image`	No
`command`	No
`args`	No
`routing_mode`	No
`template`	No
`notes`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description need not reiterate safety. It adds value by specifying what the estimate covers (routing, capacity, cost). No contradictions with annotations. However, it omits details like rate limits or state effects, but these are less critical for a read-only estimate.

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, well-structured sentence with no filler. It front-loads the key action and resource, making it easy to process. Every word contributes to understanding.

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 8 parameters (1 required) and an output schema, the description covers the tool's purpose but lacks parameter guidance. The complexity is moderate, and while the output schema reduces the need to explain return values, the missing parameter semantics leave the description incomplete for correct invocation.

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 only 13% (only model_size described). The tool description does not elaborate on how parameters like workload, routing_mode, image, command, etc., affect the estimate. With low coverage, the description should compensate but fails to add meaningful parameter context, leaving parameters ambiguous.

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 action ('Estimate'), the resource ('Jungle Grid workload'), and the specific aspects estimated ('routing, capacity source, expected cost'). It also distinguishes itself from submission tools by noting 'without submitting it', making the purpose very specific.

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 when to use this tool (before submission) versus the sibling 'submit_job'. However, it does not explicitly exclude cases like checking existing jobs or provide alternative contexts. While clear for its primary use case, additional guidance on when not to use it would improve this dimension.

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

get_artifactB

Read-only

Retrieve download information for a specific output artifact from a Jungle Grid job.

ParametersJSON Schema

Name	Required	Description	Default
`jobId`	Yes
`artifactId`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, which align with the description's 'Retrieve' action. The description adds no further behavioral context (e.g., authentication, error handling). With annotations covering safety, a score of 3 is appropriate.

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 filler, immediately conveys the tool's core action. Perfectly concise for a simple retrieval tool.

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?

Output schema exists but is not visible; the description could clarify what 'download information' includes (URL, size, etc.). Given 2 required params and no nested objects, the description is minimally sufficient but leaves ambiguity about the return value.

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

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explain the 'jobId' or 'artifactId' parameters or their formats. It simply repeats the noun 'specific output artifact', adding no semantic value over the schema property names.

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 'Retrieve' and the resource 'download information for a specific output artifact from a Jungle Grid job'. It distinguishes from siblings like 'list_artifacts' (list artifacts) and 'get_job' (get job info).

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?

Description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, limitations, or comparisons to siblings like 'list_artifacts' or 'get_job_logs'.

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

get_jobA

Read-only

Retrieve current status and execution details for a specific Jungle Grid job belonging to the authenticated user.

ParametersJSON Schema

Name	Required	Description	Default
`jobId`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds 'belonging to the authenticated user' (auth constraint) and specifies 'status and execution details' as return content. No contradiction, but marginal additional value.

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?

One sentence with clear verb-object structure, no filler, directly conveys essential information.

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?

Output schema exists, so return values are documented externally. Description covers purpose and auth constraint. Annotations provide safety profile. Complete for a simple read operation.

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%, but the single parameter jobId is self-explanatory given its name and the tool's purpose. The description does not add extra detail about jobId format or constraints, but baseline 3 is appropriate for a simple, clear parameter.

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 specifies the verb 'Retrieve' and the resource 'specific Jungle Grid job', distinguishing it from siblings like list_jobs (list all) and cancel_job (cancel). It also adds scope 'belonging to the authenticated user'.

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 use for retrieving a specific job's status/details, but lacks explicit guidance on when to use vs alternatives (e.g., when to use get_job vs get_job_logs or list_jobs). No when-not-to-use conditions.

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

get_job_logsB

Read-only

Retrieve execution logs for a specific Jungle Grid job belonging to the authenticated user.

ParametersJSON Schema

Name	Required	Description	Default
`jobId`	Yes
`limit`	No
`cursor`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes

TDQS

B3/5.0

Behavior3/5

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

Annotations already mark this as read-only and non-destructive. The description adds the user-scoping constraint, which is valuable behavioral context. However, it does not disclose pagination behavior (despite the 'cursor' parameter), potential rate limits, or the fact that logs may be truncated. With annotations covering safety, 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?

A single, perfectly scoped sentence that conveys the core action and resource. No extraneous information. Ideal conciseness.

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 has three parameters (one required) and an output schema exists, the description should cover parameter semantics and usage context. It fails on parameter explanation and provides no usage guidelines. The output schema likely covers return structure, but the description's gaps make the tool incomplete for an agent.

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 explain parameters. Only 'jobId' is implicitly clear from the resource name. The optional parameters 'limit' and 'cursor' are not mentioned, leaving their semantics entirely unspecified. This is a significant gap that hampers correct invocation.

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 verb 'Retrieve' and the resource 'execution logs for a specific Jungle Grid job'. It adds a key constraint ('belonging to the authenticated user') that helps distinguish from potential admin-only tools. However, it does not explicitly differentiate from sibling tools like 'get_job' or 'get_artifact', 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?

No guidance is provided on when to use this tool versus alternatives such as 'list_jobs' or 'get_job'. There is no mention of prerequisites, context, or any exclusion criteria, leaving the agent to infer usage solely from the tool name and description.

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

list_artifactsA

Read-only

List output artifacts associated with a specific Jungle Grid job.

ParametersJSON Schema

Name	Required	Description	Default
`jobId`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds that the tool lists 'output artifacts', which provides minor context beyond annotations. No additional behavioral traits (e.g., pagination, errors) are disclosed.

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, direct sentence of 10 words. It is front-loaded and contains no fluff, making it highly concise and structured.

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 straightforward listing tool with one parameter and an output schema, the description adequately covers the basic purpose. It could be more complete by mentioning that it returns all artifacts for the job (no pagination implied). Still, it is sufficient given the tool's simplicity.

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%, so the description must compensate. It explains that the jobId parameter refers to a 'specific Jungle Grid job', but does not elaborate on format or source. For a single required parameter, this is marginal compensation.

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', the resource 'output artifacts', and the scope 'associated with a specific Jungle Grid job'. It distinguishes from siblings like get_artifact (single artifact) and list_jobs (list of jobs).

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 you need to list artifacts for a given job, but does not explicitly state when to or not to use this tool versus alternatives such as get_artifact for a single artifact. No exclusions or alternative tools are mentioned.

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

list_jobsA

Read-only

List the authenticated user's Jungle Grid jobs, optionally filtered by status. Use this to find recent jobs before checking status, logs, or artifacts.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`cursor`	No
`status`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds context about authentication and filtering, no contradictions.

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 action, no excess.

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?

Covers purpose and usage context, but lacks details on pagination parameters and response structure despite output schema existence.

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?

Only 'status' parameter is mentioned; 'limit' and 'cursor' (pagination) are not explained despite 0% schema coverage.

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 'list', resource 'Jobs for authenticated user', and optional filter by status. Differentiates from siblings like get_job and list_artifacts with usage tip.

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 before status/log/artifact checks, but no explicit 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.

submit_jobA

Submit a Jungle Grid workload for execution. This may start managed compute infrastructure and incur usage charges.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`workload`	Yes
`image`	Yes
`command`	No
`args`	No
`env`	No
`routing_mode`	No
`template`	No
`metadata`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already indicate non-read-only and non-destructive. The description adds important behavioral context: starting infrastructure and incurring charges, which goes beyond the annotations.

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 focused sentences with no redundancy. Every word adds value.

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?

Despite having an output schema and 9 parameters, the description provides minimal context. It lacks parameter guidance, error handling, or return value details, making it insufficient for a complex submission tool.

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

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage for 9 parameters. The description does not explain any parameter's meaning or usage, leaving the agent to infer from names alone.

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 explicitly states the action ('Submit') and the resource ('Jungle Grid workload for execution'), clearly distinguishing it from siblings like cancel_job or get_job.

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 hints at when to use (for submission) and warns about potential charges and infrastructure startup, but does not explicitly compare to alternatives or state when not to use.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

11 tool updatesv0.1.9Jun 3, 2026

Changedcancel_job5 fields changed

addedInput schema / properties / jobId
```
Added value: +{
+  "type": "string"
+}
```

removedInput schema / properties / job_id

Removed value: -{
-  "description": "The ID of the job to cancel.",
-  "type": "string"
-}

removedInput schema / properties / reason / description
```
Removed value: -"Optional cancellation reason."
```

changedInput schema / required

Previous value: -[
-  "job_id"
-]New value: +[
+  "jobId"
+]

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "data": {
+      "additionalProperties": true,
+      "properties": {
+        "cancelled": {
+          "type": "boolean"
+        },
+        "id": {
+          "type": "string"
+        },
+        "job_id": {
+          "type": "string"
+        },
+        "message": {
+          "type": "string"
+        },
+        "status": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    }
+  },
+  "required": [
+    "data"
+  ],
+  "type": "object"
+}

Changedestimate_job20 fields changed

addedInput schema / properties / args

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / command
```
Added value: +{
+  "type": "string"
+}
```

removedInput schema / properties / cost_priority

Removed value: -{
-  "enum": [
-    "low",
-    "balanced",
-    "high"
-  ],
-  "type": "string"
-}

removedInput schema / properties / disk_gb

Removed value: -{
-  "description": "Optional managed-provider local disk override in GB. Leave unset to let Jungle Grid auto-size from model_size_gb.",
-  "type": "number"
-}

removedInput schema / properties / gpu_class

Removed value: -{
-  "enum": [
-    "consumer",
-    "datacenter"
-  ],
-  "type": "string"
-}

removedInput schema / properties / gpu_type

Removed value: -{
-  "enum": [
-    "A100",
-    "A10G",
-    "H100",
-    "L4",
-    "RTX3090",
-    "RTX4090",
-    "RTX5090",
-    "T4"
-  ],
-  "type": "string"
-}

removedInput schema / properties / image / description
```
Removed value: -"Docker image to run."
```

removedInput schema / properties / latency_priority

Removed value: -{
-  "enum": [
-    "low",
-    "balanced",
-    "high"
-  ],
-  "type": "string"
-}

addedInput schema / properties / model_size

Added value: +{
+  "description": "Optional model size in GB.",
+  "type": "number"
+}

removedInput schema / properties / model_size_gb

Removed value: -{
-  "description": "Approximate model size in GB — drives tier selection.",
-  "type": "number"
-}

addedInput schema / properties / notes
```
Added value: +{
+  "type": "string"
+}
```

removedInput schema / properties / optimize_for

Removed value: -{
-  "enum": [
-    "balanced",
-    "cost",
-    "speed"
-  ],
-  "type": "string"
-}

removedInput schema / properties / region_mode

Removed value: -{
-  "enum": [
-    "prefer",
-    "strict"
-  ],
-  "type": "string"
-}

removedInput schema / properties / region_preference
```
Removed value: -{
-  "type": "string"
-}
```

addedInput schema / properties / routing_mode

Added value: +{
+  "enum": [
+    "cost",
+    "speed",
+    "balanced"
+  ],
+  "type": "string"
+}

addedInput schema / properties / template
```
Added value: +{
+  "type": "string"
+}
```

addedInput schema / properties / workload

Added value: +{
+  "enum": [
+    "inference",
+    "training",
+    "fine_tuning",
+    "batch"
+  ],
+  "type": "string"
+}

removedInput schema / properties / workload_type

Removed value: -{
-  "enum": [
-    "inference",
-    "training",
-    "fine-tuning",
-    "batch"
-  ],
-  "type": "string"
-}

changedInput schema / required

Previous value: -[
-  "workload_type",
-  "image"
-]New value: +[
+  "workload"
+]

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "data": {
+      "additionalProperties": true,
+      "properties": {
+        "available": {
+          "type": "boolean"
+        },
+        "can_submit": {
+          "type": "boolean"
+        },
+        "capacity": {
+          "additionalProperties": true,
+          "properties": {
+            "estimate_source": {
+              "type": "string"
+            },
+            "live_candidate_count": {
+              "type": "number"
+            },
+            "live_capacity_available": {
+              "type": "boolean"
+            },
+            "managed_capacity_available": {
+              "anyOf": [
+                {
+                  "type": "boolean"
+                },
+                {
+                  "type": "null"
+                }
+              ]
+            },
+            "managed_profile_count": {
+              "type": "number"
+            }
+          },
+          "type": "object"
+        },
+        "classification": {
+          "additionalProperties": true,
+          "properties": {
+            "acceleration_requirement": {
+              "type": "string"
+            },
+            "confidence": {
+              "type": "string"
+            },
+            "reasons": {
+              "items": {
+                "type": "string"
+              },
+              "type": "array"
+            },
+            "requires_gpu": {
+              "type": "boolean"
+            },
+            "workload_type": {
+              "type": "string"
+            }
+          },
+          "type": "object"
+        },
+        "estimated_cost_max_usd": {
+          "type": "number"
+        },
+        "estimated_cost_min_usd": {
+          "type": "number"
+        },
+        "estimated_cost_usd": {
+          "additionalProperties": true,
+          "properties": {
+            "max": {
+              "type": "number"
+            },
+            "min": {
+              "type": "number"
+            }
+          },
+          "required": [
+            "min",
+            "max"
+          ],
+          "type": "object"
+        },
+        "likely_gpu_type": {
+          "type": "string"
+        },
+        "routed_gpu_tier": {
+          "type": "string"
+        },
+        "routing": {
+          "additionalProperties": true,
+          "properties": {
+            "route_status": {
+              "type": "string"
+            },
+            "selected_accelerator": {
+              "type": "string"
+            },
+            "selected_route_source": {
+              "type": "string"
+            },
+            "selection_reason": {
+              "type": "string"
+            }
+          },
+          "type": "object"
+        },
+        "screening": {}
+      },
+      "type": "object"
+    }
+  },
+  "required": [
+    "data"
+  ],
+  "type": "object"
+}

Addedget_artifact
Removedget_artifact_download_url

Changedget_job4 fields changed

addedInput schema / properties / jobId
```
Added value: +{
+  "type": "string"
+}
```

removedInput schema / properties / job_id

Removed value: -{
-  "description": "The job ID returned by submit_job.",
-  "type": "string"
-}

changedInput schema / required

Previous value: -[
-  "job_id"
-]New value: +[
+  "jobId"
+]

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "data": {
+      "additionalProperties": true,
+      "properties": {
+        "account_billing": {
+          "additionalProperties": true,
+          "properties": {
+            "lifetime_total_spent_usd": {
+              "type": "number"
+            }
+          },
+          "type": "object"
+        },
+        "actual_cost_usd": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "artifacts_ready": {
+          "type": "boolean"
+        },
+        "estimated_cost_usd": {
+          "additionalProperties": true,
+          "properties": {
+            "max": {
+              "type": "number"
+            },
+            "min": {
+              "type": "number"
+            }
+          },
+          "required": [
+            "min",
+            "max"
+          ],
+          "type": "object"
+        },
+        "id": {
+          "type": "string"
+        },
+        "job_id": {
+          "type": "string"
+        },
+        "last_status_update": {
+          "type": "string"
+        },
+        "phase": {
+          "type": "string"
+        },
+        "status": {
+          "type": "string"
+        },
+        "status_message": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    }
+  },
+  "required": [
+    "data"
+  ],
+  "type": "object"
+}

Changedget_job_logs6 fields changed

addedInput schema / properties / cursor
```
Added value: +{
+  "type": "string"
+}
```
addedInput schema / properties / jobId
```
Added value: +{
+  "type": "string"
+}
```

removedInput schema / properties / job_id

Removed value: -{
-  "description": "The job ID to fetch logs for.",
-  "type": "string"
-}

addedInput schema / properties / limit
```
Added value: +{
+  "type": "number"
+}
```

changedInput schema / required

Previous value: -[
-  "job_id"
-]New value: +[
+  "jobId"
+]

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "data": {
+      "additionalProperties": true,
+      "properties": {
+        "items": {
+          "items": {
+            "additionalProperties": true,
+            "properties": {
+              "level": {
+                "type": "string"
+              },
+              "message": {
+                "type": "string"
+              },
+              "timestamp": {
+                "type": "string"
+              }
+            },
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "job_id": {
+          "type": "string"
+        },
+        "logs": {
+          "items": {
+            "additionalProperties": true,
+            "properties": {
+              "level": {
+                "type": "string"
+              },
+              "message": {
+                "type": "string"
+              },
+              "timestamp": {
+                "type": "string"
+              }
+            },
+            "required": [
+              "message"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "next_cursor": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        }
+      },
+      "type": "object"
+    }
+  },
+  "required": [
+    "data"
+  ],
+  "type": "object"
+}

Addedlist_artifacts
Removedlist_job_artifacts

Changedlist_jobs6 fields changed

addedInput schema / properties / cursor
```
Added value: +{
+  "type": "string"
+}
```
addedInput schema / properties / limit / default
```
Added value: +10
```

removedInput schema / properties / limit / description

Removed value: -"Maximum number of jobs to return (default 20, max 100)."

removedInput schema / properties / status / description
```
Removed value: -"Filter by job status."
```

removedInput schema / properties / status / enum

Removed value: -[
-  "pending",
-  "queued",
-  "running",
-  "completed",
-  "failed",
-  "cancelled"
-]

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "data": {
+      "additionalProperties": true,
+      "properties": {
+        "has_more": {
+          "type": "boolean"
+        },
+        "jobs": {
+          "items": {
+            "additionalProperties": true,
+            "properties": {
+              "created_at": {
+                "type": "string"
+              },
+              "id": {
+                "type": "string"
+              },
+              "job_id": {
+                "type": "string"
+              },
+              "name": {
+                "type": "string"
+              },
+              "status": {
+                "type": "string"
+              },
+              "updated_at": {
+                "type": "string"
+              },
+              "workload_type": {
+                "type": "string"
+              }
+            },
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "limit": {
+          "type": "number"
+        },
+        "next_cursor": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        }
+      },
+      "type": "object"
+    }
+  },
+  "required": [
+    "data"
+  ],
+  "type": "object"
+}

Removedstream_job_logs

Changedsubmit_job26 fields changed

addedInput schema / properties / args

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

removedInput schema / properties / command / description

Removed value: -"Container entrypoint arguments (e.g. ['python', 'train.py', '--epochs', '10'])."

removedInput schema / properties / command / items
```
Removed value: -{
-  "type": "string"
-}
```
changedInput schema / properties / command / type
```
Previous value: -"array"New value: +"string"
```

removedInput schema / properties / cost_priority

Removed value: -{
-  "description": "Cost sensitivity.",
-  "enum": [
-    "low",
-    "balanced",
-    "high"
-  ],
-  "type": "string"
-}

removedInput schema / properties / disk_gb

Removed value: -{
-  "description": "Optional managed-provider local disk override in GB. Leave unset to let Jungle Grid auto-size from model_size_gb.",
-  "type": "number"
-}

addedInput schema / properties / env

Added value: +{
+  "additionalProperties": {
+    "type": "string"
+  },
+  "type": "object"
+}

removedInput schema / properties / environment

Removed value: -{
-  "additionalProperties": {
-    "type": "string"
-  },
-  "description": "Environment variables injected into the container. Use this for large inline scripts such as CODE when you want to keep the command array short.",
-  "type": "object"
-}

removedInput schema / properties / gpu_class

Removed value: -{
-  "description": "Optional soft GPU class preference.",
-  "enum": [
-    "consumer",
-    "datacenter"
-  ],
-  "type": "string"
-}

removedInput schema / properties / gpu_type

Removed value: -{
-  "description": "Optional exact GPU override.",
-  "enum": [
-    "A100",
-    "A10G",
-    "H100",
-    "L4",
-    "RTX3090",
-    "RTX4090",
-    "RTX5090",
-    "T4"
-  ],
-  "type": "string"
-}

removedInput schema / properties / huggingface_credential_id

Removed value: -{
-  "description": "Optional saved Hugging Face credential to inject into the managed runtime. Falls back to your account default when omitted.",
-  "type": "string"
-}

removedInput schema / properties / image / description

Removed value: -"Docker image to run (e.g. 'pytorch/pytorch:2.2.0-cuda12.1-cudnn8-runtime')."

removedInput schema / properties / latency_priority

Removed value: -{
-  "description": "Latency sensitivity. Use 'high' for real-time inference.",
-  "enum": [
-    "low",
-    "balanced",
-    "high"
-  ],
-  "type": "string"
-}

addedInput schema / properties / metadata
```
Added value: +{
+  "type": "object"
+}
```

removedInput schema / properties / model_size_gb

Removed value: -{
-  "description": "Approximate model size in GB. Used to select the right GPU tier for inference jobs.",
-  "type": "number"
-}

removedInput schema / properties / name / description

Removed value: -"Optional readable job name. A name is generated if omitted."

removedInput schema / properties / optimize_for

Removed value: -{
-  "description": "Scheduling optimization goal. 'speed' prioritises latency; 'cost' minimises spend.",
-  "enum": [
-    "balanced",
-    "cost",
-    "speed"
-  ],
-  "type": "string"
-}

removedInput schema / properties / region_mode

Removed value: -{
-  "description": "Region preference mode.",
-  "enum": [
-    "prefer",
-    "strict"
-  ],
-  "type": "string"
-}

removedInput schema / properties / region_preference

Removed value: -{
-  "description": "Optional preferred region such as us-east or eu-west.",
-  "type": "string"
-}

addedInput schema / properties / routing_mode

Added value: +{
+  "enum": [
+    "cost",
+    "speed",
+    "balanced"
+  ],
+  "type": "string"
+}

addedInput schema / properties / template
```
Added value: +{
+  "type": "string"
+}
```

removedInput schema / properties / webhook_url

Removed value: -{
-  "description": "Optional HTTPS URL to receive signed lifecycle event callbacks.",
-  "type": "string"
-}

addedInput schema / properties / workload

Added value: +{
+  "enum": [
+    "inference",
+    "training",
+    "fine_tuning",
+    "batch"
+  ],
+  "type": "string"
+}

removedInput schema / properties / workload_type

Removed value: -{
-  "description": "Type of GPU workload.",
-  "enum": [
-    "inference",
-    "training",
-    "fine-tuning",
-    "batch"
-  ],
-  "type": "string"
-}

changedInput schema / required

Previous value: -[
-  "workload_type",
-  "image",
-  "command"
-]New value: +[
+  "name",
+  "workload",
+  "image"
+]

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "data": {
+      "additionalProperties": true,
+      "properties": {
+        "estimated_cost_usd": {
+          "additionalProperties": true,
+          "properties": {
+            "max": {
+              "type": "number"
+            },
+            "min": {
+              "type": "number"
+            }
+          },
+          "required": [
+            "min",
+            "max"
+          ],
+          "type": "object"
+        },
+        "id": {
+          "type": "string"
+        },
+        "job_id": {
+          "type": "string"
+        },
+        "status": {
+          "type": "string"
+        },
+        "status_message": {
+          "type": "string"
+        },
+        "submitted_at": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    }
+  },
+  "required": [
+    "data"
+  ],
+  "type": "object"
+}

9 tool updatesv0.1.0May 10, 2026
- First observedcancel_job
- First observedestimate_job
- First observedget_artifact_download_url
- First observedget_job
- First observedget_job_logs
- First observedlist_job_artifacts
- First observedlist_jobs
- First observedstream_job_logs
- First observedsubmit_job

Install Server

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

TDQS

A3.8/5.0

Disambiguation5/5

Each tool targets a distinct operation (submit, cancel, estimate, get status, get logs, list, get artifact, list artifacts) with no overlap. The separation between job management and artifact management is clear.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case (e.g., cancel_job, get_artifact, list_jobs). The naming is predictable and easy to understand.

Tool Count5/5

With 8 tools, the server provides a focused but complete set for managing Jungle Grid jobs. Each tool serves a necessary function without bloat or undersupply.

Completeness4/5

Covers the core job lifecycle (submit, get, list, cancel, estimate, logs, artifacts). Missing an update/retry tool for modifying job parameters, but the core workflow is well-supported.

Maintenance

ActivityMaintained

ResponsivenessUnresponsive

Resources

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

Hive Compute A
io.github.srotzin
HiveCompute MCP Server — decentralized inference router for AI agents
Agent Orchestration AI & Machine Learning
2
anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
mcp A
com.everstake
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
Blockchain Cryptocurrency
1111
Tigris MCP ServerOAuth
dev.storage
Tigris MCP Server seamlessly connects AI agents to Tigris bucket and object management.
Cloud Storage Cloud Platforms File Systems
2

Related MCP Servers

Modal MCP Server
Cloud Platforms Agent Orchestration Code Execution
smehmood
A
license
A
quality
D
maintenance
An MCP server that enables AI agents to interact with Modal, allowing them to deploy apps and run functions in a serverless cloud environment.
Updated a year ago (2025-03-25 22:53 UTC)
7
3
MIT
clausius
Monitoring Observability Command Line
tamohannes
F
license
Not graded
quality
A
maintenance
An MCP server for monitoring and managing multi-cluster Slurm GPU jobs, enabling AI agents to execute commands, check allocations, and explore logs across HPC clusters.
Updated a month ago (2026-07-30 00:35 UTC)
1
-
spiderswitch
AI & Machine Learning Agent Orchestration
hiddenpath
A
license
Not graded
quality
B
maintenance
MCP server that enables agents to dynamically switch between multiple AI models (OpenAI, Anthropic, Google, etc.) with unified protocol-driven configuration and capability discovery.
Updated 2 months ago (2026-07-07 15:53 UTC)
Apache 2.0
lab-ops
AceIke
A
license
Not graded
quality
C
maintenance
MCP server that converts SSH operations on training servers into AI-callable tools for GPU monitoring, job submission, file transfer, and more.
Updated 2 months ago (2026-07-19 12:23 UTC)
1
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/Jungle-Grid/mcp-server'

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