Skip to main content
Glama
Sign In
zipviz-mcp

zipviz-mcp

Official
by ZipViz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

zipviz_sign_message

Sign a message locally with an agent's configured Ed25519 private key to produce a v=1 canonical-JSON envelope for /v1/verify, returning the base64 signature, timestamp, and signing_version.

Instructions

Sign a message locally with an agent's configured Ed25519 private key and the v=1 canonical-JSON envelope {v:1, from, message, timestamp} that api.zipviz.ai /v1/verify accepts. Returns the base64 signature, the timestamp baked into the signed payload, and signing_version:1. No network calls.

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": {
      "viz_domain": "<viz_domain>",
      "message": "<message>"
    },
    "name": "zipviz_sign_message"
  }
}

Input Schema

NameRequiredDescriptionDefault
messageYesThe message content to sign (UTF-8)
key_pathNoNOT PERMITTED. This tool always signs with the configured local agent key. Passing key_path is rejected — it would let a caller sign with any PEM the process can read.
timestampNoOptional ISO 8601 timestamp to bake into the signed payload. Defaults to `new Date().toISOString()` at sign time. Callers that need to send the timestamp alongside the signature (e.g. zipviz_send) should read it back from the return value.
viz_domainYesThe .viz domain that owns the signing key, e.g. claudais.smc.viz

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.1

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses that signing is local with the configured agent key, that there are no network calls, the canonical payload shape, and the exact return fields (base64 signature, timestamp, signing_version:1). It also explains the key_path rejection and the security reason behind it. Missing only failure behavior (unconfigured key/domain) and any permission prerequisites.

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?

Front-loaded with the action and key mechanism, followed by two short sentences covering the contract and the return shape. Every clause carries information; no filler or repetition of the tool name.

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?

With no output schema and no annotations, the description compensates fully: it documents the return values, the signing format, the local-only behavior, and the rejected parameter. An agent has everything needed to invoke this correctly and chain it into zipviz_send.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds genuine meaning beyond the schema by mapping the parameters onto the canonical envelope {v:1, from, message, timestamp} and explaining why the timestamp must be read back from the return value rather than re-supplied. That ties the parameters together semantically rather than restating them.

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?

Specific verb+resource ('Sign a message locally with an agent's configured Ed25519 private key') plus the exact envelope contract that api.zipviz.ai /v1/verify accepts. This clearly distinguishes it from siblings like zipviz_verify and zipviz_send without needing to open their schemas.

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?

States the operational context ('No network calls') and routes the follow-up case explicitly: callers that must send the timestamp alongside the signature, e.g. zipviz_send, should read it back from the return value. It stops short of naming a when-not condition or pointing to zipviz_verify as the counterpart, so it is clear context rather than full routing.

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