Skip to main content
Glama
Prismer-AI
by Prismer-AI

Ваш ИИ-агент только что вызвал инструмент. Можете ли вы доказать, что он сделал?

Большинство стеков агентов регистрируют действия постфактум, но никогда не проверяют, что было отправлено на самом деле. Если запрос был перехвачен, изменен или подделан, сторона выполнения не имеет возможности узнать об этом.

Signet решает эту проблему: каждый агент получает идентификатор Ed25519, каждый вызов инструмента подписывается, журнал аудита с хеш-цепочкой записывает все произошедшее, а клиенты или серверы могут проверить запрос перед тем, как доверять ему. 3 строки для подписи. 3 строки для проверки. Открытый исходный код.

Если Signet полезен для вас, поставьте звезду этому репозиторию, чтобы помочь другим командам найти его.

Начните с потока CLI ниже, чтобы увидеть подпись в действии, а затем перейдите к разделу «Увидеть отклонение плохих запросов», чтобы посмотреть, как сервер блокирует неподписанные, измененные, устаревшие или нецелевые запросы перед их выполнением.

Почему Signet

Signet добавляет легкий уровень доверия для действий агентов:

  • Подписывайте каждый вызов инструмента криптографическим ключом агента

  • Аудируйте произошедшее с помощью локального журнала с хеш-цепочкой, доступного только для добавления

  • Проверяйте любую квитанцию действия офлайн, сеть не требуется

  • Интегрируйте с Claude Code, Codex CLI, клиентами и серверами MCP, фреймворками Python и Vercel AI SDK

Related MCP server: agent-services-mcp

Попробуйте за 30 секунд

pip install signet-auth
from signet_auth import SigningAgent

agent = SigningAgent.create("my-agent", owner="team")
receipt = agent.sign("github_create_issue", params={"title": "fix bug"})

assert agent.verify(receipt)
print(receipt.id)

Если вы новичок, начните с одного из этих четырех путей:

Выберите свой путь

  • Claude Code: Лучший выбор для быстрого запуска в агенте кодирования. Выполните /plugin install signet@claude-plugins-official в Claude Code. Через 5 минут у вас будут подписанные вызовы инструментов и локальный журнал аудита в ~/.signet/audit/.

  • Codex CLI: Лучший выбор для подписи вызовов Bash в Codex. Скопируйте plugins/codex/ в ~/.codex/plugins/signet и добавьте один хук PostToolUse. Через 5 минут у вас будут подписанные действия Bash в Codex с использованием того же аудиторского следа.

  • Клиенты MCP: Лучший выбор, если вы управляете клиентом или транспортом MCP. Оберните свой транспорт с помощью new SigningTransport(inner, secretKey, "my-agent"). Через 5 минут у вас будут подписанные запросы tools/call с квитанциями в params._meta._signet.

  • Серверы MCP: Лучший выбор, если вы хотите проверку перед выполнением. Вызовите verifyRequest(request, {...}) в обработчике вашего инструмента. Через 5 минут у вас будут проверки подписи, актуальности, привязки к цели и инструмента/параметров на границе выполнения.

Увидеть отклонение плохих запросов

Запустите краткую демонстрацию границы выполнения:

cd examples/mcp-agent
npm run execution-boundary-demo

См. examples/mcp-agent/demo-execution-boundary.mjs для получения исходного кода демонстрации.

Когда команды обращаются к Signet

  • Вам нужен аудиторский след для агентов кодирования, инструментов MCP или CI-автоматизации

  • Вы хотите доказать, какой агент запросил действие после инцидента

  • Вам нужны квитанции, которые можно проверить офлайн без зависимости от хостингового сервиса

  • Вы хотите иметь доказательства вызова инструментов с подписью, не добавляя прокси или шлюз в свой стек

Что такое Signet и чем он не является

  • Signet — это уровень аттестации для действий агентов: подпись, аудит и проверка

  • Signet — это решение, разработанное для встраивания в существующие стеки агентов с помощью SDK, плагинов и промежуточного ПО MCP

  • Signet — это не механизм политик, брандмауэр или блокировщик действий

  • Signet — это не замена шлюзам; он дополняет инструменты предотвращения и обеспечения соблюдения

Установка

# CLI
cargo install signet-cli

# Python
pip install signet-auth

# TypeScript (MCP middleware)
npm install @signet-auth/core @signet-auth/mcp

# TypeScript (MCP server verification)
npm install @signet-auth/mcp-server

