Skip to main content
Glama

Domains

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?

Discloses important behavioral traits beyond the annotations: partial failures degrade gracefully, bundlephobia's first measurement may take 5-30 seconds, and sources_failed will report timeouts while the rest still returns. This prepares the agent for non-obvious runtime behavior without contradicting the readOnly/idempotent hints.

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?

Every sentence earns its place: purpose, usage, return object, ecosystem scope, and failure handling are packed into a compact paragraph. The information is front-loaded and logically structured, with no tautology or filler.

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 enumerates all summary fields (is_latest, license, bundle_kb_gz, etc.), mentions per-advisory details and links, and explains ecosystem limitations and failure behavior. This fully compensates for the missing schema and gives a complete picture of the tool's behavior.

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 covers 100% of parameters with descriptions, so the baseline is 3. The description adds no new parameter semantics beyond what the schema already provides; it merely restates the npm ecosystem context. It does not compensate with additional syntax or edge-case guidance.

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 it is a composite npm package check that fans out to deps.dev and bundlephobia, listing specific data points (license, advisories, bundle size, etc.). This distinguishes it from sibling tools like domain_lookup or certificate_search, which serve entirely different purposes.

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?

Explicitly instructs when to use ('whenever an agent asks is X safe / popular / small'), and provides a clear exclusion ('NPM ecosystem only in v1') with an alternative for other ecosystems ('PyPI / Maven / Cargo / Go fall under deps.dev:version directly'). This is strong guidance on both when and when not to use the tool.

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

All Domains 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

A3.9/5.0
Disambiguation4/5

Most tools have distinct purposes, but ask_pipeworx and ask_pipeworx_grounded overlap heavily (one is a grounded variant). Also, multiple polymarket tools serve related functions, though descriptions differentiate them. Overall clear but minor confusion possible.

Naming Consistency4/5

Tool names follow a mostly consistent snake_case pattern with descriptive names. Some tools use prefixes like pipeworx_ or polymarket_ which is internally consistent. A few short names like 'forget' deviate slightly, but overall convention is maintained.

Tool Count3/5

With 32 tools, the server covers a broad range of functionalities from AI visibility to prediction markets. While each tool serves a purpose, the count feels high for coherence, bordering on unnecessary complexity. Still, the scope justifies the number.

Completeness3/5

The tool set covers many areas like company data, prediction markets, domain lookups, and memory. However, there are gaps: no user management beyond subscriptions, no file handling, and some areas like real estate are mentioned but not directly addressed. Overall functional but not exhaustive.

Resources