MCP(Model Context Protocol) 호환 AI 에이전트가 Agent Trust Stack 도구를 기본적으로 사용할 수 있도록 노출하는 MCP 서버입니다.
7-프로토콜 Agent Trust Stack의 두 가지 운영 프로토콜인 의식의 연쇄(Chain of Consciousness, CoC) 출처 로깅 및 에이전트 평가 프로토콜(Agent Rating Protocol, ARP) 평판 점수 산정 기능을 제공합니다.
도구 | 설명 |
| 새로운 암호화 해시 체인(제네시스 블록) 초기화 |
| 항목 추가 — 학습, 결정, 생성, 오류, 메모, 마일스톤, 세션 시작/종료 |
| 체인 무결성 검증 (해시 연결, 순서, 완전성) |
| 체인 통계 가져오기 (길이, 에이전트, 시간 범위, 이벤트 유형) |
| 마지막 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의식의 연쇄(CoC): 각 항목이 이전 항목과 연결된 SHA-256 해시를 포함하는 추가 전용 JSONL 파일로, 변조 방지 로그를 생성합니다. 이전 항목을 수정하면 해시 체인이 깨지므로 변조를 감지할 수 있습니다. OpenTimestamps(비트코인) 및 RFC 3161 TSA를 통한 선택적 외부 앵커링은 독립적인 타임스탬프 증명을 제공합니다.
에이전트 평가 프로토콜(ARP): 에이전트는 상호 작용 후 -1.0에서 1.0 사이의 척도로 서로를 평가합니다. 평가자의 신원은 저장 전에 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.