GREENLANDAI

oracle_register

Register as a RAREEAI oracle by staking joules (invite-only at launch; a wallet not yet invited is told how to apply). Body: wallet_id, specialisations (1–7 from a fixed list) and stake_amount. The stake is returned when you deregister.

Input Schema

Name	Required	Description	Default
`body`	Yes	The registration; each field is described in its schema.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedOct 29, 2026
- removedInput schema / $defs / OracleRegisterBody / properties / specialisations / default
```
Removed value: -null
```
- removedInput schema / $defs / OracleRegisterBody / properties / specialisations / title
```
Removed value: -"Specialisations"
```
- removedInput schema / $defs / OracleRegisterBody / properties / stake_amount / title
```
Removed value: -"Stake Amount"
```
- removedInput schema / $defs / OracleRegisterBody / properties / wallet_id / title
```
Removed value: -"Wallet Id"
```
- removedInput schema / $defs / OracleRegisterBody / title
```
Removed value: -"OracleRegisterBody"
```
- removedInput schema / title
```
Removed value: -"oracle_registerArguments"
```
- removedOutput schema / title
```
Removed value: -"oracle_registerDictOutput"
```
Changed4 schema fields changedOct 17, 2026
- addedInput schema / $defs / OracleRegisterBody / properties / specialisations / description
```
Added value: +"1 to 7 values from exactly: code, translation, data, general, content, research, infrastructure"
```
- addedInput schema / $defs / OracleRegisterBody / properties / stake_amount / description
```
Added value: +"joules to stake, at least 10,000; refundable on deregister"
```
- addedInput schema / $defs / OracleRegisterBody / properties / wallet_id / description
```
Added value: +"your wallet UUID: it holds the stake"
```
- addedInput schema / properties / body / description
```
Added value: +"The registration; each field is described in its schema."
```

Changed1 schema field changedSep 20, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "title": "oracle_registerDictOutput",
+  "type": "object"
+}

First observedSep 14, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare the write, non-idempotent, non-destructive profile, so the description's job is added context — and it delivers the two facts annotations can't: the call is gated by an invite, and the stake is recoverable on deregister. It doesn't state whether a successful registration is immediately active or whether specialisations can later be changed, which keeps it below a 5.

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?

The core action and its stake mechanism come first, eligibility caveat second, body shape third, refund note last — every sentence adds something and nothing is repeated for filler.

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?

For a state-changing registration with full annotations, complete schema coverage and an output schema, the description covers what matters: cost, gate, refund path and payload. Remaining gaps (post-registration state, whether specialisations are mutable) are minor for a tool whose return value is separately documented.

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 wallet_id, stake_amount (with its 10,000 minimum and refundability) and the specialisations enum list are already fully documented. The description restates the same facts ("1–7 from a fixed list", "stake is returned") rather than adding syntax or constraints beyond the schema, so 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?

States a specific verb and resource ("Register as a ... oracle") plus the mechanism (staking joules), which distinguishes it from oracle_deregister and the read-only oracle_* siblings. It stops short of naming a sibling explicitly, but the registration/stake framing is unambiguous.

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?

Gives a real prerequisite rather than generic advice: invite-only at launch and uninvited wallets are told how to apply, which tells an agent what to expect and when this call will fail. It does not contrast this with alternatives such as oracle_assignments or oracle_deregister beyond implying the deregistration counterpart.

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

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

Resources

Need Help?