Skip to main content
Glama
deenesjakoruzh
Jungle-Grid

jungle-grid-mcp-server

Official
by Jungle-Grid
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
TypeScript
Remote

Jungle Grid MCP Server

Запускайте рабочие нагрузки на GPU в Jungle Grid из ИИ-хостов с поддержкой MCP, таких как Claude Desktop, Cursor, Windsurf и MCP Inspector.

Сервер работает локально через stdio и перенаправляет вызовы инструментов в REST API Jungle Grid с использованием вашего API-ключа.

Требования

  • Node.js 18 или новее

  • API-ключ Jungle Grid

  • Опционально: JUNGLE_GRID_API_URL для самохостируемого оркестратора

Для полноценного рабочего процесса отправки заданий API-ключу требуются права jobs:write. Эта область действия позволяет оценивать, отправлять, опрашивать, отменять и получать логи для заданий, принадлежащих учетной записи ключа. Для list_jobs по-прежнему требуются права jobs:read.

Related MCP server: gpusmarket

Быстрый старт

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

В Windows PowerShell:

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

Сервер использует stdio, поэтому при успешном ручном запуске он будет ожидать сообщений MCP. Если JUNGLE_GRID_API_KEY отсутствует, он завершит работу с понятной ошибкой.

Claude Desktop

Добавьте это в claude_desktop_config.json, затем полностью перезапустите Claude Desktop.

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

Путь к конфигурации в Windows:

%APPDATA%\Claude\claude_desktop_config.json

Путь к конфигурации в macOS:

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

Конфигурация Cursor или Project MCP

Для конфигурации проекта, которая добавляется в репозиторий, избегайте фиксации секретов. Поместите API-ключ в среду, используемую для запуска Cursor, и храните конфигурацию без секретов.

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

Для локальной, нефиксируемой конфигурации вы можете включить ключ напрямую:

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

Самохостируемый оркестратор

JUNGLE_GRID_API_URL по умолчанию имеет значение https://api.junglegrid.dev. Переопределите его, если ваш хост должен обращаться к другому оркестратору.

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

Инструменты

  • estimate_job: оценка уровня GPU, региона, длительности и стоимости в кредитах.

  • submit_job: отправка асинхронной рабочей нагрузки на GPU с опциональными значениями environment.

  • get_job: получение текущего статуса и деталей задания.

  • list_jobs: список недавних заданий для аутентифицированной учетной записи.

  • cancel_job: отмена ожидающего, стоящего в очереди или выполняющегося задания.

  • get_job_logs: получение stdout, stderr и информации о завершении.

  • stream_job_logs: потоковая передача логов в реальном времени до завершения или истечения времени ожидания.

  • list_job_artifacts: список управляемых артефактов, загруженных для задания.

  • get_artifact_download_url: создание подписанного URL для скачивания одного управляемого артефакта.

Шаблон задания в реальном времени

Используйте submit_job для запуска работы, stream_job_logs для вывода в реальном времени, а затем list_job_artifacts после завершения для получения сохраненных файлов.

{
  "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)"
  }
}

Это рекомендуемый шаблон, когда реальная полезная нагрузка Python слишком велика, чтобы комфортно поместиться в массив command.

Для управляемых заданий Jungle Grid автоматически создает /workspace/artifacts и загружает любые обычные файлы, записанные туда. Пользователям не нужно создавать подписанные URL для загрузки или вручную вызывать конечные точки завершения артефактов.

Локальная разработка

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

Проверьте сервер с помощью MCP Inspector:

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

Публикация

Проверьте пакет перед публикацией:

npm run build
npm pack --dry-run

Опубликуйте пакет с областью действия публично:

npm publish --access public

Устранение неполадок

  • JUNGLE_GRID_API_KEY environment variable is required: добавьте ключ в блок env конфигурации хоста или в среду, которая запускает хост.

  • Инструменты не отображаются: полностью закройте и снова откройте хост MCP после редактирования конфигурации.

  • Старая версия пакета: зафиксируйте версию в конфигурации, например ["@jungle-grid/mcp@0.1.0"], или очистите кэш npx.

  • Ошибки вызовов API: убедитесь, что ключ действителен, а JUNGLE_GRID_API_URL указывает на оркестратор, который вы намереваетесь использовать.

Приглашаем участников

Мы открываем сервер Jungle Grid MCP для участников, интересующихся ИИ-агентами, MCP, инструментами разработчика и выполнением рабочих нагрузок.

Хорошие первые области:

  • Улучшение документации

  • Добавление примеров промптов

  • Добавление тестов для обработчиков инструментов MCP

  • Добавление поддержки Docker

  • Улучшение GitHub Actions

  • Создание примеров интеграции

Начните с задач, помеченных good first issue.

Available Tools

8 tools
cancel_jobA
Destructive

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

ParametersJSON Schema
NameRequiredDescriptionDefault
jobIdYes
reasonNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
dataYes

TDQS

A4/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false; the description goes further by stating the concrete behavioral effects: stopping active execution and preventing further outputs. This adds context not captured by the annotations and is consistent with them.

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, the action is front-loaded, and every word adds meaning. No unnecessary detail or redundancy.

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 two-parameter mutation with an output schema, the core purpose and behavior are covered. However, the meaning of the reason parameter is missing, and there is no guidance on edge cases like cancelling an already-completed job. This leaves a moderate gap for an AI 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?

