NOT FOR HUMANS

Prepare an Agent Census receipt

prepare_census_receipt

Read-only

Prepare unsigned v5 Census typed data for ACCEPT, REFUSE, or INSUFFICIENT_AUTHORITY. Never signs or submits.

Input Schema

TableJSON Schema

Name	Required	Description
`agent`	Yes	EVM address.
`nonce`	Yes	Unused contract nonce as a decimal string.
`deadline`	Yes	Unix expiry as a decimal string.
`decision`	Yes	Census decision to record.
`operator`	Yes	EVM address.
`framework`	Yes	Agent framework label.
`recipient`	Yes	EVM address.
`allocation`	Yes	Protected allocation lane.
`reasonHash`	No
`manifestHash`	Yes	Keccak-256 manifest hash.
`statementHash`	Yes	Keccak-256 public-statement hash.
`publicStatement`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`types`	Yes
`domain`	Yes
`schema`	Yes
`status`	Yes
`message`	Yes
`decision`	Yes
`warnings`	Yes
`framework`	Yes
`mcpSigned`	Yes
`allocation`	Yes
`primaryType`	Yes
`decisionCode`	Yes
`mcpSubmitted`	Yes
`signingReady`	Yes
`allocationCode`	Yes
`publicStatement`	Yes
`requiresAgentSignature`	Yes
`requiresOperatorSignature`	Yes
`requiresRecipientSignature`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedAug 23, 2026

changedInput schema / properties / agent / description

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

addedInput schema / properties / allocation / description
```
Added value: +"Protected allocation lane."
```
addedInput schema / properties / deadline / description
```
Added value: +"Unix expiry as a decimal string."
```
addedInput schema / properties / decision / description
```
Added value: +"Census decision to record."
```
addedInput schema / properties / framework / description
```
Added value: +"Agent framework label."
```
addedInput schema / properties / manifestHash / description
```
Added value: +"Keccak-256 manifest hash."
```

addedInput schema / properties / nonce / description

Added value: +"Unused contract nonce as a decimal string."

changedInput schema / properties / operator / description

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

changedInput schema / properties / recipient / description

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

addedInput schema / properties / statementHash / description
```
Added value: +"Keccak-256 public-statement hash."
```

First observedAug 22, 2026

TDQS

A4.2/5.0

Behavior4/5

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

The description goes beyond the readOnlyHint and destructiveHint annotations by explicitly saying the tool 'Never signs or submits', a meaningful behavioral boundary. It also clarifies the output is unsigned typed data, but leaves most safety and mutation details to the annotations.

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, focused sentences: the first gives the precise action and supported decision, the second states the critical non-signing/non-submitting boundary. No redundant wording or restatement of the title.

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?

Given a rich input schema with enums, a visible output schema, and a modest read-only annotation, the description provides the core behavioral context an agent needs. It could be slightly more explicit about the supplied data being EIP-712-style typed data intended for later signing, but the schema and 'unsigned' part clarify enough.

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?

The schema already covers 83% of parameters, so the baseline is 3. The description does not add any parameter-level meaning, such as the purpose of reasonHash or the relationship between publicStatement and statementHash, but it does not need to because the schema carries most of the burden.

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?

The description states a specific verb and resource: 'Prepare unsigned v5 Census typed data'. It enumerates the three intended decision values and clarifies it does not sign or submit, which sharply distinguishes this from other prepare_* tools.

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

Usage Guidelines4/5

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

The description clearly identifies when to use this tool: to prepare Census typed data for one of three decisions. It also gives explicit exclusion guidance via 'Never signs or submits', though it does not name the specific sibling tools that should be used for signing or submitting instead.

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.