Back to tracker
Plugin tracker
Tools
Explore what tracked Claude Connectors and ChatGPT Plugins can actually do. Search by tool, Plugin, Brand, category, verb, or access requirement.
Latest snapshot2026-09-11USmethodology registry-public-v1
Searchable tools
113,017
Authless tools
7,424
Auth required
100,766
Described tools
61,166
113,017 tools
- Update Growth Signal Targetingupdate · Turn the RealtyAds account's growth-signal targeting toggles on or off — Power Prospecting (hiring growth), Coworking, Funding events, and Site Selectors. Each is a boolean. Partial input is safe — missing toggles keep their current value.
Use this tool when the user wants to enable or disable any of the RealtyAds growth-signal targeting features on a property account — "turn on power prospecting", "stop targeting based on funding events", "enable site selectors targeting on this property", "disable coworking targeting".
These four toggles live together on a single portal settings card. Each is independent (you can flip any combination), but they share the same save endpoint and are typically updated together.
Toggles:
- power_prospecting — RealtyAds AI promotes companies with strong hiring growth signals (e.g. 20%+ headcount rise).
- coworking_targeting — RealtyAds AI promotes coworking companies / flexible-space tenants.
- funding_targeting — RealtyAds AI promotes companies with recent funding events.
- site_selectors_targeting — RealtyAds AI promotes site-selection / corporate-real-estate-advisory firms.
What it does (mirrors the portal):
- UPDATEs the corresponding column on r1.realty_accounts per changed toggle (power_prospecting maps to company_growth_targeting; others map to columns of the same name).
- INSERTs one targeting_update_log row per changed toggle.
- Logs one r1.user_change_log entry per change ("Updated Power Prospecting Targeting", "Updated Funding Targeting", etc.) with action_source="mcp".
Partial input is safe. Send only the toggles you want to change — missing keys retain their current value. To disable a toggle, set it to false explicitly.
Read current state from get_ad_targeting.growth_signals before calling so the user-visible change is intentional.
Returns:
- action_taken: "updated" or "no_changes"
- account_id
- growth_signals: the new full state — { power_prospecting, coworking_targeting, funding_targeting, site_selectors_targeting }
- changes: per-toggle diff
- warnings: any unrecognized toggle names you sent
- message: short summary
This is a WRITE action.RealtyAdsRealtyAds
PluginrequiredMarketing - Update Industry Targetingupdate · Replace the account's industry targeting list with a new set of broad industry ids and/or detailed-category ids. Replace-all semantics — send the full desired set. Read current state from get_ad_targeting.filters.industries / .detailed_categories before calling.
Use this tool when the user wants to change the industry focus on a RealtyAds property account — "target Technology and Financial only", "add Life Sciences to our industry focus", "drop Retail from targeting", "broaden to include Manufacturing".
Replace-all semantics. Send the full desired set of industry ids in one call. The tool DELETEs the existing industry junction rows and re-INSERTs the new set.
Two kinds of ids are accepted:
- Broad industries (ids 1–49) — these also write to the legacy CSV column r1.realty_accounts.target_industries.
- Detailed industry categories (ids in the thousands) — these are sub-segments within a broad industry (e.g. "Accounting Services" under "Business Services"). They only write to the junction.
Common broad industry ids (active in r1.realty_industries):
1 = Business Services
2 = Education
3 = Energy Sector
4 = Financial Sector
5 = Legal Sector
6 = Life Sciences
7 = Manufacturing
8 = Media & Communications
9 = Medical Practice
10 = Nonprofit
11 = Public Sector
12 = Commercial Real Estate
13 = Retail & Consumer Goods
14 = Technology
15 = Transportation & Logistics
16 = Warehousing
If the caller doesn't know an id, call get_ad_targeting first to see the current set, or look up by name via the read-side knowledge tools — this tool will not accept industry names.
Validation: every supplied id is checked against the two catalog tables. Unrecognized ids are dropped with a warning, not silently committed.
Returns:
- action_taken: "updated" or "no_changes"
- account_id
- industries: the new full set — array of { industry_id, name, kind: "broad" | "detailed" }
- added: array of { industry_id, name } added vs prior state
- removed: array of { industry_id, name } dropped vs prior state
- warnings: any unrecognized ids you sent
- message: short summary
This is a WRITE action. Logged in r1.user_change_log under "Updated Industry Targeting" with action_source="mcp".RealtyAdsRealtyAdsPluginrequiredMarketing
- Update Saved Adupdate · Edit an existing saved ad's copy, media, landing page, or label in place without making it live.
Omitted fields stay unchanged. Use media ids returned by list_media_library or add_media_to_library. This keeps the same saved_ad_id and does not change the live ad. Call launch_saved_ad separately after explicit user confirmation.RealtyAdsRealtyAdsPluginrequiredMarketing
- Update Target Audience Groups Targetingupdate · Turn the account's high-level RealtyAds target audiences on or off — broker reach, tenants in the market, asset managers, residential brokers (multi-family), and the bookkeeping entries for the account's own uploaded lists. Each audience is a boolean. Read current state from get_ad_targeting.target_audiences before calling.
Use this tool when the user wants to change which high-level RealtyAds proprietary audiences a property account is targeting — "turn off broker reach", "stop targeting tenants in the market on this account", "turn the asset managers audience back on", etc. This is the same panel the portal's "Target Groups" section saves.
What it does (mirrors the portal):
- Replaces the `prioritized_targeting_groups` JSON on r1.realty_accounts with the desired full state.
- Inserts a `targeting_update_log` row of type `targeted_group_update`.
- Logs to r1.user_change_log under "Updated Targeting Groups" with action_source="mcp".
How to call it:
- account_id: the RealtyAds property account.
- target_audiences: a JSON object keyed by audience group id, with a boolean value for each. Group ids:
1 = Commercial Real Estate Brokers (drives "Broker Reach")
2 = Tenants In The Market (drives "Tenant Reach")
3 = My Uploaded Target Individual List
4 = My Uploaded Target Company List
5 = Asset Managers & Property Owners
6 = Residential Real Estate Brokers (multi-family accounts only)
Example:
{ "1": true, "2": true, "5": false }
sets Brokers + Tenants on, Asset Managers off, leaves anything else at its current state.
Partial input is safe: any group id not in your request keeps its existing value. To explicitly opt a group out, set its key to false.
Group ids that don't exist or aren't visible to this account's category (e.g. group 6 on a non-multi-family account) are dropped with a warning, not written.
Read current state first via get_ad_targeting (the `target_audiences` block lists each group's name + included bool). Treat the result as the source of truth before modifying.
Returns:
- action_taken: "updated" or "no_changes"
- account_id
- target_audiences: the new full state — array of { group_id, name, included }
- changes: per-group diff vs prior state
- warnings: any unrecognized group ids you sent
- message: short summary
This is a WRITE action.RealtyAdsRealtyAdsPluginrequiredMarketing
- Update Vertical Targetingupdate · Turn the RealtyAds account's vertical / specialty targeting toggles on or off — geo-fencing (universal), live-work-play and ideal-tenant (Multi-Family only), life-science investor targeting (Life Science only). Each is a boolean. Partial input is safe — missing toggles keep their current value.
Use this tool when the user wants to enable or disable any of the RealtyAds vertical / specialty targeting features on a property account — "turn on geo-fencing for this property", "stop live-work-play targeting", "enable ideal-tenant targeting on this multi-family asset", "turn on life-science investor targeting".
These toggles live on the same portal settings card as the growth signals; this tool covers the vertical / specialty ones, while `update_growth_signal_targeting` covers the universal behavior signals (power_prospecting, coworking, funding, site_selectors). Two tools so the args stay focused and the LLM can reason about which group of toggles a request matches.
Toggles:
- geo_fencing — universal. Enables physical-location geo-fencing of the property's defined geo radius.
- live_work_play_targeting — Multi-Family only. Promotes live/work/play lifestyle audience signals.
- ideal_tenant_targeting — Multi-Family only. Promotes the property's ideal-tenant profile.
- life_science_investor_targeting — Life Science only. Promotes life-science investor signals.
What it does (mirrors the portal):
- UPDATEs the corresponding column on r1.realty_accounts per changed toggle (geo_fencing stores 'enable' / 'disable'; the other three store '1' / '0').
- INSERTs one targeting_update_log row per changed toggle.
- Logs one r1.user_change_log entry per change ("Updated Geofencing", "Updated Live Work Play Targeting", "Updated Multi-family Ideal Tenant Targeting", "Updated Life Science Investor Targeting") with action_source="mcp".
Partial input is safe. Send only the toggles you want to change — missing keys retain their current value. To disable a toggle, set it to false explicitly.
The vertical-specific toggles (live_work_play, ideal_tenant, life_science_investor) only have meaningful behavior on accounts of the matching vertical — they're stored unconditionally either way, mirroring the portal.
Read current state from get_ad_targeting before calling (geo_fencing is exposed under `geography.geo_fencing`; the vertical-specific bools are under `vertical_specific`).
Returns:
- action_taken: "updated" or "no_changes"
- account_id
- vertical_targeting: the new full state — { geo_fencing, life_science_investor_targeting, live_work_play_targeting, ideal_tenant_targeting }
- changes: per-toggle diff
- warnings: any unrecognized toggle names you sent
- message: short summary
This is a WRITE action.RealtyAdsRealtyAdsPluginrequiredMarketing
- Buscar registros de facturaciónbuscar · Searches read-only Facturacion/TuFactura records in Quipo for the authenticated MCP context.tugestotugestoPluginrequiredFinance
- Buscar registros de negociosearch · Searches business records through the generic MCP interface. Supports Facturacion/TuFactura records. Use discover-business-capabilities to inspect connected modules.tugestotugestoPluginrequiredFinance
- Convertir presupuestoconvertir · Accepts, rejects, or converts a Quipo presupuesto into a factura for the authenticated MCP context.tugestotugestoPluginrequiredFinance
- Crear documento de facturacióncrear · Creates a guarded Facturacion/TuFactura invoice or presupuesto in Quipo for the authenticated MCP context after explicit confirmation.tugestotugestoPluginrequiredFinance
- Descubrir capacidades de negociodiscover · Lists available MCP business modules, record types, safe tools, workflow candidates, and blocked capabilities.tugestotugestoPluginrequiredFinance
- Enviar factura por emailenviar · Sends the original Quipo invoice PDF by email for the authenticated MCP context. Only facturas are supported.tugestotugestoPluginrequiredFinance
- Estado del servidorserver · Checks that the tugesto MCP server is reachable and responding. Returns a simple status; no business data involved.tugestotugestoPluginrequiredFinance
- Gestionar clientesgestionar · Creates, updates or deletes a Quipo client (cliente) in the authenticated MCP context after explicit confirmation.tugestotugestoPluginrequiredFinance
- Gestionar documentos de facturacióngestionar · Updates or deletes an existing Quipo invoice (factura) or quote (presupuesto), identified by serie and numero, after explicit confirmation. Facturas are only editable when Quipo allows it (pending payment, open accounting period, not sent to SII); otherwise explain that the user must create a credit note (abono) or rectifying invoice instead of calling this tool to update.tugestotugestoPluginrequiredFinance
- Gestionar productos y serviciosgestionar · Creates, updates or deletes a Quipo product/service (producto/servicio) in the authenticated MCP context after explicit confirmation.tugestotugestoPluginrequiredFinance
- Gestionar series de facturacióngestionar · Creates, updates or deletes a Quipo invoicing series (serie) in the authenticated MCP context after explicit confirmation.tugestotugestoPluginrequiredFinance
- Listar cuentas bancariasobtener · Lists the bank accounts configured for invoicing in a Quipo company, so the user can tell them apart: name, a masked account number showing only its last four characters, and whether the account is enabled. Full account numbers and BIC codes are never returned.tugestotugestoPluginrequiredFinance
- Listar empresas disponibleslistar · Lists the Quipo companies available in the authenticated MCP context. Use this before Facturacion tools when more than one company is available. Each company has an "id" and a "name". The "id" is for internal use only: pass it as the "empresa_id" parameter of the other Facturacion tools. NEVER show the "id" to the user. When presenting the list of companies, show ONLY their names, not the id.tugestotugestoPluginrequiredFinance
- Obtener PDF de facturaobtener · Gets read-only Facturacion/TuFactura artifacts from Quipo. Supports factura_pdf_link and factura_pdf.tugestotugestoPluginrequiredFinance
- Obtener artefacto de negocioget · Gets an existing business artifact from connected modules. Supports Facturacion/TuFactura invoice PDF links and PDF content.tugestotugestoPluginrequiredFinance
- Obtener cabecera de facturaciónobtener · Gets the branding and legally required company data (name, address, logo) of the authenticated user's own company. Use it to brand documents and reports with the company identity. The company phone number and email address are never returned.tugestotugestoPluginrequiredFinance
- Obtener contexto de negocioget · Returns the MCP business context: platform, supported modules, integration status, and global safety rules.tugestotugestoPluginrequiredFinance
- Obtener perfil de facturaciónobtener · Gets the authenticated user profile for invoicing in Quipo: display name, role and the names of the companies the user can operate. Login name, email address and company fiscal identifiers are never returned.tugestotugestoPluginrequiredFinance
- Obtener registro de facturaciónobtener · Gets a single read-only Facturacion/TuFactura record from Quipo for the authenticated MCP context.tugestotugestoPluginrequiredFinance
- Obtener registro de negocioget · Gets one business record through the generic MCP interface. Supports Facturacion/TuFactura records. Use discover-business-capabilities to inspect connected modules.tugestotugestoPluginrequiredFinance
- Previsualizar documento de facturaciónprevisualizar · Previews a Facturacion/TuFactura invoice PDF in Quipo without persistence for the authenticated MCP context.tugestotugestoPluginrequiredFinance
- Registrar cobro de facturagestionar · Registers a total or partial payment for a Quipo factura in the authenticated MCP context.tugestotugestoPluginrequiredFinance
- Resumen de facturaciónresumen · Summarizes a company invoicing period: totals, monthly evolution, collection status and top customers. Preferred starting point for reports and dashboards; use buscar-registros-facturacion only when document-level detail is needed.tugestotugestoPluginrequiredFinance
- Resumir área de negociosummarize · Summarizes a connected business area. Supports Facturacion/TuFactura totals, monthly evolution, collection status, and top customers.tugestotugestoPluginrequiredFinance
- Analyze an npm package install scriptanalyze · Statically scans a package's preinstall/install/postinstall/prepare lifecycle scripts AND the file(s) they reference — fetched directly from the published tarball, not just the command string in package.json — against npmscan's documented red-flags rubric (/docs/red-flags): child_process use, network calls, access to sensitive paths/env (.ssh, .aws, .npmrc, *TOKEN/*KEY), obfuscation, remote binaries hosted off trusted CDNs, writes to HOME, Discord/Telegram/Pastebin exfil endpoints, eval on decoded strings, chmod+exec of downloaded binaries, and CI-metadata telemetry — plus a possibleTyposquatOf name check. Returns a weighted totalScore and riskTier ('none'/'low'/'moderate'/'high'/'critical'). This is a heuristic static scan, not proof of malice or a guarantee of safety: it doesn't execute any code, can't see behavior gated on runtime conditions, and does NOT check maintainer/ownership history (a separate red-flags signal this tool doesn't cover). Use get_package/get_package_version first for the raw script listing; use this when you need to know what an install script actually does, not just that one exists.NPMScanNPMScanPluginnoneSecurity
- Analyze transitive dependencies for vulnerabilitiesanalyze · Recursively resolves one or more direct/root packages' dependency graphs — e.g. the "dependencies" section of a package.json — up to maxDepth levels deep (default 2, max 3) and batch-checks every resolved package@version against OSV.dev, so vulnerabilities buried several levels down (which would never show up from checking direct dependencies alone) still surface. `summary` is a one-sentence, deterministic recap (packages scanned, unresolved count, vulnerable count and which roots pulled them in) — read it first. The `vulnerablePaths` field directly answers "which of my dependencies pulled this in" by naming the root package(s) responsible for each vulnerable transitive package; `nodes` has the full resolved graph (depth, parents, resolutionError) for deeper inspection. Scope/limits worth knowing before trusting a "clean" result: only the "dependencies" field is followed (not devDependencies/peerDependencies/optionalDependencies); each range is resolved independently per branch via semver max-satisfying against published versions — this does NOT emulate npm/yarn's actual node_modules hoisting/dedup, so read results as "which vulnerable versions are reachable in the graph," not the exact installed layout; git/file/workspace/URL/npm-alias dependencies aren't resolvable from the registry and show up with a resolutionError instead of being silently skipped; and the whole traversal is capped at a total node budget — check `truncated`/`truncationNote` rather than assuming a large graph was scanned exhaustively. Prefer batch_query_vulnerabilities instead when you only need to check exact packages you already have a flat list for (faster, no graph walk).NPMScanNPMScanPluginnoneSecurity
- Audit a GitHub repository's npm dependenciesaudit · Given a GitHub repository URL, fetches its package.json (and, if present, a pnpm-lock.yaml/package-lock.json/yarn.lock — first one found wins, in that priority order) straight from the repo's default branch and runs the same vulnerability, license-compliance, install-script, and ownership-risk pipelines batch_query_vulnerabilities/check_license_compliance/analyze_install_script/check_maintainer_changes/check_package_provenance expose individually, in one call — no copy-pasting file contents required. A monorepo (package.json#workspaces, Yarn's {packages:[...]} form, or pnpm-workspace.yaml) is detected automatically: pnpm-lock.yaml and yarn.lock already record every workspace member's dependencies directly, and for package.json-only or package-lock.json repos this additionally lists the repo's file tree, resolves the declared glob patterns to member directories, and merges each member's dependencies into the audit (capped at 50 member packages) — see isMonorepo/workspacePatterns/workspacePackageCount/workspaceNote in the result. Every direct dependency (up to 100 per call, across the root and any merged workspace members) gets: an OSV.dev vulnerability check, a license-compliance verdict against the given policy (same default as check_license_compliance: only copyleft/network-copyleft/proprietary are violations unless you pass one), and a tarball-free install-script risk signal (installScriptScanScope: 'lifecycle-scripts-only'). Up to 10 of the packages that actually declare a lifecycle script — prioritized by already-vulnerable, then possible-typosquat, then whatever's left — additionally get the full tarball-fetching deep scan analyze_install_script itself runs (installScriptScanScope: 'deep-tarball-scan', with a populated installScriptFindings array); any remaining flagged packages past that cap keep the lighter signal only, noted in deepScanNote. Any package that comes back vulnerable at high/critical severity, a possible typosquat, or deprecated (ownershipRiskEligible) additionally gets check_maintainer_changes and check_package_provenance run against it — up to 5 such packages per call (ownershipRiskChecked), prioritized the same way as the deep install-script scan, populating maintainerRiskTier/maintainerFindings and provenanceRiskTier/provenanceFindings; remaining eligible packages past that cap are named in ownershipCheckNote. This is the most expensive tool in the suite (a repo lookup, a handful of file fetches, up to 100 registry doc fetches, one OSV batch call, up to 10 tarball fetches, up to 5 packages each getting a maintainer-history check plus a provenance check — the latter alone can fan out to ~8 more registry fetches on its own — and, for a monorepo needing enumeration, one file-tree listing plus up to 50 more manifest fetches) — don't call it in a loop across many repos.NPMScanNPMScanPluginnoneSecurity
- Batch query known vulnerabilitiesbatch · Query OSV.dev for known vulnerabilities across a whole npm dependency inventory at once: either pass a flat {packages:[...]} list, or paste raw package.json / lockfile / CycloneDX JSON / SPDX JSON content via `content`. The tool normalizes npm dependencies first, then chunk-queries OSV behind the scenes so large SBOMs don't stop at the upstream 100-package batch limit. Each finding includes severity, a summary, CVE aliases, and the fixed version — not just a bare advisory ID — so a dependency audit answer doesn't need a follow-up call per flagged package. For an explicit `packages` list or raw `package.json` content — names that were never actually resolved against a registry, unlike a real lockfile/SBOM — package names are also cross-checked against the npm registry (capped at 200 unique names): a name that doesn't exist there would otherwise show a silent, indistinguishable `vulnerabilityCount: 0` — see `unresolvedPackages`/`existenceCheckNote` and do not read those entries as a clean bill of health.NPMScanNPMScanPluginnoneSecurity
- Check a dependency list against a license policycheck · Given a list of packages (name + optional exact version or semver range — e.g. straight from a package.json "dependencies" object) and an optional allow/deny license policy, resolves each package's declared SPDX license and reports a compliance verdict per package. Classifies every license into one of permissive/weak-copyleft/copyleft/network-copyleft/proprietary/public-domain/unknown, and understands simple SPDX expressions: "(MIT OR GPL-3.0)" is compliant if EITHER side is permitted (a consumer may legally pick the clean alternative), "MIT AND Apache-2.0" requires both sides to pass, and "X WITH exception" is judged on X. A mixed/nested expression like "(MIT OR ISC) AND Apache-2.0" is reported as needsReview rather than guessed at. `policy.deny` entries always win over `policy.allow` (so a name can appear in both without a silent contradiction); with `policy.allow` set, anything not matching it is a violation (unproven is treated as non-compliant); with neither given, the default policy flags only copyleft/network-copyleft/proprietary (e.g. GPL/AGPL/UNLICENSED) — weak-copyleft (LGPL/MPL/EPL) and unrecognized license strings are surfaced but not auto-flagged. Policy entries accept an exact SPDX id, a family prefix ("GPL" catches GPL-2.0/GPL-3.0-only/etc.), or a category name. This reads only the registry-declared `license` field — it does not fetch or parse LICENSE file contents from the source repository.NPMScanNPMScanPluginnoneSecurity
- Check an npm package for maintainer/ownership red flagscheck · Reconstructs a package's maintainer-change history straight from the npm packument — every published version carries the maintainers-list SNAPSHOT as it stood at that publish plus who actually ran `npm publish` (`_npmUser`), so diffing consecutive snapshots in publish-time order recovers exactly who was added or removed and when, with no extra API calls. Flags: (1) a maintainer added recently who then published a release shortly afterward on a package with real prior history — the account-takeover/hostile-handoff shape behind incidents like ua-parser-js, event-stream, and the 2025 chalk/debug ('qix') compromise; (2) a full, sudden replacement of the entire maintainer list; (3) a long-standing maintainer quietly dropped from the list; (4) a maintainer-list change that happened on npm's site AFTER the latest release — not yet tied to any published version, which is the more urgent case since it means access changed hands but nothing has shipped with it yet. Also cross-checks the declared GitHub repository: whether it still resolves to the same owner/name (a transfer/rename), whether it's reachable at all, and whether the latest npm release landed long after any real push activity there — repository.ownerLogin/ownerAvatarUrl name and show the CURRENT owning account (the new one after a transfer, not the one originally declared in package.json), with ownerAvatarUrl served from our own /api/github/avatar proxy rather than linking avatars.githubusercontent.com directly, both null whenever the repo check itself didn't reach GitHub. Use get_package/check_package_provenance first for the package's general health and publish-integrity signals; use this specifically for the 'who controls this package, and did that change recently' question. If this flags a newly added or fully turned-over maintainer, follow up with check_maintainer_blast_radius on that maintainer's username — it lists every other package the same account currently touches and flags a tight publish-time cluster across them, the 'did this compromise hit just one package or a dozen' question this tool can't answer on its own.NPMScanNPMScanPluginnoneSecurity
- Check an npm package version for publish-provenance red flagscheck · Checks whether a package version was published with npm's own Sigstore-backed publish provenance (`npm publish --provenance`), and cross-checks that provenance against reality rather than just reporting its presence. Three checks: (1) parses the SLSA build attestation (declared source repo, commit, builder identity, GitHub Actions run URL) and flags a builder that isn't GitHub-hosted, or an attested source repo that doesn't match package.json's own `repository` field; (2) when this version LACKS provenance, checks whether most peer packages (same npm scope, or same maintainer for an unscoped name) DO have it — a package that's the odd one out in an org that otherwise always publishes from CI is a real anomaly, not proof of malice; (3) fetches package.json from the source repository at the exact attested commit (or a best-effort matching git tag when no provenance/commit is available) and diffs its install-lifecycle scripts (preinstall/install/postinstall/prepare) and dependency names against what's actually in the published tarball — this is the single highest-signal check here, since a script or dependency that exists on npm but was never committed is exactly the pattern of a stolen-npm-token publish that bypasses CI (the event-stream/ua-parser-js incident shape). This is a heuristic, structural check: it does NOT cryptographically re-verify the Sigstore bundle (Fulcio cert chain, Rekor inclusion proof) — it trusts that npm's registry already refused to accept a publish that failed that verification, and checks the CONTENT of what the registry reports instead. Most packages don't use --provenance yet, so its bare absence is never scored on its own — only an org-norm anomaly or an actual source mismatch is. Use get_package/get_package_version first for basic package info; use this specifically to assess publish-integrity risk.NPMScanNPMScanPluginnoneSecurity
- Compare npm packages side-by-sidecompare · Given 2-5 candidate packages for the same job (e.g. "axios vs got vs node-fetch"), fetches the same registry/popularity/maintenance/vulnerability enrichment get_package computes for each one in parallel and returns a structured side-by-side plus a deterministic, reasoned pick. Each candidate gets downloads + trend, popularityTier/maintenanceTier, GitHub stars, TypeScript support, license, deprecated status, latest-version vulnerability status, a lightweight installScriptRisk signal (scans lifecycle script command strings for known red flags — does NOT fetch the tarball; call analyze_install_script on a specific candidate for that deeper scan), and installSize (the candidate's own dist.unpackedSize plus a transitive rollup — summed dist.unpackedSize across its resolved dependency tree, walked up to depth 2 / 60 nodes per candidate; `installSize.transitive.truncated`/`sizeUnknownCount` flag when that sum is partial rather than pretending it's exact — call analyze_transitive_dependencies on a specific candidate for the full graph). `differentiators` names which candidates stand out on each dimension (most downloads, only ones with TS types, which are deprecated/vulnerable/flagged as a typosquat/install-script risk, smallest/largest install size). `recommendation.pick` is chosen deterministically from a weighted score (popularity, maintenance, deprecation, vulnerabilities, typosquat flag, install-script risk, TS support, GitHub stars — install size is reported but not scored) — never a deprecated or typosquat-flagged candidate — with `rationale` explaining why and `confidence` reflecting how close the top two scored. A name that can't be resolved (typo, unpublished, malformed) still appears in `candidates` with `found:false` and `resolutionError` set rather than failing the whole call; duplicate names in the input are rejected.NPMScanNPMScanPluginnoneSecurity
- Diff two package.json/lockfile snapshotsdiff · Compares two raw snapshots of a package.json, package-lock.json (npm v1-v3), yarn.lock (classic v1 or Berry), or pnpm-lock.yaml — e.g. before/after a PR — and reports which packages were added, removed, or version-bumped. For every added or bumped package (up to 100 per call), also checks whether its resolved version carries a preinstall/install/postinstall/prepare lifecycle script that the before-version did NOT have (`installScriptIntroduced`, the highest-signal field here — a routine-looking patch bump quietly adding a postinstall is exactly the shape of a compromised-maintainer supply-chain attack) and batch-checks it against OSV.dev, reporting `vulnerabilityDelta` (introduced/fixed/still-vulnerable/still-clean) rather than just a bare isVulnerable flag. Scope notes: only direct dependencies are diffed for package.json/package-lock.json/pnpm-lock.yaml (their own formats distinguish direct from transitive); yarn.lock has no such distinction, so its side of the diff covers every resolved package in the file — expect a larger added/removed count when diffing a yarn.lock, and check `comparisonNote` when the two snapshots are different formats. The install-script check is presence-only (read from the registry packument or lockfile metadata, not a tarball content scan) — use analyze_install_script for a deep-dive on anything flagged here. Ideal for a CI gate reviewing a dependency-changing PR.NPMScanNPMScanPluginnoneSecurity
- Find every package an npm maintainer account touches, and flag a tight publish clustercheck · Given an npm username, finds every package npm's own maintainer:<username> search index currently returns for that account (registry.npmjs.org's /-/v1/search — the same reverse lookup npmjs.com's own site search uses; the public registry API has no dedicated 'list packages by maintainer' endpoint otherwise) and looks for a tight cluster of packages whose LATEST version was published within a short rolling window of each other. That's the shape of a compromised-account supply-chain attack: a stolen or phished credential doesn't get used on one package, it gets used on every package that account can publish to, usually within hours — the exact pattern behind the September 2025 chalk/debug ('qix') compromise, which hit roughly 18 packages within about 2 hours. A large total package count is NOT itself a red flag — many legitimate maintainers publish hundreds of packages over a career — only a tight publish-time cluster is scored, weighted up by how many packages it includes and by their combined weekly downloads/dependentsCount, since a burst touching a handful of near-zero-download packages is a very different event than one touching something with billions of weekly downloads. A cluster where most of the packages share one npm scope (e.g. @docusaurus/*) is dampened, since that's the shape of a project's own monorepo doing one coordinated release, not a compromised account spread across unrelated packages — this is why a large official org account (e.g. facebook/fb) publishing several of its own monorepos still lands well below what a plain sum of its cluster count would suggest. Multiple distinct clusters on one account combine with diminishing returns (the single worst cluster counts in full; each additional one contributes half the previous one's weight), not a plain sum — an account that does many independent, legitimate coordinated releases over its lifetime should not accumulate an unbounded score purely from being prolific. avatarUrl is the same Gravatar image npmjs.com's own profile page shows for this account, derived from the email already public in the registry's own maintainer records but served from our own /api/avatar/:hash proxy rather than linking gravatar.com directly (null only if no returned package still lists an email for this exact username). Each returned package's CURRENT maintainer list is cross-checked against the queried username (isCurrentMaintainer), since access is often already revoked by the time this runs. Natural follow-up to check_maintainer_changes: when that tool flags a newly added or fully turned-over maintainer on one package, call this with that maintainer's username to see whether the same account touched other packages around the same time. Known limitations: npm's search index is a text-relevance index, not a guaranteed-complete/real-time reverse index (results can lag or omit edge cases); results are capped at one page (up to 250 packages, ranked by npm's own relevance/popularity scoring, NOT by recency) so a very large footprint may be truncated (see resultsTruncated/totalPackagesFound) and a real cluster outside that page could be missed; and lastPublished reflects only each package's latest version, not its full history. npmscanUrl is this account's profile page on npmscan itself; npmProfileUrl is the account's actual page on npmjs.com, included for verification since that's the authoritative record of the account.NPMScanNPMScanPluginnoneSecurity
- Get a specific npm package versionget · Fetch registry metadata for one exact version of a package (dependencies, install scripts, tarball) AND check that exact version against OSV.dev for known vulnerabilities — isVulnerable/highestSeverity give a direct answer, and each finding includes severity, a summary, and the fixedVersion to upgrade to. Use this to check a version pinned in a lockfile rather than the latest release.NPMScanNPMScanPluginnoneSecurity
- Get basic profile info for an npm maintainerget · Given an npm username, returns every package npm's own maintainer:<username> search index currently returns for that account (registry.npmjs.org's /-/v1/search — the public registry API has no dedicated 'list packages by maintainer' endpoint otherwise), plus precomputed aggregates: currentlyMaintainsCount (still listed as maintainer right now vs. already-revoked), totalWeeklyDownloads and totalDependents summed across every returned package, and avatarUrl — the same Gravatar image npmjs.com's own profile page shows for this account, derived from the email already public in the registry's own maintainer records but served from our own /api/avatar/:hash proxy rather than linking gravatar.com directly (null only if no returned package still lists an email for this exact username). This is a plain info lookup — it does NOT run the publish-cluster / compromised-account detection that check_maintainer_blast_radius does; use that tool instead when the goal is a security read on whether this account's recent activity looks like a takeover, not just a profile summary. Natural pairing with check_maintainer_changes: once that tool names a maintainer on a package, call this with that maintainer's username to see the rest of what they touch. npmscanUrl is this account's profile page on npmscan itself; npmProfileUrl is the account's actual page on npmjs.com, included for verification since that's the authoritative record of the account.NPMScanNPMScanPluginnoneSecurity
- Get latest npm security advisoriesget · Browse recently published npm security advisories and known-malicious-package findings. Three disjoint sources, selected via type: "reviewed" (default) is GitHub's curated, mostly CVE-backed advisories; "malware" is GitHub's own known-malicious-package advisories; "osv" is OSV.dev's OpenSSF malicious-packages feed, which covers far more malicious npm packages than GitHub ever republishes under a GHSA id. None of "malware"/"osv" carry a CVE or meaningful CWE beyond "embedded malicious code". Filter by severity, vulnerability category (XSS, SQL/NoSQL Injection, SSRF, Access Control, Code Injection, etc. — reviewed only), an affected package name, or (reviewed/malware only) look up one exact advisory by GHSA or CVE ID. Paginated with an opaque cursor: pass a previous response's nextCursor back in as cursor to fetch the next page.NPMScanNPMScanPluginnoneSecurity
- Get npm package detailsget · Fetch npm registry metadata for a package: latest version, install scripts (preinstall/postinstall are a key risk signal), maintainers, license, recent version history, weekly downloads, GitHub stars, TypeScript support, days since last publish, a topPackagesRank (position among npm's ~100k most-downloaded packages, from npmscan's own periodically-refreshed snapshot — not live), and a downloadTrend (growing/stable/declining vs. ~3 months ago). Also checks the LATEST version against OSV.dev for known vulnerabilities — isLatestVersionVulnerable/highestSeverity give a direct safe/not-safe answer, and each finding includes severity, a summary, and the fixedVersion to upgrade to (use get_package_version or query_vulnerabilities to check a specific older version instead). Also returns popularityTier/maintenanceTier (deterministic rule-based labels, not model-generated) and a plain-language maintenanceSummary, plus a possibleTyposquatOf flag if the name is one typo away from a top-5,000 package while itself being obscure — read `deprecated` and maintenanceSummary before recommending a package, since a long gap since the last release can mean either a stable/finished package or a slowing one. Includes a link to the full npmscan.com analysis page.NPMScanNPMScanPluginnoneSecurity
- Get the concrete remediation playbook for a flagged findingget · Maps a finding's `rule` value from analyze_install_script, check_maintainer_changes, or check_package_provenance to the matching human-authored incident-response playbook (the same content published at /docs/playbooks) and returns its concrete, ordered steps, severity tier, real-incident references, and prevention tips — not just a link. Pass the exact `rule` string(s) a prior finding already returned (batch up to 10 in one call to cover a whole findings array; duplicates resolving to the same playbook are deduplicated) or an `id` to look up a specific playbook by slug directly. Each matched rule also gets its own short situationNote explaining specifically what that rule caught — so a batch of several different rules landing on the same playbook does not read as identical, repeated boilerplate. An unrecognized rule or id is not an error — it comes back with matched:false and a note, since a low-severity or baseline-only finding (e.g. analyze_install_script's lifecycle-present) legitimately has no dedicated playbook.NPMScanNPMScanPluginnoneSecurity
- Look up a CVE in the NIST NVDget · Look up authoritative NIST NVD data for one exact CVE ID (e.g. "CVE-2026-2950"), or browse/search NVD by keyword, CVSS severity, CWE, or a publication-date range. Every result is enriched with CISA KEV status (`kev`, non-null only if this CVE is a confirmed, actively-exploited-in-the-wild vulnerability — treat that as an urgent-patch signal regardless of CVSS score) and FIRST.org EPSS (`epss`, the probability of exploitation in the next 30 days — a better prioritization signal than CVSS severity alone, which measures impact, not likelihood). For a single cveId lookup, if NVD has no record yet or hasn't scored it, this falls back to the raw MITRE CVE record automatically (`source: "mitre"` on the result) rather than returning nothing. NVD is NOT npm-scoped — unlike query_vulnerabilities/get_latest_advisories, search results can include CVEs for any ecosystem, so pass keywordSearch (e.g. the package name) to narrow it. Prefer this for the authoritative CVSS score/vector/KEV/EPSS data on a CVE already found via another tool, or when a user pastes a CVE ID/link directly; prefer get_latest_advisories for npm-specific browsing. NVD enforces a strict shared rate limit, so this tool may occasionally ask you to retry in a few seconds — do so rather than assuming failure.NPMScanNPMScanPluginnoneSecurity
- Query known vulnerabilities for a packagequery · Query OSV.dev for known vulnerabilities affecting an npm package, optionally scoped to one exact version (e.g. to check whether a version pinned in a lockfile is safe). Returns isVulnerable and highestSeverity as a direct answer, plus each finding's severity, a plain-language summary, CVE aliases, and the fixedVersion to upgrade to — not a raw advisory dump. Also cross-checks the name against the npm registry: isVulnerable:false on a package that does not actually exist there (typo, unpublished, wrong ecosystem) would otherwise look identical to a genuinely clean result — a nonexistent package returns an error instead, and existenceCheckNote explains it if the registry check itself could not be completed. Use before recommending, installing, or upgrading a package.NPMScanNPMScanPluginnoneSecurity
- Rank a batch of flagged vulnerabilities by what to fix firstprioritize · Given a batch of vulnerability findings already flagged elsewhere (e.g. from batch_query_vulnerabilities, analyze_transitive_dependencies, or query_vulnerabilities across a whole package.json/lockfile audit), ranks them by what to actually fix first. Combines CISA KEV status (confirmed active exploitation in the wild — an automatic top-priority override), FIRST.org EPSS (probability of exploitation in the next 30 days — the primary ranking signal, since it measures likelihood rather than just impact), and severity (a secondary/fallback signal, most useful for a GHSA finding with no CVE alias) into one composite score and a patch-now/patch-soon/scheduled/monitor tier per finding. This does NOT re-query OSV/NVD itself — pass in the severity/CVE id findings other tools already returned; it only adds KEV/EPSS enrichment (the same data get_cve returns per-CVE) and ranks the batch. A CVE id shared by multiple findings in the same call is only looked up once.NPMScanNPMScanPluginnoneSecurity
- Rank raw `npm audit --json` output by what to fix firstenrich · Given the raw output of `npm audit --json` (npm 7+'s `{vulnerabilities: {...}}` format, or legacy npm 6's `{advisories: {...}}`), parses it directly — no need to re-paste package.json/lockfile content — and runs it through the same patch-now/patch-soon/scheduled/monitor ranking prioritize_remediation exposes for hand-built finding lists. npm audit's JSON almost never includes a CVE id (only a GHSA advisory URL), so this resolves each GHSA to its CVE alias via OSV.dev when one exists (ghsaResolvedToCveCount reports how many) before doing the same CISA KEV + FIRST.org EPSS + severity scoring — skipping this step would silently degrade most findings to severity-only ranking despite prioritize_remediation being built around CVE-keyed KEV/EPSS data. Also carries through npm-audit-specific context prioritize_remediation itself has no field for: isDirect (direct vs. transitive dependency) and fixAvailable/fixTarget (npm's own computed fix — note fixTarget can name a different package than the vulnerable one, e.g. bumping a parent to pull in a patched transitive dependency). A package with more than one distinct advisory in the source report only has its first advisory used for ranking; a warning names the package so query_vulnerabilities can be called on it directly for the rest. `yarn audit --json` and `pnpm audit --json` use different report shapes and are not supported — use batch_query_vulnerabilities with the project's manifest/lockfile for those instead.NPMScanNPMScanPluginnoneSecurity
- Search npm packagessearch · Search the npm registry by name or keywords. Each result includes its current weekly/monthly download counts, dependentsCount (how many other npm packages depend on it), topPackagesRank (position among npmscan's own top-100k-by-downloads snapshot — not live, but a second independent popularity signal), and deterministic (not model-generated) popularityTier/maintenanceTier labels — a package matching the query with a 'very-low' popularityTier, zero dependents, or a 'stale' maintenanceTier is very likely an abandoned, copy-paste, or squatted package, not a real contender, regardless of how relevant its name/description look. A result may also carry possibleTyposquatOf — set when its name is one typo away (e.g. 'raect' vs 'react') from a top-5,000 package while itself having very low popularity; treat that as a red flag to call out explicitly, not silently filter. Use these (not name recognition or the package's own README) to judge which candidates are actually established, and call get_package on your shortlist for install-script risk, TypeScript support, and GitHub stars before recommending one. Includes a link to each package's full npmscan.com risk/analysis page.NPMScanNPMScanPluginnoneSecurity
- Simulate upgrading one package from one version to another, or a whole batch at oncesimulate · Given a package and a current/target version, tells you whether that specific upgrade is a safe patch/minor bump or a likely-breaking major bump, before you actually run npm install. Natural follow-up to prioritize_remediation: pass its `packageName` + `currentVersion` + `fixedVersion` straight in to check whether the suggested fix is a drop-in patch or something that needs a review pass. Classifies the jump by semver (major/minor/patch/prerelease), treats a minor bump between two pre-1.0 (0.x) versions as breaking-risk per semver's own "the API isn't stable yet" convention, and flags skipping over multiple major versions in one jump (e.g. 2.x -> 5.x) as needing a per-major changelog review rather than just a diff against the final target. Beyond semver, it also checks the registry for real signals the version number alone won't tell you: whether the target version is marked deprecated, whether it introduces a preinstall/install/postinstall/prepare lifecycle script the current version didn't have, whether it tightens its engines.node requirement, and whether it is itself a prerelease. Finally it batch-checks both versions against OSV.dev and reports vulnerabilityDelta (introduced/fixed/still-vulnerable/still-clean) — catching the case where a suggested "fix" version doesn't actually clear every open CVE. Combines all of this into one riskTier (safe/low-risk/review-recommended/breaking-change-likely/unknown) with a reasons list explaining exactly which signals drove it. This does NOT read the package's changelog/release notes or scan the target tarball's source diff for actual breaking API usage — it's a fast, deterministic pre-check, not a substitute for reading the release notes on a flagged major bump. For simulating more than one upgrade at once — e.g. every "patch-now" finding prioritize_remediation just ranked — pass `packages: [{packageName, currentVersion, targetVersion?}, ...]` (1-100 items) instead of `packageName`/`currentVersion`/`targetVersion`, not both. Registry fetches are deduped/parallelized and all OSV checks for the whole batch run as one call, so this is not the same cost as N single-item calls. A package that can't be resolved at all (typo, unpublished, registry error) shows up as its own `results` entry with `fetchError` set instead of failing the whole batch.NPMScanNPMScanPluginnoneSecurity
What is Tool Explorer?
Tool Explorer indexes the callable tool names and descriptions attached to public registry profiles. It is useful for seeing what agents can actually invoke, not just which profile exists.
How do category and verb filters work?
Category filters use the live registry category rollup. Verb filters use the public tool insights rollup, so the page stays backed by the same read models as the tracker charts.
Why do auth requirements matter?
Auth requirements show whether a tool is likely usable without account connection, requires authentication, is private, or is unknown in the current snapshot.