Skip to main content
Glama

Run job

proofable_job_create

Create an immediate or scheduled work item for an agent. Operator routes team work. Developer and designer jobs run on the hosted Operator runtime. The signed-in account must own the agent or hold active permissions for it.

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": {
      "prompt": "<prompt>",
      "agentWallet": "<agentWallet>",
      "agentId": "<agentId>"
    },
    "name": "proofable_job_create"
  }
}

Input Schema

NameRequiredDescriptionDefault
tagsNoAdditional tags
modelNoOverride model for inference
originNoWhere the outcome is announced, e.g. { type: 'slack', channel: '<channel id>' }. Finished, failed and awaiting-approval runs post there.
promptYesWork to run in natural language (user story, issue, feedback, or outcome). Never tool names.
agentIdYesAgent identifier
runAtMsNoOptional unix ms timestamp for first run
runtimeNoOptional computer intent: { requiresComputer: true, repo: { slug, ref } }. An explicit harness override may select an ACP agent. Delegation must allow run_command; if setup is unavailable, the job fails closed. Omitted jobs use hosted Operator.
providerNoInference provider label (e.g., "openrouter", "openai")
scheduleNoOptional one-time, interval, or cron schedule. Omit to run once now.
acceptanceNoWhat 'done' means for this run, checked in code with no model in the loop. A run that declares acceptance is verified on completion and becomes an accepted outcome; a run that declares none completes but is recorded as not evaluated.
agentWalletYesAgent wallet address (0x...)
runNowFirstNoFor recurring schedules, run once immediately before the next scheduled run.
outputSchemaNoJSON Schema the run's structured output must satisfy. A response that violates it fails the run instead of being recorded as a success. A string field listed in required must also be non-empty, so leave a field that may be empty out of required, and state 'this OR that' with anyOf.
runtimeClassNoOptional work-kind label: general (default), developer, or designer. Does not select tools or the computer. Hosted Operator is the default runtime. Set runtime.requiresComputer or an explicit runtime.harness to request an isolated computer.
systemPromptNoOverride system prompt
executionStepsNo
delegationQHashNoPin this job to one active agent-delegation proof. A revoked, expired, or mismatched proof is denied without falling back to another grant.
requiresReceiptNoRequire the run to create a proof receipt. A run that owes a receipt and produces none fails.
requiresJobApprovalNoOpt in to parking this run at waiting_approval before it executes, so it can be approved or denied with proofable_job_decide. Per request only, never derived from the agent's action-level approval policy.
providerSecretProofQHashNoVault secret proof ID for a provider API key. Required when the selected provider uses your key.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. Added
  4. Removed
  5. Changed3 schema fields changed
    • changedInput schema / properties / acceptance / properties / criterion / description
      Previous value: -"The condition the finished response must satisfy before this run counts as accepted. Pass a LIST when the work has more than one honest outcome, for example a deliverable OR a clear statement that it could not be produced. A list passes when ANY entry is present, which is how a loop that correctly refuses rather than inventing is not scored as a failure."New value: +"The condition the finished response must satisfy before this run counts as accepted. Pass a LIST when the work has more than one honest outcome, for example a deliverable OR a clear statement that it could not be produced. In text and exact mode a list passes when ANY entry matches, which is how a loop that correctly refuses rather than inventing is not scored as a failure. In fields mode a list names fields that must ALL be non-empty."
    • changedInput schema / properties / acceptance / properties / mode / description
      Previous value: -"How the criterion is checked. text (default): the response must contain the criterion phrase (or any entry of a criterion list). Use this when the work has an honest decline alongside its deliverable. exact: the response must BE the criterion (or any entry of a list) after stripping quotes, backticks, emphasis and whitespace; a response that merely mentions the phrase fails. Use exact for sealed checks (canary tokens, holdout answers) where a refusal that names the answer must not count as accepted. fields: the criterion names structured output fields that must be present and non-empty. evidence: the criterion names artifact kinds (screenshot, trace, test, …) the result must carry, with a retrievable reference for each."New value: +"How the criterion is checked. text (default): the response must contain the criterion phrase (or any entry of a criterion list). Use this when the work has an honest decline alongside its deliverable. exact: the response must BE the criterion (or any entry of a list) after stripping quotes, backticks, emphasis and whitespace; a response that merely mentions the phrase fails. Use exact for sealed checks (canary tokens, holdout answers) where a refusal that names the answer must not count as accepted. fields: every named field must be present and non-empty; a list means all of them, not any, and an empty string, list or object counts as missing. When either of two fields may carry the result (a deliverable, or a stated reason there is none), name neither here and state the OR with anyOf in outputSchema. evidence: the criterion names artifact kinds (screenshot, trace, test, …) the result must carry, with a retrievable reference for each."
    • changedInput schema / properties / outputSchema / description
      Previous value: -"JSON Schema the run's structured output must satisfy. A response that violates it fails the run instead of being recorded as a success."New value: +"JSON Schema the run's structured output must satisfy. A response that violates it fails the run instead of being recorded as a success. A string field listed in required must also be non-empty, so leave a field that may be empty out of required, and state 'this OR that' with anyOf."
  6. Changed3 schema fields changed
    • changedInput schema / properties / schedule / description
      Previous value: -"Optional one-time, interval, or cron schedule."New value: +"Optional one-time, interval, or cron schedule. Omit to run once now."
    • addedInput schema / properties / schedule / properties
      Added value: +{
      +  "expr": {
      +    "description": "For cron: a five-field cron expression, e.g. \"0 9 * * 1-5\".",
      +    "type": "string"
      +  },
      +  "intervalMs": {
      +    "description": "For interval: milliseconds between runs.",
      +    "exclusiveMinimum": 0,
      +    "maximum": 9007199254740991,
      +    "type": "integer"
      +  },
      +  "runAtMs": {
      +    "description": "For once: unix ms of the run.",
      +    "type": "number"
      +  },
      +  "type": {
      +    "description": "once (default) runs at runAtMs; interval repeats every intervalMs; cron follows expr in tz.",
      +    "enum": [
      +      "once",
      +      "interval",
      +      "cron"
      +    ],
      +    "type": "string"
      +  },
      +  "tz": {
      +    "description": "For cron: IANA time zone. Default UTC.",
      +    "type": "string"
      +  }
      +}
    • removedInput schema / properties / schedule / propertyNames
      Removed value: -{
      -  "type": "string"
      -}
  7. Added

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare the mutation profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=false). The description adds genuinely new context by explaining runtime routing (developer/designer jobs run on the hosted Operator runtime) and an authorization requirement, but never warns that repeated calls create duplicate jobs (non-idempotent), nor describes cost, latency, or what a created job returns.

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?

Four short sentences with the core action front-loaded and no filler. Slightly staccato and the middle sentence about Operator routing could be folded into the runtime note, but nothing is wasted.

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 a 20-parameter nested schema at 95% coverage, there is little the description must carry. It covers authorization and runtime routing, which are the cross-cutting facts not obvious from field docs. It omits return behavior (no output schema exists, so a created job's identifier/status is not described anywhere) and the relationship to requiresJobApproval and proofable_job_decide.

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 95%, so the schema already explains nearly every one of the 20 parameters in depth. The description contributes only a small clarification about work-kind routing (developer/designer on hosted Operator), which the runtimeClass schema field already states more precisely. Baseline 3 is appropriate.

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 ('Create an immediate or scheduled work item for an agent'), which is unambiguous and clearly the creation counterpart to siblings like proofable_job_get, proofable_job_list, proofable_job_cancel, and proofable_job_decide. It does not explicitly name those siblings, so it stops short of a 5.

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?

Adds a useful prerequisite ('the signed-in account must own the agent or hold active permissions for it') that helps an agent know whether it may call this at all. However, it gives no guidance on when to schedule vs. run immediately, when to opt into requiresJobApproval rather than relying on proofable_job_decide later, or how this relates to the other job tools.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.