Skip to main content
Glama
mrkeyoor

should-i-use

by mrkeyoor
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

should-i-use

The MCP that tells your agent what NOT to install.

Most library docs MCP servers dump thousands of tokens of documentation into your context and let the model sort it out. This one answers the actual question: which library to pick, which to skip, and how to do the thing. Typical answers run 25 to 360 tokens. Every response is hard-clamped at 500.

992 libraries indexed. Last updated: 2026-08-16.

The index grows daily. Data comes from a curated set of npm and PyPI libraries with honest guides written to a fixed rubric and grounded in each library's own docs: what a library is actually like to set up, when you should not use it, verified alternatives, 4-axis scorecards, and version-correct code snippets. If a library is not indexed, the tools say so plainly instead of guessing.

If you want a Context7 alternative that treats context as a budget rather than a bucket, this is it.

Quickstart

No API key, no database. The index ships inside the package.

npx should-i-use-mcp install

That writes the server entry into whichever agent configs already exist on your machine: Claude Code, Claude Desktop, Cursor, Windsurf, Cline, VS Code, Zed, Codex, Gemini CLI. Each file it touches is backed up as .bak first. Restart your agent afterwards.

For a repo-local config instead of your home directory:

npx should-i-use-mcp install --project

That writes .mcp.json and .cursor/mcp.json in the current directory, so everyone who clones the repo gets the server.

Claude Code, one line

claude mcp add should-i-use -- npx -y should-i-use-mcp

By hand

If you would rather edit the JSON yourself, add this to your client's MCP config (~/.cursor/mcp.json for Cursor, ~/.codeium/windsurf/mcp_config.json for Windsurf, the Claude Desktop config on macOS or Windows, and so on):

{
  "mcpServers": {
    "should-i-use": {
      "command": "npx",
      "args": ["-y", "should-i-use-mcp"]
    }
  }
}

Any other MCP client: command npx, args ["-y", "should-i-use-mcp"]. Running from a local checkout: command node, args ["/path/to/should-i-use/server.js"]. VS Code puts the same object under servers instead of mcpServers, and Zed under context_servers; the installer handles both.

Hosted endpoint (rolling out)

A hosted streamable-HTTP endpoint is rolling out at https://mrkeyoor.com/mcp. It serves the live index, so it can be a day fresher than the npm snapshot. The npx install above is the stable path today.

Related MCP server: mcp-npm-tools

Tools

Tool

Example call

What you get back

pick_library

pick_library("parse CSV files in node")

Top 1-3 picks with one-line reasoning, plus a skip warning for the winner

should_i_use

should_i_use("moment")

Verdict, 4-axis scores with reasons, top skip-if items, last push and download signals

audit_dependencies

audit_dependencies(<contents of package.json>)

Only the dependencies worth a decision: unmaintained, unstable, or worth swapping

alternatives

alternatives("axios")

Curated alternatives with "prefer it when" lines and verdicts

how_do_i

how_do_i("got", "retry a failed request")

The 1-2 best snippets for the task plus their gotchas, nothing else

docs_link

docs_link("fastapi", "middleware")

Docs URL and repo link, one line each

audit_dependencies

The pitch is "ask before you npm install". This is the tool for the codebase you did not write, where the installing already happened.

Pass it the contents of package.json, requirements.txt, pyproject.toml, or just a newline-separated list of names. It returns only the dependencies that need a human decision, sorted into REPLACE (unmaintained), WATCH (unstable API or thin maintenance), and WORTH RECONSIDERING (a documented reason to skip plus a named alternative). It stays quiet about the boring majority, and it says nothing at all about packages that are not in the index rather than inventing an opinion.

Real output, unedited:

REPLACE (1 unmaintained):
- crypto-js: last push 2.0y ago, still 19.3M/wk. Nineteen million weekly
  downloads of pure inertia behind a library whose own README tells you to
  stop using it. Consider @noble/hashes or @noble/ciphers.
