Skip to main content
Glama
agentscore-trustless

AgentScore MCP Server

by agentscore-trustless
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

Server Quality Checklist

67%
Profile completionA complete profile improves this server's visibility in search results.

  • Latest release: v1.0.0

  • Disambiguation5/5

    Each 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.

    Naming Consistency3/5

    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.

    Tool Count3/5

    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.

    Completeness2/5

    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.

  • Average 3.1/5 across 3 of 3 tools scored.

    See the Tool Scores section below for per-tool breakdowns.

    • No community issues in the last 6 months
    • 0 commits in the last 12 weeks
    • No stable releases found
    • No critical vulnerability alerts
    • No high-severity vulnerability alerts
    • No code scanning findings
    • CI status not available

  • This repository is licensed under MIT License.

  • This repository includes a README.md file.

  • No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.

    Tip: use the "Try in Browser" feature on the server page to seed initial usage.

  • Add a glama.json file to provide metadata about your server.

  • If you are the author, simply .

    If the server belongs to an organization, first add glama.json to the root of your repository:

    {
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}

    Then . Browse examples.

  • Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

  • Behavior3/5

    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.

    Conciseness4/5

    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.

    Completeness2/5

    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.

    Parameters2/5

    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.

    Purpose4/5

    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.

    Usage Guidelines2/5

    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.

  • Behavior2/5

    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.

    Conciseness5/5

    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.

    Completeness3/5

    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.

    Parameters4/5

    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.

    Purpose4/5

    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.

    Usage Guidelines2/5

    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.

  • Behavior2/5

    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.

    Conciseness5/5

    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.

    Completeness3/5

    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.

    Parameters4/5

    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.

    Purpose4/5

    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.

    Usage Guidelines2/5

    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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

  • Confirm that the MCP server is working as expected.
  • Confirm that there are no obvious security issues.
  • Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

agentscore-mcp MCP server

Copy to your README.md:

Score Badge

agentscore-mcp MCP server

Copy to your README.md:

Latest Blog Posts

MCP directory API

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