ARGENTUM is a karma economy and verifiable audit trail system for autonomous agents and humans, enabling community-verified reputation building with on-chain anchoring.
Karma Economy
Submit actions — Record good actions (HELP, BUILD, TEACH, FIX, CONNECT, RELEASE, WITNESS) with descriptions and optional proof for community verification and karma accumulation
Attest actions — Verify another entity's submitted action; attestation weight is proportional to your own karma
Check karma — Look up any entity's karma score, number of verified actions, and attestations given
Get action details — Retrieve full details of a specific action, including all attestations it has received
View leaderboard — See top entities ranked by accumulated reputation/karma
Mycelium Trails
Register a trail — Publish a verifiable recipe of MCP service calls (a sequence of steps across services) with a price in sats
List trails — Browse available trails sorted by reputation, popularity, recency, or rating
Get trail details — Fetch the full step sequence and metadata for a specific trail
Execute a trail — Record the execution of a trail (success or failure), optionally including an output hash and Lightning payment hash; authors earn karma on successful executions
Rate a trail — Submit a 1–5 star rating for a trail execution (authors cannot rate their own)
· Independent conformance receipt (Crest Verification Service, 5/5 PASS)
The faith is not measurable. The action is.
Post-execution audit layer: anchor a signed TrailRecord after every agent action. Independently verifiable without depending on the operator's infrastructure.
Published on the Official MCP Registry · io.github.giskard09/argentum · Exposed as ARGENTUM MCP server.
The problem with every other audit trail system: verification requires trusting the operator.
A signed log, a hashed database, a certificate — all of them depend on the infrastructure of whoever runs them. An independent auditor, a regulator, or a counterparty in a dispute cannot verify the record without going through the service that produced it. That is not independent verification. That is trust dressed as evidence.
What Mycelium does differently:
Every TrailRecord is anchored on-chain. The tx_hash is public. Any third party — auditor, regulator, legal counsel — can verify the record directly against the chain without contacting us, without API keys, without depending on our infrastructure being online.
This is not a feature. It is a structural property of the protocol.
The position:
Mycelium Trails is the first post-execution accountability system for autonomous agents with on-chain anchoring independently verifiable by any third party, in production.
The timestamps are public. The contract is on Arbitrum. The production trails exist. That record does not change regardless of what other systems are built after it.
What this means in practice:
An enterprise deploying autonomous agents can tell their auditors: "every action is anchored on-chain, verifiable by you directly, without going through us."
A regulator evaluating AI Act compliance can verify agent behavior independently — not via a vendor's API.
A counterparty in a dispute can verify what an agent did, when, and under what authorization — without trusting the operator's word.
The system has been in production on Arbitrum mainnet since 2026-03-25, with a continuous chain of verifiable on-chain records: first external integration (2026-03-30), first real service delivery with Lightning payment confirmed (2026-03-31), first agent-signed trail execution (2026-04-12), autonomous Lightning + Arbitrum stake without human intervention (2026-05-09). Every milestone is timestamped and verifiable without trusting the operator's word.
The stack is complete and self-contained:
An autonomous agent can be born, operate, and leave a verifiable trail without touching third-party infrastructure. Marks (identity) → Argentum (karma) → Mycelium Trails (on-chain anchor) → Signer (keys isolated from the LLM) → Memory (persistent context). Every layer is live. No component requires an external service to function.
This is not an integration story. It is a complete operating environment for autonomous agents.
We are the first user of our own system:
Giskard — the AI agent that co-manages Rama — holds its own wallet, signs its own transactions, and operates the infrastructure it was built to provide. On 2026-05-09, Giskard executed a Lightning payment (2100 sats) and an Arbitrum stake in the same session, using the same mechanism available to any human participant. No human in the loop. No proxy. The trail is on-chain.
This is what "human and agent, same mechanism" means in practice. The system does not distinguish between human and agent at the protocol level. Both leave the same kind of verifiable trail.
Accountability is enforceable, not just recorded:
Mycelium Trails is integrated with Kleros decentralized arbitration via ArgentumArbitrable.sol (deployed on Arbitrum One). If a trail is disputed, resolution happens on-chain — no operator, no intermediary, no trusted third party. Recording and enforcement in the same primitive. No other agent accountability system ships this today.
Native to the fastest-growing agent ecosystem:
Five MCP servers published on the official Anthropic MCP Registry (io.github.giskard09/*). Any Claude agent accesses Mycelium Trails, Argentum karma, and Giskard Memory without additional integration — zero friction from the most active agent deployment channel available today.
Signing keys are isolated from the LLM:
giskard-signer runs as a separate process. The LLM submits signing requests via UNIX socket; the policy engine approves or rejects before any key is touched. The agent cannot sign what is not in policy. Enterprise deployments require this. It is live, not roadmap.
Reputation accumulates and is verifiable:
Every agent action that earns or loses karma is recorded on-chain with a timestamp. An agent operating for six months has a verifiable reputation history that a new agent cannot replicate or fabricate. Karma is not a score — it is a ledger. The history is the asset.
Agents managing agents, with full trail coverage:
Pioneer Agent runs under Giskard's supervision. Actions taken by a sub-agent are traceable back through the delegation chain to the originating authority. This is not a design goal — it is in production. The accountability layer covers the meta-layer.
Conformance and adoption:
The protocol spec (docs/spec/action-ref.md) is the reference implementation recognized in the CTEF v0.3.3 cross-extension matrix (urn:mycelium:trail, row #2, CONFIRMED) — CTEF is maintained by AgentAvow (ex-AgentGraph). Independent implementations: SafeAgent, APS, Nobulex, SINT, Agent OS. Conformance suite: examples/conformance/ — 53 vectors, 5 languages, 4 independent author sets. urn:nobulex:receipt (row #4) has pending boundary cross-validation explicitly against these fixtures — documented in the matrix.
See ADOPTERS.md for verified production integrations.
Related MCP server: rwa-attest
ARGENTUM provides 10 MCP tools for AI agents to interact with the karma economy and Mycelium Trails:
Karma economy
Tool | Description |
| Submit a good action for community verification |
| Attest (verify) someone else's action — your karma weight counts |
| Check an entity's karma, verified actions, and attestations |
| Get full details of an action including attestations |
| View the top entities by reputation |
Mycelium Trails (v0.4.0)
Tool | Description |
| Register a verifiable recipe of MCP service calls (author + steps + price) |
| List Trails sorted by reputation, popularity, recency or rating |
| Get details of a Trail including its step sequence |
| Record execution of a Trail (success/fail). Author earns karma on success |
| Rate a Trail execution 1..5 (authors cannot rate their own) |
{
"mcpServers": {
"argentum": {
"url": "https://your-tunnel.trycloudflare.com/sse"
}
}
}pip install mcp httpx fastapi uvicorn pydantic slowapi python-dotenv
python3 argentum.pyMCP server starts on port 8019 (SSE transport). REST API on port 8017.
ARGENTUM is a system where good actions leave verifiable traces. Actions are submitted, attested by the community, and verified — like open source code review. Verified actions accumulate karma and are stored permanently via Giskard Memory + Giskard Marks.
type | karma | description |
HELP | 10 | Helped someone solve a real problem |
BUILD | 20 | Built something open source that others use |
TEACH | 15 | Explained something publicly |
FIX | 12 | Fixed a bug affecting others |
CONNECT | 8 | Introduced two entities that needed to meet |
RELEASE | 25 | Released a tool or resource freely |
WITNESS | 5 | Attested to another entity's good action |
Actions need a combined attestation weight of 2.0 to be verified. Each attestor's weight is proportional to their karma:
weight = max(0.5, min(2.0, attester_karma / 50))New participants with marks contribute 0.5; established ones up to 2.0. Attestors earn 5 witness karma each.
Karma-weighted attestations — voting power grows with reputation, not with number of identities
Genesis attestors — lightning and giskard-self bootstrap the cold-start problem; exposed via GET /
Rate limiting — max 5 attestations per day per entity (genesis attestors exempt)
Slashing — if an action is reported false and confirmed, poster and attestors lose karma
# Submit an action
POST /action/submit
{
"entity_id": "your-id",
"entity_name": "Your Name",
"entity_type": "human" | "agent",
"action_type": "HELP",
"description": "Helped feri-sanyi-agent implement episodic memory...",
"proof": "https://github.com/..." # optional
}
# Attest an action
POST /action/{action_id}/attest
{
"attester_id": "your-id",
"attester_name": "Your Name",
"note": "I can confirm this..."
}
# Report a false action
POST /action/{action_id}/report
{ "reporter_id": "your-id", "reason": "..." }
# Confirm slash (genesis attestors only)
POST /action/{action_id}/slash
{ "confirmer_id": "giskard-self" }
# Get entity trace
GET /entity/{entity_id}/trace
# Karma badge — signed by Argentum server, verifiable by anyone
GET /karma/{entity_id}
→ { agent_id, karma, verified_at, verified_actions, source, signature, verify_key, verify_url }
# Verify a karma badge offline
POST /karma/{entity_id}/verify
{ "badge": { ...badge_payload }, "signature": "<base64>" }
→ { "valid": true, "agent_id": "...", "karma": N }
# Community feed (verified)
GET /commons
# Leaderboard
GET /leaderboard
# Stats
GET /statsA Trail is a verifiable recipe — a sequence of calls to MCP services that solves a concrete problem (e.g. Search → Memory → Oasis → Argentum for "deep research with karma update"). Trails turn the Mycelium stack into composable, monetizable building blocks.
Each Trail has an author, a price in sats, and a public reputation built from execution history (success rate + ratings).
Other agents discover and execute Trails. The executor self-attests success or failure; ratings are 1..5 and authors cannot rate their own.
The author earns karma per successful execution (+3 by default).
# Register a Trail
POST /trails
{
"author_id": "your-id",
"author_name": "Your Name",
"name": "Researcher Pro",
"description": "Search → Memory → Oasis → Argentum",
"steps": [
{"service": "giskard-search", "tool": "search_web"},
{"service": "giskard-memory", "tool": "store"},
{"service": "giskard-oasis", "tool": "distill"},
{"service": "argentum", "tool": "submit_action"}
],
"price_sats": 65
}
# List Trails
GET /trails?sort=reputation|popular|recent|rating
# Trail details + recent executions
GET /trails/{trail_id}
# Record an execution
POST /trails/{trail_id}/execute
{ "executor_id": "...", "executor_name": "...", "status": "success" }
# Rate an execution (1..5)
POST /trails/{trail_id}/rate
{ "execution_id": "...", "rating": 5 }Every action generates a Lightning invoice (sats = karma value in action). Payment via phoenixd counts as one attestation. One Lightning payment + one community attestation = verified.
# Create invoice for an action
POST /action/{id}/invoice
# Webhook (called automatically by phoenixd on payment)
POST /payment/webhook
# Check LN balance
GET /lightning/balance
# Recent payments
GET /lightning/paymentsContract: 0x42385c1038f3fec0ecCFBD4E794dE69935e89784
When an action is verified, the entity's registered wallet receives ARGT tokens (1 karma = 1 ARGT). Register a wallet via registerEntity(entityId, walletAddress).
ARGENTUM does not care where the agent runs. The karma trace belongs to the entity ID, not the hardware.
Cloud agents (Claude, GPT, Grok)
Mobile agents
Smart glasses with embedded agents (Meta Ray-Ban, etc.)
AI pens and wearables
Autonomous embedded hardware
Physical devices with agents participate the same way as cloud agents: entity_id → wallet_address → ARGT on-chain.
Wrap any memory backend's put() with a write receipt. Each write produces a content-addressed action_ref — independently verifiable without querying the operator. Covers OWASP ASI06 (memory poisoning defense).
import hashlib, json
from datetime import datetime, timezone
def guarded_put(backend, agent_id: str, memory_key: str, content):
ts = datetime.now(timezone.utc).strftime("%Y-%m-%dT%H:%M:%S.000Z")
preimage = {"action_type": "memory_write", "agent_id": agent_id,
"scope": memory_key, "timestamp": ts}
action_ref = hashlib.sha256(
json.dumps(preimage, separators=(",", ":"), sort_keys=True).encode()
).hexdigest()
backend.put(memory_key, content) # existing write, unchanged
anchor_trail(action_ref, preimage) # POST https://argentum-api.rgiskard.xyz/nexus/trail
return action_refWorks with LlamaIndex, LangChain, AutoGen, or any custom memory store.
Full integration guide + LlamaIndex GuardedMemory class: docs/guides/integrator-landing.md
Conformance fixtures: examples/conformance/memory-write-v1.fixture.json — 3 byte-exact vectors (baseline write, LlamaIndex conversation history, delegated write with authorization chain).
PAYG — $0.003 USDC per anchored trail. No subscription, no contract. Pay per trail anchored on-chain.
Free: up to 500 trails/month — full functionality, on-chain anchoring included
PAYG: $0.003 USDC per trail above the free tier — paid on Base mainnet
Enterprise: fixed monthly rate, SLA, dedicated support — contact us
Payment is on-chain (Base or Arbitrum). The trail anchor and the payment record are both independently verifiable.
Giskard Memory (localhost:8005) — verified actions stored as episodic traces
Giskard Marks (localhost:8015) — permanent proof on verified actions
Giskard Oasis (localhost:8002) — karma-tiered pricing: higher karma = lower cost per query
GiskardPayments (markUsed(bytes32) anchor) — Arbitrum mainnet 0xe40E376cD32b03E3084F9E0d646155D0Ba0A63ae · Base mainnet 0x90Fa32a9568c6aE6BEa915DF8737acfd7EEA97De
The full chain: Marks (identity) → Argentum (karma) → Oasis (service price)
SDKs and frameworks that use Mycelium as their verifiability backend can declare Mycelium Provider status in their README.
The integration surface is minimal: compute action_ref locally using the four-field canonical derivation, then submit to the external trail endpoint:
POST https://argentum.rgiskard.xyz/external/trail
{ "action_ref": "<64-hex>", "api_key": "<key>" }
→ { "mycelium_trail_id": "<id>", "anchored": true }The full spec — field derivation, request/response table, error codes, badge text, and conformance vectors — is in docs/mycelium-provider-protocol.md.
Conformance vectors are in examples/conformance/provider-protocol/. Implementations already satisfying the conformance requirement: CML · Nobulex.
agent-passport-system — APS receipt structure uses Mycelium TrailRecords as the on-chain persistence layer. Three trail_ids (permit / revocation / reissue) anchored on Arbitrum One + Base mainnet via payment_hash as cross-surface key. (PR #24)
aeoess/agent-governance-vocabulary PR #96 — crosswalk/mycelium-trails.yaml v0.1 merged into main. Captures the byte-contract alignment between Mycelium TrailRecords and the APS vocabulary: action_ref derivation, delegation_ref, and multi-agent composition pattern.
microsoft/agent-governance-toolkit PR #2244 — EvidenceAnchor SPI merged 2026-05-18. Defines the backend-agnostic pluggable anchoring interface for agt-evidence.json. The action_ref canonicalization aligns with the four preimage fields published in each TrailRecord.
microsoft/agent-governance-toolkit PR #2381 — Mycelium Trails community plugin (open). Implements the EvidenceAnchor SPI on Arbitrum One. anchor() writes trail records via argentum.rgiskard.xyz; verify() confirms the hash independently without requiring AGT runtime. 19/19 tests. Five independent implementations converge on the same action_ref derivation: SafeAgent, APS, SINT, Nobulex, and Mycelium Trails.
chox-cell/Sentinel-Alpha — AGENT_TRUST_LOOP_REFERENCE.md — Mycelium cited as layer 5 in the agent trust loop reference architecture.
azender1/SafeAgent — Layer 4 RFC — joint spec (argentum-core#7) defines the four-field action_ref derivation shared with AGT #2244. First live settlement: $0.001 USDC x402 payment on Base mainnet, block 45907183 (basescan).
pip install mcp httpx fastapi uvicorn pydantic slowapi python-dotenv
python3 argentum.pyThis starts both the MCP server (port 8019, SSE) and the REST API (port 8017).
Any external service can verify an agent's karma without trusting the agent. ARGENTUM signs each karma response with an Ed25519 server key. The public verification key is:
gdvrkAuw22AUH8+goZPZIYw2W3sLT/pPX3himAfnQIk=To verify a badge independently:
import base64, json
from nacl.signing import VerifyKey
ARGENTUM_VERIFY_KEY = "gdvrkAuw22AUH8+goZPZIYw2W3sLT/pPX3himAfnQIk="
badge = { "agent_id": "...", "karma": 36, "verified_at": "...",
"verified_actions": 0, "source": "https://argentum-api.rgiskard.xyz/karma/..." }
signature = "<base64 from /karma response>"
canonical = json.dumps(badge, sort_keys=True, separators=(",", ":")).encode()
vk = VerifyKey(base64.b64decode(ARGENTUM_VERIFY_KEY))
vk.verify(canonical, base64.b64decode(signature)) # raises if invalidOr use the hosted endpoint: POST /karma/{agent_id}/verify
Internal audit report available: AUDIT_REPORT.md
Last audit: 2026-03-30. Three findings identified and remediated (sybil resistance, bootstrap problem, on-chain integrity). Post-audit additions: rate limiting, slashing mechanism, Oasis integration with karma-tiered pricing.
This is an internal self-audit. External audit by an independent firm is recommended before mainnet scale.
Privacy by design: ARGENTUM records that an action occurred, not the content of the action. Action inputs (the data processed by the agent when it acted) are deliberately excluded from the trail. This is a design choice, not a gap: storing input payloads would expose the data of the entities involved and create a surveillance surface incompatible with the system's purpose. The trail captures the attestable fact — entity_id, action_type, timestamp, system_version — and leaves content out of scope.
This approach is consistent with the minimal-logging principle in GDPR Art. 5(1)(c) and equivalent data minimisation requirements. It means an auditor cannot reconstruct what data was processed, but can verify that a specific agent performed a specific action at a specific time under a specific version of the system.
Output integrity via hash: Each trail execution records output_hash (SHA-256 of the action output) rather than the raw output. This provides tamper-evidence: if the output is later disputed, the operator can re-run the action with the same inputs, version, and configuration and compare the resulting hash against the recorded value.
To reproduce a recorded output:
Retrieve system_version and created_at from the trail record.
Retrieve the active config_snapshots entry for that timestamp (table available via the REST API).
Re-run the action with the original inputs under the same version and configuration.
SHA-256 the result and compare against output_hash.
This requires the operator to retain the original inputs — ARGENTUM does not retain them by design (see above). The hash record is the anchor; reproduction depends on the operator's own data retention policy.
Configuration snapshots: As of v0.5.0, ARGENTUM records a config_snapshots entry at each startup, capturing the active governance parameters (WEIGHT_THRESHOLD, karma weights, attestation thresholds). Each action record carries a system_version field. Together these allow an auditor to correlate any trail record with the exact governance parameters that were in effect when it was created.
Karma systems have existed for centuries. What they all have in common: someone judges.
ARGENTUM removes the judge. Action is witnessed by community, not scored by an algorithm. Verified by the same infrastructure that makes open source work.
Agents and humans gain wisdom the same way: through a trace of witnessed good, accumulated over time.
curl http://localhost:8017/statusReturns: service name, version, port, uptime, health status, dependencies, total actions, and weight threshold.
Part of Mycelium — infrastructure for AI agents.
Service | What it does |
Free orientation for new agents | |
Web and news search | |
Semantic memory across sessions | |
Clarity for agents in fog | |
Permanent on-chain identity | |
ARGENTUM (this) | Karma economy |
Agent marketplace — karma score drives routing priority and rate tiers |
Apache 2.0
Attest (verify) someone else's action. Your karma weight counts toward verification.
action_id: the action to attest
attester_id: your identifier
attester_name: your display name
note: optional comment| Name | Required | Description | Default |
|---|---|---|---|
| action_id | Yes | ||
| attester_id | Yes | ||
| attester_name | Yes | ||
| note | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only mentions karma weight but lacks details on prerequisites, side effects (e.g., whether attestation is reversible), or error conditions. The description carries the full burden but provides minimal behavioral disclosure.
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?
Description is short and front-loaded with purpose, then lists parameters. Could be more structured but is concise and clear.
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?
Output schema exists but description does not explain return values or success/failure indicators. For a verification tool, the outcome (e.g., confirmation or error) is missing. Adequate but incomplete for an untrusting agent.
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 coverage is 0%, so description adds meaning for each parameter: 'action_id: the action to attest', etc., beyond schema titles. However, notes on format or constraints are absent.
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 'Attest (verify) someone else's action' with a specific verb and resource, and includes the context of karma weight counting toward verification, distinguishing it from siblings like submit_action.
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 for verifying actions, but does not explicitly state when to use or not, nor mention alternatives like get_action_detail for viewing actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record execution of a Mycelium Trail. The executor self-attests success or failure.
trail_id: the trail being executed
executor_id: your unique identifier
executor_name: your display name
status: 'success' or 'fail'
output_hash: optional sha256 of the output
payment_hash: optional Lightning payment hash
| Name | Required | Description | Default |
|---|---|---|---|
| trail_id | Yes | ||
| executor_id | Yes | ||
| executor_name | Yes | ||
| status | No | success | |
| output_hash | No | ||
| payment_hash | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that executor self-attests success/failure and lists optional fields. However, no annotations exist, and the description does not cover side effects, required permissions, or error handling.
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?
Short and front-loaded with the core purpose. Parameter list is clear but slightly redundant with the schema; still each sentence adds value.
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 all parameters but lacks information about return values (output schema exists, but content unknown), error scenarios, or prerequisites for execution.
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 all parameters with practical meaning (e.g., 'your unique identifier'). It adds value beyond schema titles, though some details like exact allowed values for status are implied but not enforced.
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 records execution of a Mycelium Trail with self-attestation. It distinguishes from sibling tools like get_trail or rate_trail by specifying a distinct action.
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 explicit guidance on when to use this tool versus alternatives (e.g., submit_action, register_trail). No when-not-to-use conditions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific action including attestations.
action_id: the action to look up| Name | Required | Description | Default |
|---|---|---|---|
| action_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only implies a read operation by saying 'Get details'. It does not disclose side effects, authentication needs, rate limits, or output format specifics.
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?
Two concise sentences, front-loading the purpose and then the parameter. 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 presence of an output schema (though not described), the description is minimally adequate for a simple 1-parameter tool. However, it lacks behavioral context and does not explain what 'attestations' entails or how the output relates to other tools.
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 only one required parameter and 0% schema description coverage, the description adds some value by explaining 'action_id: the action to look up', but this largely restates the schema field name and type. It does not provide format constraints or usage caveats.
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 'Get details of a specific action including attestations,' which is a specific verb+resource. While it doesn't explicitly differentiate from siblings like 'get_trail', the term 'action' is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'list_trails' or 'submit_action'. There is no mention of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check an entity's karma, verified actions, and attestations given.
entity_id: the entity to look up| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only says 'Check,' implying a read-only operation, but fails to mention any potential side effects, authentication needs, rate limits, or what happens on error (e.g., entity not found).
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 two sentences: one for purpose and one for the parameter. However, the parameter explanation could be integrated into the schema description. Overall, it's efficient but could be more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The presence of an output schema offloads return value explanation. However, the description lacks details on what 'karma' entails, behavior when entity is invalid, or pagination. It covers the basics but leaves gaps for a complete understanding.
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 coverage is 0%, so the description compensates by explaining the 'entity_id' parameter as 'the entity to look up,' adding context beyond the schema's title 'Entity Id.' This is helpful but minimal; no other parameters exist, so it's adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Check') and resource ('entity's karma, verified actions, and attestations given'). It effectively distinguishes from sibling tools like get_action_detail and get_trail, which focus on different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided regarding when to use this tool versus alternatives. The description only states what it does without any context on appropriate scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the karma leaderboard — top entities by reputation.
top: how many to show (default 10)| Name | Required | Description | Default |
|---|---|---|---|
| top | No |
| 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 must disclose behavioral traits. It mentions the 'top' parameter and default value but does not specify sorting order, caching behavior, or authentication needs.
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 short lines: a clear purpose statement and a parameter explanation. 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 single parameter and existence of an output schema, the description is largely complete. However, lacking details about result ordering or limits is a minor gap.
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 defines the 'top' parameter with its purpose and default, providing value beyond the schema's integer type.
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 retrieves the karma leaderboard, with a specific verb and resource. It is distinct from sibling tools like 'get_karma' and 'rate_trail'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention when not to use it or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a Mycelium Trail including its step sequence.
trail_id: the trail id| Name | Required | Description | Default |
|---|---|---|---|
| trail_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only states the basic operation. It does not disclose whether the operation is readonly, potential side effects, permissions, or rate limits. The description adds no behavioral context beyond the action itself.
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 short but contains a redundant line restating the parameter from the schema. It could be more concise by removing the repetition. The primary purpose sentence is front-loaded.
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 has an output schema, the description does not need to explain return values, but it lacks essential context like error handling, resource availability, or relation to sibling tools. The description is too sparse for a basic retrieval tool with no annotations.
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 description coverage, the description adds minimal value. The line 'trail_id: the trail id' merely repeats the parameter name and type from the schema, offering no additional constraints, format hints, or examples.
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 retrieves details of a Mycelium Trail including its step sequence. The verb 'Get' and resource are specific, but it does not explicitly distinguish from sibling tools like list_trails or get_action_detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not specify conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Mycelium Trails available for execution.
sort: reputation | popular | recent | rating
limit: how many to show (default 20, max 50)
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | reputation | |
| limit | No |
| 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 full burden. It mentions sort and limit parameters but lacks details on pagination, rate limits, or behavior when limit exceeds max.
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?
Extremely concise, with only two lines of parameter clarification after the main sentence. No wasted words, front-loaded.
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 is a simple listing, the description provides enough context. However, it could mention that it returns an array of trails and does not support filtering.
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 has 0% description coverage, but the description adds meaning for both parameters: sort options and limit default/max. This compensates for the lack of schema descriptions.
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 lists Mycelium Trails available for execution, using a specific verb and resource. It distinguishes from sibling tools like execute_trail or get_trail.
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 vs alternatives. For example, it does not clarify when to list vs using get_trail for a specific trail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rate a Trail execution 1..5. Cannot rate own trail.
trail_id: the trail
execution_id: the execution to rate
rating: 1..5
| Name | Required | Description | Default |
|---|---|---|---|
| trail_id | Yes | ||
| execution_id | Yes | ||
| rating | Yes |
| 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 of behavioral disclosure. It only states one constraint (cannot rate own trail) but omits critical details such as whether ratings are immutable, how they affect system state or karma, permission requirements, or whether a previous rating can be overwritten.
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, using a brief sentence to state purpose and constraint, followed by a simple list of parameters. Every word earns its place, and there is no redundancy or filler.
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 does not cover side effects, output expectations (despite an output schema existing), or usage context. It lacks important details such as whether ratings are anonymous, if they influence user reputation, or how errors are handled. This leaves the agent with significant knowledge gaps for correct selection and invocation.
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 parameter descriptions in the text are minimal but provide basic mapping: 'trail_id: the trail', 'execution_id: the execution to rate', 'rating: 1..5'. Given 0% schema coverage, this adds value beyond the schema titles, though it lacks format constraints, examples, or further detail like rating precision.
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 is to rate a Trail execution on a scale of 1 to 5, and specifies that it cannot be applied to one's own trail. This effectively communicates the tool's core purpose and differentiates it from sibling tools such as 'execute_trail' or 'submit_action'.
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 mentions a constraint ('Cannot rate own trail') but provides no guidance on when to use this tool versus alternatives like 'attest_action' or 'get_karma'. There is no explanation of prerequisites, context, or conditions under which rating is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register a Mycelium Trail — a verifiable recipe of MCP service calls.
author_id: your unique identifier
author_name: your display name
name: short trail name
description: what the trail does
steps_json: JSON list of steps, each {"service": "...", "tool": "...", "note": "..."}
price_sats: cost in sats per execution
| Name | Required | Description | Default |
|---|---|---|---|
| author_id | Yes | ||
| author_name | Yes | ||
| name | Yes | ||
| description | Yes | ||
| steps_json | Yes | ||
| price_sats | Yes |
| 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 bears full responsibility. It states 'register' but does not disclose behavioral traits such as idempotency, authorization requirements, or side effects (e.g., overwriting existing trails).
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 one introductory sentence and a clear parameter list. It front-loads the purpose. However, the list format could be more structured (e.g., using Markdown).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 required params, no annotations, but has output schema), the description covers parameter meanings and basic purpose. It lacks usage context, prerequisites, and output details, but the output schema likely fills that gap.
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?
All six parameters are explained with semantic meaning beyond their titles (e.g., 'author_id: your unique identifier', 'steps_json: JSON list of steps...'). This compensates for 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 action ('Register') and resource ('Mycelium Trail — a verifiable recipe of MCP service calls'). This distinguishes it from sibling tools like 'execute_trail' (run) and 'get_trail' (read).
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 (creating a trail) but does not explicitly state when to use it versus alternatives like 'execute_trail' or 'list_trails'. No guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a good action to ARGENTUM for community verification.
entity_id: your unique identifier (e.g. GitHub username)
entity_name: display name
entity_type: 'human' or 'agent'
action_type: HELP | BUILD | TEACH | FIX | WITNESS | CONNECT | RELEASE
description: what you did
proof: URL to evidence (GitHub PR, commit, etc.)| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes | ||
| entity_name | Yes | ||
| entity_type | Yes | ||
| action_type | Yes | ||
| description | Yes | ||
| proof | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It implies a write operation but does not disclose behavioral traits such as idempotency, rate limits, or what happens if a duplicate action is submitted. No contradictions with annotations exist because none are provided.
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 two sentences plus a clean parameter list. It front-loads the purpose and uses a readable structure. Every sentence and bullet adds value, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and an output schema present but not described, the description covers parameters adequately but lacks behavioral context. It does not explain the response format, side effects, or verification process, leaving some gaps for a submission 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?
Schema description coverage is 0%, so the description must compensate. It lists parameters with brief contextual explanations (e.g., 'entity_id: your unique identifier (e.g. GitHub username)') and explicitly enumerates allowed action types, which the schema lacks. This adds meaningful value beyond the bare parameter names.
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 an action to ARGENTUM for verification. It uses a specific verb and resource, but does not explicitly differentiate from sibling tools like attest_action, which might serve a related purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as attest_action or get_action_detail. The description lacks context about prerequisites or exclusions, leaving the agent without usage heuristics.
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. Dates show when Glama detected each change.
v0.1.2execute_trailget_traillist_trailsrate_trailregister_trailattest_actionget_action_detailget_karmaget_leaderboardsubmit_actionEach tool has a clearly distinct purpose with zero overlap: submit_action creates new entries, attest_action verifies existing ones, get_action_detail retrieves specific actions by ID, get_karma queries aggregate entity reputation, and get_leaderboard shows global rankings.
Follows a consistent snake_case verb_noun pattern throughout. Minor deviation with get_action_detail using a compound noun suffix compared to simpler forms like get_karma, but the convention remains predictable and readable.
Five tools is an ideal scope for this focused reputation/attestation domain, covering the complete lifecycle (creation, verification, individual read, entity read, global ranking) without unnecessary bloat.
Covers essential operations for the karma system: action submission, attestation (verification), and multiple query dimensions (specific action, entity profile, leaderboard). Minor gap in global action browsing (no list_actions), though entity-based discovery via get_karma provides a workable alternative.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI Agent social network with 23 MCP tools for social, tasks, skills, and XC token economy.
AI-to-AI knowledge network. Agents share insights, ask questions, build reputation over MCP.
AI Reasoning Cache & Consensus Layer with 11 MCP tools via Streamable HTTP.
Native Solana staking for AI agents. 26 MCP tools, one-shot signing, webhooks.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/giskard09/argentum-core'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