REPLACE (1 unmaintained):
- python-jose: last push 4mo ago, still 10.6M/wk. It works, it is widely
  deployed, and the API is pleasant, but a cryptography library with a
  three-and-a-half-year release gap and a ten-month turnaround on two
  critical advisories is not where new code should start. Consider pyjwt
  or joserfc.

Both of those are popular packages in current use. Download count is not a maintenance signal, and that is the gap this tool is for.

A good first prompt after installing: "audit my dependencies".

Token budget, measured

  • Typical answer: 25 to 360 tokens, depending on the tool and how much the library page has to say.

  • Hard cap: 500 tokens per response, enforced in clamp.js. Long answers are cut at sentence boundaries with a pointer to docs_link.

  • The smoke test (npm run smoke) spawns the server, calls every tool against the bundled data, and fails if any response breaks the cap. The budget is a test, not a promise.

Measured against Context7 across 10 rounds of 20 queries on libraries sampled at random from this index, tokens estimated as chars/4. Ours is one how_do_i call; theirs is the two calls an agent actually makes, resolve-library-id plus the docs call at its default budget. Query text was authored from each library's description only, never from our stored answers.

Median tokens per answer

should-i-use

238

Context7

1154

Ratio

4.8x (round range 3.9x-6.2x)

Of 200 rows, 199 were answered by both servers; Context7 had no usable entry for 1 library, this index for 0.

Every number there is a measured MCP response, not a vendor claim. See the limitations below for what that ratio does and does not prove.

How the data is made

Every entry is a guide written to a fixed rubric, grounded in the library's own docs and validator-gated, backed by registry and repo signals — not scraped docs:

  • Guides and verdicts: what the library is, when to use it, when to skip it, published at mrkeyoor.com/libs by Keyoor.

  • Scores: 4 axes (API stability, docs quality, maintenance, ecosystem), 1-5 each, with a one-line reason per score.

  • Signals: last push, weekly downloads, and stars refreshed daily from the registries and GitHub.

  • Snippets: checked against the indexed version, each with its gotcha.

The bundled snapshot (data/libraries.json) is exported daily from that index. Honest means the index will tell you to skip the popular option when the maintenance signals say so. No library has paid to be listed or to change a score.

Set SHOULD_I_USE_DATA=/path/to/libraries.json to point the server at your own snapshot (same shape: a JSON array of library docs).

Requirements

  • Node 20+

  • Nothing else. No database, no network access at runtime.

Limitations

Worth knowing before you rely on it:

  • Coverage is curated, not complete. A few hundred libraries, not every package on npm and PyPI. audit_dependencies therefore stays quiet on anything unindexed, and a clean audit means "nothing flagged in what I know", not "your dependencies are fine".

  • The tools are advisory unless you add the policy line. An agent calls MCP tools when it decides to, so on its own this is a strong suggestion, not an interceptor: nothing forces every npm install through a check. To make the check near-automatic, run npx should-i-use-mcp install --with-policy inside a project: it appends a one-line dependency policy to your CLAUDE.md/AGENTS.md (creating AGENTS.md if neither exists), and agents that read project rules will then consult the index before adding any dependency.

  • Guides are research, not test drives. Each guide is grounded in the library's documentation, release notes, changelog, and issue history on a fixed rubric, not a hands-on install of every release. The 50 most-downloaded entries are additionally install-verified in clean containers (latest run: 49/50 clean; the one timeout was sglang's CUDA wheel tree, which its own guide warns about).

  • Guides are point-in-time. Signals refresh daily and guides are reviewed on a pipeline, so a library that shipped a big release or found a new maintainer this week can be ahead of what the guide says. Check docs_link when the answer looks stale.

  • pick_library ranks on keywords, not embeddings. Plain phrasing works well; unusual or metaphorical phrasing can miss entirely. If nothing matches, it says so instead of returning a shrug, but you may need to reword.

  • The benchmark is indicative, not definitive. 10 rounds of 20 queries on randomly sampled libraries, measured across two days. The 4.8x ratio is a real measurement with a 3.9x-6.2x round range, not a general law. The method and every row are in bench/; rerun it yourself if the number matters to you.

  • Verdicts are opinions. Informed, sourced, and argued, but still one person's judgment call. Disagreeing with one is a valid bug report.

