should-i-use (ours)
should-i-use is our own MCP server, published by MrKeyoor as the npm package should-i-use-mcp. It gives a coding agent six tools for library decisions: audit_dependencies, pick_library, how_do_i, docs_link, should_i_use and alternatives. It answers over stdio, needs no API key, and reports itself as version 0.2.0.
How we started it
npx -y should-i-use-mcpUse it if your agent keeps guessing about packages and you want a second opinion that arrives as a tool call instead of a web search. We wrote it, so read this page with that in mind: the harness that measured everything else in the batch measured this one too, unmodified. The strongest argument against is that six opinion tools sit permanently in a context window that could be holding your code, and the opinions are ours, not a consensus of the ecosystem. If you never ask an agent which library to pick, there is nothing here for you.
Use it if
Skip it if
The bill for your context window
| Tool | Est. tokens | Described? | Required params |
|---|---|---|---|
| audit_dependencies | ~173 | yes (305 chars) | 1 |
| pick_library | ~118 | yes (170 chars) | 1 |
| how_do_i | ~116 | yes (172 chars) | 2 |
| docs_link | ~95 | yes (108 chars) | 1 |
| should_i_use | ~83 | yes (137 chars) | 1 |
| alternatives | ~80 | yes (122 chars) | 1 |
Its tools/list payload is 2665 bytes, about 666 tokens by the chars/4 estimate, measured 2026-08-19. That is lighter than the median server in this batch and a rounding error next to Notion, the heaviest thing we booted, whose tool list runs into five figures of tokens. The weight is spread evenly rather than parked in one monster schema: audit_dependencies is the largest description at 173 tokens, and the smallest, alternatives, costs 80. Nothing here needs trimming.
Setup reality
There is no setup, which is the entire point. We ran `npx -y should-i-use-mcp` as an unprivileged user with a clean environment and no secrets, and it came up and served tools/list. The harness scraped no env-var hints from stderr, because it asked for none; the only thing it printed was a line saying it was running on stdio. Transport is stdio, so it drops into any client config as a command plus args. Boot took 7856 ms on our shared box, and most of that is npm resolving and fetching the package, not the server starting.
Questions people ask
Is this review biased, given you wrote the server?
Yes, in the sense that we chose to build it. The numbers are not biased: same harness, same clean environment, same boot timeout as every other entry in the batch, and we published the boot time even though it is slow for a server that does nothing on startup.
Do I need an API key or account?
No. When we booted it with an empty environment it started and answered anyway, and the harness recorded no env-var hints. That is unusual in this batch; most servers that failed to boot did so waiting for a token.
Why did it take almost eight seconds to start?
Because npx resolves and downloads the package first. Pin it locally or install it globally and that cost disappears from every session after the first. The measured figure is the cold path on a shared four-core box, which is the honest worst case.
What do the six tools actually return?
Short judgments, not documentation dumps. should_i_use and alternatives return a verdict and a shortlist for a named package, audit_dependencies takes a manifest and flags what it would replace, and docs_link and how_do_i point at the specific page rather than pasting it.
Other docs servers we started
| Server | Vendor | Boots | Context tax |
|---|---|---|---|
| Context7 | Upstash | ✓ | ~1,215 tokens |
How this page is made: the server is spawned as an unprivileged user with a clean environment and no credentials, then asked for its tools, resources and prompts over stdio. Token figures are estimates at four characters per token, not a tokenizer count. One run, one machine. Corrections: contact the desk.