The schema has 0% description coverage, and the description does not explain either parameter. jobId is only implied by 'existing job,' and the optional reason parameter is entirely unexplained. Agents must infer parameter meaning without support.

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 and resource: 'Cancel an existing Jungle Grid job,' which clearly distinguishes it from sibling tools like submit_job, get_job, and list_jobs. It also adds the functional effect of stopping active execution and preventing further outputs, leaving no ambiguity about the tool's purpose.

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 clear usage context: it applies to an existing job and may affect active execution. It does not explicitly name alternatives or when-not conditions, but no sibling tool offers cancellation, so the context is sufficient for an agent to select this tool.

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
NameRequiredDescriptionDefault
workloadYes
model_sizeNoOptional model size in GB.
imageNo
commandNo
argsNo
routing_modeNo
templateNo
notesNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
dataYes

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_artifactA
Read-only

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

ParametersJSON Schema
NameRequiredDescriptionDefault
jobIdYes
artifactIdYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
dataYes

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is known. The description adds the distinction that this provides download information rather than artifact content, but it reveals little else about behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, direct sentence that front-loads the action and resource. There is no filler or redundant repetition of the tool name.

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 read-only getter with an output schema, the description adequately covers the core purpose. It falls short only in not explicitly guiding the agent toward when to prefer list_artifacts, but this is a minor gap given the tool's simplicity.

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 carries the burden of explaining parameters. It only loosely maps 'job' and 'specific artifact' to jobId and artifactId, but adds no format, constraints, or additional meaning for either 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 states a specific action ('Retrieve download information') and a specific resource ('a specific output artifact from a Jungle Grid job'). It clearly differs from siblings like list_artifacts and 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 implies when to use it: when download information for a particular artifact is needed. However, it does not explicitly contrast with alternatives such as list_artifacts or mention any exclusions.

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
NameRequiredDescriptionDefault
jobIdYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
dataYes

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
NameRequiredDescriptionDefault
jobIdYes
limitNo
cursorNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
dataYes

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
NameRequiredDescriptionDefault
jobIdYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
dataYes

TDQS

A4/5.0
Behavior3/5

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

The annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds job-scoped output artifact context, but does not disclose additional behavioral details such as pagination, ordering, or empty-result behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no filler. The core action and scope are front-loaded, making it easy for an agent to parse quickly.

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 read-only list tool with one parameter, an output schema, and safety annotations, the description is largely sufficient. It could be more complete by pointing to get_artifact for retrieving a single artifact, but that is optional rather than essential.

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 maps jobId to 'a specific Jungle Grid job,' which provides the core semantic, but it does not give format details, examples, or how to obtain the job ID.

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 and resource: 'List output artifacts associated with a specific Jungle Grid job.' This clearly identifies the operation and distinguishes it from sibling tools like list_job_inputs (inputs) and get_artifact (single artifact).

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 phrase 'associated with a specific Jungle Grid job' provides clear context for when to use the tool: when you need output artifacts for a known job. It does not explicitly name alternatives or exclusions, so it stops short of a 5.

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
NameRequiredDescriptionDefault
limitNo
cursorNo
statusNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
dataYes

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already declare the tool readOnly and non-destructive, so the safety profile is covered. The description adds useful scope information ('authenticated user's jobs') and implies recency ordering, but it does not go into pagination or response behavior. No contradiction with 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 short sentences, with the core action front-loaded and the usage guidance second. Every sentence earns its place and there is no filler or repetition of schema information.

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

Completeness4/5

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

The description conveys the tool's purpose, user scope, optional filtering, and its place in the job workflow. With an output schema available, return structure does not need to be spelled out. It only lacks explicit pagination semantics and accepted status values, which are conventional gaps rather than deal-breakers.

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 parameter meaning. It only addresses 'status' as a filter and leaves 'limit' and 'cursor' entirely unexplained, with no status value details. This is inadequate for a tool with three undocumented optional 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?

The description states a specific verb ('List'), a clearly bounded resource ('the authenticated user's Jungle Grid jobs'), and an optional filter ('by status'). It is readily distinguishable from sibling tools like get_job, which targets a single job, and list_artifacts/list_job_inputs, which target different resources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly guides when to use it: 'Use this to find recent jobs before checking status, logs, or artifacts.' This gives an agent a clear workflow trigger. It does not name alternatives or state when not to use it, but the contextual cue is strong enough.

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
NameRequiredDescriptionDefault
nameYes
workloadYes
imageYes
commandNo
argsNo
envNo
routing_modeNo
templateNo
metadataNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
dataYes

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.

  1. 11 tool updatesv0.1.9
    • 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"
+}
  2. 9 tool updatesv0.1.0
    • 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
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.8/5.0

Scored across 8 tools

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

ActivitySlowing
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers

  • clausius

    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.
    1
    -

  • gpusmarket

    jyswee
    A
    license
    Not graded
    quality
    B
    maintenance
    MCP server for renting real GPUs from the terminal. Enables browsing, renting, chatting, managing, and pooling GPU instances with per-second billing, designed for AI agents.
    250 npm
    1
    -

  • Jungle Grid MCP Server

    jaguarkyng
    A
    license
    A
    quality
    C
    maintenance
    Enables MCP-aware agents to estimate, submit, monitor, cancel, and retrieve artifacts from Jungle Grid workloads, supporting asynchronous AI execution, batch processing, training, fine-tuning, and access to logs and managed outputs.
    11
    11 npm
    MIT