# TypeScript (Vercel AI SDK middleware)
npm install @signet-auth/vercel-ai

Быстрый старт

Плагин Claude Code

Автоматически подписывайте каждый вызов инструмента в Claude Code без настройки:

# Option A: From the official Anthropic plugin marketplace
/plugin install signet@claude-plugins-official

# Option B: Add Signet as a marketplace source, then install
/plugin marketplace add Prismer-AI/signet
/plugin install signet@signet

Каждый вызов инструмента подписывается с помощью Ed25519 и записывается в журнал аудита с хеш-цепочкой в ~/.signet/audit/.

Альтернативные методы установки:

# From Git
claude plugin add --from https://github.com/Prismer-AI/signet

# Via signet CLI
signet claude install

Плагин Codex

Автоматически подписывайте каждый вызов инструмента Bash в Codex CLI:

git clone https://github.com/Prismer-AI/signet.git
cp -r signet/plugins/codex ~/.codex/plugins/signet

Затем добавьте хук в ~/.codex/hooks.json:

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "node \"$HOME/.codex/plugins/signet/bin/sign.cjs\"",
        "timeout": 5
      }]
    }]
  }
}

Или используйте сервер MCP для инструментов подписи по требованию:

codex mcp add signet -- npx @signet-auth/mcp-tools

CLI

# Generate an agent identity
signet identity generate --name my-agent

# Sign an action
signet sign --key my-agent --tool "github_create_issue" \
  --params '{"title":"fix bug"}' --target mcp://github.local

# Verify a receipt
signet verify receipt.json --pubkey my-agent

# Audit recent actions
signet audit --since 24h

# Verify log integrity
signet verify --chain

Интеграция с клиентом MCP (TypeScript)

import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StdioClientTransport } from "@modelcontextprotocol/sdk/client/stdio.js";
import { generateKeypair } from "@signet-auth/core";
import { SigningTransport } from "@signet-auth/mcp";

// Generate an agent identity
const { secretKey } = generateKeypair();

// Wrap any MCP transport -- all tool calls are now signed
const inner = new StdioClientTransport({ command: "my-mcp-server" });
const transport = new SigningTransport(inner, secretKey, "my-agent");

const client = new Client({ name: "my-agent", version: "1.0" }, {});
await client.connect(transport);

// Every callTool() is now cryptographically signed
const result = await client.callTool({
  name: "echo",
  arguments: { message: "Hello!" },
});

В каждый запрос tools/call внедряется подписанная квитанция в params._meta._signet.

Проверка сервера MCP

Если вы также управляете сервером MCP, проверяйте запросы перед выполнением:

import { verifyRequest } from "@signet-auth/mcp-server";

server.setRequestHandler(CallToolRequestSchema, async (request) => {
  const verified = verifyRequest(request, {
    trustedKeys: ["ed25519:..."],
    maxAge: 300,
  });
  if (!verified.ok) return { content: [{ type: "text", text: verified.error }], isError: true };
  console.log(`Verified: ${verified.signerName}`);
  // process tool call...
});

Интеграция с Vercel AI SDK

import { generateText } from "ai";
import { generateKeypair } from "@signet-auth/core";
import { createSignetCallbacks } from "@signet-auth/vercel-ai";

const { secretKey } = generateKeypair();
const callbacks = createSignetCallbacks(secretKey, "my-agent");

const result = await generateText({
  model: openai("gpt-4"),
  tools: { myTool },
  ...callbacks,
  prompt: "...",
});

// Every tool call is now signed
console.log(callbacks.receipts);

Эталонный сервер MCP

Этот репозиторий также включает минимальный эталонный сервер MCP, который демонстрирует проверку на стороне сервера с помощью @signet-auth/mcp-server.

cd examples/mcp-agent
npm ci
npm run verifier-server

Доступные инструменты:

  • inspect_current_request — проверяет текущий вызов инструмента MCP, если он включает params._meta._signet

  • verify_receipt — проверяет необработанную квитанцию Signet с помощью открытого ключа

  • verify_request_payload — проверяет синтетическую полезную нагрузку tools/call MCP офлайн

Переменные окружения:

  • SIGNET_TRUSTED_KEYS — открытые ключи ed25519:<base64>, разделенные запятыми

  • SIGNET_REQUIRE_SIGNATUREtrue или false (по умолчанию false)

  • SIGNET_MAX_AGE — максимальный возраст квитанции в секундах (по умолчанию 300)

  • SIGNET_EXPECTED_TARGET — необязательная ожидаемая цель receipt.action.target

