What can you do with this server?

This server lets AI agents check, rate, and discover AI microservices by trust score. * Check a service's reputation before calling it: get a 0-1 trust score, confidence, rating count, and availability/latency/conformity breakdown via check_reputation. * Rate a service after calling it by submitting HTTP status, latency, optional schema validity, quality score, response size, and an optional JWT receipt via submit_rating. * Discover reliable services by listing rated services sorted by score, rating count, or last rated, with filters for minimum score and minimum number of ratings via list_services. * All endpoints accept flexible service identifiers: URL, domain, or DID formats resolve to the same service. * No account or API key needed — the API is free and open; premium endpoints and MCP integration are also available for agents.

Which integrations are available for this server?

Drop-in tools for CrewAI, exposing functions to check reputation, submit ratings, and list services. Drop-in tools for LangChain, exposing functions to check reputation, submit ratings, and list services.

trustscoreagent-mcp

Official

by trustscoreagent

Overview Schema Source Related Servers Discussions Admin

Remote

TrustScoreAgent

Free, open reputation registry for AI microservices. Agents check trust scores before calling any service.

Status: Phase 1 (early). The API, scoring (Beta + EigenTrust), receipt verification, Merkle audit trail and MCP server are implemented and tested — but the public dataset is still small, some services (*.example.com) are demo seed data, and parts of the design (on-chain anchoring, x402 payments, mandatory agent signatures) are Phase 2. We publish early and openly on purpose: the trust layer for the agentic economy should exist, be auditable, and be adoptable before it becomes critical. See the trust model in SECURITY.md.

What is this?

AI agents increasingly rely on paid microservices. TrustScoreAgent lets any agent:

Check the reputation of a service before calling it
Rate a service after calling it
Discover which services are reliable

No account needed. No API key. Identify services by URL, domain, or DID.

Related MCP server: AgentVeil Protocol

Quick start

# Check a service's trust score (any format works)
curl "https://api.trustscoreagent.com/v1/score?service=api.example.com"
curl "https://api.trustscoreagent.com/v1/score?service=https://api.example.com/v1/translate"

# Unknown services return a neutral score (0.5) — no errors
curl "https://api.trustscoreagent.com/v1/score?service=never-seen-before.com"

# Rate a service after calling it
curl -X POST "https://api.trustscoreagent.com/v1/rate" \
  -H "Content-Type: application/json" \
  -H "X-Agent-DID: my-agent.example.com" \
  -d '{
    "service": "api.example.com",
    "metrics": {
      "status_code": 200,
      "latency_ms": 143,
      "schema_valid": true
    }
  }'

# List top-rated services
curl "https://api.trustscoreagent.com/v1/services?sort_by=score&min_ratings=10"

Local development

# Start PostgreSQL and Redis
docker compose up -d

# Run the API
dotnet run --project src/TrustScore.Api

# Run tests
dotnet test

# Swagger UI
open http://localhost:5000/swagger

Architecture

C# / .NET 8 — ASP.NET Core Minimal API
PostgreSQL — Ratings and service scores
Redis — Score caching, rate limiting, nonce tracking
Beta Reputation System — Bayesian scoring (per-dimension: availability, latency, conformity)
EigenTrust — Anti-Sybil agent trust scoring
Merkle Tree — Cryptographic audit log with inclusion proofs
Ed25519 Receipt Verification — Cryptographic proof of service interaction
MCP Server — Integration with Claude, Cursor, and MCP-compatible agents

API Reference

Core (free, always)

Endpoint	Description
`GET /v1/score?service=`	Trust score for a service (0.5 neutral for unknown)
`POST /v1/rate`	Submit a rating after calling a service
`GET /v1/services`	List rated services (pagination, sorting, filtering)
`GET /v1/agent/trust?did=`	Check your agent's trust score
`GET /v1/audit/root`	Latest Merkle tree root
`GET /v1/audit/proof/{id}`	Cryptographic inclusion proof for a rating

Premium (free for now, x402 micropayments later)

Endpoint	Description
`GET /v1/score/history?service=`	Daily aggregated score history
`GET /v1/score/detailed?service=`	Latency percentiles, quality distribution
`POST /v1/scores/bulk`	Up to 100 scores in one request

Service identification

All endpoints accept services in any format — they are normalized internally:

api.example.com (domain)
https://api.example.com/v1/translate (URL)
did:web:api.example.com (DID)

All three resolve to the same service.

MCP Server

TrustScoreAgent is available as an MCP server for Claude, Cursor, and other agents.

