Keryx

Export your private job metadata

history_private_jobs_export

Read-onlyIdempotent

Private data for this authenticated caller only. Exact-payer completed private jobs in the current store; explicit history:read required. Bounded scan/continuation, unknown provenance and NULL own spend/creator settlement remain explicit. No wallet selector, public report/share link, model prompt, research, source fetch, signer, purchase or mutation authority. Manual finite JSON metadata export only; complete/truncated and continuation are returned. Result bodies are excluded.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "history_private_jobs_export"
  }
}

Input Schema

Name	Required	Description
`to`	No	Inclusive creation-time upper bound in the same UTC format; must not precede from.
`from`	No	Inclusive creation-time lower bound in UTC (Z or +00:00), retaining up to six fractional digits.
`limit`	No	Maximum completed private-job rows per bounded page, 1-25 inclusive; defaults to 25.
`cursor`	No	Private opaque cursor from this owner's previous page with identical filters; preserve it exactly.
`search`	No	Literal case-sensitive substring in your saved private-job questions, up to 200 characters.
`network`	No	Filter recorded network: eip155:5042 for Arc or eip155:5042002 for Arc testnet; selects no signer.
`surface`	No	Filter recorded job origin; missing provenance remains unknown.

Output Schema

Name	Required	Description	Default
`rows`	Yes
`pages`	Yes
`scope`	Yes
`bounds`	Yes
`format`	Yes
`wallet`	Yes
`complete`	Yes
`truncated`	Yes
`nextCursor`	Yes
`capabilities`	Yes
`qualification`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedNov 7, 2026

addedInput schema / properties / cursor / description

Added value: +"Private opaque cursor from this owner's previous page with identical filters; preserve it exactly."

addedInput schema / properties / from / description

Added value: +"Inclusive creation-time lower bound in UTC (Z or +00:00), retaining up to six fractional digits."

addedInput schema / properties / limit / description

Added value: +"Maximum completed private-job rows per bounded page, 1-25 inclusive; defaults to 25."

addedInput schema / properties / network / description

Added value: +"Filter recorded network: eip155:5042 for Arc or eip155:5042002 for Arc testnet; selects no signer."

addedInput schema / properties / search / description

Added value: +"Literal case-sensitive substring in your saved private-job questions, up to 200 characters."

addedInput schema / properties / surface / description

Added value: +"Filter recorded job origin; missing provenance remains unknown."

addedInput schema / properties / to / description

Added value: +"Inclusive creation-time upper bound in the same UTC format; must not precede from."

addedOutput schema / properties / rows / items / properties / id / description

Added value: +"Exact private research ID: prv_ followed by 64 lowercase hex digits; preserve it and keep it private."

AddedOct 15, 2026

TDQS

A4/5.0

Behavior5/5

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

Beyond the read-only, idempotent, closed-world annotations, the description discloses authentication requirements, bounded scanning and continuation, explicit handling of unknown provenance and NULL settlement fields, and a clear list of forbidden capabilities. It also states that result bodies are excluded and that complete/truncated status and continuation are returned.

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?

The description is compact and front-loads the privacy scope, authorization requirement, and exclusions. It is dense with semicolon-separated clauses and some jargon, but most wording conveys material constraints rather than filler.

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 the rich input schema and existing output schema, the description supplies the remaining operational context an agent needs: caller scoping, required authorization, bounded pagination, truncation behavior, and explicit capability exclusions. Nothing essential for calling this complex export safely appears to be missing.

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 explains all seven parameters in detail. The description adds general context about bounded scans and continuation but does not add much parameter-specific meaning beyond what the schema provides.

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 clearly identifies a metadata export of exact-payer completed private jobs in the current store, scoped to the authenticated caller. It distinguishes the resource and privacy boundary, but it does not explicitly name when this export should be chosen over sibling history tools such as history_private_jobs_list or history_private_jobs_detail.

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?

It states an explicit history:read requirement and limits use to private data for the authenticated caller, which gives useful preconditions. However, it provides no direct when-to-use versus alternative guidance against the closely related private-job list, detail, or general history export tools.

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

All Keryx 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.