RQM Jobs MCP

Recover an account-funded job

get_account_job

Read-only

Read this agent's saved account-funded job by its returned job ID to check status and recover available result and receipt. Use after submission or when following up on an existing purchase; acceptance is not completion. Report the saved state and only available results, with their limitations. If the job ID was lost, use list_account_jobs with the original idempotency key first. Never authorizes another purchase.

Input Schema

Name	Required	Description	Default
`job_id`	Yes	UUID returned for the saved account job. Recover a missing ID with list_account_jobs using the original purchase idempotency key; do not invent an ID or submit again.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 7, 2026

addedInput schema / properties / job_id / description

Added value: +"UUID returned for the saved account job. Recover a missing ID with list_account_jobs using the original purchase idempotency key; do not invent an ID or submit again."

changedOutput schema / description

Previous value: -"Unmodified Account Core response object; fields depend on the action and saved job version. Balance is not spending-policy readiness."New value: +"Unmodified Account Core saved-job response. Interpret the saved status before claiming completion; result and receipt availability depends on job state and saved version."

Changed1 schema field changedOct 3, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": {},
+  "description": "Unmodified Account Core response object; fields depend on the action and saved job version. Balance is not spending-policy readiness.",
+  "properties": {},
+  "type": "object"
+}

AddedSep 25, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare the safe read-only, non-destructive profile, so the description's job is to add nuance — and it does: 'acceptance is not completion', results may be partial with limitations, and the read does not re-authorize a purchase. It stops short of describing pagination or exact return shape, but the added behavioral nuance is meaningful.

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?

Front-loaded with the core action and purpose, then layered with usage, caveats, and fallback in a compact sequence. Slightly dense but each sentence carries actionable information.

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?

An output schema exists, so return details need not be spelled out, and annotations cover safety. The description supplies the remaining needed context — partial results, acceptance vs completion, and ID-recovery path — though it could note read-latency or state enumeration more explicitly.

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?

With one parameter at 100% schema coverage, the schema already documents the UUID format and even the list_account_jobs fallback. The description reiterates the job-ID semantics but adds no format or syntax detail beyond the schema, matching the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (read/recover) and resource (this agent's saved account-funded job) keyed by job ID, and names the concrete outcomes (status, result, receipt). It is clearly distinct from siblings like run_account_job (submission) and list_account_jobs (lost-ID recovery).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use it ('after submission or when following up on an existing purchase') and routes to the alternative when the ID is lost ('use list_account_jobs with the original idempotency key first'). Also warns 'never authorizes another purchase', which constrains misuse.

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

All RQM Jobs MCP 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.

Resources

Need Help?