Skip to main content
Glama
Ikalus1988

MisakaNet

by Ikalus1988
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

misakanet_register

Registers an agent to obtain a node_id and token for remote MCP write access. Reuse a private client_id to receive the same node and token on later calls.

Instructions

Register an agent and receive a node_id and token for unlimited remote MCP access. Reading needs no registration; only write tools do. Local stdio MCP is unlimited and does not need registration. For remote HTTP MCP, call this tool first to get a token, then pass it as the user parameter in subsequent calls. Input semantics: agent_type is optional (defaults to 'unknown'); client_id is an optional stable identifier (8-64 chars of A-Z a-z 0-9 . _ : -) you generate once and keep private — with it, later calls return the same node_id and token (reused=true), without it each call mints a new node. SECURITY: client_id is a key, not a label — the server derives a deterministic node_id from it and returns the stored token if one exists, so knowing someone's client_id is enough to obtain their token. Generate a random UUID and store it like a secret; do not derive from hostname or workspace id. Output schema: JSON with {node_id, token, registered_at, agent_type, reused?}. Error cases: invalid_client_id (wrong format). Side effects: persists registration record in usage_meter. Auth: none. Rate limits: one registration per session.

Input Schema

NameRequiredDescriptionDefault
client_idNoOptional stable identifier for this client (8-64 chars of A-Z a-z 0-9 . _ : -). Generate it once and reuse it so later calls return the same node instead of a new one.
agent_typeNoOptional agent type identifier (e.g. 'claude-code', 'cursor', 'aider'). Defaults to 'unknown'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.30.2
    • addedInput schema / properties / client_id
      Added value: +{
+  "description": "Optional stable identifier for this client (8-64 chars of A-Z a-z 0-9 . _ : -). Generate it once and reuse it so later calls return the same node instead of a new one.",
+  "type": "string"
+}
  2. Addedv2.18.0

TDQS

A4.7/5.0
Behavior4/5

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

Adds substantial context beyond annotations: error case (invalid_client_id), side effect (persists registration record in usage_meter), auth (none), rate limits (one per session), and the conditional reuse behavior. The reuse semantics (same node/token when client_id supplied) nuance the idempotentHint=false annotation but do not contradict it, since the no-client_id default still mints a new node.

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?

Dense but well organized and front-loaded with purpose and access rules. It is on the long side and the SECURITY paragraph is somewhat repetitive of the earlier client_id sentence, keeping it just below top marks.

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?

Despite no output schema, the description specifies the return shape ({node_id, token, registered_at, agent_type, reused?}) and covers error cases, side effects, auth, and rate limits. Nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, but the description goes further than the schema: it frames client_id as 'a key, not a label,' warns that knowing someone's client_id is enough to obtain their token, and instructs generating a random UUID rather than deriving from hostname. This is meaningful semantic value beyond the field descriptions.

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 ('Register an agent') and concrete outcome ('receive a node_id and token for unlimited remote MCP access'). It also immediately scopes what does NOT need registration (reads, local stdio), distinguishing it from the sibling write/read tools.

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-to-use rules: 'Reading needs no registration; only write tools do,' local stdio is unlimited, and for remote HTTP MCP 'call this tool first to get a token.' No alternative or exclusion is left to inference.

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

Deploy Server

Other Tools