Public leaderboard

Public assessment

shunshi-ai/bazi-reader-mcp (shunshi-bazi-mcp)

shunshi-bazi-mcp · v0.1.0 · scanned

What changed in the harness

Selection accuracy 98%, destructive-action safety rate 100% (baseline only -- no rewrite pass applied).

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

30.0 / 30

30.0 out of 30
02Legibility

29.4 / 30

29.4 out of 30
03Economics

19.8 / 20

19.8 out of 20
04Discoverability

15.0 / 20

15.0 out of 20

Highest-impact fix

Estimated gain +5 points

Make target tools discoverable on the first call

Clarify tool names, decision boundaries, and required argument schemas so an agent can choose and construct the target call without exploratory steps.

Description evidence

Defects and rewrites.

0 defects 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
No description defects were flagged in this assessment.

Selection evidence

Confusable tool pairs.

1 pair where similar names or overlapping descriptions may send an agent toward the wrong tool.

Tool A Tool B Confidence Why they collide
getBaziChart getHuangli medium A natural query like '看看今天这个日子的八字' or 'today's bazi/四柱 for the day' straddles both tools: the name getBaziChart directly matches '八字', yet getBaziChart requires a person's birth date/time/gender to build a full chart, whereas getHuangli is what actually returns the day's 干支, 宜忌, and 流日. Both accept year/month/day, and 'bazi' appears in both descriptions (getHuangli mentions staying consistent with 八字 流日), so a date-only query mentioning 八字 could misroute the agent to getBaziChart, which would then fail or force fabricated birth parameters.

Compare the field

One score is useful.
The evidence makes it actionable.

Back to the leaderboard