ShapelessAI

Reply to a job

jobs_continue

Send another message to a job, optionally with files attached - also the way to resume a stuck or failed run with full history. Needs the write scope.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>",
      "text": "<text>"
    },
    "name": "jobs_continue"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	The job id.
`text`	Yes	The message, up to 4000 characters.
`model`	No	Brain for this run: claude-opus-5-5, claude-opus-5, claude-sonnet-5, claude-fable-5-1, gpt-5.6-sol or gpt-6-astra. Absent means the account's default. A model test runs the same goal once per model.
`panel`	No	Give the run the war-room panel and the identity graph tools; open the job's url to see the panel it lays out.
`autoRun`	No	Execute the plan the moment it is ready instead of pausing for approval. Deliverables still land as proposed drafts.
`budgetUsd`	No	Budget for this turn, in dollars.
`mediaKeys`	No	Media keys already in the account (from assets_upload or assets_list) to attach.

Output Schema

Name	Required	Description	Default
`id`	Yes
`status`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 10, 2026

addedInput schema / properties / panel

Added value: +{
+  "description": "Give the run the war-room panel and the identity graph tools; open the job's url to see the panel it lays out.",
+  "type": "boolean"
+}

Changed1 schema field changedOct 7, 2026

changedOutput schema / (root)

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

First observedSep 29, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so safety basics are covered. The description adds one genuinely useful non-schema fact, the required write scope, plus confirmation that resumption preserves full history; however it says nothing about cost implications, latency, or what the deliverable/approval semantics mean at a high level beyond what the parameter docs state. I'll score it 3 — the write scope is a real addition, but the rest is largely restatement.

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

Conciseness4/5

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

A single dense sentence with the primary action front-loaded, followed by the resume capability and the auth requirement. Every clause carries information, though the dash-and-word-conjunction construction makes it slightly run-on.

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?

Given an output schema, full parameter documentation and annotations, the description covers purpose, auth prerequisite and the non-obvious resume behavior. The remaining gap is minor: no indication of what resuming does with prior plan state versus a normal message, which matters for a 7-parameter mutation tool.

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 100%, so every parameter including model, panel, autoRun, budgetUsd and mediaKeys is already documented in detail. The description only echoes two of them ('optionally with files attached' for mediaKeys and history for the text field). Baseline 3 applies.

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?

States a specific verb and resource ('send another message to a job') and adds a second mode ('resume a stuck or failed run with full history'), which is far more informative than the title 'Reply to a job'. It does not explicitly name how it differs from siblings like jobs_run or jobs_stop, so an agent must infer the boundary from the word 'another'.

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?

Gives clear when-to-use context for the two main cases: appending a message to an existing job, and reanimating a stalled or failed run with its history intact. It stops short of explicit when-not guidance or naming an alternative tool for starting a fresh job.

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

All ShapelessAI tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.