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., "@AgentScore MCP Server check the reputation score for agent 0x71C2..."
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.
Official MCP server for the AgentScore Registry (Base Sepolia).
npm install
npm run build
npm run dev # stdio (Claude Desktop, Cursor, etc.)
# or
HTTP_PORT=3000 npm start # HTTP/SSERelated MCP server: AgentZone MCP
npm run docker:build
npm run docker:run
# Server available at http://localhost:3000/mcpClaude Desktop / Cursor / Windsurf
Add to your MCP config (usually ~/Library/Application Support/Claude/mcp.json or equivalent):
{
"mcpServers": {
"agent-score": {
"command": "node",
"args": ["/absolute/path/to/agent-score-mcp/dist/index.js"]
}
}
}{
"mcpServers": {
"agent-score": {
"command": "docker",
"args": ["run", "-i", "--rm", "agent-score-mcp"]
}
}
}POST to http://localhost:3000/mcp with standard MCP JSON-RPC.
getAgentScore(identifier) → {score, historyCount, metadataURI}
getAgentHistory(tokenId, limit) → [{score, timestamp}, ...]
listRegisteredAgents(owner?) → array of enriched agents
All read-only. Zero private keys. Fully trustless.
Enjoy building with AgentScore reputation! 🚀
Returns array of past scores with timestamps (recent first)
| Name | Required | Description | Default |
|---|---|---|---|
| tokenId | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It successfully communicates the sort order ('recent first') and return structure ('array'), but fails to confirm idempotency, safety (read-only status), error conditions, or rate limiting that would typically appear in 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 single-sentence description is ruthlessly efficient with zero redundancy, front-loading the return type and ordering behavior. However, extreme brevity comes at the cost of necessary parametric and contextual detail, preventing a perfect score.
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?
Despite low structural complexity (2 simple params), the description is incomplete due to zero schema coverage and no output schema. Critical omissions include parameter semantics (tokenId purpose, limit bounds) and differentiation from getAgentScore. The return value description is partial (omits data types, potential nullability).
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%, requiring the description to compensate for undocumented parameters. It completely omits explanation of tokenId (is it an agent identifier or session token?) and limit (pagination window), forcing inference solely from parameter names. This is a significant gap given the lack of schema documentation.
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 historical score data ('past scores') with temporal metadata ('timestamps'), distinguishing it from the sibling getAgentScore (presumably current/single scores) via the 'past' and 'array' qualifiers. However, it could specify what domain these 'scores' represent (performance ratings, game scores, etc.).
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 siblings getAgentScore or listRegisteredAgents. It omits prerequisites (e.g., whether the agent must be registered first) and doesn't indicate if this is for debugging, analytics, or operational checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns current reputation score, history count and metadata URI. Accepts tokenId (number) OR agent address (0x...)
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes |
| Name | Required | Description |
|---|---|---|
| score | Yes | |
| metadataURI | Yes | |
| historyCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden but only implies read-only safety through the word 'Returns'. It fails to disclose authentication requirements, rate limits, or whether the reputation score is real-time versus cached.
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 consists of exactly two efficient sentences with zero waste: the first states the return payload and the second explains input flexibility, making it appropriately 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?
While the output schema obviates the need for detailed return value explanation, the description lacks safety behavioral context (critical given no annotations) and does not clarify relationships to sibling tools, leaving gaps in contextual 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?
Given 0% schema description coverage at the root parameter level, the description effectively compensates by explaining the polymorphic identifier accepts 'tokenId (number) OR agent address (0x...)', clarifying both the dual input types and the expected hex format for addresses.
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 current reputation score, history count and metadata URI' (specific verb + resources), but it does not explicitly differentiate from sibling tools like getAgentHistory, leaving some ambiguity about overlap regarding 'history count' versus full history retrieval.
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?
While the description provides input format guidance ('Accepts tokenId OR agent address'), it offers no guidance on when to select this tool versus getAgentHistory or listRegisteredAgents, nor does it mention prerequisites like authentication or valid token ranges.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all agents (or single agent by owner address). Returns enriched data.
| Name | Required | Description | Default |
|---|---|---|---|
| owner | No | Optional owner address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions 'Returns enriched data' hinting at comprehensive output, but fails to disclose critical behavioral traits like pagination for 'all agents', rate limits, or authorization requirements.
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 sentences, front-loaded with action verb. No redundant words; every clause earns its place by conveying scope or output characteristics.
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 low complexity (1 optional param) and no output schema, description minimally suffices but leaves gaps. 'Enriched data' is vague, and 'List all' raises pagination concerns that remain unaddressed.
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?
While schema has 100% coverage describing 'owner' as 'Optional owner address', the description adds crucial semantic context that this parameter filters the results to a single agent (or the agent owned by that address), clarifying the 'all vs single' behavior.
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?
Uses specific verb 'List' with resource 'agents' and clarifies scope ('all' vs 'single agent by owner'). However, it does not explicitly differentiate from siblings getAgentHistory/getAgentScore.
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 filtering capability via parenthetical '(or single agent by owner address)', but provides no explicit guidance on when to use this versus getAgentHistory or getAgentScore, and no exclusions or prerequisites.
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.
v1.0.0getAgentHistorygetAgentScorelistRegisteredAgentsEach tool has a clearly distinct purpose: getAgentHistory retrieves historical data, getAgentScore provides current reputation metrics, and listRegisteredAgents enumerates agents with optional filtering. There is no overlap in functionality, and the descriptions clearly differentiate their roles.
The naming is mixed: getAgentHistory and getAgentScore follow a consistent verb_noun pattern, but listRegisteredAgents uses a different verb style ('list' vs. 'get'). While all names are readable, the inconsistency in verb choice reduces predictability.
With only 3 tools, the set feels thin for a server named 'AgentScore MCP Server', which suggests a broader scope for managing agent scores and data. While the tools cover basic retrieval and listing, the count may be insufficient for comprehensive operations like updating scores or managing registrations.
The tool surface is significantly incomplete for an agent scoring system. It only includes read operations (get and list), with no ability to create, update, or delete scores or agents. This leaves obvious gaps in CRUD coverage, likely causing agent failures in scenarios requiring data modification.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
On-chain ERC-8004 agent registry. Search, register, and check reputation across 16 chains.
Agent reputation registry: check, register, and endorse AI agents
Read-only on-chain intelligence for AI agents on Base: balances, tokens, gas, tx status.
Read-only on-chain intelligence for AI agents on Base: balances, tokens, gas, tx status.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/agentscore-trustless/agentscore-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