Contributing

  • Missing library or wrong verdict? Open an issue. Challenges to verdicts are how the index gets better.

  • Code changes: PRs welcome for the server (server.js, tools.js, clamp.js, data.js, install.js). Keep responses inside the 500 token cap; npm run smoke enforces it.

  • Data changes: data/libraries.json is generated, so edits to it get overwritten by the next export. File an issue instead and the fix lands upstream.

License

Available Tools

5 tools
alternativesAInspect

Curated alternatives to a library, each with a one-line "prefer it when" and a verdict if the alternative is also indexed.

ParametersJSON Schema
NameRequiredDescriptionDefault
libraryYesLibrary name as published on npm or PyPI

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the transparency burden. It discloses that results are 'curated' and include a conditional verdict 'if the alternative is also indexed,' which adds some behavioral context. However, it does not mention potential outcomes (e.g., unknown library), output format details, or whether the operation is read-only.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that front-loads the core purpose ('Curated alternatives to a library') and packs key output features without unnecessary words. Every part earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains the primary output (alternatives with 'prefer it when' and verdict) but lacks details about error cases, the source/nature of the curation, or how the alternative indexing verdict is determined. For a one-parameter tool with no output schema, this is adequate but not fully comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already fully documents the 'library' parameter as 'Library name as published on npm or PyPI' (100% coverage). The description adds no new parameter-level details, so the schema carries the load, warranting the baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns curated alternatives to a library, with each alternative accompanied by a 'prefer it when' line and a verdict. This distinguishes it from sibling tools like docs_link and how_do_i, though it doesn't use an explicit verb like 'list' or 'get'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when the user needs alternative library options, but it does not explicitly state when to use this tool versus alternatives like should_i_use or pick_library. No exclusions or alternative suggestions are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

how_do_iAInspect

Return the 1-2 best code snippets for a task with a library, plus the gotcha for each. Snippets are correct for the indexed version. Far cheaper in tokens than a docs dump.

ParametersJSON Schema
NameRequiredDescriptionDefault
taskYesWhat you want to do, e.g. "retry a failed request"
libraryYesLibrary name as published on npm or PyPI

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses a key behavioral caveat: 'Snippets are correct for the indexed version,' warning that they may not be correct for other versions. It also mentions the gotcha per snippet and the token cost, adding useful context beyond a simple description. It does not cover error cases or exact response format, but it provides meaningful behavioral insight.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three tight sentences, front-loaded with the action and result. Each sentence earns its place: the first states what the tool returns, the second adds the critical version accuracy caveat, and the third gives a cost efficiency reason. There is no fluff or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with only two well-documented parameters, and no output schema exists. The description adequately explains the return content: 1-2 best snippets and their gotchas. Given the tool's simplicity, it provides a sufficient overview, though it could mention the response structure or ordering. It feels complete for the use case.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, meaning both parameters (library and task) are already fully documented in the schema. The description reinforces their semantics by saying 'for a task with a library' but provides no additional format, syntax, or usage details beyond what the schema already states. Thus, the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Return' and names the resource: '1-2 best code snippets for a task with a library.' It also adds a distinctive detail about the 'gotcha for each.' However, unlike the TDQS 4.3 example, it does not explicitly distinguish itself from sibling tools like pick_library or docs_link, though the function is clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool: when you have a specific library and task. It also gives a practical guideline by noting it is 'far cheaper in tokens than a docs dump,' which helps the agent decide between this and a documentation lookup. It lacks explicit exclusions or alternative tool mentions, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pick_libraryAInspect

Given a coding task, recommend 1-3 libraries from the should-i-use index with one-line reasoning and an honest warning about the top pick. Use before installing anything.

