Skip to main content
Glama
Ikalus1988

MisakaNet

by Ikalus1988
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

misakanet_register

Register an agent to obtain a node_id and token for remote MCP write access; reading requires no registration.

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

TableJSON 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

A5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and delivers: side effects (persists a record in usage_meter), auth (none), rate limits (one per session), error cases (invalid_client_id), and a reuse contract. It even discloses the critical security property that client_id functions as a secret key because the server returns a stored token deterministically.

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?

Dense but well-structured with labeled sections (Input semantics, SECURITY, Output schema, Error cases, Side effects, Auth, Rate limits). The core purpose and the key/warning are front-loaded, and no sentence is filler.

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?

Because no output schema exists, the description compensates by naming the returned JSON shape and the reused flag. It covers auth, rate limits, error paths, side effects, and the security caveat, leaving nothing an agent needs to call it correctly unstated.

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 adds semantics the schema does not: client_id is a key rather than a label, calling with it yields reused=true and the same node, and omitting it mints a new node each call. It also supplies generation guidance (random UUID, not hostname-derived), which is actionable beyond the schema text.

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 the concrete payoff ('receive a node_id and token for unlimited remote MCP access'). It also positions itself against siblings by clarifying that only write tools require registration while reading tools do not.

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?

Explicitly states when to use it (remote HTTP MCP, before other calls, to get a token) and when not to (reading needs no registration, local stdio is unlimited). It also tells the agent where the token goes in subsequent calls.

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