Skip to main content
Glama

Gnomad

by io.github.pipeworx-io

Scan Dependency

scan_dependency
Read-onlyIdempotent

Composite "should I add this npm package to my project" check in ONE call — fans out across deps.dev (license + advisories + version history) and bundlephobia (gzipped/minified bundle size, dependency count, ESM/tree-shake support). Use whenever an agent asks "is X safe / popular / small" or "what does adding lodash cost me". Returns a summary block (is_latest, license, published_at, advisory_count, bundle_kb_min, bundle_kb_gz, dependency_count, has_esm, tree_shakeable), per-advisory detail, links, and a list of recent alternative versions. NPM ecosystem only in v1; PyPI / Maven / Cargo / Go fall under deps.dev:version directly. Partial failures degrade gracefully — bundlephobia's first measurement on a new version can take 5-30s; sources_failed will list it if it times out, the rest still returns.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
packageYesnpm package name. Scoped packages (e.g. "@types/node") are accepted.
versionNoSpecific version to check (e.g., "18.3.1"). Defaults to the latest published version when omitted.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the read-only, idempotent hints, the description discloses important behavioral traits: it fans out across two external services, handles partial failures gracefully, mentions that bundlephobia's first measurement can take 5-30 seconds, and explains the 'sources_failed' field. This gives a clear picture of runtime behavior and failure modes.

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 concise yet information-dense. It is structured logically: purpose, usage, return value, ecosystem scope, and failure behavior. Every sentence adds unique information, and there is 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?

Despite lacking an output schema, the description specifies the exact return field names (is_latest, license, published_at, etc.), explains partial failure behavior, latency expectations, and ecosystem limitations. This is a complete description for a complex composite tool.

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 provides 100% coverage for the two parameters (package and version), so the baseline is 3. The description does not add significant new semantics beyond what the schema states; it indirectly references versions through 'version history' and 'new version' but doesn't elaborate on parameter formats or constraints.

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 the tool's purpose: a composite check for 'should I add this npm package to my project', combining deps.dev and bundlephobia data. The verb 'scan' and specific resources (npm package, deps.dev, bundlephobia) are explicit, and it distinguishes itself from siblings by being a single-call composite.

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

Usage Guidelines5/5

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

The description provides explicit usage guidance: 'Use whenever an agent asks "is X safe / popular / small" or "what does adding lodash cost me"'. It also clearly delineates when NOT to use it by noting that other ecosystems (PyPI/Maven/Cargo/Go) fall under deps.dev:version directly, guiding the agent to alternatives.

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

All Gnomad toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.4/5.0
Disambiguation2/5

The set mixes several overlapping query surfaces: ask_pipeworx and ask_pipeworx_beta are currently identical, ask_pipeworx_grounded/deep_research/discover_tools/suggest_questions all serve related retrieval/discovery purposes, and the five polymarket_* tools have similar opportunity-finding goals. Only the unusually detailed descriptions save some tools from misselection; an agent would struggle to quickly pick the right one.

Naming Consistency4/5

Names are uniformly snake_case and mostly follow a verb_noun or prefixed_noun pattern (ask_pipeworx, validate_claim, polymarket_edges, scan_dependency). Minor inconsistencies exist — bare nouns like gene/variant/search sit alongside compound names like generate_llms_txt, and the pipeworx_ prefix isn't applied to ask_pipeworx/deep_research — but the overall style is recognizable and predictable.

Tool Count2/5

36 tools is too many for a coherent server, especially since the domains are largely unrelated: 5 gnomAD genomics tools, 20+ Pipeworx/Polymarket data tools, memory CRUD, subscription management, and a couple of web-dev utilities. The count doesn't align with a single obvious scope and would overwhelm an agent selecting among them.

Completeness3/5

Within the major subdomains coverage is strong: memory has remember/recall/forget, subscriptions have full lifecycle tools, and Polymarket has edge detection plus fill-risk checking. However, there are notable gaps — no tool to fetch a pipeworx:// citation URI despite deep_research promising resolvable citations, and the gnomAD surface lacks batch queries, coverage, or constraint data for a server named Gnomad.

Resources