Vaultfire MCP Server
⚠️ アルファ版ソフトウェア — Vaultfireプロトコルは現在開発中です。スマートコントラクトはメインネットにデプロイされていますが、第三者セキュリティ企業による正式な監査は受けていません。読み取り専用ツールはどのエージェントでも安全に使用できます。書き込みツールはライブコントラクトとやり取りするため、トランザクションは不可逆です。自己責任でご利用ください。免責事項については LICENSE を参照してください。
@vaultfire/mcp-server
Vaultfire Protocol 用 MCPサーバー
MCP対応AIのためのオンチェーン信頼性検証。 Claude · Copilot · Cursor · Windsurf · Google ADK などで動作します。
Base · Avalanche · Arbitrum · Polygon 上にデプロイ済み。
クイックスタート
Claude Desktop
claude_desktop_config.json (macOSでは通常 ~/Library/Application Support/Claude/claude_desktop_config.json) に以下を追加します：
{
"mcpServers": {
"vaultfire": {
"command": "npx",
"args": ["-y", "@vaultfire/mcp-server"],
"env": {
"VAULTFIRE_CHAIN": "base"
}
}
}
}書き込みツール（エージェント登録、ボンド作成）を有効にするには、秘密鍵を追加してください：
{
"mcpServers": {
"vaultfire": {
"command": "npx",
"args": ["-y", "@vaultfire/mcp-server"],
"env": {
"VAULTFIRE_CHAIN": "base",
"PRIVATE_KEY": "your_private_key_here"
}
}
}
}Cursor
プロジェクトルートの .cursor/mcp.json に以下を追加します：
{
"mcpServers": {
"vaultfire": {
"command": "npx",
"args": ["-y", "@vaultfire/mcp-server"],
"env": {
"VAULTFIRE_CHAIN": "base"
}
}
}
}汎用 (npx)
# Read-only mode (no key needed)
npx @vaultfire/mcp-server
# With a specific chain
VAULTFIRE_CHAIN=avalanche npx @vaultfire/mcp-server
# With write tools enabled
PRIVATE_KEY=your_private_key npx @vaultfire/mcp-serverグローバルインストール
npm install -g @vaultfire/mcp-server
vaultfire-mcp-server利用可能なツール
読み取り専用ツール（常に利用可能）
ツール | 説明 |
| 完全な信頼性検証：アイデンティティ、ボンド、Street Cred、評判、ブリッジ状態 |
| Street Credスコア (0-95) とティアを取得 |
| オンチェーンアイデンティティデータ (URI、タイプ、登録日、アクティブ状態) |
| アドレスに関連するすべてのパートナーシップボンド |
| 評判データ (平均評価、フィードバック数、検証済み %) |
| 機能タグでエージェントを検索 |
| プロトコル統計：総エージェント数、ボンド数、ボンド価値、ブリッジ同期 |
書き込みツール (PRIVATE_KEY 環境変数が必要)
ツール | 説明 |
| AIエージェントをオンチェーンに登録 (ERC-8004) |
| 経済的ステークを伴うパートナーシップボンドを作成 |
警告: 書き込みツールはメインネットに実際のトランザクションを送信します。トランザクションは取り消せません。
リソース
このサーバーは、プロトコルのコンテキスト用に2つのMCPリソースを公開しています：
URI | 説明 |
| コントラクトアドレスとチェーン詳細を含むサポート対象の4つのチェーン |
| Street Credスコアリングの計算式とティアの定義 |
設定
環境変数 | 必須 | デフォルト | 説明 |
| いいえ |
| クエリ対象のチェーン： |
| いいえ | — | 書き込みツール（登録、ボンド）用の秘密鍵。コミットしないでください。 |
| いいえ | — | カスタムRPC URL（選択したチェーンのデフォルトを上書き） |
Street Credスコアリング
Street Credは、ライブのオンチェーンデータから計算される複合信頼スコア (0–95) です：
コンポーネント | ポイント | 条件 |
アイデンティティ登録済み | 30 | エージェントがERC-8004オンチェーンアイデンティティを持つ |
ボンドあり | 25 | 少なくとも1つのパートナーシップボンドが存在する |
ボンド有効 | 15 | 少なくとも1つのボンドが現在有効である |
ボンドティア | 0–20 | プラチナ (≥0.5 ETH) / ゴールド (≥0.1) / シルバー (≥0.05) / ブロンズ (≥0.01) |
複数のボンド | 5 | 2つ以上のボンドがある（エコシステム参加者） |
ティア：
ティア | スコア範囲 | 説明 |
ランク外 | 0 | オンチェーンの信頼シグナルなし |
ブロンズ | 1–30 | 基本的なアイデンティティまたは最小限のボンド活動 |
シルバー | 31–55 | 登録済みで、ある程度のステークを伴うボンドがある |
ゴールド | 56–75 | 有意義なステークを伴うアクティブなボンドがある |
プラチナ | 76–95 | 重要なステークを伴う複数のアクティブなボンドがある |
サポートされているチェーン
チェーン | チェーンID | ハブ | ネイティブトークン |
Base | 8453 | ✅ プライマリ | ETH |
Avalanche | 43114 | — | AVAX |
Arbitrum | 42161 | — | ETH |
Polygon | 137 | — | POL |
Vaultfireを選ぶ理由
特徴 | Vaultfire | AxisTrust | Cred Protocol | Okta XAA |
AIアカウンタビリティボンド | ✅ | ❌ | ❌ | ❌ |
AIパートナーシップボンド | ✅ | ❌ | ❌ | ❌ |
オンチェーン、トラストレス | ✅ | ❌ | 部分的 | ❌ |
マルチチェーン (初日から) | ✅ (4) | ❌ | ❌ | ❌ |
Street Cred複合スコア | ✅ | T-Score | C-Score | ❌ |
信念加重ガバナンス | ✅ | ❌ | ❌ | ❌ |
ERC-8004準拠 | ✅ | ❌ | ✅ | ❌ |
メトリクスよりもモラルを。監視よりもプライバシーを。管理よりも自由を。 人間の繁栄を搾取よりも収益性の高いものにする。
主な差別化要因：
AIアカウンタビリティボンド — 単なるスコアではなく、実際の経済的なリスク負担
AIパートナーシップボンド — エージェント間の相互的な経済的ステーク
信念加重ガバナンス — 業界初（トークン加重ではない）
初日からクロスチェーン対応 — 4つのメインネットチェーン
Street Credスコアリング — オンチェーンデータに基づく0-95の複合信頼スコア
Vaultfireエコシステム
パッケージ | 説明 |
コアSDK — エージェント登録、ボンド作成、評判クエリ | |
LangChain / LangGraph統合 | |
エージェント間 (A2A) プロトコルブリッジ | |
エンタープライズIAMブリッジ (Okta, Azure AD, OIDC) | |
本パッケージ — Claude, Copilot, Cursor用MCPサーバー | |
OpenAI Agents SDK統合 | |
Vercel AI SDKミドルウェアおよびツール | |
信頼性検証付きXMTPメッセージング | |
信頼ゲート付きX402決済プロトコル | |
Vaultfire Name Service — 人間が読めるエージェントID | |
CrewAI統合 (Python) | |
ライブのオンチェーン信頼性を持つ3つのリファレンスエージェント | |
A2A Trust Extension仕様 — エージェントカードのオンチェーン信頼性 | |
Vaultfireボンドが信頼スコアを凌駕する理由 — ライブ証明 | |
信頼フレームワークホワイトペーパー — AIの経済的アカウンタビリティ | |
開発者ポータル — クイックスタート、プレイグラウンド、フレームワークピッカー |
セキュリティ
読み取り専用ツールは認証情報を必要とせず、どこでも安全に実行できます
書き込みツールは
PRIVATE_KEYを必要とします — 必ず環境変数から読み込み、ハードコードは避けてくださいスマートコントラクトはメインネットにデプロイされていますが、正式な監査は受けていません
書き込みツール経由で送信されたトランザクションは不可逆です
MCPサーバーの設定（
PRIVATE_KEYを含む）を信頼できない相手に公開しないでください
ライセンス
MIT — Copyright 2025 Ghostkey316
完全な条項および保証の免責事項については LICENSE を参照してください。
Available Tools
7 toolsvaultfire_discover_agentsC
Find registered AI agents by capability tags. Returns a list of agent addresses that match the requested capabilities. Capabilities are hashed on-chain.
| Name | Required | Description | Default |
|---|---|---|---|
| capabilities | Yes | Capability tags to search for (e.g., ["code-review", "translation"]) | |
| chain | No | Chain to query (default: base) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action and return type. It doesn't disclose behavioral traits such as whether this is a read-only operation, potential rate limits, authentication needs, or how the on-chain hashing affects results. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 a single, efficient sentence that front-loads the purpose and key details. Every word earns its place with no redundancy or unnecessary elaboration, making it easy to parse quickly.
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 complexity of querying on-chain data with hashed capabilities and no output schema, the description is incomplete. It doesn't explain the return format (e.g., structure of addresses, pagination), error conditions, or how capability matching works. For a tool with no annotations and no output schema, this leaves too much unspecified for reliable 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?
Schema description coverage is 100%, so the schema fully documents both parameters. The description adds no additional meaning beyond what's in the schema, such as explaining the format of capability tags or the implications of chain selection. Baseline 3 is appropriate when the schema does the heavy lifting.
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 verb 'find' and resource 'registered AI agents' with the mechanism 'by capability tags', and specifies the return type 'list of agent addresses'. However, it doesn't explicitly differentiate from sibling tools like 'vaultfire_get_agent' which might retrieve details about a specific agent rather than searching by capabilities.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'vaultfire_get_agent' for individual agent details or 'vaultfire_verify_agent' for verification, leaving the agent to infer usage from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
vaultfire_get_agentA
Get on-chain identity data for an agent address: agent URI, agent type, registration timestamp, and active status. Returns ERC-8004 compliant identity info.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Ethereum address of the AI agent (0x...) | |
| chain | No | Chain to query (default: base) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions the return format ('ERC-8004 compliant identity info'), it lacks critical operational details: whether this is a read-only operation (implied but not stated), authentication requirements, rate limits, error conditions, or what happens with invalid addresses. The description provides basic functionality but misses important behavioral context.
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 perfectly concise - two sentences that efficiently communicate purpose and return format with zero wasted words. The first sentence clearly states what the tool does and what data it returns, while the second provides important compliance context. Every element earns its place.
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 read operation with 2 parameters and 100% schema coverage but no output schema, the description provides adequate but incomplete context. It clearly states what data is returned but doesn't describe the response structure or format details. The ERC-8004 compliance mention is helpful but assumes prior knowledge. Given the missing output schema, more detail about return values would improve completeness.
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 description coverage is 100%, so the schema already fully documents both parameters. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain format requirements for the address beyond '0x...' or clarify chain selection implications. With complete schema coverage, the baseline score of 3 is appropriate.
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 specific action ('Get on-chain identity data') and resource ('for an agent address'), listing exactly what data is retrieved (agent URI, agent type, registration timestamp, active status). It distinguishes itself from siblings like vaultfire_get_bonds or vaultfire_get_reputation by focusing on core identity information rather than financial or social metrics.
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 when identity data is needed for an agent address, but provides no explicit guidance on when to choose this tool versus alternatives like vaultfire_verify_agent (which might verify rather than retrieve) or vaultfire_discover_agents (which might list multiple agents). No when-not-to-use scenarios or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
vaultfire_get_bondsB
Get all partnership bonds for an address. Returns bond IDs and full bond details including partner addresses, partnership type, stake amount (in ETH/native token), creation date, and active status.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Ethereum address to look up bonds for (0x...) | |
| chain | No | Chain to query (default: base) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool retrieves data (implied read-only) and lists the types of details returned, but lacks information on behavioral traits like rate limits, error handling, authentication needs, or whether it's a query or mutation. It adds some context but is incomplete for a tool with no annotations.
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 a single, well-structured sentence that efficiently states the purpose and return details without unnecessary words. It is front-loaded with the main action and provides essential information concisely.
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 no annotations and no output schema, the description partially compensates by listing return details, but it does not fully cover behavioral aspects or provide a complete picture for a tool with two parameters. It is adequate but has clear gaps in usage guidance and transparency.
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 description coverage is 100%, so the input schema already documents both parameters ('address' and 'chain') with descriptions and enums. The description does not add any meaning beyond the schema, such as explaining parameter interactions or default behaviors, meeting the baseline for high coverage.
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 verb ('Get') and resource ('partnership bonds for an address'), specifying it returns bond IDs and details like partner addresses, type, stake, creation date, and status. However, it does not explicitly differentiate from sibling tools like 'vaultfire_get_agent' or 'vaultfire_get_reputation', which might handle different data types, so it lacks sibling differentiation for a perfect score.
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?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any prerequisites, exclusions, or comparisons to sibling tools such as 'vaultfire_discover_agents' or 'vaultfire_verify_agent', leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
vaultfire_get_reputationB
Get reputation data for an agent: average rating, total feedback count, verified feedback count, and percentage of verified feedback. Ratings are stored on-chain from real interactions.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Ethereum address of the AI agent (0x...) | |
| chain | No | Chain to query (default: base) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that ratings are 'stored on-chain from real interactions,' which adds context about data source and authenticity, but lacks details on error handling, rate limits, or response format. For a read operation, this is minimally adequate but leaves gaps in understanding operational behavior.
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 highly concise and front-loaded, using a single sentence to convey the core purpose and key metrics. Every word earns its place, with no redundant information. It efficiently communicates the tool's function without unnecessary elaboration, making it easy for an agent to parse quickly.
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 tool's moderate complexity (2 parameters, no output schema, no annotations), the description is somewhat complete but has gaps. It covers what data is retrieved and its on-chain nature, but lacks details on output structure, error cases, or integration with sibling tools. Without annotations or output schema, more context on behavioral aspects would improve completeness 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?
Schema description coverage is 100%, so the input schema fully documents the parameters ('address' and 'chain'). The description adds no additional parameter semantics beyond what the schema provides, such as explaining address validation or chain selection implications. Baseline 3 is appropriate as the schema handles the heavy lifting without description enhancement.
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's purpose: retrieving reputation data for an AI agent, including specific metrics like average rating, feedback counts, and verification percentages. It distinguishes this from sibling tools like 'vaultfire_get_agent' or 'vaultfire_get_street_cred' by focusing on reputation metrics, though it doesn't explicitly contrast with them. The mention of on-chain storage adds useful context but doesn't fully differentiate from alternatives.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'vaultfire_get_agent' or 'vaultfire_get_street_cred', leaving the agent to infer usage based on tool names alone. There's no indication of prerequisites, such as needing an agent address, or when this tool is preferred over others for reputation-related queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
vaultfire_get_street_credA
Get the Street Cred score (0-95) and tier for an agent address. Tiers: Unranked (0), Bronze (1-30), Silver (31-55), Gold (56-75), Platinum (76-95). Also returns the score breakdown showing how each component contributes.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Ethereum address of the AI agent (0x...) | |
| chain | No | Chain to query (default: base) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the output (score, tier, breakdown) but doesn't mention potential errors, rate limits, authentication needs, or data freshness. It adds some context by detailing the tier ranges and score components, but lacks operational traits like response format or failure modes.
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 front-loaded with the core purpose in the first sentence, followed by tier details and additional output information. Every sentence adds value (e.g., tier ranges, breakdown explanation) without redundancy, making it efficient and well-structured for quick comprehension.
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 tool's moderate complexity (2 parameters, no output schema, no annotations), the description is reasonably complete. It explains the output (score, tier, breakdown) and tier ranges, which compensates for the lack of output schema. However, it could improve by addressing behavioral aspects like error handling or data sources, leaving minor gaps.
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 schema description coverage is 100%, so the input schema already documents both parameters (address and chain) thoroughly. The description doesn't add any parameter-specific details beyond what the schema provides, such as examples or edge cases, but it doesn't need to compensate for gaps, resulting in a baseline score of 3.
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's purpose with specific verbs ('Get the Street Cred score and tier') and resource ('for an agent address'), distinguishing it from siblings like vaultfire_get_agent or vaultfire_get_reputation by focusing on a specific scoring metric. It explicitly mentions the score range (0-95) and tier breakdown, making the purpose unambiguous.
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 by specifying it's for an agent address, but it doesn't explicitly state when to use this tool versus alternatives like vaultfire_get_agent or vaultfire_get_reputation. There's no guidance on prerequisites, exclusions, or comparative contexts, leaving the agent to infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
vaultfire_protocol_statsA
Get Vaultfire Protocol statistics: total registered agents, total bonds created, total active bond value (in native token), and bridge sync count.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain to query (default: base) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool's read-only nature ('Get') and the specific metrics returned, which is helpful. However, it lacks details on behavioral traits like rate limits, authentication requirements, error conditions, or response format, which would be valuable for a tool with no annotation coverage.
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 a single, well-structured sentence that front-loads the purpose and efficiently lists the four key statistics. Every word contributes to understanding the tool's function without redundancy or fluff, making it highly concise and effective.
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 tool's low complexity (one optional parameter, no output schema, no annotations), the description is reasonably complete. It clearly states what statistics are returned, which compensates for the lack of output schema. However, it could improve by mentioning response format or any limitations, but for a simple read operation, it provides sufficient context.
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, with the 'chain' parameter fully documented (type, enum values, default). The description adds no parameter-specific information beyond what the schema provides, such as clarifying the 'native token' unit or 'bridge sync' meaning. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't enhance parameter understanding.
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 specific action ('Get') and resource ('Vaultfire Protocol statistics'), listing the exact metrics returned (total registered agents, total bonds created, total active bond value, bridge sync count). It distinguishes this from sibling tools like 'vaultfire_get_agent' or 'vaultfire_get_bonds' by focusing on aggregate protocol-level stats rather than individual entities.
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 retrieving protocol-wide statistics, but provides no explicit guidance on when to use this tool versus alternatives like 'vaultfire_discover_agents' or 'vaultfire_get_bonds'. No exclusions or prerequisites are mentioned, leaving the agent to infer context from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
vaultfire_verify_agentA
Full trust verification for an AI agent address: checks on-chain identity (ERC-8004), partnership bonds, Street Cred score (0-95), reputation data, and cross-chain bridge recognition. Returns a trusted/untrusted verdict with reason. Use this before interacting with an unknown agent.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Ethereum address of the AI agent to verify (0x...) | |
| chain | No | Chain to query (default: base) | |
| minScore | No | Minimum Street Cred score to be considered trusted (default: 20, max: 95) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses behavioral traits such as returning a 'trusted/untrusted verdict with reason' and performing multiple checks, but lacks details on rate limits, error handling, or authentication needs. The description is informative but not comprehensive for a verification tool with no annotation support.
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 front-loaded with the tool's purpose and key checks, followed by usage guidance. Every sentence earns its place by adding value, with no redundant or vague language, making it efficient and well-structured.
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 complexity of a verification tool with 3 parameters and no output schema, the description is mostly complete. It explains what the tool does and when to use it, but lacks details on output format or behavioral aspects like error cases. With no annotations, it could benefit from more transparency, but it's adequate for basic 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?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond what the schema provides, such as explaining interactions between parameters or usage nuances. Baseline 3 is appropriate as the schema does the heavy lifting.
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's purpose with specific verbs ('verify', 'checks') and resources ('AI agent address'), listing multiple verification criteria (on-chain identity, partnership bonds, Street Cred score, reputation data, cross-chain bridge recognition). It distinguishes from sibling tools like 'vaultfire_get_street_cred' or 'vaultfire_get_reputation' by combining all checks into a single trusted/untrusted verdict.
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 explicitly states when to use this tool: 'Use this before interacting with an unknown agent.' This provides clear context for usage versus alternatives, though it doesn't name specific sibling tools, the guidance is direct and actionable for the agent's decision-making.
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.
7 tool updates
v1.0.0- First observed
vaultfire_discover_agents - First observed
vaultfire_get_agent - First observed
vaultfire_get_bonds - First observed
vaultfire_get_reputation - First observed
vaultfire_get_street_cred - First observed
vaultfire_protocol_stats - First observed
vaultfire_verify_agent
TDQS
Scored across 7 tools
Each tool has a clearly distinct purpose with no overlap: discover_agents finds agents by tags, get_agent retrieves identity data, get_bonds lists partnership bonds, get_reputation provides rating data, get_street_cred gives a score and tier, protocol_stats shows system-wide metrics, and verify_agent performs a comprehensive trust check. The descriptions reinforce these unique functions, making misselection unlikely.
All tool names follow a consistent verb_noun pattern with the prefix 'vaultfire_' (e.g., vaultfire_discover_agents, vaultfire_get_agent). This uniform snake_case naming convention makes the set predictable and easy to parse, with no deviations in style or structure across the seven tools.
With 7 tools, the count is well-scoped for a server focused on AI agent verification and data retrieval in the Vaultfire ecosystem. Each tool serves a specific, non-redundant function, covering discovery, identity, bonds, reputation, scoring, stats, and verification, which aligns perfectly with the domain's needs without being overly sparse or bloated.
The tool surface provides complete coverage for the domain of AI agent verification and on-chain data access. It includes discovery, detailed identity and bond retrieval, reputation and scoring metrics, protocol-level statistics, and a comprehensive verification tool that integrates all aspects. There are no obvious gaps; agents can perform end-to-end workflows without dead ends.
Related MCP Connectors
Trust infrastructure for AI agents. Portable reputation (JTS 0-5), agent discovery, vouching.
Trust infrastructure for AI agents: read a verifiable Trust Rating, claim an identity, earn a badge.
Read-only smart-contract security intelligence for autonomous agents.
On-chain ERC-8004 agent registry. Search, register, and check reputation across 16 chains.