# Add to Claude Code
claude mcp add trustscoreagent -- npx -y @trustscoreagent/mcp-server

See docs/mcp.md for full setup instructions.

Framework integrations

Drop-in tools for agent frameworks (no account or API key needed):

LangChain — from trustscoreagent_langchain import get_trustscoreagent_tools
CrewAI — from trustscoreagent_crewai import get_trustscoreagent_tools

Each exposes trustscore_check_reputation, trustscore_submit_rating, and trustscore_list_services. See integrations/.

Documentation

API Reference
Examples & Recipes
Receipt Standard
MCP Server Setup — Claude, Cursor, Windsurf
Why Trust Matters for Agents
Privacy & Data Handling

Contributing

Contributions are welcome — see CONTRIBUTING.md and our Code of Conduct. To report a vulnerability, follow SECURITY.md.

Project status & trust model

TrustScoreAgent is Phase 1 (early). What that means in practice:

Baseline data is real and auditable. Initial scores come from a transparent operated probe (did:web:trustscoreagent.com:probe) that measures the availability, latency and conformity of a curated list of public, free APIs — real, Merkle-audited measurements, not fabricated numbers. Community and receipt-verified ratings accumulate on top. (The earlier fictitious *.example.com seeds have been removed.)
Single operator. Neutrality currently rests on open-source scoring code and a verifiable Merkle audit trail, not on decentralization. Federation is a later phase.
Agent identity can be proven, but is not yet mandatory. Agents identified by a did:key sign each rating with their Ed25519 key (X-Agent-Signature), which binds the rating to the holder of that key. Unsigned ratings still count at half weight so existing clients keep working, which means a rating is only as attributable as its signature. Verified service receipts remain the strongest signal, and on-chain Merkle anchoring is still Phase 2.

See SECURITY.md for the full trust model and how to report vulnerabilities.

License

Apache-2.0. See LICENSE.

Available Tools

3 tools

check_reputationA

Check the trust score and reputation of an AI microservice before calling it. Returns a score between 0 and 1, confidence level, number of ratings, and dimensional breakdown (availability, latency, conformity). Use this BEFORE calling any untrusted external service to verify its reliability.

ParametersJSON Schema

