Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Jungle Grid MCP Server Estimate the cost of a batch job using python:3.11-slim"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Jungle Grid MCP lets MCP-aware agents estimate, submit, monitor, cancel, and retrieve artifacts from Jungle Grid workloads. It supports local stdio clients and hosted Streamable HTTP deployments that forward tool calls to the Jungle Grid API.
Use it for asynchronous AI workload execution, batch processing, training, fine-tuning, uploaded file or script backed jobs, lifecycle diagnostics, workload logs, and managed output artifacts.
Requirements:
Node.js 18 or newer
A Jungle Grid API key for local stdio, or an OAuth bearer token for hosted HTTP
API scopes that match the tools you want to call
Run the local stdio server with npx:
JUNGLE_GRID_API_KEY=jg_placeholder npx -y @jungle-grid/mcpInstall globally if you prefer a stable executable:
npm install -g @jungle-grid/mcp
junglegrid-mcpRelated MCP server: agent-mesh MCP Server
Local stdio uses environment variables:
Variable | Required | Purpose |
| Yes for local stdio | Bearer token forwarded to the Jungle Grid API. |
| No | API base URL. Defaults to |
| No | Legacy API base URL alias, also accepted. |
Hosted HTTP gateway deployments also support:
Variable | Required | Purpose |
| No | Starts Streamable HTTP instead of stdio. |
| No | HTTP port. Defaults to |
| No | Service token used for OAuth introspection or fallback API calls. |
| No | OAuth issuer. Defaults to |
| No | Protected resource URL. Defaults to |
| No | OAuth protected-resource metadata URL. |
| No | Enables |
Never commit API keys, OAuth tokens, signed upload URLs, signed artifact URLs, or callback secrets.
Local clients launch the package and communicate over stdio.
{
"mcpServers": {
"junglegrid": {
"command": "npx",
"args": ["-y", "@jungle-grid/mcp"],
"env": {
"JUNGLE_GRID_API_KEY": "jg_placeholder"
}
}
}
}Add the same mcpServers block to claude_desktop_config.json, then fully quit and reopen Claude Desktop.
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.jsonFor project config, avoid checked-in secrets. Put the key in the environment used to launch Cursor:
{
"mcpServers": {
"junglegrid": {
"command": "npx",
"args": ["-y", "@jungle-grid/mcp"]
}
}
}For a local uncommitted Cursor config:
{
"mcpServers": {
"junglegrid": {
"command": "npx",
"args": ["-y", "@jungle-grid/mcp"],
"env": {
"JUNGLE_GRID_API_KEY": "jg_placeholder",
"JUNGLEGRID_API_BASE": "https://api.junglegrid.dev"
}
}
}
}The HTTP server exposes:
GET /healthz
GET /.well-known/oauth-protected-resource
POST /mcp
Start it locally:
MCP_TRANSPORT=http PORT=3000 JUNGLEGRID_INTERNAL_SERVICE_TOKEN=service_token_placeholder npm startHosted MCP clients must send Authorization: Bearer <oauth_access_token> to POST /mcp. The server introspects tokens at /oauth/introspect on the configured API base and requires tool-specific scopes.
Ask your MCP client to call the tools in this order:
{
"tool": "estimate_job",
"arguments": {
"workload_type": "batch",
"image": "python:3.11-slim",
"command": ["python", "-c", "print('hello from Jungle Grid')"],
"routing_mode": "balanced"
}
}If the estimate is acceptable, submit the job:
{
"tool": "submit_job",
"arguments": {
"name": "mcp-hello",
"workload_type": "batch",
"image": "python:3.11-slim",
"command": ["python", "-c", "print('hello from Jungle Grid')"],
"expected_artifacts": ["/workspace/artifacts/output.txt"]
}
}Use the returned job_id with get_job, get_job_events, get_job_logs, list_artifacts, and get_artifact.
The current tool registry exposes these exact tool names:
Tool | Purpose | Required parameters | Optional parameters |
| Estimate routing, capacity source, and expected cost without creating work. |
|
|
| Submit a workload. This may start compute and incur usage charges. |
|
|
| Create a signed upload slot for an input file or script. |
|
|
| List uploaded inputs and scripts for the authenticated account. | none | none |
| List recent jobs. | none |
|
| Read job status, phase, scheduling, billing, and artifact readiness. |
| none |
| Read lifecycle events for scheduling, provisioning, startup, failures, and cancellation. |
| none |
| Read persisted runtime and workload logs. |
|
|
| Request cancellation of a non-terminal job. |
|
|
| List managed output artifacts for a job. |
| none |
| Create temporary artifact download information. |
| none |
Accepted workload_type values are inference, training, fine_tuning, and batch. The MCP server forwards fine_tuning to the REST API as fine-tuning. Accepted routing_mode values are cost, speed, and balanced.
estimate_jobReturns classification, route status, capacity source, estimated cost range, availability, and screening details when returned by the API. An estimate is not a reservation and does not guarantee immediate startup.
Common errors: missing workload_type, invalid enum value, authentication failure, forbidden scope, invalid request, upstream API error.
{
"workload_type": "inference",
"model_size": 7,
"image": "pytorch/pytorch:2.4.0-cuda12.1-cudnn9-runtime",
"command": ["python", "infer.py"],
"routing_mode": "balanced",
"notes": "single model inference run"
}submit_jobCreates an asynchronous job. model_size is an optional size in GB used to select suitable GPU capacity and is forwarded as REST model_size_gb. command is preferably an array of strings. env must be an object with string values and is forwarded as REST environment. input_files and script_files accept arrays of { "input_id": "..." }; string IDs are normalized for compatibility. The current REST implementation supports one uploaded script reference.
Expected response includes job_id, status, queued_at or submitted_at, routing fields, input/script details, and artifact contract fields when returned by the API.
Common errors: missing name, image, or workload_type; invalid workload type; command or args too long; invalid environment values; missing or incomplete input IDs; insufficient funds; unavailable capacity; maintenance; authentication or scope failures.
{
"name": "transcribe-audio",
"workload_type": "inference",
"model_size": 7,
"image": "python:3.11-slim",
"command": ["python", "/workspace/scripts/transcribe.py", "/workspace/inputs/audio.ogg", "/workspace/artifacts/transcript.txt"],
"script_files": [{ "input_id": "inp_script123" }],
"input_files": [{ "input_id": "inp_audio123" }],
"expected_artifacts": ["/workspace/artifacts/transcript.txt"],
"routing_mode": "balanced",
"metadata": {
"request_id": "req_123"
}
}upload_job_inputCreates a signed upload slot. It does not upload file bytes by itself. Upload the bytes to upload.upload_url using upload.method, then complete the upload with upload.complete_url and the returned upload.token.
kind is an arbitrary string accepted by the API. Use input for normal input files and script for scripts by convention. Script uploads mount under /workspace/scripts/<filename>; input uploads mount under /workspace/inputs/<filename>.
Expected response:
{
"upload": {
"input_id": "inp_123",
"filename": "transcribe.py",
"method": "PUT",
"upload_url": "https://signed-upload.example",
"token": "upload_token",
"expires_at": "2026-06-11T12:15:00Z",
"complete_url": "https://api.junglegrid.dev/v1/job-inputs/inp_123/complete"
}
}Common errors: missing filename, invalid filename, file too large, upload storage unavailable, authentication or scope failure.
list_job_inputsReturns uploaded inputs with input_id, filename, content_type, size_bytes, kind, status, ready, mount_path, and timestamps when available.
list_jobsReturns jobs, limit, next_cursor, and has_more. limit is capped by the API. status is a free-form filter string passed to the API; do not assume the MCP schema restricts it to a fixed enum.
get_jobReturns the current job status and details. Status, execution phase, lifecycle events, runtime details, and workload logs are separate surfaces.
Important response fields include status, phase, execution_phase, status_message, status_reason, phase_started_at, phase_last_updated_at, wait_duration_seconds, delayed_start, delay_reason, scheduling, startup_diagnostics, provider, artifacts_ready, failure, input_files, script_file, and artifact_contract when present.
get_job_eventsReturns lifecycle events before and during execution. Events may exist before workload logs begin. Events include IDs, types, phases, titles, messages, source, level, timestamps, sequence, and a generated timestamp.
Use events to diagnose queueing, route selection, scheduling, provider provisioning, input preparation, startup, retries, failures, and cancellation.
get_job_logsReturns stored log entries with items, next_cursor, has_more, failure_highlight, and usage_hint when available. Entries include entry_id, source, category, stream, message, truncated, and created_at when returned by the API.
Logs can be empty while a job is queued, scheduling, provisioning, or preparing. Call get_job_events when logs are empty but the job is not terminal. This MCP tool fetches persisted logs; it does not provide true streaming.
cancel_jobRequests cancellation for a pending, queued, assigned, starting, or running job. Completed, failed, rejected, or already cancelled jobs return a conflict from the API.
Expected response includes job_id, status, and status_reason when returned by the API. Cancellation may trigger managed teardown, but do not assume immediate infrastructure shutdown.
list_artifactsReturns managed artifacts for a job. Artifacts include artifact_id, job_id, filename, content_type, size_bytes, status, ready, and timestamps when returned by the API. Failed jobs may have no artifacts or partial artifacts.
get_artifactCreates temporary download information for one artifact. The API returns artifact metadata, a signed URL, and expires_at. Treat the URL as a secret.
Common errors: artifact not found, artifact not ready, artifact storage unavailable, forbidden job, authentication failure.
Estimate:
{
"workload_type": "batch",
"image": "python:3.11-slim",
"command": ["python", "-c", "from pathlib import Path; Path('/workspace/artifacts/output.txt').write_text('done')"],
"routing_mode": "balanced"
}Submit:
{
"name": "simple-artifact-job",
"workload_type": "batch",
"image": "python:3.11-slim",
"command": ["python", "-c", "from pathlib import Path; Path('/workspace/artifacts/output.txt').write_text('done')"],
"expected_artifacts": ["/workspace/artifacts/output.txt"],
"routing_mode": "balanced"
}Monitor:
{ "job_id": "job_123" }Call get_job, get_job_events, and get_job_logs with the same job_id until the status is terminal.
Retrieve:
{ "job_id": "job_123" }Call list_artifacts, then:
{
"job_id": "job_123",
"artifact_id": "art_123"
}Create upload slots:
{
"filename": "transcribe.py",
"content_type": "text/x-python",
"kind": "script"
}{
"filename": "audio.ogg",
"content_type": "audio/ogg",
"kind": "input"
}Upload each file to the returned signed upload_url, then complete it:
curl -X PUT "$UPLOAD_URL" \
-H "Content-Type: text/x-python" \
--data-binary @transcribe.py
curl -X POST "$COMPLETE_URL" \
-H "Authorization: Bearer $JUNGLE_GRID_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"token": "upload_token",
"filename": "transcribe.py",
"content_type": "text/x-python",
"size_bytes": 1234,
"etag": "optional-etag"
}'Submit with input IDs:
{
"name": "file-backed-transcription",
"workload_type": "inference",
"image": "python:3.11-slim",
"command": ["python", "/workspace/scripts/transcribe.py", "/workspace/inputs/audio.ogg", "/workspace/artifacts/transcript.txt"],
"script_files": [{ "input_id": "inp_script123" }],
"input_files": [{ "input_id": "inp_audio123" }],
"expected_artifacts": ["/workspace/artifacts/transcript.txt"]
}Monitor with get_job_events, get_job, and get_job_logs.
Retrieve /workspace/artifacts/transcript.txt with list_artifacts and get_artifact.
REST MCP routes return an envelope:
{
"ok": false,
"error": {
"code": "INVALID_REQUEST",
"message": "name, image, and workload_type are required"
}
}The MCP server converts API errors into tool errors like:
submit_job failed: INVALID_REQUEST: name, image, and workload_type are requiredCommon API codes include UNAUTHORIZED, FORBIDDEN, INVALID_REQUEST, JOB_INPUT_NOT_FOUND, JOB_INPUT_NOT_READY, ARTIFACT_NOT_READY, NOT_FOUND, CONFLICT, INSUFFICIENT_FUNDS, MAINTENANCE_ACTIVE, and INTERNAL_ERROR.
Keep API keys and OAuth tokens out of prompts, source control, browser bundles, logs, and issue trackers.
Prefer host secret stores or local-only MCP config files for JUNGLE_GRID_API_KEY.
Treat signed upload and artifact URLs as temporary bearer secrets.
Do not print environment variables that contain tokens from workload code.
Review submit_job and cancel_job requests before allowing an agent to execute them, because they can spend credits or stop active work.
npm install
npm run build
npm testRun stdio from the built package:
JUNGLE_GRID_API_KEY=jg_placeholder node dist/index.jsRun HTTP locally:
MCP_TRANSPORT=http PORT=3000 JUNGLEGRID_INTERNAL_SERVICE_TOKEN=service_token_placeholder node dist/index.jsInspect with MCP Inspector:
JUNGLE_GRID_API_KEY=jg_placeholder npx @modelcontextprotocol/inspector node dist/index.jsPublic Jungle Grid documentation: https://junglegrid.dev/docs
MCP documentation page: https://junglegrid.dev/docs/mcp
MIT
Cancel an existing Jungle Grid job. This may stop active execution and prevent further outputs.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | ||
| reason | No |
| Name | Required | Description |
|---|---|---|
| data | Yes |
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.
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.
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.
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.
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.
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 routing, capacity source, and expected cost for a proposed Jungle Grid workload without submitting it.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | ||
| image | No | ||
| notes | No | ||
| command | No | ||
| template | No | ||
| model_size | No | Optional model size in GB. | |
| routing_mode | No | ||
| workload_type | Yes |
| Name | Required | Description |
|---|---|---|
| data | Yes |
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 established. The description adds meaningful behavioral context by explicitly stating that the workload is not submitted, which reinforces the non-mutating nature and clarifies that this is a dry-run style estimation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight sentence that leads with the action verb and immediately states the tool's scope and non-effect. Every word contributes meaning; there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has eight parameters, one required, and a very low schema description coverage; the description gives no guidance on what fields matter or how they interact. While an output schema exists, the description still leaves the agent under-equipped to construct a correct estimate request.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 13%, with seven of eight parameters undocumented. The description does not explain any parameter names, relationships, or how to construct a valid workload estimate, so it fails to compensate for the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Estimate') with precise objects: routing, capacity source, and expected cost. The phrase 'without submitting it' clearly distinguishes this from submit_job, so an agent can tell them apart without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for pre-submission planning ('for a proposed workload', 'without submitting it'), but it does not explicitly state when to choose this over alternatives such as submit_job or list_jobs. No exclusions are provided, and no sibling tool is named as the right choice when submission is actually desired.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve download information for a specific output artifact from a Jungle Grid job.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | ||
| artifactId | Yes |
| Name | Required | Description |
|---|---|---|
| data | Yes |
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.
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.
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.
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.
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.
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.
Retrieve current status, execution phase, stable phase-entry timing, latest provider/platform update timing, scheduling delay, routing, failure, and artifact contract details for a specific Jungle Grid job. phase_started_at is when the job first entered the current normalized phase; phase_last_updated_at is later provider/platform progress or heartbeat when present; delayed_start identifies a prolonged wait in the actual current phase. A supported estimate does not guarantee immediate or successful runtime startup.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes |
| Name | Required | Description |
|---|---|---|
| data | Yes |
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 covered. The description adds meaningful behavioral context beyond annotations: it explains the distinction between phase_started_at and phase_last_updated_at, defines delayed_start, and includes an important caveat that a supported estimate does not guarantee immediate or successful runtime startup. This helps the agent interpret results and set expectations without contradicting 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise relative to the amount of field-level explanation it provides. The main purpose is front-loaded in the first sentence, and the subsequent sentences define key timing/status fields and a caveat. There is little redundancy, though the first sentence is a long list that could be slightly more scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and the annotations cover the read-only safety profile, the description provides sufficient operational context for a status-retrieval tool. It explains the meaning of the returned timing/delay fields and cautions about estimate reliability. It does not mention how to obtain jobId or direct users to sibling tools for more granular detail, but those are relatively minor gaps for a simple lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single jobId with no description, and schema description coverage is 0%. The description only loosely ties jobId to 'a specific Jungle Grid job', without explaining its format, where to obtain it, or any constraints. Since schema coverage is low, the description was expected to compensate with parameter semantics, but it does not significantly go beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a precise verb ('Retrieve') and a specific resource ('a specific Jungle Grid job'), and enumerates the specific data categories returned (status, phase, timing, delay, routing, failure, artifact contract). This makes it clearly distinct from sibling tools like list_jobs, get_job_events, and get_artifact, even without explicitly naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving a single job's current status and related metadata, but it does not explicitly say when to choose it over siblings such as get_job_events, get_job_logs, or list_artifacts. There is no when-not-to-use guidance, though the purpose is clear enough that an agent could infer the primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve platform lifecycle events for a job, including scheduling and startup events that can appear before workload logs exist.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context by explaining that the events include scheduling/startup stages and can precede workload logs, which goes beyond what the annotations alone convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the verb and resource, then adds useful detail about lifecycle events and their timing. Every clause earns its place and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a low-complexity read-only tool with one self-explanatory parameter and an output schema present. The description covers the key use case and the behavioral nuance about events appearing before logs; nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explicitly explain jobId, but the single parameter's name is self-explanatory and the description ties it to the job context ('for a job'). This provides marginal semantic value beyond the raw schema, though a more explicit parameter explanation would be better.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') and resource ('platform lifecycle events for a job'), and it distinguishes itself from get_job_logs by noting scheduling/startup events may appear before workload logs exist. This makes the tool's unique purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when this tool is appropriate: when interested in platform-level lifecycle events, especially before workload logs are available. It does not explicitly name alternative tools or state when not to use it, but the context strongly implies the distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve paginated job logs. Entries include category so platform/runtime logs can be distinguished from workload_stdout/workload_stderr. If workload logs are empty while a job is queued/starting, call get_job_events for platform scheduling events.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | ||
| limit | No | ||
| cursor | No |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only/non-destructive annotations, the description discloses that entries include a category field, that pagination is supported, and that workload logs can be empty during queueing/starting phases. These operational details help the agent interpret results correctly without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The main purpose is front-loaded, the category detail earns its place, and the conditional routing is compact and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, alternative routing, and relevant edge-case behavior, and an output schema exists to document return fields. The only missing context is more explicit pagination parameter details, but this is a minor gap given the schema and overall transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 adds only the 'paginated' concept, which implies limit/cursor semantics, but does not explain cursor format, limit defaults, or jobId requirements. The parameter names are self-explanatory to some degree, but the description leaves the pagination contract vague.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource combination ('Retrieve paginated job logs') that immediately identifies the tool's purpose. It also distinguishes log categories and mentions get_job_events as a separate concern, making it easy for an agent to differentiate from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit conditional usage rule: if workload logs are empty while a job is queued/starting, call get_job_events instead. This directly tells the agent when to choose an alternative, which is ideal usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List output artifacts associated with a specific Jungle Grid job.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes |
| Name | Required | Description |
|---|---|---|
| data | Yes |
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.
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.
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.
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.
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.
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 uploaded job inputs for the authenticated account, including mount paths.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context by specifying the authenticated-account scope and that mount paths are included, which is useful 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It states the action, resource, scope, and key output detail efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, an output schema present, and annotations covering the read-only/destructive profile, the description is complete for correct tool selection and invocation. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100%, so there is nothing for the description to add. The baseline of 4 for a no-parameter tool is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('uploaded job inputs'), and clarifies scope ('for the authenticated account') plus the notable detail of including mount paths. This clearly distinguishes it from sibling tools like upload_job_input and list_jobs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear this is the tool for retrieving the authenticated account's uploaded job inputs, which is sufficient context for selection. It does not explicitly name alternatives or exclusion conditions, but the read-only list nature and sibling set make the intended usage obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the authenticated user's Jungle Grid jobs, optionally filtered by status. Use this to find recent jobs before checking status, logs, or artifacts.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| status | No |
| Name | Required | Description |
|---|---|---|
| data | Yes |
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.
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.
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.
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.
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.
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 a Jungle Grid workload for execution. This may start managed compute infrastructure and incur usage charges.
| Name | Required | Description | Default |
|---|---|---|---|
| env | No | ||
| args | No | ||
| name | Yes | ||
| image | Yes | ||
| command | No | ||
| metadata | No | ||
| template | No | ||
| model_size | No | Optional model size in GB used to select GPU capacity. | |
| input_files | No | Uploaded input references to mount under /workspace/inputs/<filename>. | |
| routing_mode | No | ||
| script_files | No | Uploaded script references to mount under /workspace/scripts/<filename>. | |
| workload_type | Yes | ||
| expected_artifacts | No | Expected output files under /workspace/artifacts. |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful side-effect context beyond the annotations: it may start managed compute infrastructure and incur usage charges. This is valuable for an agent deciding whether to proceed, especially since readOnlyHint is false and openWorldHint is true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The core action is front-loaded, and the cost/infrastructure warning lands immediately after, making the most important behavioral information prominent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 13-parameter submission tool with nested objects and no output schema details provided, the description is too thin. It omits workflow context such as how the submitted job can be tracked, whether it returns a job ID, and how it relates to upload_job_input or estimate_job.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description contains no parameter-level guidance, and schema description coverage is only 31%, so the description must compensate for undocumented parameters but does not. Required fields like name, workload_type, and image are not mentioned, nor are routing_mode, env, command, or metadata semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Submit') and resource ('Jungle Grid workload for execution'), clearly conveying that this tool creates and launches a workload. This distinguishes it from siblings like list_jobs, get_job, cancel_job, and estimate_job without requiring schema inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not say when to use this tool versus alternatives such as estimate_job or upload_job_input. It implies readiness to execute, but provides no explicit guidance about prerequisites, ordering, or when another sibling should be used instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a managed upload slot for an input file or script. Upload bytes to upload_url with HTTP PUT, complete the upload through complete_url, then pass input_id to submit_job.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | ||
| filename | Yes | ||
| content_type | No |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It reveals a non-obvious interaction pattern: the tool itself does not receive the bytes; it returns an external upload_url, expects an HTTP PUT, and requires a final complete call. This goes well beyond annotations (openWorldHint) and is crucial for invoking the tool correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences deliver the purpose, the protocol, and the link to submit_job without extra words. The workflow is front-loaded before the downstream step.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It includes the essential multi-step flow and there is an output schema to document return values. Remaining gaps, such as upload_url authentication, slot expiry, or what completing actually does, keep it short of perfect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needs to explain parameters. It only hints at kind via 'input file or script'; filename and content_type are left undefined. With three parameters and no schema-level descriptions, this is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The descripion uses a concrete verb and resource: 'Create a managed upload slot' rather than simply 'upload an input.' It also names the downstream submit_job and tells the agent the slot's output feeds it, which clearly distinguishes this from the sibling submit_job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete sequence: create slot, PUT bytes to upload_url, complete via complete_url, then pass input_id to submit_job. This provides clear usage context, though it does not explicitly state when not to use it or directly contrast with sibling tools beyond submit_job.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.20.2cancel_jobestimate_jobget_artifactget_jobget_job_eventsget_job_logslist_artifactslist_job_inputslist_jobssubmit_jobupload_job_inputEach tool targets a distinct resource and action: inputs, estimates, jobs, events, logs, and artifacts are clearly separated. get_job, get_job_events, and get_job_logs could overlap, but their descriptions draw clear boundaries around status, platform lifecycle events, and paginated logs respectively.
All tools follow a consistent verb_noun snake_case pattern, with list_* for collections and get_* for individual resources. Verbs are specific and predictable across upload, estimate, submit, list, get, and cancel.
At 11 tools, the surface is well-scoped for a job-submission and artifact-retrieval workflow. Each tool maps to a necessary step in the lifecycle without redundant or filler operations.
The tool set covers the full workflow: upload inputs, estimate cost, submit jobs, monitor status/events/logs, cancel jobs, and retrieve artifacts. Minor conveniences like deleting old inputs are absent, but no essential operation for the stated purpose appears to be missing.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Discover and call AI agents via MCP. Supports A2A agents and platform agents with async tasks.
Create, browse, remix, collaborate on, and run durable AI workflow nodes from MCP hosts.
Agent-native collaboration network: orchestrate a team of long-running agents from any MCP client.
Workflow diagnostics, capability routing, and x402 settlement for MCP-compatible agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jaguarkyng/Jungle-Grid--mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
