kyde score

Attach a human to the key

claim_key

Attach your human's email to the key (double opt-in: Kyde mails a confirmation link). Once confirmed, the key is claimed: the human gets the management dashboard, and rebaseline, webhook changes and revocation work only for them — no agent, including you, can reset its own score. Ask the human once for the address; never invent or guess one; skip when get_scores already shows claimed: true.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "email": "<email>"
    },
    "name": "claim_key"
  }
}

Input Schema

Name	Required	Description
`key`	No	Scoring key; omit when sent as x-kyde-key header.
`email`	Yes	The human's email address, given by them.
`product_updates`	No	Separate, optional consent: may Kyde send occasional product updates to this address? Ask as its own question; pass true only on an explicit yes. Default false; revocable in the dashboard.

Output Schema

Name	Required	Description	Default
`next`	Yes
`claim`	Yes
`email_sent`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 6, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "claim": {
+      "type": "string"
+    },
+    "email_sent": {
+      "type": "boolean"
+    },
+    "next": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "claim",
+    "email_sent",
+    "next"
+  ],
+  "type": "object"
+}

AddedNov 5, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only declare openWorldHint=true and destructiveHint=false; the description supplies the far more consequential behavior: the double opt-in pending state, the transfer of control (dashboard, rebaseline, webhook, revocation) to the human, and the irreversible loss of the agent's ability to reset its own score. That is exactly the context an agent needs before calling a write tool, and it does not conflict with any annotation.

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?

Three dense sentences, front-loaded with the action and mechanism, then consequences, then the procedural guardrail and skip condition. No filler or restatement of the title.

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?

With an output schema, full schema descriptions and annotations present, the description covers everything else an agent needs: the opt-in flow, the authorization consequences, sourcing discipline, and the skip condition.

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%, so the baseline is 3, but the description adds a real constraint beyond the schema's 'given by them': ask once, never invent or guess an address. It does not elaborate on product_updates, though the schema fully covers that consent parameter, so the gap is minor.

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 ('Attach your human's email to the key') and immediately names the mechanism (double opt-in confirmation link) and the resulting state change. It also distinguishes itself from sibling capabilities by noting that rebaseline, set_webhook and revoke_key become human-only once claimed, so an agent can tell what this tool uniquely does.

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?

Explicit when-not guidance: 'skip when get_scores already shows claimed: true' names the sibling to check first and the exact condition that selects skipping. It also constrains sourcing ('Ask the human once... never invent or guess one'), leaving nothing to inference.

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

All kyde score 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?