Name	Required	Description	Default
`service_did`	Yes	The service to check. Accepts any format: URL (https://api.example.com), domain (api.example.com), or DID (did:web:api.example.com). All resolve to the same service.

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It describes the read-like behavior and return data but does not disclose potential costs, resource usage, or side effects. The transparency is adequate but could be improved by noting the operation's lightweight nature.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences. The first sentence states the purpose, and the second adds return details and usage guidance. No redundant information, earning full marks.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple single-parameter tool and high schema coverage, the description is mostly complete. It explains purpose, output elements, and usage timing. Minor improvement could be detailing the confidence level scale, but it's sufficient as is.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a detailed parameter description already present. The description adds no new information beyond what the schema provides, so it meets but does not exceed the baseline for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: checking the trust score and reputation of an AI microservice. It specifies the output components (score, confidence, ratings, dimensional breakdown) and distinguishes from siblings like list_services and submit_rating by its unique function.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly advises using the tool before calling any untrusted external service. While it doesn't list when not to use it, the only parameter is straightforward, and the use case is clearly defined, making the guidance effective.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_servicesA

List AI microservices that have been rated, sorted by trust score. Use this to discover reliable services or find alternatives. Returns a paginated list with scores and dimensional breakdown.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Number of results (default 20, max 100)
`sort_by`	No	Sort field (default: score)
`min_score`	No	Minimum trust score filter (0.0-1.0)
`min_ratings`	No	Minimum number of ratings filter

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses return format: paginated list with scores and dimensional breakdown. No mention of authentication, rate limits, or pagination details. Adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences covering purpose, usage, and return info. No waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Good for a list tool with no output schema, but lacks details on pagination mechanism and error handling. Adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so description adds no additional parameter meaning beyond what schema provides. Baseline score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool lists AI microservices that have been rated, sorted by trust score. Distinguished from siblings (check_reputation for single service, submit_rating for submitting).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states use case: 'discover reliable services or find alternatives.' Does not explicitly exclude siblings but context implies differentiation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

submit_ratingA

Rate an AI microservice after calling it. Provide the technical metrics from your interaction. This helps other agents know if the service is reliable. Include the receipt from the X-Trust-Receipt header if the service provided one.

ParametersJSON Schema

Name	Required	Description
`receipt`	No	JWT receipt from the service's X-Trust-Receipt header (optional)
`latency_ms`	Yes	Response time in milliseconds (round sub-millisecond responses up to 1)
`service_did`	Yes	The service you called. URL, domain, or DID (e.g., api.example.com)
`status_code`	Yes	HTTP status code returned by the service (e.g., 200, 500)
`schema_valid`	No	Whether the response matched the expected format (optional)
`quality_score`	No	Subjective quality rating from 1 (poor) to 5 (excellent) (optional)
`response_size_bytes`	No	Size of the response in bytes (optional)

TDQS

A3.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, description carries full burden but only states to submit rating and include receipt if provided. Lacks details on idempotency, duplicate handling, 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with key action, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Schema with good parameter descriptions combined with tool purpose is mostly complete. Lacks details on submission confirmation or error handling, but not critical given schema coverage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% of parameters; description adds context by grouping parameters as 'technical metrics' and highlighting the receipt. Adds value beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool rates an AI microservice by providing technical metrics after calling it. Distinguishes from siblings (check_reputation, list_services) as a submission tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage after calling a service ('after calling it') but does not provide explicit when-not-to-use or compare to sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

3 tool updatesv0.1.0Jul 14, 2026
- First observedcheck_reputation
- First observedlist_services
- First observedsubmit_rating

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored 2026-07-14 09:55 across 3 tools

Disambiguation5/5

Each tool serves a distinct step in the trust scoring workflow: check_reputation for pre-call verification, list_services for discovery, and submit_rating for post-call feedback. There is no functional overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case (check_reputation, list_services, submit_rating), making them predictable and easy to understand.

Tool Count5/5

With just 3 tools, the server is tightly scoped to its purpose. Each tool is essential and non-redundant, covering the core actions needed for trust evaluation.

Completeness4/5

The tool set covers the main lifecycle: discover (list_services), verify (check_reputation), and rate (submit_rating). A minor gap is the lack of a tool to retrieve or update a specific rating, but the essential workflow is complete.

Maintenance

ActivityActive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Mnemom — Trust Ratings for AI Agents A
io.github.mnemom
Trust infrastructure for AI agents: read a verifiable Trust Rating, claim an identity, earn a badge.
Security Autonomous Agents
1531
Joy Trust Network B
io.github.tlkc888-Jenkins
Trust infrastructure for AI agents. Portable reputation (JTS 0-5), agent discovery, vouching.
Autonomous Agents Security
312
Agent Reputation Registry A
org.memoryapi
Agent reputation registry: check, register, and endorse AI agents
Agent Orchestration Autonomous Agents Security
2
AI Codex B
io.github.majorelalexis-stack
Neutral W3C DID/VC identity and reputation oracle for AI agents (did:key/did:web, eddsa-jcs-2022).
Blockchain Cryptocurrency Web3 & Decentralized Tech
2

Related MCP Servers

BasedAgents
Autonomous Agents Security
maxfain
A
license
A
quality
B
maintenance
AI agent identity and reputation registry. Ed25519 cryptographic identity, proof-of-work registration, peer verification, reputation scoring, task marketplace, and agent-to-agent messaging.
Updated 7 hours ago (2026-09-22 19:10 UTC)
16
360 npm
Apache 2.0
AgentVeil Protocol
AI & Machine Learning Autonomous Agents Security
agentveil-protocol
A
license
A
quality
A
maintenance
Trust, identity, and reputation infrastructure for AI agents. Register agents with W3C DID (Ed25519), check EigenTrust reputation scores, submit peer attestations, search agents by capability, and verify IPFS-anchored audit trails. 11 tools.
Updated 7 days ago (2026-09-16 08:32 UTC)
20
167 PyPI
15
MIT
TrustMesh MCP Server
Autonomous Agents Security AI & Machine Learning
Clioloop
A
license
Not graded
quality
Not graded
maintenance
Provides AI agents with trust scoring and reputation management capabilities for secure interactions. Enables agents to check trust scores, rate interactions, and manage disputes before transacting with other agents.
Updated 5 months ago (2026-04-19 00:57 UTC)
-
AgentTrust
Security Autonomous Agents
raditotev
F
license
A
quality
D
maintenance
Reputation and trust scoring service for AI agents, exposed as an MCP server. Evaluate counterparties, report interactions, issue portable trust certificates, and detect Sybil attacks.
Updated 6 months ago (2026-03-22 16:24 UTC)
23
-