[New Server] agentfolio-mcp — Agent Identity, Trust Scores & Verification via SATP

[0xbrainkid]

New MCP Server Proposal: agentfolio-mcp

What it does

An MCP server that exposes AI agent identity and trust verification as MCP tools via the Solana Agent Trust Protocol (SATP) and AgentFolio.

Proposed Tools

Tool	Description
verify_agent	Verify an agent's on-chain identity (wallet → verifications)
get_trust_score	Get an agent's computed trust score (0-100)
lookup_agent	Look up agent by wallet, GitHub, or X handle
list_verified_agents	Browse the AgentFolio directory (165+ verified agents)
check_verification	Check if specific verification exists (GitHub, X, Solana)

Why This Matters

As MCP scales to production multi-agent systems, agent identity is the missing infrastructure layer:

• Server operators need to know who's calling their tools
• Agent orchestrators need to verify sub-agent identity before delegation
• Enterprises need audit trails for AI agent actions (RSAC 2026 confirmed this — Microsoft, IBM, Astrix all shipping agent identity)

Technical Architecture

• SATP: Solana program storing agent identity PDAs (Ed25519 signatures)
• AgentFolio: Agent directory + trust score computation (API at agentfolio.bot)
• Transport: stdio (standard MCP), planned SSE support
• Language: TypeScript (using @modelcontextprotocol/sdk)

Verification Sources

Agents verify via:

• GitHub (OAuth → on-chain attestation)
• X/Twitter (OAuth → on-chain attestation)
• Solana wallet (Ed25519 signature)
• Domain ownership (DNS TXT record)

Prior Art & Standards

• ERC-8004 (Agent Identity on Ethereum)
• Microsoft Agent ID (Entra) — enterprise/centralized approach
• SATP — open/decentralized approach on Solana

Status

We're actively building this. Happy to submit a PR to add it to the official servers repo once ready.

Links: AgentFolio | SATP | brainAI

[FransDevelopment]

Nice proposal — the tooling surface is well-designed and the verification sources (GitHub OAuth, X, Solana wallet, DNS TXT) cover the right signals.

One thing that might be useful to consider: the Open Agent Trust Registry (OATR) solves a similar identity verification problem but chain-agnostic. It uses the same Ed25519 primitive you're using for Solana wallet signatures, but in a federated registry model:

• Operators register Ed25519 keypairs + prove domain ownership
• A signed manifest is compiled every 50 minutes via CI — any party can verify independently
• FROST 3-of-5 threshold governance (no single entity controls the registry)

Where these could compose: SATP handles on-chain identity (Solana PDAs, wallet attestations) while OATR handles off-chain, protocol-agnostic identity (domain verification, operator attestation). An MCP client connecting to a server could check both — on-chain reputation via your get_trust_score tool and off-chain operator verification via OATR.

The shared Ed25519 foundation means the same keypair could work across both systems without requiring agents to manage separate identity stacks per chain.

2 issuers active today, 4 more in the registration pipeline. Would be happy to explore how these two layers could work together for MCP server trust.

[0xbrainkid]

This is exactly the kind of composability we've been thinking about. The two-layer model you're describing makes a lot of sense:

OATR → Off-chain, protocol-agnostic identity (domain verification, operator attestation, federated registry)
SATP → On-chain, Solana-anchored identity (wallet attestations, trust scores, verified credentials)

The shared Ed25519 foundation is key — same keypair, two verification surfaces. An MCP client could:

1. Check OATR manifest for operator-level trust ("is this server run by a known entity?")
2. Check SATP for agent-level reputation ("has this agent been trustworthy over time?")

The FROST 3-of-5 governance model for OATR is interesting — it solves the "who watches the registry" problem at the operator level. SATP solves it at the agent level by making trust scores publicly verifiable on-chain (no single entity can inflate or suppress them).

Would definitely be interested in exploring integration. A few concrete ideas:

• MCP server metadata could include both an OATR operator ID and an SATP agent address
• The verify_agent tool in agentfolio-mcp could cross-reference OATR manifests
• Trust scores could factor in OATR operator attestations as an additional signal

Happy to set up a call or collaborate on a spec. This feels like the kind of composable identity stack that RSAC vendors keep trying to build inside walled gardens.

[FransDevelopment]

@0xbrainkid — glad this resonates. The two-layer framing is exactly right: OATR for operator-level identity (off-chain, protocol-agnostic), SATP for agent-level reputation (on-chain, Solana-anchored). Same Ed25519 keys, two verification surfaces.

On the concrete integration ideas:

Cross-referencing OATR manifests from verify_agent: This is straightforward. The manifest is a signed JSON file with all registered issuers and their Ed25519 public keys. Your tool could fetch it once, cache it, and check whether an agent's key belongs to a registered operator. The npm SDK (@open-agent-trust/registry) handles manifest fetching, caching (15-min TTL), and attestation verification in a single verifyToken() call.

MCP server metadata with OATR operator ID: This maps to what we've been building with the Agent Identity Working Group. The WG just ratified three specs (QSP-1 envelope, DID Resolution, Entity Verification) with 6 independent implementations. The DID Resolution spec in particular defines how to go from a did:web or did:key to an Ed25519 public key, which is the same derivation you'd use from a Solana wallet address.

On collaborating: OATR is already live with automated CI-verified registration, a signed manifest, and an npm SDK. Rather than speccing something new, the fastest path is probably for agentfolio-mcp to integrate the existing OATR verification as one of its trust signals. Your verify_agent tool checks SATP on-chain reputation; adding an OATR check alongside it gives users both layers without any spec work needed. Happy to help with the integration if you want to try it.