signet
AI 에이전트가 도구를 호출했습니다. 무엇을 했는지 증명할 수 있나요?
대부분의 에이전트 스택은 사후에 작업을 기록하지만 실제로 무엇이 전송되었는지는 검증하지 않습니다. 요청이 재전송되거나, 변조되거나, 위조된 경우 실행 측에서는 이를 알 방법이 없습니다.
Signet은 이를 해결합니다. 각 에이전트는 Ed25519 ID를 부여받고, 모든 도구 호출은 서명되며, 해시 체인으로 연결된 감사 로그가 기록됩니다. 클라이언트나 서버는 신뢰하기 전에 요청을 검증할 수 있습니다. 서명에 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-authfrom 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: 코딩 에이전트에서 가장 빠르게 실행해 볼 수 있습니다. Claude Code에서
/plugin install signet@claude-plugins-official을 실행하세요. 5분 안에 서명된 도구 호출과~/.signet/audit/에 저장된 로컬 감사 로그를 갖게 됩니다.Codex CLI: Codex에서 Bash 도구 호출을 서명하는 데 가장 좋습니다.
plugins/codex/를~/.codex/plugins/signet으로 복사하고PostToolUse훅을 하나 추가하세요. 5분 안에 동일한 감사 추적을 사용하여 Codex에서 서명된 Bash 작업을 수행할 수 있습니다.MCP 클라이언트: MCP 클라이언트나 전송을 제어하는 경우 가장 좋습니다.
new SigningTransport(inner, secretKey, "my-agent")로 전송을 래핑하세요. 5분 안에params._meta._signet에 영수증이 포함된 서명된tools/call요청을 갖게 됩니다.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 installCodex 플러그인
Codex CLI에서 모든 Bash 도구 호출을 자동 서명하세요:
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-toolsCLI
# 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 --chainMCP 클라이언트 통합 (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 서버
이 저장소에는 @signet-auth/mcp-server를 사용한 서버 측 검증을 보여주는 최소한의 MCP 참조 서버가 포함되어 있습니다.
cd examples/mcp-agent
npm ci
npm run verifier-server사용 가능한 도구:
inspect_current_request—params._meta._signet이 포함된 경우 현재 MCP 도구 호출을 검증합니다verify_receipt— 공개 키에 대해 원시 Signet 영수증을 검증합니다verify_request_payload— 오프라인에서 합성 MCPtools/call페이로드를 검증합니다
환경 변수:
SIGNET_TRUSTED_KEYS— 쉼표로 구분된ed25519:<base64>공개 키SIGNET_REQUIRE_SIGNATURE—true또는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-authfrom 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 AsyncSignetCallbackHandlerCrewAI 통합
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 agentSmolagents 통합
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에서 사용할 수 없습니다 (이슈 #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..."
}서명은 RFC 8785 (JCS) 정규 JSON을 사용하여 전체 영수증 본문(작업 + 서명자 + 타임스탬프 + 논스)을 포함합니다. 필드를 수정하면 서명이 무효화됩니다.
CLI 명령어
명령어 | 설명 |
| Ed25519 ID 생성 (기본적으로 암호화됨) |
| 암호화 없이 생성 (CI용) |
| 모든 ID 나열 |
| 공개 키를 JSON으로 내보내기 |
| 작업 서명 |
| 매개변수 해시만 저장 (원시 매개변수 제외) |
| stdout 대신 파일에 영수증 쓰기 |
| 감사 로그 추가 건너뛰기 |
`signet verify |
Available Tools
4 toolssignet_content_hashA
Compute SHA-256 hash of canonical JSON (RFC 8785 JCS). Accepts any JSON value.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | JSON content to hash (object, array, string, number, boolean, or null) |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| secret_key | No | Base64 secret key (optional if SIGNET_SECRET_KEY env is set) | |
| tool | Yes | Tool name being called | |
| params | No | Tool parameters (any JSON value) | |
| signer_name | Yes | Agent name | |
| signer_owner | No | Agent owner (optional) | |
| target | No | Target MCP server URI |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| receipt_json | Yes | Receipt JSON string | |
| public_key | Yes | Public key (base64 or ed25519:base64) |
TDQS
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.
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.
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.
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.
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.
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.
4 tool updates
v0.10.0- Added
signet_content_hash - Added
signet_generate_keypair - Added
signet_sign - Added
signet_verify
TDQS
Scored across 4 tools
Each tool performs a distinct cryptographic operation: hashing, key generation, signing, and verification. No overlap in purpose reduces ambiguity.
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.
Four tools is well-scoped for a cryptographic signing server. Each tool is essential, covering the core workflow without bloat.
The tool set covers the full signing lifecycle: input representation (hash), key generation, signing, and verification. No obvious gaps for the stated purpose.
Maintenance
Related MCP Connectors
MCP server for mandates, delegation, policy-gated execution, credential grants, and audit.
Tamper-evident proof creation and verification for AI agents via MCP, A2A, and REST.
Production-grade cryptography toolkit with 31 MCP tools for classical, PQC, and KMS workflows.
Self-hosted MCP server: 26 deterministic dev, security, and EVM tools.
Related MCP Servers
- AlicenseAqualityDmaintenanceMCP 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).8MIT
- AlicenseAqualityFmaintenanceA 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.555 npmMIT

touchstone-mcpofficial
AlicenseNot gradedqualityCmaintenanceLocal MCP server that signs and records agent actions into a tamper-evident log using Ed25519 keys for frictionless integration with Touchstone.24 npmApache 2.0- AlicenseNot gradedqualityCmaintenanceA sovereign, MIT-licensed MCP server for professional-service workflows, providing offline-capable, Ed25519-signed tools for autonomous agents and human developers.MIT