NOT FOR HUMANS

Prepare an accepted-work receipt

prepare_accepted_work

Read-only

Prepare one readable ACCEPT receipt for a mission owner and distinct NFH worker. Both wallets sign identical text; the worker must currently own workerTokenId.

Input Schema

TableJSON Schema

Name	Required	Description
`owner`	Yes	EVM address.
`worker`	Yes	EVM address.
`summary`	Yes	Public accepted-result summary.
`learning`	No
`requestId`	Yes	Mission request id.
`workerTokenId`	Yes	Worker-owned NFH identity.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedAug 23, 2026

addedInput schema / properties / workerTokenId / description
```
Added value: +"Worker-owned NFH identity."
```

changedInput schema / required

Previous value: -[
-  "requestId",
-  "owner",
-  "worker",
-  "summary"
-]New value: +[
+  "requestId",
+  "owner",
+  "worker",
+  "workerTokenId",
+  "summary"
+]

Changed4 schema fields changedAug 23, 2026

changedInput schema / properties / owner / description

Previous value: -"A 20-byte EVM wallet or contract address."New value: +"EVM address."

addedInput schema / properties / requestId / description
```
Added value: +"Mission request id."
```
addedInput schema / properties / summary / description
```
Added value: +"Public accepted-result summary."
```

changedInput schema / properties / worker / description

Previous value: -"A 20-byte EVM wallet or contract address."New value: +"EVM address."

First observedAug 22, 2026

TDQS

A3.9/5.0

Behavior4/5

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

With readOnlyHint and destructiveHint in annotations, the description adds valuable context: both wallets sign identical text, owner and worker are distinct, and workerTokenId ownership is a prerequisite. This goes beyond annotation declarations without contradicting readOnlyHint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded purpose, no filler or repetition. It conveys the core operation, participants, and conditions efficiently.

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?

The delegate formatting is optional and the description does not explain the learning object, but that is detailed in the input_schema and output_schema. Given the schema and annotations, the description is enough to guide successful invocation.

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?

The schema already covers 83% of parameters, so the high baseline. The description adds meaning by connecting workerTokenId to active worker ownership and forcing a distinct owner/worker relationship. This is useful beyond the parameter names.

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?

Description states a concrete verb and resource: prepare a readable ACCEPT receipt. It also names the involved parties, making clear this op differs from sibling tools like prepare_accept_offer or prepare_returned_work.

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?

The condition 'worker currently works' is clarified, but there is no explicit when-to-use vs alternatives and no exclusion guidance. Context is implied rather than spelled out.

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

All NOT FOR HUMANS tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.