Skip to main content
Glama
zyndai

zyndai-mcp-server

by zyndai
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

Authenticate with Zynd (browser)

zyndai_login

Authenticate with Zynd via browser-based login to obtain a developer key. This is a prerequisite for registering a persona.

Instructions

Onboard the user with Zynd via the registry's restricted-mode browser flow.

What happens when called:

  1. The MCP server hits GET {registry}/v1/info to discover the auth URL.

  2. It binds a localhost HTTP listener and spawns the user's browser at the auth URL with a callback_port + state CSRF token.

  3. The user signs up or logs in on the website and the browser redirects to the local callback with an encrypted developer private key.

  4. The MCP decrypts (AES-256-GCM keyed on SHA-256(state)) and saves the keypair at ~/.zynd/developer.json — same path the zynd CLI uses, so CLI tools share state.

This tool is the prerequisite for zyndai_register_persona. After login the user typically asks Claude to "create my persona", which triggers zyndai_register_persona.

Args:

  • name (string, optional): suggested developer display name

  • force (bool, optional): overwrite an existing developer key

Errors:

  • "developer key already exists" — pass force:true to overwrite, or run zyndai_whoami to see who you're already logged in as.

  • "registry uses open onboarding" — the configured ZYNDAI_REGISTRY_URL doesn't support browser auth. Use a registry whose /v1/info reports developer_onboarding.mode = "restricted".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoOptional developer display name shown on the auth website. The user can also set or change it during the auth flow.
forceNoRe-run auth even if a developer keypair already exists at ~/.zynd/developer.json. Existing key is overwritten.

Tool Definition Quality

A4.3/5.0
Behavior5/5

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

Annotations are minimal (readOnlyHint=false, openWorldHint=true, etc.), but the description fully compensates by detailing the multi-step process: API call, listener binding, browser spawn, decryption, and file saving. It discloses side effects (e.g., writing to ~/.zynd/developer.json) and error conditions.

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?

The description is well-structured with clear sections (overview, numbered steps, Args, Errors). It is somewhat lengthy but each part serves a purpose. Front-loaded with the tool's action. Minor redundancy (e.g., parameter details repeated in schema and description).

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?

The description covers the login flow, dependencies, error states, and relationship to sibling tools. It lacks explicit mention of return value (no output schema), but error handling compensates. For a complex tool, it is largely complete.

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 baseline is 3. The description adds minimal extra context beyond the schema (e.g., 'suggested developer display name' vs. schema's 'Optional developer display name...'). No significant semantic enhancement.

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 explicitly states the tool's purpose: 'Onboard the user with Zynd via the registry's restricted-mode browser flow.' It details the step-by-step process and positions itself as the prerequisite for zyndai_register_persona, clearly distinguishing from sibling tools.

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?

The description provides clear context: it is the first step, typically followed by 'create my persona' invoking zyndai_register_persona. It also explains error handling (e.g., force overwrite, using zyndai_whoami). However, it does not explicitly list scenarios when not to use this tool or compare to all siblings.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/zyndai/mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server