docs: add independent trust assessment resource for MCP server security

[karlmehta]

Summary

Adds a brief note under the existing Security section pointing developers to an independent trust assessment resource for MCP servers before production deployment.

Why

MCP servers often have write access to critical systems (databases, payments, cloud infrastructure, email). Developers connecting these to AI agents in production should evaluate:

• Input validation (SQL injection, path traversal via tool arguments)
• Permission scope (read-only vs. full access)
• Rate limiting (can a runaway agent exhaust resources?)
• Audit trail (are tool calls logged?)
• Rollback capability (can destructive operations be undone?)

This adds a single paragraph with a link to an independent assessment covering 10 security dimensions for 91 servers from this list.

Change

6 lines added under ## 🔒 Security — a subheading and brief description with link.

No changes to server code, configurations, or the server listing itself.

[karlmehta]

Hi maintainers — happy to adjust this based on your feedback. A few thoughts:

1. The problem is real: MCP servers with write access to databases, payments, and cloud infra have no security evaluation standard. Developers connecting agents to these in production are flying blind.

2. Happy to make this more generic: If you'd prefer, I can replace the external link with a contributed SECURITY_EVALUATION.md guide that describes security dimensions to consider (tool safety, input validation, permission scope, etc.) without linking to any specific vendor. The current link is just one implementation.

3. Alternative placement: If the Security section isn't the right spot, I could add it under "Creating Your Own Server" as security best practices for server developers.

Open to whatever approach works best for the project. The goal is just to help developers think about security before connecting MCP servers to production agents.

[karlmehta]

Update: We've expanded beyond trust scores to launch ANS (Agent Naming Service) — the identity, verification, and ownership layer for AI agents.

Three services, parallel to web infrastructure:

Web	Agent (ANS)
DNS (domain → IP)	ANS Registry (agent → owner + capabilities)
WHOIS (who owns this?)	ANS Lookup (who owns this agent? verified?)
SSL Certificate	TrustScore Certificate
Domain Transfer	Agent Ownership Transfer
Certificate Authority	TrustModel

For MCP server developers, ANS provides:

1. Register your MCP server → get a unique ANS ID (ans://your-server.trustmodel.ai)
2. Verify ownership via DNS TXT record (same as SSL verification)
3. Get scored → TrustScore certificate issued automatically
4. Transfer ownership when maintainers change (no more orphan servers)

Why this matters for the MCP ecosystem:

• Enterprises won't connect agents to unverified MCP servers
• ANS verification = the "SSL padlock" for agent connections
• Orphan detection: if a maintainer leaves, the server gets flagged before it becomes a risk
• 91 MCP servers are already pre-scored at trustmodel.ai/mcp-servers

Live pages:

• Trust Rankings: https://trustmodel.ai/mcp-servers (91 servers scored)
• ANS (Agent Naming Service): https://trustmodel.ai/ans
• Badge for your README: [![TrustScore](https://trustmodel.ai/badge/mcp/YOUR-SERVER.svg)](https://trustmodel.ai/mcp-servers)

We'd love feedback from the MCP maintainers on whether ANS-style verification could be integrated into the MCP protocol itself — e.g., an agent verifying a server's identity before connecting.