AgentVeil Protocol
This server exposes AgentVeil Protocol tools for discovering and vetting AI agents, managing reputation and attestations, verifying audit integrity, and controlling high-risk actions through Runtime Gate approvals.
Look up agent profiles by DID and search agents by capability, provider, or minimum reputation.
Check trust decisions and detailed reputation scores, tiers, risk factors, and confidence.
View peer attestations and network-wide protocol statistics.
Register a local agent, publish/update its capability card, and inspect your own agent identity.
Submit cryptographically signed, immutable peer ratings for other agents.
Inspect an agent’s audit trail and verify the tamper-evident SHA-256 audit chain.
Evaluate proposed actions with Runtime Gate to get ALLOW, human-approval, or BLOCK decisions.
Run controlled actions and fetch/approve/deny pending human approval requests.
Resume approved actions and retrieve signed decision and execution receipts.
AgentVeil
Stop risky AI agent actions. Not the work.
Independent AI agent security. On configured routes, AgentVeil checks supported actions and applies policy: allow, request approval, provide redirect guidance to a controlled path, or block. Safe alternatives require an available controlled path. Works with Cursor, Claude Code, Codex, Gemini CLI, Hermes CLI, and MCP tools.
Quick Start · Console · The Loop · Connectors · Evidence · Scope · Design Basis · Docs
pip install agentveil-mcp-proxyPackages: agentveil-mcp-proxy · agentveil | Website: agentveil.dev | Console: agentveil.dev/console (early access) | Plans: agentveil.dev/#pricing | Package source: packages/agentveil-mcp-proxy/
Agent action boundary: AI runtimes execute agents. AgentVeil mediates configured action paths around them. When a native or risky action hits the boundary, AgentVeil decides allow, approval required, redirect guidance toward a controlled path, or hard-block. Routed MCP calls follow the same decision model and record bounded local evidence.
AgentVeil is not machine-wide control. Actions outside configured AgentVeil boundaries are not classified or logged.
Visual overview: request → AgentVeil boundary → redirect / approval / hard-block → local proof.
Data handling: AgentVeil is designed to keep raw MCP arguments local by default and to record bounded metadata and hashes for evidence. See Data Handling.
The AgentVeil Loop
AgentVeil is one product loop, not a pile of separate components:
Step | What happens |
Attempt | Agent tries a native mutation or routed MCP action in a configured project |
Decision | AgentVeil returns allow, approval required, redirect, or hard-block |
Controlled path | When one is available, redirect guidance tells the agent to retry through the managed MCP route |
Proof | Bounded local evidence records the decision; inspect it with |
Approval fixes actions that need human review. Redirect tells the agent to retry through the controlled MCP route when one is available. Hard-block means approval will not help for that action. Local proof is available now through the CLI. Console summaries complement those local records; they do not replace local evidence export or offline verification.
Related MCP server: BasedAgents
What AgentVeil Adds
AgentVeil is not an AI agent and does not replace an agent runtime. It adds a control layer around actions that are configured to pass through AgentVeil.
Layer | Agent runtime / framework | AgentVeil adds |
Execution | Runs the agent and exposes tools | Mediates configured action paths before execution |
Approval | May prompt per tool call, depending on runtime | Adds policy-aware approval for routed writes and mutations |
Risk classification | Runtime-specific, if present | Shared read / write / destructive / unknown classification |
Sandbox boundary | Runtime-specific | Project or downstream sandbox limits for routed actions |
Evidence | Usually chat or runtime logs | Bounded local records with request ids, decisions, and hashes |
Cross-runtime consistency | Per runtime | Same core control semantics where actions are routed through AgentVeil |
Quick Start
Use AgentVeil with a supported project connector, or run the Core MCP Proxy directly.
Start from the Console
Access: AgentVeil Solo is available through a free trial and a paid subscription. See plans and access terms. The public SDK and MCP Proxy are software components distributed under their respective licenses.
Sign in at agentveil.dev/console/auth (early access) with GitHub or Google, pick your agent, and run the command the Console shows. The same commands are listed below for each connector.
When you run a connector's setup command, AgentVeil opens the Console in your
browser so you can approve this machine. The Console then shows what your
connected projects report: project connection status, decision summaries and
approval summaries. Raw prompts, source code and file contents stay on your
machine in this connector-summary flow. This is not a blanket statement about
content supplied to hosted SDK/API workflows; see Data Handling.
Local connector and proxy control do not require Console pairing; backend-backed
SDK and Runtime Gate workflows have their own service requirements.
Successful connector setup and explicit status checks can also attempt browser pairing and, for an eligible Console workspace, download and install an additional local provider package. Availability depends on the workspace capability and provider checks; installing the public proxy alone does not grant that capability. See the package's Console scope for the distinction between pairing, reporting, and provider installation.
If the browser did not open (for example on a headless machine) or you closed it, connect later:
agentveil-mcp-proxy loginlogin prints a verification URL and a short code (--no-open for headless
use); agentveil-mcp-proxy logout disconnects this machine. See
Connect To AgentVeil Console
for the exact scope.
Cursor project connector
pip install agentveil-mcp-proxy
agentveil-mcp-proxy setup cursor --choose-folderChoose the project folder you want to protect, then reopen / reload Cursor for that project.
After setup, in the configured project:
supported native risky agent actions can be blocked before execution;
the agent receives redirect guidance toward the AgentVeil MCP route;
routed MCP writes can require approval;
AgentVeil records bounded local evidence for decisions and outcomes.
Some Cursor versions may require enabling the managed agentveil-mcp-proxy MCP server once in Tools & MCPs after reload.
Claude Code project connector
pip install agentveil-mcp-proxy
agentveil-mcp-proxy setup claude-code --choose-folder --yesChoose the project folder you want to protect, then reopen / reload Claude Code for that project.
After setup, in the configured project:
supported native Claude Code mutation tools are checked by a project-local hook;
risky native mutations are blocked with redirect guidance toward the controlled MCP route;
AgentVeil MCP writes go through the proxy approval path;
bounded evidence is written locally.
Codex project connector
pip install agentveil-mcp-proxy
agentveil-mcp-proxy setup codex --choose-folder --yesChoose the project folder you want to protect, then open / restart Codex for
that project. Codex asks you to trust the AgentVeil project hook once; until
the hook fires and evidence is observed, setup status --client codex remains
advisory, not protected.
After setup and hook trust, in the configured project:
supported native Codex mutation tools are checked by a project-local hook;
risky native mutations are blocked with redirect guidance toward the controlled MCP route;
AgentVeil MCP writes go through the proxy approval path;
bounded evidence is written locally.
Gemini CLI project connector
pip install agentveil-mcp-proxy
agentveil-mcp-proxy setup gemini-cli --choose-folder --yesChoose the project folder you want to protect, then open / restart Gemini CLI for that project. Gemini CLI asks you to trust the project folder before it loads local settings, hooks, and MCP servers.
After setup and folder trust, in the configured project:
supported native Gemini CLI mutation tools are checked by a project-local hook;
risky native mutations are blocked with redirect guidance toward the controlled MCP route;
AgentVeil MCP writes go through the proxy approval path;
bounded evidence is written locally.
Hermes CLI controlled MCP profile
Hermes CLI is launched through AgentVeil rather than installed as a persistent project hook:
pip install agentveil-mcp-proxy
agentveil-mcp-proxy launch --profile hermes-cli --choose-folder -- \
hermes chat -q "Create a project note"The launcher configures a project-local Hermes home, routes Hermes to the AgentVeil MCP tools, and keeps local proof/evidence in the selected project.
In this profile:
Hermes project work is routed through the AgentVeil MCP route;
routed reads, writes, approval, sandbox boundaries, redirect guidance, and local proof use the shared AgentVeil control layer;
native Hermes tools are limited by profile settings, but AgentVeil does not claim host-wide control of Hermes or the machine.
Core MCP Proxy path
For lower-level MCP routing without an IDE connector (an alternative to the connector setup above, not an additional required step after connector setup):
pip install agentveil-mcp-proxy
agentveil-mcp-proxy init --quickstart-filesystem ./sandbox
agentveil-mcp-proxy doctor --full
agentveil-mcp-proxy runThis starts the core route: MCP tool calls explicitly pointed at agentveil-mcp-proxy.
For manual identity registration, backend readiness and signer-pinned offline
verification, follow the Core MCP Proxy quickstart.
Verify your setup works
After installing a project connector, walk the current shipped path in that project:
Ask the agent to read project context. Routed reads such as
list_workspace,read_file,get_file_info, andinstruction_surface_statusshould allow.Ask the agent to create or edit a file, for example:
Create avp-test.txt with the text helloThe configured connector should stop the native mutation with redirect guidance; the agent should then use the controlled MCP route, where risky writes require approval. 3. Open the approval page when prompted and review the bounded proof details. 4. Inspect local proof from the CLI:
agentveil-mcp-proxy events show --lastThe default human output should include lines like
decision=approval_required and tool=write_file without dumping raw JSON.
Use --json when you need structured fields.
Connectors Available Today
AgentVeil is built around action-control boundaries. Cursor, Claude Code, Codex, and Gemini CLI are supported project hook connectors. Hermes CLI is available as a controlled MCP launch profile. The Core MCP Proxy is runtime-agnostic for MCP clients that are explicitly configured to call it.
Surface | Mechanism | What it adds | Status |
Cursor project connector | Project-local hooks + MCP route | Native mutation block + redirect guidance, routed MCP approval/evidence | Available |
Claude Code project connector | Project-local | Native mutation block + redirect guidance, routed MCP approval/evidence | Available |
Codex project connector | Project-local | Native mutation block after one-time hook trust, redirect guidance, routed MCP approval/evidence | Available |
Gemini CLI project connector | Project-local | Native mutation block after one-time folder trust, redirect guidance, routed MCP approval/evidence | Available |
Hermes CLI profile | AgentVeil launcher + project-local Hermes MCP route | Routed MCP approval/evidence, sandbox boundaries, redirect guidance inside the AgentVeil route | Available |
Core MCP Proxy | MCP transport boundary | Routed MCP policy, approval, redirect / policy-stop outcomes, bounded evidence | Available |
Here, Available identifies a shipped integration mechanism, not control of unlisted client modes or a guarantee that a project's connection is active. Required reloads, trust prompts, route configuration and observed hook evidence still apply. Check the connector instructions above and local setup status.
The Python SDK also includes framework examples and optional helper modules for CrewAI, LangGraph, AutoGen, PydanticAI, OpenAI, Gemini, and AWS Bedrock. Those examples are not the same as a project connector: they show how agent workflows can use AgentVeil primitives, while connector coverage still depends on what is configured and routed through AgentVeil.
Future connectors can follow the same model: configure a boundary, route risky actions through controlled tools, and record evidence.
Compatibility
Current connector checks have been run with:
Surface | Checked version |
Cursor | 3.6.31 |
Claude Code | 2.1.126 |
Codex | interactive TUI hook trust path |
Gemini CLI | 0.49.0 folder trust path |
Hermes CLI | live controlled MCP route path |
Python package metadata | Python 3.10-3.13 |
Compatibility is scoped to the versions and client paths listed here. It does not establish support for other client modes or later releases. Python metadata states the declared interpreter range; runtime checks remain environment-specific. Where a row omits an exact version or check date, it is not a version-pinned compatibility guarantee. For project readiness, use the connector-specific instructions and local status.
Other versions may work, but are not listed here until verified.
What AgentVeil Controls
AgentVeil has two public action-control surfaces:
Project connectors
configured per project/workspace;
install managed local hooks and MCP route config;
block supported native risky agent mutation tools;
return redirect guidance toward AgentVeil MCP tools;
use MCP Proxy approval and evidence for routed tool calls.
Core MCP Proxy
wraps downstream MCP servers;
classifies routed MCP tool calls;
returns allow / approval_required / redirect / policy-stop outcomes;
records bounded local evidence.
What AgentVeil Does Not Control
AgentVeil does not claim machine-wide control.
It does not control:
your whole machine;
every Cursor / Claude / Codex / Gemini / Hermes chat globally;
every autonomous agent runtime globally;
direct human terminal commands outside configured AgentVeil paths;
IDE actions outside supported agent tool surfaces;
MCP servers not routed through AgentVeil;
disabled, removed, or bypassed hooks;
unsupported client modes that skip hooks.
Actions outside configured AgentVeil boundaries are not classified or logged.
Bounded Evidence
AgentVeil records bounded local evidence for controlled actions, so you can review what an agent requested, whether it was allowed, given redirect guidance, sent for approval, returned a hard-block decision, and whether the controlled path completed.
Inspect recent decisions:
agentveil-mcp-proxy events show --last
agentveil-mcp-proxy events show --last --jsonExample evidence shape:
{
"tool": "write_file",
"decision": "approval_required",
"approval": "approved",
"target_reached": true,
"payload_hash": "sha256:...",
"timestamp": "2026-06-25T..."
}Evidence is designed for audit and incident review:
what the agent requested;
what policy decided;
whether approval was required;
whether the action executed;
hashes and bounded metadata instead of raw prompts or full payloads by default.
This is useful for AI-agent governance, compliance review, and debugging unsafe automation.
Handling False Positives
AgentVeil is designed to fail closed for risky actions. If a supported agent action is blocked unexpectedly, inspect local decision evidence before changing the setup.
Start with:
agentveil-mcp-proxy events show --last
agentveil-mcp-proxy setup status --jsonFor routed MCP actions, approval and policy behavior are documented in:
If a connector is not right for a project, remove only the managed AgentVeil entries for that project instead of editing client config by hand.
Preview managed removal:
agentveil-mcp-proxy setup remove cursor
agentveil-mcp-proxy setup remove claude-code
agentveil-mcp-proxy setup remove codex
agentveil-mcp-proxy setup remove gemini-cliApply removal after review:
agentveil-mcp-proxy setup remove cursor --yes
agentveil-mcp-proxy setup remove claude-code --yes
agentveil-mcp-proxy setup remove codex --yes
agentveil-mcp-proxy setup remove gemini-cli --yesScope
Component | Availability and boundary |
Public local packages | Project connectors, explicitly routed MCP calls and local evidence; Console pairing is optional. Backend-backed flows still need the configured backend. |
Hosted Console | Device pairing and bounded connection/decision/approval summaries; visibility depends on what the connected project reports. |
Additional local provider capabilities | Separate package, workspace eligibility and activation checks; they are not granted by installing the public proxy. See the package scope. |
SDK primitives | APIs and examples for application-owned integrations, distinct from ready-to-use project connectors. |
Preview / design-partner flows | The limited-release patterns listed below; they are not general public connector coverage. |
Available today:
MCP Proxy for routed MCP tool calls;
project-local Cursor connector;
project-local Claude Code connector;
project-local Codex connector;
project-local Gemini CLI connector;
Hermes CLI controlled MCP launch profile;
approval / redirect / block / evidence outcomes for routed actions;
bounded local evidence export.
Available as SDK / protocol primitives:
capability-token primitives;
local identity helpers;
delegation receipts;
proof packet helpers.
Preview / design-partner product flows:
session-token flows for reducing repeated approvals;
richer policy packs;
credential custody;
egress boundary;
hosted approval and team governance.
Not included in the public connector:
machine-wide shell interception;
global Cursor / Claude / Codex / Gemini / Hermes lock;
automatic control of unrelated chats;
private enterprise policy packs;
hosted service implementations for auth, licensing, telemetry, or enterprise custody. Public clients may still contain pairing, summary upload and provider installation code; this exclusion concerns the hosted implementation.
Example Risk Patterns
AgentVeil is useful when an agent crosses from reading context into changing state.
Workflow | Low-risk actions | Higher-risk actions AgentVeil can gate |
Code / PR workflow | read files, inspect git history, list workspace | edit files, run mutation commands, change repo state |
Content workflow | read drafts, inspect metadata | publish, send, update CMS-like content |
Data workflow | read query results, inspect schemas | mutate records, export sensitive data, run destructive operations |
Package / build workflow | inspect dependencies, read lockfiles | install packages, run scripts, change build output |
Agentic media / broadcast workflows
Agentic media and broadcast workflows often start with read access to files, assets, CMS entries, Git history, or SQL query results, then cross into higher-risk writes and sends: publishing updates, changing a repository, mutating a database, or sending final content.
This is one example of the broader risk pattern:
agent reads metadata -> allow / observe
agent edits file or record -> approval required
agent publishes or sends -> approval / redirect
agent tries unsafe mutation -> block
agent action completes -> bounded evidenceAgentVeil does not ship native broadcast, CMS, or SQL integrations in this package. The example describes the risk pattern for agentic workflows.
Why This Exists
AI agents increasingly hold direct access to files, repositories, package managers, credentials, and workflow tools.
The risk is no longer only what an AI says. The risk is what an AI can do.
AgentVeil focuses on action control:
Block unsafe native agent actions in configured project connectors.
Return redirect guidance so the agent can retry through controlled MCP tools.
Require approval for routed writes and mutations.
Record bounded evidence for audit, review, and compliance.
AgentVeil does not solve the general access-control safety problem. It narrows the problem to configured projects, routed MCP calls, supported agent tool paths, and explicit policy decisions.
Design Basis
The MCP Proxy design is summarized in MCP Proxy Design Principles.
Fail-safe defaults: missing policy, missing approval, or unavailable trusted decisions move toward denial or explicit review.
Complete mediation on routed calls: each protected downstream MCP call goes through the same classify, decide, evidence, and forward-or-deny path.
Least privilege: approvals are scoped to concrete action context instead of broad standing permission.
Separation of privilege: local proxy identity, control grants, and backend signing authority are separate roles.
Bounded evidence: receipts, payload hashes, and local evidence chains bind decisions to the routed action subset.
For deeper security framing, including Saltzer & Schroeder and HRU-aware limits, see MCP Proxy Design Principles.
Comparison
Category | Main focus | Where AgentVeil differs |
Prompt/content guardrails | Detect unsafe text | AgentVeil controls actions and tool calls, not only prompts |
LLM API gateways | Route model traffic | AgentVeil mediates agent tool execution and evidence |
Direct MCP servers | Expose tools to agents | AgentVeil adds policy, approval, redirect, and evidence between agent and tool when routed through the proxy |
Secret managers | Store credentials | AgentVeil controls when risky agent actions may execute |
Generic audit logs | Record app events | AgentVeil binds evidence to specific agent action requests and decisions |
Reporting Issues And Security Findings
For bugs and integration problems, use the repository issue tracker. For security-sensitive findings, follow the repository Security Policy.
Security-sensitive reports should not include secrets, raw credentials, private keys, or full customer data in public issues.
Licensing
The root SDK is MIT-licensed.
agentveil-mcp-proxy is a separately packaged source-available component under BUSL-1.1. See Licensing before using it in commercial or competing hosted services.
Hosted Console and plans. Local connector and proxy control do not require Console pairing. Hosted services and additional capabilities have their own availability and terms; see plans and pricing. A software license describes rights to the package, not a hosted subscription or entitlement.
Python SDK and advanced protocol primitives
Advanced Python SDK package: agentveil.
The public SDK also includes protocol primitives that can support custom integrations: local did:key identity, delegation receipts, credential helpers, reputation credential access, receipt helpers, and optional framework adapter modules under agentveil.tools.* when their framework dependencies are installed.
These primitives are not the main product path in this README. For direct use, start with:
Available Tools
20 toolsapprove_actionA
Approve a pending human approval request and return signed receipt JCS plus sha256.
Inputs: approval_id (required). Returns: result
check_reputationA
Get the full reputation profile of an agent: score, confidence, risk factors, and tier.
Returns detailed numerical data for analysis and logging.
Use this when you need the actual numbers (score, confidence, risk breakdown).
NOT for yes/no delegation decisions — use check_trust instead (returns allowed: true/false).
NOT for rating history — use get_attestations_received for individual peer reviews.
Read-only. Does not modify any data or affect the target agent's score.
Args:
did: Agent's DID in W3C format. Must start with "did:key:z6Mk".
Returns:
JSON with score (0.0-1.0), confidence (0.0-1.0), risk_score (0.0-1.0),
risk_factors (list), tier (newcomer/basic/trusted/elite), and interpretation.
Inputs: did (required). Returns: result
check_trustA
Quick yes/no delegation decision: is this agent trusted enough for my task?
Returns allowed (true/false) with a human-readable reason. Use this when you
only need a go/no-go answer before delegating work.
NOT for detailed analysis — use check_reputation for full score breakdown.
NOT for rating history — use get_attestations_received for peer reviews.
Tiers from lowest to highest: newcomer, basic, trusted, elite.
Advisory signal, not a guarantee.
Read-only. Does not modify any data.
Args:
did: Agent's DID (did:key:z6Mk...).
min_tier: Minimum required tier: "newcomer", "basic", "trusted", "elite". Default "trusted".
task_type: Optional task category for specialized scoring.
Returns:
JSON with allowed (true/false), score, tier, risk_level, and reason.
Inputs: did (required), min_tier, task_type. Returns: result
controlled_actionA
Run the high-level AVP controlled-action flow.
Returns `ControlledActionOutcome.to_dict()` as a JSON string. Possible
statuses are `executed`, `approval_required`, and `blocked`. Human approval
is never auto-approved; after approval, call `execute_after_approval`.
Inputs: action (required), resource (required), environment (required), delegation_receipt (required), +4 more. Returns: result
deny_actionB
Deny a pending human approval request and return signed receipt JCS plus sha256.
Inputs: approval_id (required), reason. Returns: result
execute_after_approvalB
Resume a controlled action after principal approval.
The approval payload key is `approval_id`. This tool deliberately passes
that key through to `AVPAgent.execute_after_approval(...)`.
Inputs: action (required), audit_id (required), resource (required), approval_id (required), +2 more. Returns: result
get_agent_infoA
Get public profile information about a registered AI agent.
Returns display name, verification status, capabilities, and provider.
Use this when you already have a specific DID and need profile data.
For trust assessment, use check_reputation or check_trust instead.
For rating history, use get_attestations_received.
To find agents by capability, use search_agents.
Read-only — does not affect reputation or any stored data.
Args:
did: The agent's DID (did:key:z6Mk...).
Must be a registered agent on the AVP network.
Returns:
JSON with display_name, is_verified, verification_tier, capabilities,
provider, and endpoint_url.
Returns {"error": "Agent not found"} if DID is not registered.
Inputs: did (required). Returns: result
get_approval_requestB
Fetch a human approval request visible to the local agent identity.
Inputs: approval_id (required). Returns: result
get_attestations_receivedA
Get peer ratings (attestations) received by an agent — who rated them and how.
Returns individual ratings from other agents: who gave them, positive/negative,
weight, and context. Use this to understand the evidence behind a score.
NOT for protocol-level events — use get_audit_trail for registration, disputes, transfers.
NOT for the computed score — use check_reputation for the final number.
Read-only. Does not affect reputation or stored data.
Args:
did: Agent's DID (did:key:z6Mk...) to look up ratings for.
Returns:
JSON list of attestations (newest first) with from_agent_did,
outcome, weight, context, and created_at.
Inputs: did (required). Returns: result
get_audit_trailA
Get the tamper-evident audit trail: every protocol action by this agent.
Returns hash-chained events: registration, card publications, disputes,
job actions. Each entry links cryptographically to the previous one.
Use this for compliance, due diligence, or dispute evidence.
NOT for peer ratings — use get_attestations_received for who rated this agent.
Use verify_audit_chain to check integrity of the entire chain.
Read-only. Public data, no authentication required.
Args:
did: Agent's DID (did:key:z6Mk...) to get audit history for.
limit: Maximum entries (1-100). Default 20. Newest first.
Returns:
JSON list of audit entries with action type, timestamp,
target DID, payload, and hash chain reference.
Inputs: did (required), limit. Returns: result
get_decision_receiptB
Fetch exact signed DecisionReceipt JCS text and its sha256 digest.
Inputs: audit_id (required). Returns: result
get_execution_receiptA
Fetch exact signed ExecutionReceipt JCS text and its sha256 digest.
Inputs: receipt_id (required). Returns: result
get_my_agent_infoA
Get YOUR agent's DID, registration status, and reputation — the locally configured agent only.
Call this to verify your own setup before calling submit_attestation or publish_agent_card.
Returns private details (public key, registration state) not available through get_agent_info.
NOT for looking up other agents — use get_agent_info(did) for any agent by DID,
or check_reputation(did) for another agent's trust score.
No parameters. Uses the agent configured via AVP_AGENT_NAME environment variable.
Read-only. Does not modify any data.
Returns:
JSON with did, public_key_hex, is_registered, is_verified,
and current reputation (or "not yet scored").
Inputs: no named parameters. Returns: result
get_protocol_statsA
Get network-wide aggregate statistics: total agents, attestations, and verified identities.
Call this to answer "how big is the AVP network?" or "is the service active?"
before registering a new agent. Returns counts, not individual agent data.
NOT for individual agents — use check_reputation for a specific agent's score,
or search_agents to find agents by capability.
Read-only. No authentication required. No parameters.
Returns:
JSON with total_agents, total_attestations, verified_agents,
total_cards, and protocol version.
Inputs: no named parameters. Returns: result
publish_agent_cardA
Publish or update your agent's capability card for network discovery.
Makes your agent discoverable by other agents using search_agents.
IMPORTANT: This operation is idempotent — calling it again replaces
the previous card entirely. The card becomes publicly visible to all
agents on the network immediately.
Requires a registered agent identity (call register_agent first).
Use search_agents afterward to verify your card is discoverable.
Use get_my_agent_info to check your current registration status.
Side effects: creates or replaces your public capability card.
No effect on other agents' data.
Args:
capabilities: Comma-separated capabilities. At least one required.
Examples: "code_review,security_audit,testing".
provider: LLM provider powering this agent. Helps discovery filtering.
endpoint_url: URL for receiving HTTP requests from other agents.
Returns:
JSON with card details: capabilities list, provider, endpoint,
and confirmation. Returns {"error": "..."} if not registered
or on invalid input.
Inputs: capabilities (required), provider, endpoint_url. Returns: result
register_agentA
Register a new AI agent on the Agent Veil Protocol network.
Creates a cryptographic identity (Ed25519 keypair), generates a W3C DID,
and registers the agent. Keys are saved locally to ~/.avp/agents/
with restricted permissions (chmod 0600).
IMPORTANT: Registration is irreversible. The DID becomes the agent's
permanent identifier. Keys cannot be regenerated for the same DID —
keep the local key file safe.
Call this once before using write operations (submit_attestation,
publish_agent_card). Use get_my_agent_info to verify setup afterward.
Side effects: creates local key file, registers agent on the network.
Args:
display_name: Human-readable name (e.g. "Code Reviewer").
If empty, uses AVP_AGENT_NAME environment variable.
Returns:
JSON with the new agent's DID, display_name, registration status,
and local key storage path.
Returns {"error": "..."} if registration fails (network error, name conflict).
Inputs: display_name. Returns: result
runtime_evaluate_actionA
Evaluate one proposed action with AVP Runtime Gate.
Returns the Runtime Gate decision payload from AVP. The decision is expected
to be one of ALLOW, WAITING_FOR_HUMAN_APPROVAL, or BLOCK. This tool only
evaluates the action; it does not execute anything and does not intercept
other MCP tool calls.
Inputs: action (required), resource (required), environment (required), delegation_receipt (required), +2 more. Returns: result
search_agentsA
Find AI agents by capability, provider, or minimum reputation score.
Use this to discover available agents for a task before delegation.
Results are sorted by reputation score (highest first).
Combine filters to narrow results.
Use get_agent_info when you already have a specific DID.
Use check_reputation or check_trust to evaluate a found agent.
Read-only — does not modify any data.
Args:
capability: Filter by published capability. Examples:
"code_review", "security_audit", "translation". Empty for all.
provider: Filter by LLM provider. Examples: "anthropic", "openai". Empty for all.
min_reputation: Minimum reputation score (0.0-1.0). Default 0.0 returns all.
limit: Maximum number of results (1-100). Default 10.
Returns:
JSON list of matching agents with DID, display_name, capabilities,
provider, and reputation score. Returns empty list if no matches.
Inputs: limit, provider, capability, min_reputation. Returns: result
submit_attestationA
Submit a peer attestation (rating) for another agent after an interaction.
Records your evaluation of another agent's performance. This is the
primary mechanism for building reputation on the network.
IMPORTANT: Attestations are cryptographically signed and immutable —
they cannot be modified or deleted after submission. Use the dispute
system to contest unfair ratings received.
Side effects: permanently modifies the target agent's attestation
history and may change their computed reputation score.
Requires a registered agent identity (call register_agent first).
Self-attestation (rating yourself) is blocked.
Args:
to_did: DID of the agent being rated (did:key:z6Mk...).
outcome: Must be "positive", "negative", or "neutral".
weight: Confidence (0.0-1.0). Default 0.9.
context: Interaction type for category-specific scoring. Empty for general.
Returns:
JSON with attestation ID, signature confirmation, and effective weight.
Returns {"error": "Rate limited"} if limits exceeded.
Returns {"error": "..."} on invalid input or network errors.
Inputs: to_did (required), weight, context, outcome. Returns: result
verify_audit_chainA
Verify the cryptographic integrity of AVP's immutable audit trail.
Checks that no audit entries have been tampered with by verifying
the SHA-256 hash chain from genesis to the latest entry.
Use this before relying on audit data for compliance or dispute resolution.
For an individual agent's audit history, use get_audit_trail instead.
Read-only — no authentication required. Safe to call at any time.
Returns:
JSON with is_valid (true/false), total_entries count, latest_hash,
and verification timestamp. is_valid=false means tampering detected.
Returns {"error": "..."} on network errors.
Inputs: no named parameters. Returns: result
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 20 tools
Each tool has a clearly distinct purpose with detailed descriptions that explicitly contrast with similar tools (e.g., check_reputation vs check_trust, get_agent_info vs get_my_agent_info). There is no ambiguity between tools.
All tools consistently use snake_case with a verb-first pattern (e.g., approve_action, check_reputation, submit_attestation). There is no mixing of conventions or inconsistent verb styles.
With 20 tools covering registration, reputation, attestations, audit, agent discovery, and action approval, the count is well-scoped for the protocol's domain. Each tool serves a distinct and necessary function without redundancy.
The tool set covers major workflows: registration, profile publication, reputation assessment, attestations, audit trail, and controlled actions. A minor gap is the lack of a dedicated dispute tool mentioned in submit_attestation, but the set still feels comprehensive for most use cases.
Maintenance
Related MCP Connectors
Trust infrastructure for AI agents. Portable reputation (JTS 0-5), agent discovery, vouching.
Agent reputation registry: check, register, and endorse AI agents
Trust infrastructure for AI agents: read a verifiable Trust Rating, claim an identity, earn a badge.
On-chain ERC-8004 agent registry. Search, register, and check reputation across 16 chains.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceAgent network intelligence for trust verification, broker discovery, and capability matching. Ed25519 identity, graph-based trust scoring, USDC payments, and MCP tools for agent registration, search, and trust attestation.4,039 npm5Apache 2.0
- AlicenseAqualityBmaintenanceAI agent identity and reputation registry. Ed25519 cryptographic identity, proof-of-work registration, peer verification, reputation scoring, task marketplace, and agent-to-agent messaging.26870 npm3Apache 2.0
- AlicenseAqualityCmaintenanceEnterprise AI governance layer for spend tracking, runtime guardrails, policy enforcement, and budget limits. Connects Claude, ChatGPT, and any MCP client to ThinkNEO's control plane for SOC2/GDPR/HIPAA compliance monitoring and real-time provider health.83Apache 2.0
- AlicenseAqualityBmaintenanceCryptographic accountability for AI agents. Ed25519-signed receipts for every MCP tool call. Constraints, chains, AI judgment, invoicing, and local dashboard included.244 npm1MIT