SigRank MCP server

enroll

Idempotent

Bind this device to your SigRank operator by pasting a signalaf.com Settings key so signed tokens run cascade to the live board; it stores a local ed25519 keypair and sends only the public key.

Instructions

Bind THIS device to your SigRank operator so your signed token runs cascade to the live board. Paste the key from signalaf.com → Settings → "New key" (or "Generate connect code"). On first run it generates + stores a local ed25519 keypair (~/.sigrank-mcp/identity.json); only the PUBLIC key is ever sent. By enrolling you agree to the SignalAF Terms of Service (signalaf.com/terms) and Privacy Policy (signalaf.com/privacy). Need a new key? Click "New key" at signalaf.com → Settings, then paste it here.

Input Schema

Name	Required	Description	Default
`code`	Yes	the key / connect code (SIGR-XXXXX-XXXXX-XXXXX) from Settings → New key (or Generate connect code)
`device_label`	No	optional label for this device (default: sigrank <version> · <platform>; hostnames are never sent unless you pass a label yourself)

Output Schema

Name	Required	Description
`reason`	No	Error reason if status is error
`status`	No	Enrollment result
`codename`	No	Operator codename if enrolled
`device_id`	No	Local device ID
`operator_id`	No	Operator ID if enrolled
`trust_status`	No	Trust level of the device

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.19.16Oct 16, 2026

changedInput schema / properties / device_label / description

Previous value: -"optional label for this device (default: hostname · agent version)"New value: +"optional label for this device (default: sigrank <version> · <platform>; hostnames are never sent unless you pass a label yourself)"

Changed1 schema field changedv0.16.0Jul 7, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "codename": {
+      "description": "Operator codename if enrolled",
+      "type": "string"
+    },
+    "device_id": {
+      "description": "Local device ID",
+      "type": "string"
+    },
+    "operator_id": {
+      "description": "Operator ID if enrolled",
+      "type": "string"
+    },
+    "reason": {
+      "description": "Error reason if status is error",
+      "type": "string"
+    },
+    "status": {
+      "description": "Enrollment result",
+      "enum": [
+        "enrolled",
+        "error"
+      ],
+      "type": "string"
+    },
+    "trust_status": {
+      "description": "Trust level of the device",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Addedv0.6.10Jul 4, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare idempotentHint, destructiveHint=false, and openWorldHint=false. The description adds substantial beyond-annotation context: it creates and stores a local ed25519 keypair at ~/.sigrank-mcp/identity.json, sends only the PUBLIC key, and binds the user to ToS/Privacy terms.

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

Conciseness3/5

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

Mostly front-loaded and informative, but the key-pasting instruction appears twice ('Paste the key from signalaf.com → Settings → New key' and later 'Need a new key? Click New key at signalaf.com → Settings, then paste it here'), which is redundant and pads the length.

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?

An output schema exists, so return values need not be explained. The description covers the prerequisite operator context, side effects (keypair file), privacy handling, and legal terms, leaving little an agent would need missing before calling it.

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 the schema already documents both `code` (format SIGR-XXXXX) and `device_label` (default and hostname behavior). The description reinforces the code-source workflow but adds little syntax or semantics beyond what the schema provides, 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 (bind/enroll) and resource (THIS device's identity to the SigRank operator), with a concrete outcome ('your signed token runs cascade to the live board'). It is unique among siblings, none of which perform enrollment, though it doesn't explicitly name an alternative.

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?

Clear context for use (first-run enrollment, paste the Settings key) and a recovery path for the 'need a new key' case. No explicit when-not or alternative routing, but none of the sibling tools overlap, so context is sufficient.

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