01Safety
0.0 / 30
What changed in the harness
Selection accuracy 100→98, token cost up 12%, unconfirmed writes 0%→0%.
Category breakdown
Where the score comes from.
Earned points across the four signals Gradable measures. Safety and Legibility are scored out of 30; Economics and Discoverability are scored out of 20.
02Legibility
25.7 / 30
03Economics
17.9 / 20
04Discoverability
12.6 / 20
Highest-impact fix
Estimated gain +30 pointsAdd explicit identity and permission preflight tools
Expose machine-readable principal/tenant confirmation and a non-mutating permission check so agents can verify both before destructive actions.
Description evidence
Defects and rewrites.
10 defects found across the exposed tool descriptions. Suggested rewrites make purpose, inputs, boundaries, and returns easier for an agent to understand.
| Tool | Defect types | Suggested rewrite |
|---|---|---|
estimate_job |
params_unexplained |
Estimate routing, capacity source, and expected cost for a proposed Jungle Grid workload without submitting it. workload_type picks the execution kind (inference, training, fine_tuning, or batch) that drives GPU and acceleration classification; image, command, and args define the container image and entrypoint to run; routing_mode (cost, speed, or balanced) biases accelerator selection; template optionally applies a reusable job configuration, and notes records free-form context. Returns per-workload classification (GPU requirement and confidence), selected accelerator and route, live and managed capacity availability, and an estimated cost range (estimated_cost_usd min/max) with a can_submit flag, without starting any compute or incurring charges. |
submit_job |
params_unexplained |
Submit a Jungle Grid workload for execution, which may start managed compute infrastructure and incur usage charges. name labels the job for later lookup; workload_type selects the execution kind (inference, training, fine_tuning, or batch); image is the container image to run; command and args define the entrypoint and its arguments; env sets environment variables for the workload; routing_mode (cost, speed, or balanced) biases accelerator selection; template applies a reusable job configuration; metadata attaches arbitrary key/value labels. Attach uploaded inputs via input_files (mounted under /workspace/inputs) and scripts via script_files (mounted under /workspace/scripts), and declare expected outputs under /workspace/artifacts. Returns the job_id with initial status and submitted_at plus an estimated cost range to monitor via get_job. |
upload_job_input |
params_unexplained |
Create a managed upload slot for a file that can later be attached to a job. filename is the name of the file to upload; content_type is its MIME type; kind determines whether it becomes an input (mounted under /workspace/inputs when submitted) or a script (mounted under /workspace/scripts). Returns upload metadata with an input_id, a short-lived upload_url to PUT the bytes to, and a complete_url to finalize the upload; after completing, pass the input_id to submit_job via input_files or script_files. |
list_jobs |
params_unexplained |
List the authenticated user's Jungle Grid jobs. limit caps the number of jobs returned per page (default 10); cursor resumes pagination from the next_cursor of a previous response; status optionally filters to jobs with a given status. Returns a jobs array with id, name, status, workload_type, and timestamps, plus pagination metadata (limit, next_cursor, has_more). Use this to find recent job_ids before checking status, logs, or artifacts. |
get_job |
params_unexplained |
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. jobId identifies the job as returned by submit_job or list_jobs. 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_events |
params_unexplained |
Retrieve platform lifecycle events for a specific Jungle Grid job, including scheduling and startup events that can appear before workload logs exist. jobId identifies the job as returned by submit_job or list_jobs. Returns an ordered list of event items with type, phase, title, message, source, level, and timestamps for that job. |
get_job_logs |
params_unexplained |
Retrieve paginated logs for a specific Jungle Grid job. jobId identifies the job as returned by submit_job or list_jobs; limit caps the number of log entries per page; cursor resumes pagination from the next_cursor of a previous response. 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 or starting, call get_job_events for platform scheduling events. |
cancel_job |
name_restates_behavior params_unexplained |
Cancel an existing queued or running Jungle Grid job, for example when it was submitted by mistake, is stuck, or its outputs are no longer needed. This may stop active execution, prevent further outputs, and stop further usage charges. jobId identifies the job to cancel as returned by submit_job or list_jobs; reason optionally records why it was cancelled. Returns the job_id, the post-cancellation status, a cancelled boolean, and a message. |
list_artifacts |
name_restates_behavior params_unexplained |
List the output artifacts produced by a specific Jungle Grid job so the caller can see which are ready to download before fetching them, typically after the job has run. jobId identifies the job as returned by submit_job or list_jobs. Returns an artifacts array with each artifact's name, artifact_id, status, ready flag, size_bytes, and mime_type; use get_artifact to obtain download details for a chosen artifact. |
get_artifact |
params_unexplained |
Retrieve download information for a specific output artifact from a Jungle Grid job. jobId identifies the job that produced the artifact, and artifactId identifies the artifact within it, both as returned by submit_job/list_jobs and list_artifacts. Returns the artifact's name, size_bytes, and mime_type, a ready flag, and a time-limited download_url with its expiration; use the download_url to fetch the artifact bytes. |
Selection evidence
Confusable tool pairs.
4 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.
| Tool A | Tool B | Confidence | Why they collide |
|---|---|---|---|
get_job |
get_job_events |
medium | Both take only jobId and 'retrieve' job-related detail; a task like 'check what's happening with job X' or 'show the job's startup timeline' could send an agent to either the status/phase endpoint or the lifecycle-events endpoint. |
get_job |
get_job_logs |
medium | Tasks like 'get details on job X' or 'see how my job is progressing' are ambiguous between the status/phase/timing tool and the runtime-log tool, since both are single-jobId retrievals with overlapping descriptions. |
get_job_events |
get_job_logs |
high | Both cover per-job activity and are cross-referenced in the descriptions (get_job_logs advises calling get_job_events while queued/starting); a task like 'find out what my job did' or 'debug why it stalled' doesn't cleanly map to one, inviting the wrong pick. |
get_job_logs |
get_artifact |
medium | A task like 'get my job's output' or 'retrieve my results' is genuinely ambiguous between workload console logs (stdout/stderr) and downloadable output artifact files, especially since get_job_logs also surfaces workload output. |
Compare the field