Home · Guides

Forty percent of the score is your worst-described tool

Glama scores every MCP server it indexes and publishes both the rubric and the arithmetic. The formula on a listed server's score page:

definition quality = 0.6 * mean(tool scores) + 0.4 * min(tool scores)
overall            = 0.7 * definition quality + 0.3 * mean(4 coherence dimensions)
tiers              = A >= 3.5, B >= 3.0, C >= 2.0, D >= 1.0, F below 1.0

Read the first line again. A server with nine excellent tools and one careless one is scored as if the careless one were four of them. Adding a good tool barely moves the number. Fixing the worst one moves it a lot.

The six dimensions

Each tool is scored 1 to 5 on six axes, quoted from glama.ai/mcp/methodology section 1.6, read 2026-09-09:

Above the per-tool score sit two more: tool-set coherence, meaning whether the tools compose into a non-overlapping surface, and server cohesiveness, meaning whether the stated purpose matches the capabilities actually exposed.

The measurement that made the minimum rule concrete

This project publishes a catalogue of MCP servers. A licence package is vendored into every one of them, so every server ships the same two tools written by the same person in the same style, three lines apart in one file. Across 20 connectors scored on 2026-09-08:

license_activate was the lowest-scoring tool on 20 of 20 servers. Its sibling, in the same file, scored nearly twice as high. So this is the text and not the surface, and because the package is shared, one string was capping a whole fleet. Modelling the effect of lifting only that tool to 3.5 and changing nothing else moves the fleet mean from 3.562 to 3.874 and takes A tier from 12 of 20 to 20 of 20. That second figure is a model rather than a measurement, and it assumes coherence stays put.

The rule that makes a score improvement a defect

A description that scores well by claiming behaviour the code does not have is worse than a low score. One of ours ended up saying a tool "takes no arguments and activates nothing" while its own schema declared a required key parameter described as "License key from checkout". That contradiction is precisely what Parameter Semantics penalises, and rewording it would have been dishonest. The fix was to make the code do what the name says.

The other gate, which has nothing to do with words

Glama's methodology, section 1.3, read the same day: if an inferred Dockerfile fails to produce a working build, the profile page is preserved but distribution is withheld, and the server does not appear in search results, category listings or recommendations. A build that works in your monorepo and not in the repository you published is enough to trigger this. Ours did exactly that, copying packages and servers directories that do not exist in a split-out repository.

What to do with this

1. List your tools and find the worst description. Not the least important tool, the worst description. That one is 40 percent of the score.
2. Check any tool you vendored from a shared package. It was written for a different reason and nobody has read it since.
3. For each tool, answer the six questions in order. Usage Guidelines and Behavioral Transparency are the two most often missing, because they are the two nobody thinks to write.
4. Verify each claim against the code before you ship it. A description is an assertion about behaviour.
5. Clone your published repository into an empty directory and build it there.

Sources: glama.ai/mcp/methodology sections 1.3 and 1.6, read 2026-09-09, for the dimensions and the build rule; the formula and tier thresholds from a listed server's own score page, recorded in data/glama_r2.json in this repository alongside the per-connector scores; the tool scores above measured on 20 connectors of this project on 2026-09-08. The description contradiction is from this project's own loop notes.

Questions

Does this apply outside one directory?

The arithmetic is one directory's. The input is not: a tool description is what a model reads when it decides whether to call you, so the same text is your first impression in every client. Improving it needs no account and no submission anywhere.

Should I remove a weak tool to raise the minimum?

Only if it should not exist. Deleting a published tool breaks callers, and the coherence score separately penalises gaps. Rewriting the description is the cheaper move and the honest one.

How do I write Usage Guidelines?

Say when to call the tool and when not to, in one sentence each. The second half is the one that gets omitted: which neighbouring tool is the right one instead, and what state the tool assumes. A model choosing between two similar tools has nothing else to go on.

What is server cohesiveness?

Whether the tools match the stated purpose. The methodology's own example is a server claiming to be a Postgres client while exposing arbitrary shell execution. It is scored separately from the per-tool axes and it is a design question, not a wording one.

How often is it rescored?

The methodology says every new commit and every rebuild triggers a full re-run, and that connector scores update on every introspection sweep. In practice a stamp on a score page can sit unchanged for a day or more after a deploy, so treat a stale date as a queue rather than a rejection.

Related

All MCP servers and prices · All guides · Buy the bundle $39