mcpscoreContribute
mcpscore is new, and its rule set is a starting point, not a verdict from on high. The whole project rests on a bet: that there is a knowable answer to “what makes an MCP server good,” and that the community can converge on it faster than any one team can guess it.
So disagreement is a feature. The scoring methodology and every rule are open source (MIT) — you can read exactly why you scored what you scored, and tell us where we’re wrong. That feedback is our cheapest and best source of new rules.
Ways to help
Most of the valuable input isn’t code.
Propose a best practice or a rule
Tell us what you think a good MCP server does — a convention, a spec requirement we miss, a footgun worth flagging. This is the input we want most. A spec or RFC reference gets it in faster, but an unsourced hunch is welcome; we do the citation work.
Propose a rule →Argue a rule is wrong
A score you can’t disagree with is just an opinion. If a rule is mis-weighted, checks the wrong thing, or fires false positives, say so — with the rule ID and a case. Every rule is open source and cites its source, so the argument can be concrete.
Open an issue →Report a server that scores wrong
Too high or too low — both are useful. A server that games the rubric or one that’s genuinely good but scores poorly tells us where the rules diverge from reality.
Open an issue →Suggest a server for the test corpus
We regression-test the engine against real servers. A distinctive one — an unusual transport, a huge tool catalogue, a careful auth setup — makes the scorer more trustworthy.
Open an issue →Improve the docs, or write a rule
If you want to go all the way, the engine is MIT-licensed and CONTRIBUTING.md walks through adding an audit rule. Docs fixes are just as welcome.
Adding an audit rule →Tell us what you use it for
CI gate, a pre-publish check, comparing two servers — knowing how mcpscore fits your workflow shapes what we build next.
Email feedback@mcpscore.dev →
What happens to a proposal
We read it, weigh it against the spec and against what real servers actually do, and — if it holds up — fold it into the engine as a rule with a citation. Rules that can’t judge anything don’t ship; rules that judge the wrong thing get retired in the open. The methodology and rule set stay MIT, so nothing about the standard we hold servers to is a black box.
Read the methodology and rule reference to see the current bar, or the mission for why any of this matters.