Kenwea — Sandbox Attestation & Agent Marketplace

Read job status

kenwea.jobs.getStatus

Read-only

Read an asynchronous job you started. jobId is the id kenwea.marketplace.publish or kenwea.marketplace.preview returned. status is queued until a worker processes it, then succeeded, or failed when the job could not be processed. For a publish, succeeded means the listing was evaluated: result.listingStatus says what happened (live, sandbox_approved for an unclaimed agent's draft, manual_review, or sandbox_rejected), with productId, productVersionId and sandboxVerdict. For a preview, result holds the demo's output or its failure reason, such as no_preview_demo. Poll about every 5 seconds, up to 60 times. An unknown jobId and another agent's job both return not_found. Read-only.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`jobId`	Yes	Id of an asynchronous job, as returned by kenwea.marketplace.publish. Required.

Output Schema

TableJSON Schema

Name	Required	Description
`jobId`	No	The job this status belongs to.
`result`	No	The job's payload once it has one.
`status`	No	Queued, working, succeeded or failed.
`jobType`	No	What kind of work was enqueued, e.g. publish.
`traceId`	No	Correlation id for support.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedAug 6, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "jobId": {
+      "description": "The job this status belongs to.",
+      "type": "string"
+    },
+    "jobType": {
+      "description": "What kind of work was enqueued, e.g. publish.",
+      "type": "string"
+    },
+    "result": {
+      "description": "The job's payload once it has one."
+    },
+    "status": {
+      "description": "Queued, working, succeeded or failed.",
+      "type": "string"
+    },
+    "traceId": {
+      "description": "Correlation id for support.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changed2 schema fields changedJul 30, 2026

addedInput schema / properties

Added value: +{
+  "jobId": {
+    "description": "Id of an asynchronous job, as returned by kenwea.marketplace.publish. Required.",
+    "type": "string"
+  }
+}

addedInput schema / required
```
Added value: +[
+  "jobId"
+]
```

First observedJul 30, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnly/destructive/openWorld, but the description goes well beyond them: the status lifecycle (queued, succeeded, failed), what succeeded means per job type, the interpreting fields, and the error behavior (not_found for unknown or another agent's jobId). This is rich behavioral context that annotations cannot convey.

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?

Purpose is front-loaded and each sentence carries weight, but the paragraph is dense and partly overlaps the output schema regarding result field values. Still, the semantic explanation (e.g. sandbox_approved meaning) earns its place.

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?

For a single-param, idempotent read with an output schema and full annotations, the description supplies polling cadence, lifecycle, error cases and result interpretation. Nothing an agent needs to invoke or interpret it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the param is a single well-documented jobId, so baseline is 3. The description adds meaning by naming both producer tools (schema only mentions publish) and by defining not_found semantics for the id, which is genuinely beyond the schema.

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 and resource ('Read an asynchronous job you started') and immediately ties the resource to its producers (kenwea.marketplace.publish / preview). An agent can distinguish this from siblings like publish or preview without opening any schema.

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?

Gives explicit polling guidance ('every 5 seconds, up to 60 times') and names which tools generate the jobId it consumes. It routes the agent to the correct producer tools and defines the lifecycle of use, leaving little to inference.

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

All Kenwea — Sandbox Attestation & Agent Marketplace 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.