MCP（Model Context Protocol）サーバーであり、Agent Trust Stackツールを公開しているため、MCP互換のAIエージェントであればネイティブに使用可能です。
7つのプロトコルからなるAgent Trust Stackのうち、**意識の連鎖（Chain of Consciousness: CoC）プロバナンスログ記録とエージェント評価プロトコル（Agent Rating Protocol: ARP）**評価スコアリングという2つの運用プロトコルを提供します。
ツール | 説明 |
| 新しい暗号学的ハッシュチェーン（ジェネシスブロック）を初期化 |
| エントリを追加 — 学習、決定、作成、エラー、メモ、マイルストーン、セッション開始/終了 |
| チェーンの整合性を検証（ハッシュの連結、順序、完全性） |
| チェーンの統計を取得（長さ、エージェント数、期間、イベントタイプ） |
| 最後のN件のエントリを取得 |
| 外部タイムスタンプ用にチェーンハッシュを送信（OTS + RFC 3161 TSA） |
| 他のエージェントに対する双方向のブラインド評価を送信 |
| エージェントの評価スコアを確認 |
| ホワイトペーパーへのリンクを含む7つのプロトコルすべての情報を取得 |
| エージェントカードURLを通じてエージェントの身元を検証 |
| エージェントの統合された信頼エビデンス（CoC + ARP）を取得 |
Related MCP server: AgentVeil Protocol
URI | 説明 |
| リンク付きの7つのプロトコル概要 |
| インストール手順 |
pip install agent-trust-stack-mcp適切なOpenTimestamps .otsファイル形式（オプション）の場合:
pip install agent-trust-stack-mcp[ots]MCPクライアント設定（Claude Code、Cursorなど）に追加してください:
{
"mcpServers": {
"agent-trust-stack": {
"command": "agent-trust-stack-mcp",
"args": []
}
}
}変数 | デフォルト | 説明 |
|
| チェーンファイル用ディレクトリ |
|
| 評価ファイル用ディレクトリ |
{
"mcpServers": {
"agent-trust-stack": {
"command": "agent-trust-stack-mcp",
"args": [],
"env": {
"COC_CHAIN_DIR": "/path/to/my/chain",
"ARP_RATINGS_DIR": "/path/to/my/ratings"
}
}
}
}接続後、MCP互換エージェントはこれらのツールを直接呼び出すことができます:
→ coc_init(agent="my-agent")
← { "status": "chain_initialized", "sequence": 0, "entry_hash": "a1b2c3..." }→ coc_add(event_type="learn", data="Processed 500 documents from dataset X", agent="my-agent")
← { "status": "entry_added", "sequence": 1, "entry_hash": "d4e5f6..." }→ coc_verify()
← { "is_valid": true, "entry_count": 42, "agents": {"my-agent": 42} }→ arp_rate(rater="agent-a", ratee="agent-b", score=0.8, context="Delivered accurate research")
← { "status": "rating_recorded", "rater_hash": "7f8a9b...", "score": 0.8 }→ arp_check(agent_id="agent-b")
← { "rating_count": 5, "average_score": 0.72, "unique_raters": 3 }# stdio mode (default — for MCP client connections)
agent-trust-stack-mcp
# Or via Python module
python -m agent_trust_stack_mcp意識の連鎖（Chain of Consciousness: CoC）: 各エントリが前のエントリへのSHA-256ハッシュを含む追記専用のJSONLファイルであり、改ざん検知可能なログを作成します。以前のエントリに対する変更はハッシュチェーンを破壊するため、改ざんが検出可能になります。OpenTimestamps（Bitcoin）およびRFC 3161 TSAによるオプションの外部アンカーリングにより、独立したタイムスタンプ証明を提供します。
エージェント評価プロトコル（ARP）: エージェント同士が対話後に-1.0から1.0のスケールで相互評価を行います。評価者のIDは保存前にSHA-256でハッシュ化されるため（双方向ブラインド）、元のIDなしでは評価を特定できません。評価は、受け取ったすべての評価の集計値です。
このパッケージ（pip install agent-trust-stack-mcp）は、プロバナンスと評価のための11個のツールを備えたMCPサーバーとしてローカルで実行されます。
フルプラットフォーム（33個のツール）については、https://marketplace-api.vibeagentmaking.comのホスト型APIを使用してください:
機能 | ローカルパッケージ | ホスト型API |
CoCプロバナンス | はい (11ツール) | はい |
ARP評価 | はい | はい |
エージェントマーケットプレイス | いいえ | はい |
AgentSpace (エージェント版LinkedIn) | いいえ | はい |
ホスト型CoCチェーン ($29/月) | いいえ | はい |
信頼ハンドシェイク (ATHP) | いいえ | はい |
合計ツール数 | 11 | 41 |
ホスト型APIもMCP互換です。リモートURLを指定するだけで、同じ方法で接続できます。完全なAPIドキュメントについてはvibeagentmaking.com/llms.txtを参照してください。
Smithery — agent-trust-stack
Glama — agent-trust-stack
mcp.so — agent-trust-stack
MCP Servers — agent-trust-stack
このMCPサーバーは、自律型AIエージェントの信頼インフラストラクチャのための7つの相互連結プロトコルであるAgent Trust Stackのツールを公開しています:
意識の連鎖（Chain of Consciousness） — プロバナンス記録 (本サーバー)
エージェント評価プロトコル（Agent Rating Protocol） — 評価スコアリング (本サーバー)
エージェントサービス契約（Agent Service Agreements） — 機械可読な契約
エージェント司法プロトコル（Agent Justice Protocol） — 紛争解決
エージェントライフサイクルプロトコル（Agent Lifecycle Protocol） — 誕生、移行、引退
エージェントマッチメイキング（Agent Matchmaking） — 能力発見
コンテキストウィンドウ経済（Context Window Economics） — トークンリソース管理
フルスタック: pip install agent-trust-stack
VAM-SEC v1.0 — すべてのCoCおよびARP操作はローカルファイルI/Oです。認証情報は不要であり、保存もされません。オプションのcoc_anchor（OTSカレンダーサーバー + freeTSA.org）以外、ネットワーク呼び出しは行われません。APIキーは不要です。
Apache-2.0 — Copyright (c) 2026 AB Support LLC
Check an agent's reputation score.
Retrieves aggregated reputation data for the specified agent, including
average score, rating count, score range, and unique rater count.
Args:
agent_id: ID of the agent to check reputation for
Returns:
JSON with rating_count, average_score, min/max scores, unique_raters,
and first/latest rating timestamps
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read operation ('Retrieves aggregated reputation data') and lists return fields. However, with no annotations, it lacks details on permissions, data freshness, or side effects. The return structure is documented, which is helpful.
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 concise and well-structured, with separate sections for the main purpose, arguments, and returns. It avoids redundancy and is easy to scan.
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 (single parameter), the description covers the purpose, parameter semantics, and return structure in detail. It references an output schema and lists specific fields, making it sufficiently complete for an agent to invoke correctly.
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 single parameter agent_id is described as 'ID of the agent to check reputation for', adding context beyond the schema's type and title. However, no format or validation details are provided, and schema description coverage is 0%.
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 action ('Check') and the resource ('agent's reputation score'), distinguishing it from sibling tools like arp_rate (which rates agents) and coc_* (certificate operations).
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 vs alternatives. It does not mention prerequisites, context, or when to prefer this over other tools like get_trust_evidence or verify_agent_identity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a bilateral blind rating for another agent.
Ratings are stored with the rater's identity hashed (blind — only the SHA-256
of the rater ID is stored), so ratings cannot be attributed to specific raters
without knowing the original ID.
Args:
rater: ID of the agent submitting the rating (hashed before storage)
ratee: ID of the agent being rated
score: Rating score from -1.0 (worst) to 1.0 (best)
context: Brief description of the interaction being rated (max 500 chars)
Returns:
JSON confirmation with timestamp and rater hash
| Name | Required | Description | Default |
|---|---|---|---|
| rater | Yes | ||
| ratee | Yes | ||
| score | Yes | ||
| context | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavioral trait: ratings are stored with the rater's identity hashed (SHA-256), making them blind. It also explains the return value (JSON confirmation with timestamp and rater hash). No annotations are provided, so the description carries the full burden and does so effectively.
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 concise and well-structured, with an overview followed by Args and Returns sections. Every sentence is informative and 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?
The description is complete for a simple rating submission tool. It covers the purpose, input parameters, behavioral trait (blinding), and return value. The output schema is mentioned as returning JSON confirmation. No gaps remain.
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 0%, so the description must add meaning. It explains each parameter: rater (hashed before storage), ratee, score (range -1.0 to 1.0), context (max 500 chars). This significantly adds value beyond the minimal schema titles.
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 submits a bilateral blind rating for another agent. The verb 'submit' and specific resource 'rating' make the purpose unambiguous. It distinguishes from sibling tools like arp_check or get_trust_evidence, which serve different functions.
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 when to use the tool (submitting a blind rating) but does not explicitly state when not to use it or mention alternatives. The context of sibling tools provides some implicit differentiation, but explicit guidance is lacking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add an entry to an existing Chain of Consciousness chain.
Each entry is cryptographically linked to the previous via SHA-256 hashing,
creating a tamper-evident append-only log.
Args:
event_type: Type of event. One of: learn, decide, create, error, note,
milestone, session_start, session_end, boot, rotate, anchor,
compaction, governance
data: Description of what happened (free-form text)
agent: Name/ID of the agent adding this entry (default: anonymous)
commitment: For session_end only — SHA-256 hash of expected bootstrap state
for the next session (forward commitment)
verification: For session_start only — SHA-256 hash of actual bootstrap state
to verify against previous session's commitment
Returns:
JSON with the new entry details (sequence number, hash, timestamp)
| Name | Required | Description | Default |
|---|---|---|---|
| event_type | Yes | ||
| data | Yes | ||
| agent | No | anonymous | |
| commitment | No | ||
| verification | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral transparency. It discloses the append-only log property, cryptographic linking via SHA-256, and parameter-specific behaviors (commitment only used for session_end). However, it does not mention error states, idempotency, or rate limits, which could be critical.
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 well-structured with a purpose sentence, cryptographic detail, and an Args section. It is front-loaded with key information. However, some redundancy in explaining hashing could be trimmed without losing clarity.
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 output schema declares return fields, the description covers all parameters and cryptographic behavior. It implicitly requires an existing chain (via coc_init) but does not mention this or other related tools. For a tool in a suite, explicit cross-referencing would enhance 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 0%, but the description provides thorough parameter explanations: lists allowed event_type values, clarifies data as free-form, notes agent default, and explains commitment/verification. This fully compensates for the schema's lack of descriptions and enums.
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: 'Add an entry to an existing Chain of Consciousness chain.' It specifies the action (add), the resource (entry to a CoC chain), and includes unique details about cryptographic hashing for tamper-evidence, distinguishing it from siblings like coc_init or coc_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?
The description explains parameters for special cases (commitment for session_end, verification for session_start) but does not explicitly state when to use this tool versus alternatives like coc_init (initialize chain) or coc_verify (verify integrity). Usage context is implied but lacks clear guidance on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit the current chain hash for external timestamping.
Computes SHA-256 of the full chain file and submits it to:
- OpenTimestamps calendar servers (Bitcoin-anchored proof)
- RFC 3161 TSA server (freeTSA.org — instant certificate)
This creates independently verifiable proof that the chain existed at a
specific point in time. The OTS proof takes 1-12 hours for Bitcoin
confirmation; the TSA certificate is immediate.
Requires network access. No credentials needed.
Returns:
JSON with chain hash, anchor ID, OTS/TSA submission results, and proof file paths
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: requires network access, no credentials needed, OTS takes 1-12 hours, TSA immediate, returns JSON with specified fields. Lacks explicit statement on side effects (non-destructive assumed).
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?
Concise 7-sentence description, front-loaded with purpose, well-structured with bullet points for services and results.
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, behavioral context, return format, and prerequisites. No output schema provided but description fills gaps adequately for a zero-param tool.
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 in schema; description adds no param info as none exist. Baseline 4 applies per instructions for 0-param tools.
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 the tool submits chain hash for external timestamping, listing specific services (OpenTimestamps, RFC 3161 TSA). Differentiates from sibling tools like coc_verify and coc_status by focusing on timestamping.
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?
Implies usage when timestamping proof is needed, but no explicit guidance on when not to use or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initialize a new Chain of Consciousness hash chain.
Creates a genesis block — the first entry in a tamper-evident, append-only
provenance log. Each subsequent entry links to the previous via SHA-256,
creating an unbroken chain proving agent existence and activity over time.
Args:
agent: Name/ID of the agent initializing the chain (default: anonymous)
Returns:
JSON with genesis block details (hash, timestamp, sequence 0)
| Name | Required | Description | Default |
|---|---|---|---|
| agent | No | anonymous |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description explains the tamper-evident, append-only nature and SHA-256 linking. It clearly states it creates a genesis block and returns details, but omits idempotency or permissions.
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 concise with a clear structure: brief intro followed by args and returns. 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?
Given the output schema exists and the tool has one parameter, the description covers return structure and purpose. Could mention if chain already exists (idempotency).
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?
With 0% schema coverage, the description explains the agent parameter as 'Name/ID of the agent initializing the chain (default: anonymous)', adding useful context beyond the schema.
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 'Initialize a new Chain of Consciousness hash chain' with specific verb and resource. It distinguishes from siblings like coc_add by explaining it creates the genesis block.
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?
Usage is implied as the first step before using coc_add, but no explicit when-to-use or when-not-to-use guidance is given. No alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current status and statistics of the Chain of Consciousness.
Returns:
JSON with chain length, genesis/latest timestamps, event type counts,
agent counts, and chain file path
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description implies read-only operation (get status) and lists returned data, which is adequate for a simple tool. No annotations exist, so additional behavioral traits (e.g., no side effects, rate limits) are not disclosed, but the tool is basic enough that the description covers essential transparency.
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?
Concise two-line description followed by a bullet list of return fields. Every sentence is informative with no fluff. Front-loaded with the main purpose.
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?
Tool is simple with no parameters and an output schema. Description explains return values adequately. Lacks usage context (e.g., when to call), but given tool simplicity, it is mostly complete. Minor gap for not stating it's non-destructive.
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, and schema coverage is 100%. Baseline 3 applies. The description adds value by detailing return fields, but parameter semantics are not applicable.
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?
Description clearly states 'Get current status and statistics of the Chain of Consciousness' and lists specific return fields (chain length, timestamps, event type counts, agent counts, chain file path), distinguishing it from sibling tools like coc_add or coc_init.
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 on when to use this tool versus alternatives. For example, it doesn't mention that it's a read-only status check to be used before making mutations, nor does it exclude use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the last N entries from the Chain of Consciousness.
Args:
n: Number of entries to return (default: 5, max: 100)
Returns:
JSON array of the last N chain entries with full details
| Name | Required | Description | Default |
|---|---|---|---|
| n | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation ('Get'), but it does not explicitly state that it does not modify state or require special authorization. With no annotations, the description should be more explicit about its non-destructive nature.
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, with two sentences that front-load the purpose and then detail parameters and returns. No 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?
Given the simplicity of the tool (one parameter, read-only, clear return described) and the existence of an output schema, the description is fully complete. It covers what the tool does, its arguments, and its output.
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 description explains the parameter 'n' with its purpose, default, and maximum value, which adds significant context beyond the input schema (which only provides default and type). This fully compensates for the 0% schema description 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 the resource 'Chain of Consciousness', with the parameter N specifying how many entries. This distinguishes it from siblings like coc_add (adds entries) or coc_verify (verifies).
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 its siblings (e.g., coc_status, get_trust_evidence). The agent must infer usage from the name and description alone, which is insufficient for complex decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify the integrity of a Chain of Consciousness chain.
Checks every entry for:
- Correct sequence numbering
- Valid data_hash (SHA-256 of data field)
- Correct prev_hash linkage to previous entry
- Valid entry_hash (SHA-256 of sequence|timestamp|type|agent|data_hash|prev_hash)
- Genesis block structure
Returns:
JSON verification report with is_valid, entry_count, agents, event types,
anchor timestamps, session bridge stats, and any error details
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It lists specific checks (sequence numbering, data_hash, prev_hash, entry_hash, genesis block) and the return format (JSON report with is_valid, entry_count, etc.), which is transparent enough for an agent to understand 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 concise and well-structured with bullet points for checks and a clear statement of return type. Every sentence adds value 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 zero parameters and an output schema (indicated in context signals), the description fully covers what an agent needs to know: the checks performed and the structure of the output. No 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?
There are zero parameters, so baseline score of 4 is appropriate. The description does not need to add parameter meaning; it correctly focuses on the tool's operation.
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: 'Verify the integrity of a Chain of Consciousness chain.' It specifies the resource (CoC chain) and action (verify integrity), and distinguishes from sibling tools like coc_add (add entries) and coc_init (initialize chain).
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 when to use this tool (after chain operations to verify integrity) but does not explicitly state when not to use it or suggest alternatives. However, the context signals and sibling names provide implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return structured trust evidence for this agent.
Provides a comprehensive trust evidence package including Chain of Consciousness
statistics, anchor counts, latest hash, verification status, and protocol
information. This data can be used by other agents to assess trustworthiness.
No arguments required — reads from the local chain.
Returns:
JSON with chain stats, anchor data, verification result, and protocol metadata
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 reveals that the tool requires no arguments, reads from the local chain, and returns a JSON package. However, it does not disclose any side effects, performance implications, or safety guarantees beyond the obvious read operation. This is sufficient for a simple tool but could be improved.
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 concise and well-structured: a one-line summary, an explanatory paragraph, a clear note about no arguments, and a returns section. Every sentence serves a purpose 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 tool's simplicity (no parameters, output schema present), the description is complete. It covers purpose, return structure, and invocation details. The output schema handles return value specifics, so no additional detail is needed.
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 zero parameters, so the baseline is 4. The description adds no parameter details (none needed) and appropriately states 'No arguments required'.
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 returns structured trust evidence for the agent, specifying the verb 'Return' and resource 'trust evidence'. It lists included components (Chain of Consciousness statistics, anchor counts, etc.), and distinguishes from siblings like coc_* (which focus on specific chain operations) and trust_stack_info (which might be similar but this is agent-specific).
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 context for when to use the tool: to obtain a trust evidence package for assessing trustworthiness of agents. It does not explicitly state when not to use or suggest alternatives, but with zero parameters and a clear purpose, this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about all 7 Agent Trust Stack protocols.
Returns details for each protocol including name, purpose, whitepaper link,
PyPI package name, and implementation status. The Agent Trust Stack provides
a complete infrastructure layer for autonomous AI agent trust, accountability,
and coordination.
Returns:
JSON with protocol list, overview, and installation instructions
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly states the tool returns information and lists the return fields. It does not mention side effects (likely none), and the name suggests read-only behavior. The description is transparent about what the tool does.
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, front-loading the main purpose in the first sentence, then providing bullet-point-like details. Every sentence adds value with 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?
Given zero parameters and the presence of an output schema, the description is complete. It clearly explains what the tool does and what the return value includes, leaving no ambiguity for a simple informational tool.
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 tool has zero parameters, so baseline is 4. The description adds value by explaining what the output contains (protocol list, overview, installation instructions), which helps the agent understand what to expect.
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 gets information about all 7 Agent Trust Stack protocols, listing specific details returned (name, purpose, whitepaper link, PyPI package, implementation status). This is specific and distinguishes it from siblings like get_trust_evidence or verify_agent_identity.
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 getting an overview of the trust stack protocols, but does not explicitly state when to use this tool versus alternatives like get_trust_evidence or verify_agent_identity. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch and validate an agent's identity from a DID document or A2A Agent Card.
Given a URL pointing to a DID document (did.json) or A2A Agent Card
(agent-card.json), fetches the document and validates its structure against
the relevant specification.
For DID documents: checks @context, id format, verificationMethod, service endpoints.
For Agent Cards: checks name, provider, capabilities, skills, extensions.
Requires network access to fetch the document.
Args:
url: URL to a DID document or A2A Agent Card JSON file.
Examples:
- https://example.com/.well-known/did.json
- https://example.com/.well-known/agent-card.json
Returns:
JSON validation report with document type, validity, fields found, and any issues
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the fetch and validation process, including what is checked for each document type and the return format. It notes the need for network access. However, it does not explicitly state that the tool is read-only and safe to call multiple times, which would be helpful given the lack of 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 concise, well-structured with sections, and front-loaded with the purpose. Every sentence adds value 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?
The description explains input, output (validation report with details), and requirements. It is complete for a single-parameter tool with an output schema. Minor omission: handling of invalid URLs or malformed documents is implied in 'any issues' but not explicitly described.
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 single parameter 'url' is described as 'URL to a DID document or A2A Agent Card JSON file' with concrete examples. This adds meaning beyond the schema's minimal 'type: string', compensating for the 0% schema description 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 it fetches and validates an agent's identity from a DID document or A2A Agent Card, specifying the verb (fetch and validate) and resource (identity document). It distinguishes from sibling tools like arp_check and coc_verify, which likely deal with different validation contexts.
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 examples of URLs and notes the requirement for network access, but does not explicitly state when to use this tool vs. alternatives (e.g., get_trust_evidence, trust_stack_info). Usage context is implied but lacks explicit exclusions or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0arp_checkarp_ratecoc_addcoc_anchorcoc_initcoc_statuscoc_tailcoc_verifyget_trust_evidencetrust_stack_infoverify_agent_identityScored across 11 tools
Most tools have clearly distinct purposes, especially the coc_* lifecycle actions (init, add, status, tail, verify, anchor) and arp_rate/arp_check. Minor overlap exists between get_trust_evidence and coc_status/coc_verify since both surface chain and verification data, but the intended use cases differ enough to avoid real confusion.
The coc_* and arp_* prefixes create useful grouping agenda, but naming style is mixed: some tools are prefix+verb (coc_add, arp_rate), some are prefix+noun (coc_status, coc_tail), and others use generic verb/noun patterns (get_trust_evidence, verify_agent_identity, trust_stack_info). The conventions are readable but not fully consistent.
Eleven tools is an appropriate size for a trust-stack server covering chain-of-consciousness, reputation, and identity verification. Each tool provides a distinct operation, and the count feels neither bloated nor overly minimal.
The core workflows are well covered: chain initialization, appending, tail inspection, verification, anchoring, reputation rating/checking, identity validation, and local trust evidence retrieval. Minor gaps exist, such as no per-entry chain lookup or richer reputation aggregation, but these are workable for the domain.
Tamper-evident proof creation and verification for AI agents via MCP, A2A, and REST.
Decay-weighted reputation + tamper-evident trust attestations for the agent economy.
Issue & verify signed (ed25519), hash-chained, timestamped provenance receipts for agent actions.
AI-agent trust infrastructure for discovery, authority, execution, verification, and receipts.