Автономный сервер подписи MCP

@signet-auth/mcp-tools предоставляет подпись, проверку и хеширование контента Signet в качестве инструментов MCP — подключайтесь к любому клиенту, совместимому с MCP:

npx @signet-auth/mcp-tools

Доступные инструменты: signet_generate_keypair, signet_sign, signet_verify, signet_content_hash.

Python (LangChain / CrewAI / AutoGen + еще 6)

pip install signet-auth
from signet_auth import SigningAgent

# Create an agent identity (saved to ~/.signet/keys/)
agent = SigningAgent.create("my-agent", owner="willamhou")

# Sign any tool call -- receipt is auto-appended to audit log
receipt = agent.sign("github_create_issue", params={"title": "fix bug"})

# Verify
assert agent.verify(receipt)

# Query audit log
for record in agent.audit_query(since="24h"):
    print(f"{record.receipt.ts} {record.receipt.action.tool}")

Интеграция с LangChain

from signet_auth import SigningAgent
from signet_auth.langchain import SignetCallbackHandler

agent = SigningAgent("my-agent")
handler = SignetCallbackHandler(agent)

# Every tool call is now signed + audited
chain.invoke(input, config={"callbacks": [handler]})

# Async chains supported too
from signet_auth.langchain import AsyncSignetCallbackHandler

Интеграция с CrewAI

from signet_auth import SigningAgent
from signet_auth.crewai import install_hooks

agent = SigningAgent("my-agent")
install_hooks(agent)

# All CrewAI tool calls are now globally signed
crew.kickoff()

Интеграция с AutoGen

from signet_auth import SigningAgent
from signet_auth.autogen import signed_tool, sign_tools

agent = SigningAgent("my-agent")

# Wrap a single tool
wrapped = signed_tool(tool, agent)

# Or wrap all tools at once
wrapped_tools = sign_tools([tool1, tool2], agent)

Интеграция с LangGraph

LangGraph использует систему обратных вызовов LangChain — тот же обработчик работает напрямую:

from signet_auth import SigningAgent
from signet_auth.langgraph import SignetCallbackHandler

agent = SigningAgent("my-agent")
handler = SignetCallbackHandler(agent)

result = graph.invoke(input, config={"callbacks": [handler]})

Интеграция с LlamaIndex

from signet_auth import SigningAgent
from signet_auth.llamaindex import install_handler

agent = SigningAgent("my-agent")
handler = install_handler(agent)

# All tool call events are now signed
index = ... # your LlamaIndex setup
response = index.as_query_engine().query("What is Signet?")

# Access receipts
print(handler.receipts)

Интеграция с Pydantic AI

from signet_auth import SigningAgent
from signet_auth.pydantic_ai_integration import SignetMiddleware

agent = SigningAgent("my-agent")
middleware = SignetMiddleware(agent)

@middleware.wrap
def my_tool(query: str) -> str:
    return f"result: {query}"

Интеграция с Google ADK

from signet_auth import SigningAgent
from signet_auth.google_adk import SignetPlugin

agent = SigningAgent("my-agent")
plugin = SignetPlugin(agent)

# Pass as callback to ADK agent

Интеграция с Smolagents

from signet_auth import SigningAgent
from signet_auth.smolagents import signet_step_callback

agent = SigningAgent("my-agent")
callback = signet_step_callback(agent)

bot = CodeAgent(tools=[...], model=model, step_callbacks=[callback])

Интеграция с OpenAI Agents SDK

from signet_auth import SigningAgent
from signet_auth.openai_agents import SignetAgentHooks

agent = SigningAgent("my-agent")

oai_agent = Agent(
    name="assistant",
    hooks=SignetAgentHooks(agent),
    tools=[...],
)

