Skip to main content
Glama

RQM Jobs MCP

by com.rqmtechnologies
OverviewDiscussionsAdmin

Run a job using prepaid RQM credits

run_account_job
DestructiveIdempotent

Purchase one discovered service using prepaid credits within the account owner's saved spending policy. First search_buyer_jobs for the task and inspect the selected request_schema, required inputs, limits, examples and evidence boundaries. Use its buyer service_id as capability_id; validate the user's inputs and ask for missing data rather than substituting an example. Set max_total_price to the caller-approved USD ceiling; discovery is not a binding quote and balance alone is not policy authorization. Acceptance or a queued job is not completion: retain the returned job ID and use get_account_job to read saved status, result and receipt. If submission times out or its outcome is uncertain, first recover with list_account_jobs using the original idempotency_key. Any retry must preserve the same key, capability, request and price ceiling; never create a new purchase or switch payment rails to recover. This tool never signs x402 or funds the account. Report only observed completion and findings within the service's evidence boundaries.

Input Schema

NameRequiredDescriptionDefault
requestYesUser inputs matching the selected service request_schema. Consult its required fields and example; ask for missing data, units, rules or tolerances rather than inventing them.
capability_idYesBuyer service_id returned by discovery, not an implementation_capability_id. Select a supported service before submitting.
idempotency_keyYesStable caller-chosen identifier for one purchase. Preserve the exact key and request on retries; recover uncertain submissions with list_account_jobs using this key.
max_total_priceYesCaller-approved total price ceiling in USD as a decimal string with up to six fractional digits. Not a quote, funding instruction or policy authorization; the saved spending policy must also permit this job.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • 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 submission response for the saved job. Acceptance does not establish completion; use the returned job ID to read saved status and available result and receipt."
  2. Changed5 schema fields changed
    • addedInput schema / properties / capability_id / description
      Added value: +"Buyer service_id returned by discovery, not an implementation_capability_id. Select a supported service before submitting."
    • addedInput schema / properties / idempotency_key / description
      Added value: +"Stable caller-chosen identifier for one purchase. Preserve the exact key and request on retries; recover uncertain submissions with list_account_jobs using this key."
    • addedInput schema / properties / max_total_price / description
      Added value: +"Caller-approved total price ceiling in USD as a decimal string with up to six fractional digits. Not a quote, funding instruction or policy authorization; the saved spending policy must also permit this job."
    • addedInput schema / properties / request / description
      Added value: +"User inputs matching the selected service request_schema. Consult its required fields and example; ask for missing data, units, rules or tolerances rather than inventing them."
    • 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"
+}
  3. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare write/idempotent/open-world/destructive semantics, but the description adds substantial context beyond them: it never signs x402 or funds the account, acceptance or a queued job is not completion, balance alone is not policy authorization, and any retry must preserve the same key and ceiling. This is unusually rich behavioral disclosure for a financial mutation.

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?

It is long, but front-loads the purpose and every sentence addresses a real risk (validation, idempotency, recovery, non-completion). Minor redundancy exists, such as the idempotency_key guidance appearing both in the description and in the schema, and the 'never signs x402' point restated as a closing constraint.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a destructive, open-world financial tool with nested request objects and an available output schema, the description covers the prerequisites, submission semantics, idempotency contract, recovery path, and evidence-boundary reporting duties. Nothing an agent needs to call it correctly is missing, and return values need not be explained since an output schema exists.

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 the schema already documents all four parameters, including the capability_id/buyer service_id distinction and the max_total_price decimal-string pattern. The description largely restates this (capability_id from discovery, ceiling is not a quote), adding little beyond the structured fields. 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?

The description opens with a specific verb and resource: 'Purchase one discovered service using prepaid credits within the account owner's saved spending policy.' That is unambiguous. It indirectly separates itself from quote_job ('discovery is not a binding quote') but never explicitly distinguishes itself from the sibling run_buyer_job or settle_buyer_job, so it falls short of full sibling differentiation.

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?

It states the prerequisite workflow (search_buyer_jobs first, inspect request_schema and evidence boundaries), the recovery path on timeout (list_account_jobs with the original idempotency_key), and the retry rule (preserve key, capability, request, and ceiling; never switch payment rails). These are explicit when-to-use and when-not-to-do-something instructions.

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 toolsInspect
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