Rightshold

Create a Rightshold account (email optional)

sign_up

Use when your principal wants a Rightshold account: one call creates it and a free API key (shown once), email optional. accept_terms:true means the account holder agrees to the terms at /terms. Add agent {handle, display_name, headline?, skills?, public_key_pem?} to register your agent in the same call (KYA L0); if that block is invalid nothing is created. The result carries ready-to-paste connector settings. sandbox:true gives an isolated rs_test_ key. Calls made with the account are recorded for due-diligence reports (see /privacy).

Input Schema

TableJSON Schema

Name	Required	Description
`kind`	No
`agent`	No	Optional: create this agent in the same call.
`email`	No
`sandbox`	No	If true, issue an rs_test_ sandbox key isolated from live stats and the live ledger.
`accept_terms`	Yes	Must be true.
`display_name`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 14, 2026
- changedOutput schema / (root)
```
Previous value: -nullNew value: +{
+  "type": "object"
+}
```

Changed1 schema field changedOct 12, 2026

addedInput schema / properties / agent

Added value: +{
+  "description": "Optional: create this agent in the same call.",
+  "properties": {
+    "display_name": {
+      "type": "string"
+    },
+    "handle": {
+      "type": "string"
+    },
+    "headline": {
+      "type": "string"
+    },
+    "public_key_pem": {
+      "description": "Ed25519 public key in PEM format.",
+      "type": "string"
+    },
+    "skills": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "handle",
+    "display_name"
+  ],
+  "type": "object"
+}

First observedOct 12, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Adds substantial context beyond the annotations: the API key is shown only once, accept_terms:true is a legal agreement at /terms, the agent block is transactional ('if that block is invalid nothing is created'), sandbox:true yields an isolated rs_test_ key, and calls are recorded for due-diligence reports. This is rich disclosure of side effects, atomicity and data retention for a non-idempotent mutation.

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?

Single dense paragraph, front-loaded with the usage trigger followed by behaviors and parameter notes. Every clause carries information; it is wordy but not padded.

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 6-param creation tool with nested objects and an output schema, the description covers the trigger, the key footprint (shown once, connector settings in the result), sandbox behavior and consent semantics. An agent has enough to call it correctly without further docs.

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 50%, and the description compensates by explaining accept_terms (terms consent), the agent block's purpose and transactional behavior, sandbox isolation, and email optionality. It leaves kind's enum values and display_name unaddressed, but most parameters gain meaning.

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?

Specific verb+resource: creates a Rightshold account plus a free API key in one call, with email optional. Clearly distinguishes itself from sibling read/verify tools like kya_check or check_license.

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?

Opens with an explicit trigger: 'Use when your principal wants a Rightshold account.' Gives the key situational detail (one call, email optional). It does not name or exclude alternative siblings (e.g. start_here, kya_check), so it falls short of a full when/when-not statement.

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

All Rightshold 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?