Jungle Grid MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | HTTP port (only used with MCP_TRANSPORT=http). | 3000 |
| MCP_RESOURCE | No | Protected resource URL. | https://mcp.junglegrid.dev |
| OAUTH_ISSUER | No | OAuth issuer. | https://api.junglegrid.dev |
| MCP_TRANSPORT | No | Transport mode. Set to 'http' to start Streamable HTTP instead of stdio. | stdio |
| JUNGLEGRID_API_BASE | No | API base URL. | https://api.junglegrid.dev |
| JUNGLE_GRID_API_KEY | No | Bearer token forwarded to the Jungle Grid API. Required for local stdio mode. | |
| JUNGLE_GRID_API_URL | No | Legacy API base URL alias, also accepted. | |
| MCP_RESOURCE_METADATA_URL | No | OAuth protected-resource metadata URL. | |
| OPENAI_APPS_CHALLENGE_TOKEN | No | Enables /.well-known/openai-apps-challenge when configured. | |
| JUNGLEGRID_INTERNAL_SERVICE_TOKEN | No | Service token used for OAuth introspection or fallback API calls. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| estimate_jobA | Estimate routing, capacity source, and expected cost for a proposed Jungle Grid workload without submitting it. |
| submit_jobB | Submit a Jungle Grid workload for execution. This may start managed compute infrastructure and incur usage charges. |
| upload_job_inputA | 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. |
| list_job_inputsA | List uploaded job inputs for the authenticated account, including mount paths. |
| list_jobsA | List the authenticated user's Jungle Grid jobs, optionally filtered by status. Use this to find recent jobs before checking status, logs, or artifacts. |
| get_jobA | 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. |
| get_job_eventsA | Retrieve platform lifecycle events for a job, including scheduling and startup events that can appear before workload logs exist. |
| get_job_logsA | 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. |
| cancel_jobA | Cancel an existing Jungle Grid job. This may stop active execution and prevent further outputs. |
| list_artifactsA | List output artifacts associated with a specific Jungle Grid job. |
| get_artifactA | Retrieve download information for a specific output artifact from a Jungle Grid job. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 11 tools
Each 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.