ParametersJSON Schema
NameRequiredDescriptionDefault
taskYesWhat you are trying to do, e.g. "parse CSV files in node"
ecosystemNoOptional registry filter

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It reveals the output behavior (1-3 libraries, one-line reasoning, honest warning) and implies a non-destructive read-only operation via 'Use before installing anything.' This exceeds the minimum for a recommendation tool but doesn't go into deeper side effects or requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, info-dense sentence that front-loads the core purpose and then adds usage guidance. Every word earns its place, with no fluff or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with only 2 simple parameters and no output schema, the description fully covers purpose, output format, and usage timing. It also hints at the data source (should-i-use index) and differentiates from siblings. No critical information is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both 'task' and 'ecosystem' are already well documented. The tool description does not add parameter-specific details, but it doesn't need to—the schema handles it. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action: 'recommend 1-3 libraries from the should-i-use index' with reasoning and a warning. It distinguishes from sibling tools like 'should_i_use' (which likely evaluates a specific library) and 'alternatives' (which suggests substitutes) by focusing on task-based recommendations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context with 'Given a coding task' and explicit timing guidance: 'Use before installing anything.' It doesn't explicitly name alternatives or exclusions, but the directive is unambiguous and gives the agent enough to know when to invoke it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

should_i_useAInspect

Honest verdict on a specific library: 4-axis scores with reasons, when to skip it, and maintenance signals (last push, weekly downloads).

ParametersJSON Schema
NameRequiredDescriptionDefault
libraryYesLibrary name as published on npm or PyPI

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden of disclosing behavior. It mentions useful outputs like 'when to skip it' and 'maintenance signals,' but it does not state whether the tool fetches live data, is subjective, or has side effects. This leaves some behavioral uncertainty.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence front-loads the purpose ('Honest verdict') and lists key output components in a readable, colon-separated format. Every phrase contributes meaning; there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter tool with no output schema or annotations, the description adequately conveys the tool's purpose and return contents. The vague reference to '4-axis scores' is a minor gap, but overall it is sufficiently complete for the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 100% description coverage for the single 'library' parameter, so the baseline is 3. The description adds no parameter-specific details beyond the schema, merely referring to 'a specific library.'

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly identifies the tool as producing an 'Honest verdict' on a library, with specific output components like scores and maintenance signals. This distinguishes it from sibling tools, though the exact 4 axes are not enumerated, preventing a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied: use when evaluating whether to adopt a library. It does not explicitly contrast with sibling tools like 'alternatives' or 'how_do_i,' so no clear exclusions or when-not-to-use guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 5 tool updatesv0.1.0
    • First observedalternatives
    • First observeddocs_link
    • First observedhow_do_i
    • First observedpick_library
    • First observedshould_i_use
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a distinct role: discovering libraries for a task (pick_library), evaluating a known library (should_i_use), exploring alternatives (alternatives), getting usage snippets (how_do_i), and finding documentation (docs_link). There is no overlap in purpose or input type.

Naming Consistency2/5

Tool names are a mix of verb phrases (pick_library, how_do_i), noun phrases (alternatives, docs_link), and a sentence-like phrase (should_i_use). While all lowercase with underscores, the lack of a consistent syntactic pattern makes the naming unpredictable.

Tool Count5/5

With 5 tools, the server is well-scoped and each tool serves a clear, distinct function. The count falls comfortably within the ideal 3-15 range for a focused toolkit.

Completeness5/5

The tool set covers the complete library decision workflow: discovering candidates, evaluating a library, comparing alternatives, obtaining usage code, and accessing official docs. There are no obvious gaps for the server's stated purpose.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • MCP Package Hero

    moinsen-dev
    A
    license
    A
    quality
    D
    maintenance
    A comprehensive MCP server for checking package versions and rating package quality across Python (PyPI), JavaScript/TypeScript (npm), Dart (pub.dev), and Rust (crates.io) ecosystems.
    5
    MIT

  • mcp-npm-tools

    rog0x
    A
    license
    A
    quality
    D
    maintenance
    MCP server providing npm registry search, package details, dependency auditing, bundle size estimation, and package comparison tools for AI agents.
    5
    32 npm
    MIT

  • freshdeps-mcp

    SolvoHQ
    A
    license
    Not graded
    quality
    D
    maintenance
    MCP server that checks npm and PyPI package health, providing maintenance signals, version info, CVE counts, and alternative suggestions.
    MIT