Skip to main content
Glama
Ikalus1988

MisakaNet

by Ikalus1988
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

misakanet_register

Register an agent to receive a node_id and token for unlimited remote MCP write access. Reuse your client_id to get the same credentials 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 you generate once — with it, later calls return the same node_id and token and renew them, without it each call mints a new node. Output schema: JSON with node_id, token, registered_at, agent_type, and reused=true when an existing node was found for client_id. Error cases: invalid_client_id. Side effects: persists registration record. 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 provided, the description carries the full burden and excels: it discloses side effects (persists registration record), auth (none), rate limits (one per session), error cases (invalid_client_id), and output structure. It also clarifies the idempotent behavior of client_id, making all behavioral traits explicit.

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?

The description is structured with clear labels (Input semantics, Output schema, Error cases, Side effects, Auth, Rate limits) and front-loads the core purpose. Every sentence contributes necessary information without redundancy. Despite its length, it is efficiently organized and easily scannable.

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 registration tool with optional parameters, multiple access modes, and no output schema, the description covers all required aspects: purpose, usage conditions, parameter semantics, output format, error handling, side effects, auth, and rate limits. Nothing an agent needs to call 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?

Although schema coverage is 100%, the description adds substantial value beyond the schema: it explains that client_id is optional but ensures the same node_id/token are returned and renewed on subsequent calls, versus minting a new node without it. It also confirms the default for agent_type. This is exactly the kind of semantic enrichment that helps an agent decide how to fill parameters.

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?

The description opens with a specific verb and resource: 'Register an agent and receive a node_id and token for unlimited remote MCP access.' It clearly states the tool's purpose and distinguishes it from siblings (only registration tool) by explaining when it's needed (remote write access) versus local stdio or read-only operations.

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?

Provides explicit when-to-use and when-not-to-use guidance: reading needs no registration, local stdio is unlimited, remote HTTP MCP requires calling this first and then passing the token as the user parameter. Also explains the client_id reuse behavior and its effect on token renewal, leaving no ambiguity about invocation conditions.

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