Public leaderboard

Public assessment

Thezenmonster/agentscore-mcp-server (@agentscore-xyz/mcp-server)

agentscore-xyz-mcp-server · v2.2.0 · scanned

What changed in the harness

Selection accuracy 100→100, token cost up 1%, unconfirmed writes 0%→0%.

Category breakdown

Where the score comes from.

Earned points across the four signals Gradable measures. Safety and Legibility are scored out of 30; Economics and Discoverability are scored out of 20.

01Safety

0.0 / 30

0.0 out of 30
02Legibility

29.2 / 30

29.2 out of 30
03Economics

20.0 / 20

20.0 out of 20
04Discoverability

13.3 / 20

13.3 out of 20

Highest-impact fix

Estimated gain +30 points

Add explicit identity and permission preflight tools

Expose machine-readable principal/tenant confirmation and a non-mutating permission check so agents can verify both before destructive actions.

Description evidence

Defects and rewrites.

1 defect found across the exposed tool descriptions. Suggested rewrites make purpose, inputs, boundaries, and returns easier for an agent to understand.

Tool Defect types Suggested rewrite
install_policy_gate
no_return_description
Write the AgentScore Policy Gate workflow file to this repo, creating .github/workflows/agentscore-policy-gate.yml with OIDC authentication (no API key needed) and the repo's detected MCP dependencies included. The gate auto-provisions the repo on first push. Returns the path of the workflow file written and a summary of the MCP dependencies detected and included in it.

Selection evidence

Confusable tool pairs.

2 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.

Tool A Tool B Confidence Why they collide
generate_policy_gate_setup install_policy_gate high Both take the same path/repo_url args and produce the identical workflow YAML; a task like 'set up the AgentScore policy gate for this repo' doesn't clearly indicate whether the user wants the file previewed/generated or actually written to .github/workflows, so an agent could easily call the wrong one.
check_abuse check_my_repo low check_abuse takes a single package/agent identifier while check_my_repo scans an entire repo path for MCP dependencies; a vague task like 'check this repo for abusive packages' could nudge an agent toward check_abuse when check_my_repo is the intended repo-wide tool, though the differing input shapes make this fairly resolvable.

Compare the field

One score is useful.
The evidence makes it actionable.

Back to the leaderboard