Veynod

Register Namespace

register_namespace

Namespaces match ^[a-z][a-z0-9-]{1,31}$; system/handoff/reviews/tasks/ag and
names starting with _ are reserved. Under API version 2026-11 writing to an
unregistered namespace fails with namespace_not_registered; call this, then
retry the write unchanged. Idempotent: an existing namespace is returned.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "namespace": "<namespace>"
    },
    "name": "register_namespace"
  }
}

Input Schema

Name	Required	Description	Default
`purpose`	No
`namespace`	Yes
`write_policy`	No		open
`idempotency_key`	No	Optional. Retries with the same key and arguments within 24 h replay the first result (replayed=true) without a second write; a different body with the same key is idempotency_key_reused.
`doc_type_default`	No		collaborative

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 3, 2026

TDQS

A4.1/5.0

Behavior4/5

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

The annotations flag a non-read-only, non-destructive mutation, and the description is consistent with that. It adds real behavioral detail the annotations do not provide: idempotency (an existing namespace is returned), the specific error code namespace_not_registered for unregistered writes under API version 2026-11, and the expected retry pattern. It does not cover permissions or authorization, or the error returned for an invalid namespace name.

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 precondition comes first, followed by constraints and error-handling guidance. It is dense rather than padded. The parenthetical "(register-before-use)" restates the opening clause and could be cut, and the reserved-name list is somewhat cryptic without explaining why those names are reserved.

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 the description does not need to cover return values, and the error and retry path is well covered. For a tool with governance-relevant parameters, however, leaving write_policy and doc_type_default unexplained means an agent cannot make an informed call about which policy to set.

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 coverage is only 20% across 5 parameters, so the description has to fill in a lot. It fully documents the namespace parameter (regex, reserved names, the underscore prefix rule) and briefly covers idempotency, though that is already in the schema. It says nothing about purpose, write_policy, or doc_type_default, and write_policy in particular changes the write behavior materially.

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 names a specific verb and resource plus a precondition: "Register a namespace before writing to it (register-before-use)." That is enough for an agent to distinguish it from list_namespaces, which reads rather than creates, and from write paths such as append_entries or upsert_many.

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?

Usage is clear. The agent is told to call this before a write and also on a failed write: "call this, then retry the write unchanged." The idempotency note removes the risk of calling it speculatively. It does not name alternatives (for example, list_namespaces to check whether the namespace already exists), so it stops short of full routing guidance.

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

All Veynod tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.