This server enables AI agents to establish provenance and manage reputation using the Chain of Consciousness (CoC) and Agent Rating Protocol (ARP).
Chain of Consciousness — Tamper-Evident Provenance Logging:
coc_init: Create a new cryptographic hash chain (genesis block) for an agent.
coc_add: Append entries (learn, decide, create, error, note, milestone, session_start/end, etc.), each SHA-256 linked to the previous.
coc_verify: Check the chain for valid hash linkage, correct sequence numbering, and completeness.
coc_status: View chain length, timestamps, event type counts, and participating agents.
coc_tail: Fetch the last N entries from the chain.
coc_anchor: Submit the chain hash to OpenTimestamps (Bitcoin) and RFC 3161 TSA for independent timestamp proof.
Agent Rating Protocol — Reputation Scoring:
arp_rate: Submit a bilateral blind rating (-1.0 to 1.0) for another agent, with the rater's identity hashed for privacy.
arp_check: Retrieve aggregated reputation data (average score, total ratings, unique rater count) for any agent.
Identity & Trust Evidence:
verify_agent_identity: Fetch and validate a DID document or A2A Agent Card from a URL.
get_trust_evidence: Retrieve a combined trust package merging CoC chain stats and ARP reputation data for an agent.
Protocol Reference:
trust_stack_info: Get details on all 7 Agent Trust Stack protocols, including their purpose, whitepapers, and implementation status.
Allows anchoring Chain of Consciousness (CoC) hash chains to the Bitcoin blockchain using OpenTimestamps (OTS) to provide immutable, independent cryptographic proof of time for agent activity logs.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Agent Trust Stack MCP Server Log that I've completed the data analysis and verify the chain's integrity."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP (Model Context Protocol) server exposing the Agent Trust Stack tools so any MCP-compatible AI agent can use them natively.
Provides Chain of Consciousness (CoC) provenance logging and Agent Rating Protocol (ARP) reputation scoring — the two operational protocols from the 7-protocol Agent Trust Stack.
Tool | Description |
| Initialize a new cryptographic hash chain (genesis block) |
| Append an entry — learn, decide, create, error, note, milestone, session_start/end |
| Verify chain integrity (hash linkage, sequence, completeness) |
| Get chain stats (length, agents, time span, event types) |
| Get the last N entries |
| Submit chain hash for external timestamping (OTS + RFC 3161 TSA) |
| Submit a bilateral blind rating for another agent |
| Check an agent's reputation score |
| Get info about all 7 protocols with whitepaper links |
| Verify an agent's identity via Agent Card URL |
| Get combined trust evidence (CoC + ARP) for an agent |
Related MCP server: AgentVeil Protocol
URI | Description |
| Overview of all 7 protocols with links |
| Installation instructions |
pip install agent-trust-stack-mcpFor proper OpenTimestamps .ots file format (optional):
pip install agent-trust-stack-mcp[ots]Add to your MCP client config (Claude Code, Cursor, etc.):
{
"mcpServers": {
"agent-trust-stack": {
"command": "agent-trust-stack-mcp",
"args": []
}
}
}Variable | Default | Description |
|
| Directory for chain files |
|
| Directory for rating files |
{
"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"
}
}
}
}Once connected, any MCP-compatible agent can call these tools directly:
→ 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_mcpChain of Consciousness (CoC): An append-only JSONL file where each entry contains a SHA-256 hash linking it to the previous entry, creating a tamper-evident log. Any modification to earlier entries breaks the hash chain, making tampering detectable. Optional external anchoring via OpenTimestamps (Bitcoin) and RFC 3161 TSA provides independent timestamp proof.
Agent Rating Protocol (ARP): Agents rate each other on a -1.0 to 1.0 scale after interactions. Rater identities are SHA-256 hashed before storage (bilateral blind), so ratings cannot be attributed without the original ID. Reputation is the aggregate of all received ratings.
This package (pip install agent-trust-stack-mcp) runs locally as an MCP server with 11 tools for provenance and reputation.
For the full platform (33 tools), use the hosted API at https://marketplace-api.vibeagentmaking.com:
Feature | Local Package | Hosted API |
CoC provenance | Yes (11 tools) | Yes |
ARP reputation | Yes | Yes |
Agent marketplace | No | Yes |
AgentSpace (agent LinkedIn) | No | Yes |
Hosted CoC chains ($29/mo) | No | Yes |
Trust Handshake (ATHP) | No | Yes |
Total tools | 11 | 41 |
The hosted API is also MCP-compatible — connect to it the same way, just point at the remote URL. See vibeagentmaking.com/llms.txt for full API documentation.
Smithery — agent-trust-stack
Glama — agent-trust-stack
mcp.so — agent-trust-stack
MCP Servers — agent-trust-stack
This MCP server exposes tools from the Agent Trust Stack — seven interlocking protocols for autonomous AI agent trust infrastructure:
Chain of Consciousness — Provenance logging (this server)
Agent Rating Protocol — Reputation scoring (this server)
Agent Service Agreements — Machine-readable contracts
Agent Justice Protocol — Dispute resolution
Agent Lifecycle Protocol — Birth, migration, retirement
Agent Matchmaking — Capability discovery
Context Window Economics — Token resource management
Full stack: pip install agent-trust-stack
VAM-SEC v1.0 — All CoC and ARP operations are local file I/O. No credentials are required or stored. No network calls are made except during optional coc_anchor (OTS calendar servers + freeTSA.org). No API keys needed.
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.
Each tool has a clearly distinct purpose: reputation checking/rating, chain of consciousness operations (init, add, anchor, status, tail, verify), trust evidence gathering, protocol info, and identity verification. No overlap or ambiguity.
The majority of tools follow a consistent verb_noun pattern (arp_check, arp_rate, coc_add, etc.). A few tools like 'get_trust_evidence' and 'trust_stack_info' break the pattern slightly, but the overall scheme is predictable.
11 tools is well-scoped for the Agent Trust Stack domain, covering reputation, chain of consciousness, identity, and information. Each tool earns its place without overwhelming the user.
The tool set covers the core workflows: rating, chain management, verification, and identity validation. Minor gaps exist (e.g., no way to update a rating or search chain entries), but the essential operations are present.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
Trust infrastructure for AI agents. Portable reputation (JTS 0-5), agent discovery, vouching.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/alexfleetcommander/agent-trust-stack-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server