Примечание: Аргументы вызова инструмента пока недоступны в API хуков (issue #939). Подписывается только имя инструмента.

Низкоуровневый API

from signet_auth import generate_keypair, sign, verify, Action

kp = generate_keypair()
action = Action("github_create_issue", params={"title": "fix bug"})
receipt = sign(kp.secret_key, action, "my-agent", "willamhou")
assert verify(receipt, kp.public_key)

Двусторонняя квитанция (совместная подпись сервера)

from signet_auth import generate_keypair, sign, sign_bilateral, verify_bilateral, Action

# Agent signs the tool call
agent_kp = generate_keypair()
action = Action("github_create_issue", params={"title": "fix bug"})
agent_receipt = sign(agent_kp.secret_key, action, "my-agent")

# Server co-signs with the response
server_kp = generate_keypair()
bilateral = sign_bilateral(
    server_kp.secret_key, agent_receipt,
    {"content": [{"type": "text", "text": "issue #42 created"}]},
    "github-server",
)
assert verify_bilateral(bilateral, server_kp.public_key)
assert bilateral.v == 3  # v3 = bilateral receipt

Как это работает

Your Agent
    |
    v
SigningTransport (wraps any MCP transport)
    |
    +---> Signs each tool call (Ed25519)
    +---> Appends Action Receipt to local audit log (hash-chained)
    +---> Forwards request to MCP server (unchanged)

Только на стороне агента. Серверы MCP менять не нужно.

Квитанция действия

Каждый вызов инструмента создает подписанную квитанцию:

{
  "v": 1,
  "id": "rec_e7039e7e7714e84f...",
  "action": {
    "tool": "github_create_issue",
    "params": {"title": "fix bug"},
    "params_hash": "sha256:b878192252cb...",
    "target": "mcp://github.local",
    "transport": "stdio"
  },
  "signer": {
    "pubkey": "ed25519:0CRkURt/tc6r...",
    "name": "demo-bot",
    "owner": "willamhou"
  },
  "ts": "2026-03-29T23:24:03.309Z",
  "nonce": "rnd_dcd4e135799393...",
  "sig": "ed25519:6KUohbnSmehP..."
}

Подпись охватывает все тело квитанции (действие + подписывающий + метка времени + одноразовый номер) с использованием канонического JSON RFC 8785 (JCS). Изменение любого поля делает подпись недействительной.

Команды CLI

Команда

Описание

signet identity generate --name <n>

Генерировать идентификатор Ed25519 (по умолчанию зашифрован)

signet identity generate --unencrypted

Генерировать без шифрования (для CI)

signet identity list

Список всех идентификаторов

signet identity export --name <n>

Экспортировать открытый ключ в формате JSON

signet sign --key <n> --tool <t> --params <json> --target <uri>

Подписать действие

signet sign --hash-only

Available Tools

4 tools
signet_content_hashA

Compute SHA-256 hash of canonical JSON (RFC 8785 JCS). Accepts any JSON value.

ParametersJSON Schema
NameRequiredDescriptionDefault
contentYesJSON content to hash (object, array, string, number, boolean, or null)

TDQS

A4/5.0
Behavior4/5

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

No annotations are provided, so the description carries full burden. It transparently states the computation (SHA-256 hash) and the canonicalization method (RFC 8785 JCS). It discloses no side effects or permissions needed, which is acceptable for a pure computation tool. However, it could mention that the output is a hex-encoded string.

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 extremely concise, consisting of two sentences. It front-loads the action ('Compute SHA-256 hash') and the specification ('RFC 8785 JCS'). Every word contributes meaningfully without redundancy.

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?

Given the low complexity (1 parameter, no nested objects, no output schema), the description is mostly complete. It covers the input and the core operation. However, it could mention that the return value is a hex-encoded hash string, as this is not obvious from the description alone.

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?

The input schema has 100% description coverage, so the baseline is 3. The description adds 'any JSON value' which is already in the schema's parameter description. No additional semantics are provided beyond what the schema already conveys.

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 clearly states 'Compute SHA-256 hash of canonical JSON (RFC 8785 JCS). Accepts any JSON value.' It specifies the algorithm (SHA-256), the canonicalization standard (JCS), and the accepted input types. This distinctly sets it apart from sibling tools like signet_sign and signet_verify.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

While the tool's purpose is clear, the description does not provide guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or contexts where hashing is preferred over signing/verification. Usage is implied but not explicitly guided.

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

signet_generate_keypairA

Generate a new Ed25519 keypair. Returns only the public key. Use Signet CLI to manage secret keys securely.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.6/5.0
Behavior5/5

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

Discloses that the secret key is not returned and points to CLI for secure management, providing critical behavioral context beyond the schema. No annotations present, so description carries full burden.

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?

Two concise sentences with no redundancy, front-loading the key action and outcome.

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?

Covers purpose and output limitation. Lacks detail on public key format or usage, but adequate for a simple key generation tool with no output schema.

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?

No parameters exist in schema; description adds no parameter info but baseline is 4 for zero-parameter tools. Sufficient for the tool's simplicity.

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?

Clearly states 'Generate a new Ed25519 keypair' and specifies it returns only the public key, distinguishing it from siblings like sign, verify, and content_hash.

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?

Explicitly advises using Signet CLI for secret key management, giving implicit guidance on when not to use this tool. Lacks explicit alternatives but context is clear.

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

signet_signA

Sign an action (tool call) with an Ed25519 key, producing a cryptographic receipt. Uses SIGNET_SECRET_KEY env var if set, otherwise requires secret_key argument.

ParametersJSON Schema
NameRequiredDescriptionDefault
secret_keyNoBase64 secret key (optional if SIGNET_SECRET_KEY env is set)
toolYesTool name being called
paramsNoTool parameters (any JSON value)
signer_nameYesAgent name
signer_ownerNoAgent owner (optional)
targetNoTarget MCP server URI

TDQS

A3.7/5.0
Behavior2/5

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

No annotations are provided, so the description must cover behavioral traits. It mentions key sources but omits edge cases (e.g., both env and arg provided), error behavior, and the receipt format, leaving significant gaps.

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?

Single sentence, front-loaded with verb and resource, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 6 parameters and no output schema, the description explains the signing action but omits the return value (cryptographic receipt structure), which is needed for a complete understanding.

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% (baseline 3). The description adds value by explaining the secret_key's optionality via env var fallback, which is not fully captured in the schema description alone.

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 uses a specific verb 'Sign' and resource 'action (tool call)' with Ed25519 key, clearly distinguishing it from sibling tools like verification or key generation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains two key sourcing methods (env var vs argument) but lacks explicit guidance on when to use signing versus other tools or prerequisites like key availability.

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

signet_verifyA

Verify a Signet receipt signature. Returns {valid: true/false}. Accepts both bare base64 and ed25519:-prefixed public keys.

ParametersJSON Schema
NameRequiredDescriptionDefault
receipt_jsonYesReceipt JSON string
public_keyYesPublic key (base64 or ed25519:base64)

TDQS

A4.2/5.0
Behavior4/5

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

Despite lacking annotations, the description discloses the return format and key format flexibility, providing sufficient behavioral context for a read-only verification operation.

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 succinct, with two sentences that front-load the primary purpose and add key detail without unnecessary words.

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?

For a simple verification tool with no output schema, the description covers the return structure and key parameter details, making it sufficiently complete for agent use.

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?

The input schema has 100% description coverage for both parameters, and the description adds value by explaining the accepted public key formats (bare base64 or ed25519:base64), enriching the schema's simple type definition.

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 clearly states the tool verifies a Signet receipt signature, explicitly lists the return value as {valid: true/false}, and specifies accepted key formats, distinguishing it from sibling tools that deal with content hashing, key generation, and signing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for verifying signatures but does not provide explicit guidance on when to use this tool vs siblings, nor does it mention prerequisites or error conditions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv0.10.0
    • Addedsignet_content_hash
    • Addedsignet_generate_keypair
    • Addedsignet_sign
    • Addedsignet_verify

TDQS

A4.2/5.0

Scored across 4 tools

Disambiguation5/5

Each tool performs a distinct cryptographic operation: hashing, key generation, signing, and verification. No overlap in purpose reduces ambiguity.

Naming Consistency4/5

Tools follow a 'signet_' prefix pattern. Most use verb_noun (generate_keypair, sign, verify), but 'content_hash' is noun_noun. Minor inconsistency but still clear.

Tool Count5/5

Four tools is well-scoped for a cryptographic signing server. Each tool is essential, covering the core workflow without bloat.

Completeness5/5

The tool set covers the full signing lifecycle: input representation (hash), key generation, signing, and verification. No obvious gaps for the stated purpose.

Maintenance

ActivityMaintained
ResponsivenessWithin a week

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    D
    maintenance
    MCP server for AI agent identity — verify agents with Ed25519 signatures, check trust scores, sign and verify content, exchange encrypted messages. Built on the Agent Identity Protocol (AIP).
    8
    MIT
  • A
    license
    A
    quality
    F
    maintenance
    A thin MCP server that wraps provenance-receipts and quality-gate services as tools, enabling AI agents to certify content origin and score quality via Ed25519-signed receipts.
    5
    55 npm
    MIT
  • A
    license
    Not graded
    quality
    C
    maintenance
    Local MCP server that signs and records agent actions into a tamper-evident log using Ed25519 keys for frictionless integration with Touchstone.
    24 npm
    Apache 2.0
  • A
    license
    Not graded
    quality
    C
    maintenance
    A sovereign, MIT-licensed MCP server for professional-service workflows, providing offline-capable, Ed25519-signed tools for autonomous agents and human developers.
    MIT