# lurq (remote · api.lurq.run)

Verify npm packages before your AI agent installs them: hallucinations, advisories, API drift.

- Trust score: 80/100 (high trust)
- Change this week: +3
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-09-20

## Components

- remote · `api.lurq.run`: 80/100 (this document), [markdown](https://verifymcp.io/servers/jadenryu-lurq/api.md), [page](https://verifymcp.io/servers/jadenryu-lurq/api)

## Channel facts

- Endpoint: `https://api.lurq.run/mcp`
- Transports: `streamable-http`
- Auth: `required`
- Version: `0.1.7`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-09-20.

- **Endpoint Security**: 89/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation is enforced on tool calls, but the challenge carries no valid RFC 9728 metadata, so a client cannot discover where to get a token.
  - HTTPS is enforced; there's no plaintext access path.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 74/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 2552 tokens (~159/item across 16 items; 16 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 23/100
  - Stability observed for 7 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - We read all 16 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 17 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### How do I install the lurq MCP server?

lurq is a hosted endpoint at https://api.lurq.run/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add --transport http jadenryu-lurq 'https://api.lurq.run/mcp'
```

### Cursor

```json
{
  "mcpServers": {
    "jadenryu-lurq": {
      "url": "https://api.lurq.run/mcp"
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "jadenryu-lurq": {
      "type": "http",
      "url": "https://api.lurq.run/mcp"
    }
  }
}
```

### Codex

```toml
[mcp_servers.jadenryu-lurq]
url = "https://api.lurq.run/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "jadenryu-lurq": {
      "type": "remote",
      "url": "https://api.lurq.run/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add jadenryu-lurq --url 'https://api.lurq.run/mcp' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  jadenryu-lurq:
    url: "https://api.lurq.run/mcp"
```

### Netclaw

```json
{
  "McpServers": {
    "jadenryu-lurq": {
      "Transport": "http",
      "Url": "https://api.lurq.run/mcp"
    }
  }
}
```

### Vellum

```bash
assistant mcp add jadenryu-lurq -t streamable-http -u 'https://api.lurq.run/mcp'
```

### Other

```json
{
  "mcpServers": {
    "jadenryu-lurq": {
      "type": "http",
      "url": "https://api.lurq.run/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-09-19 (score 80, +1)

No change was recorded against any check on this day. Stability & Change Management went from 17 to 20. That category is still filling its 30-day observation window: 5 days of observed history at the previous scan, 6 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-17 (score 79, 0)

- [functional regression] Schema quality: 2278 → 2552
- [functional] New tool “connect_check”

### 2026-09-16 (score 79, +1)

No change was recorded against any check on this day. Stability & Change Management went from 7 to 10. That category is still filling its 30-day observation window: 2 days of observed history at the previous scan, 3 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-14 (score 78, +1)

- [functional improvement] Stability: unverified → 0.03

### 2026-09-13 (score 77)

First indexed and scored.

## MCP tools (16)

### `evaluate` (~123 tokens)

Evaluate a package

Full evidence read for one npm package: health and quality scores and the signals behind them, advisories, the shared safety verdict, a summary and a usage guide. Use it when a choice needs more than verify's install gate. Enforces the account's dependency policy. A package lurq has never tracked is fetched and scored on demand, waiting up to ~4 seconds; if scoring takes longer the result is `tracked: false` with a note to retry in a few seconds, which is not an answer about the package.

Input parameters:

- `package` (string, required): npm package name

### `policy` (~71 tokens)

Read the dependency policy

The rules this account's selection policy enforces on which packages you may add: denied packages (with the reason), license allowlist, confidence, advisory, adoption, staleness and bundle-size floors. Read it once before choosing dependencies so you pick an allowed package first; evaluate already enforces it. Read-only.

### `compare` (~75 tokens)

Compare packages

Side-by-side comparison of 2–5 npm packages you are choosing between, ranked by health score. Untracked names are fetched on demand; one still being scored comes back under `pending` (retry shortly), and a name not on npm under `notFound`.

Input parameters:

- `packages` (array, required): 2–5 npm package names

### `compat` (~258 tokens)

Check package compatibility

Check whether a set of packages forms a coherent stack. Resolves the whole set the way npm would and returns a definitive verdict: compatible, conflict (with the exact clashing constraints), or unknown. Checks peer-dependency and engine ranges from declared metadata, plus any recorded sandbox conflicts. Read-only: never installs or executes package code. Not always instant: a set checked before answers immediately, but a new set is resolved live from registry metadata, which can take up to ~25 seconds. Call once with the whole stack before committing to it.

Input parameters:

- `node` (string): Optional target Node runtime (e.g. "20" or "20.20.2") for engines.node checks
- `packages` (array, required): The full candidate stack to check together, 2–30 npm package names — a whole package.json dependency list is the intended input. Pass every package in one call: conflicts routinely appear only across…
- `versions` (object): Optional exact versions keyed by package name, e.g. {"react":"19.0.0"} (use when not checking latest). Must be exact semver versions, not ranges.

### `verify` (~90 tokens)

Verify a package

Confirm an npm package is real, healthy, and not risky before installing: guards against hallucinated or typosquatted names, deprecations and known advisories, and returns a safety verdict with its reasons and what was not checked. Checks the live registry. The cheap gate to call before every install; use evaluate when you need the full scores.

Input parameters:

- `package` (string, required): npm package name to verify

### `usage` (~300 tokens)

Version-exact API surface + drift

A package version's TYPED API: exported symbols and their signatures from its shipped .d.ts (or DefinitelyTyped), exact to the version, none of it in the model's training data. Use before writing code against a package whose API may have moved. For whether a name exists at RUNTIME (what decides if an import throws) use resolve_surface; for is-it-safe-to-install use verify. Pass knownVersion (e.g. the version you were trained on) to get the precise delta: added, removed, renamed, changed. Also returns the version's declared engines (Node/runtime floor). Large surfaces are paged, 80 symbols per call: `totalSymbols` is the size, `query` filters by name, `offset` pages. `shallow: true` means the API lives on an interface's members that are not listed, and the note says where to read them. For framework file/convention changes (not exported symbols), consult the official migration guide / Context7 instead.

Input parameters:

- `knownVersion` (string): A version you already know; returns the API delta from it to the target
- `offset` (integer): Index of the first symbol to return, to page past the first 80
- `package` (string, required): npm package name
- `query` (string): Part of a symbol name (case-insensitive); returns only matching symbols
- `version` (string): Target version (defaults to latest)

### `diagram` (~66 tokens)

Reference architecture diagram

Emit a reference-architecture Mermaid diagram for a stack you have already chosen (package names). A labeled starting point keyed by layer, not a validated architecture, and not an architecture designer.

Input parameters:

- `stack` (array): Package names that make up the stack; omit or empty to get usage guidance

### `resolve_surface` (~128 tokens)

Version-exact runtime surface

What a package version ACTUALLY exports at runtime, extracted from its shipped JavaScript rather than from documentation or the model's memory: names and arity, not type signatures (use usage for those). Call before writing code against a package whose API may have moved. Runtime existence is what decides whether an import throws; a removed type breaks tsc, a removed runtime symbol breaks the program. A miss returns UNKNOWN and queues extraction, UNKNOWN never means the symbol is absent.

Input parameters:

- `package` (string, required): npm package name
- `version` (string): Exact version; omit for the latest extracted

### `diff_surface` (~142 tokens)

Surface diff between two versions

What changed in a package's runtime surface between two versions: symbols removed, added, and arity changes, plus renames the package itself proves (a removed name that shared one declaration with a name the new version still exports). Removals break `node`; type-only removals are returned separately because they break `tsc` instead. Answers "when did this stop working" from static comparison, with no install required. Use before an upgrade, and to explain a break after one.

Input parameters:

- `fromVersion` (string, required): Version you are on
- `package` (string, required): npm package name
- `toVersion` (string, required): Version you are moving to

### `mcp_stack` (~178 tokens)

Do these MCP servers coexist?

Check whether a set of MCP servers can be wired into one agent together. The npm question does not apply — servers are separate processes with nothing to resolve between them. They clash in the single flat TOOL NAMESPACE the agent assembles from all of them: two servers exposing the same tool name leave the agent unable to express which it means, and nothing errors, one simply shadows the other. Also reports the standing context cost, since every tool's schema rides in every request. Pass `tools` for a server when you already hold its tool list (any server: remote, PyPI, Docker, private) and it is analysed as-is; otherwise the npm server's probed surface is used, and one that has not been probed makes the answer UNKNOWN, never clean.

Input parameters:

- `servers` (array, required): The servers configured into one agent

### `mcp_surface` (~180 tokens)

An MCP server's tool contract

What an MCP server ACTUALLY exposes: every tool, its required and optional parameters, and its behaviour annotations, read from a live `tools/list` handshake in a sandbox rather than from a README or the model's memory. Call before wiring an agent to a server, or when a tool call is failing for reasons the error does not explain. Also returns `requires` — the API keys and settings the server declares it needs — and `configRequest`, a ready-made line to put in front of your user when something is missing, so 'it needs a token' never presents as 'it is broken'. A miss returns UNKNOWN and queues a probe; UNKNOWN never means the server has no tools.

Input parameters:

- `server` (string, required): npm package name of the MCP server
- `version` (string): Exact version; omit for the latest probed

### `mcp_drift` (~157 tokens)

MCP tool-contract drift between two versions

What moved in an MCP server's tool contract between two versions: tools removed, parameters that became required, types narrowed, and annotation flips. Two findings here have no npm equivalent and are why this exists. SILENT DRIFT is a schema that changed while its description stayed byte-identical, invisible to anyone reading a changelog. PRIVILEGE WIDENING is a tool that stopped being read-only or started being destructive, which does not break anything and is worse than a break. Use before upgrading a server an agent depends on.

Input parameters:

- `fromVersion` (string, required): Version you are on
- `server` (string, required): npm package name of the MCP server
- `toVersion` (string, required): Version you are moving to

### `connect_check` (~274 tokens)

Will this MCP server work in my client?

Before wiring an MCP server into a client, find out whether it will work there and exactly what it takes. Accepts an endpoint URL, an official-registry server name, or an npm package name. Answers per client (Claude Code, Claude.ai, ChatGPT, Cursor, VS Code, Codex, Gemini CLI and more): WORKS; NEEDS_SETUP with the steps (a key to send as a header, an OAuth client to pre-register and the redirect URIs to allow, a URL placeholder to fill); BLOCKED with the reason and which side causes it; or UNKNOWN when a decisive fact is not established. Built from a credential-free probe of the endpoint (whether it answers, how it authenticates, which OAuth registration methods it offers, spec deviations strict clients refuse, tool names and schemas) and from primary-sourced client constraints. Returns ready-to-paste config in each client's own format, with placeholder values. Tell the user what it found, including which client it was checked for. UNKNOWN never means it will not work.

Input parameters:

- `client` (string): One client to check, e.g. claude-code, cursor, chatgpt; omit for every client
- `server` (string, required): Endpoint URL (https://…), official registry name (io.github.acme/weather), or npm package name

### `audit` (~156 tokens)

Audit a whole project

Assess an entire project's dependencies in ONE call: which packages are outdated, deprecated or carry advisories for the exact installed version, and which configured MCP servers have drifted, need credentials, or cannot be observed at all. Send the inventory you read locally (names and versions only — never source). Returns a per-item verdict plus an explicit coverage count: how many were answered, how many are queued because the index has not seen them, and how many were skipped and why. An item lurq could not assess is reported as unassessed, never as clean.

Input parameters:

- `mcpServers` (array): MCP servers read from .mcp.json / agent configs
- `packages` (array): npm dependencies read from package.json + lockfile

### `capabilities` (~92 tokens)

What lurq can do

Look up which lurq tool answers a situation, and what to run next. Call when you're unsure whether lurq covers something (an upgrade, a licence rule, a version's exact exports, publishing a package) instead of guessing or skipping it. Returns matching capabilities with the tool or command to use.

Input parameters:

- `query` (string): What you are trying to do, in plain words. Omit for the full menu.

### `report_outcome` (~132 tokens)

Report how a package worked out

Opt-in feedback after you act on lurq's evidence about a package (verify, evaluate, compare, compat): whether you went with it and whether it built. No source code, only the coarse decision + a build signal. Helps lurq learn which packages agents actually succeed with; safe to skip.

Input parameters:

- `accepted` (boolean, required): Did you go with this package?
- `buildSignal` (string): Coarse post-install result, if known
- `need` (string): What you needed the package for, in plain words (no source code)
- `package` (string, required): The package you decided on

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/jadenryu-lurq/api#diagnostics

## Score history

- 2026-09-20: 80
- 2026-09-19: 80
- 2026-09-18: 79
- 2026-09-17: 79
- 2026-09-16: 79
- 2026-09-15: 78
- 2026-09-14: 78
- 2026-09-13: 77

## Common questions

### What is the lurq MCP server?

lurq is an MCP server listed in the public MCP registry as io.github.jadenryu/lurq. Verify npm packages before your AI agent installs them: hallucinations, advisories, API drift. This page covers its hosted endpoint (https://api.lurq.run/mcp).

### Is the lurq MCP server safe to use?

lurq scores 80 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the lurq MCP server expose?

lurq exposes 16 tools: evaluate, policy, compare, compat, verify, and 11 more. Their descriptions and schemas cost roughly 2,422 tokens of context every time the server is loaded.

### Does the lurq MCP server require authentication?

Yes. lurq asked us for credentials when we connected, so you will need to authorise it in your MCP client before it can do anything.

### Is the lurq MCP server still maintained?

lurq is still listed as active in the MCP registry. We last reached this channel on 20 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

## Links

- Remote endpoint: https://api.lurq.run/mcp
- Authorisation metadata: https://api.lurq.run/.well-known/oauth-protected-resource/mcp
- Repository: https://github.com/jadenryu/lurq
- Website: https://www.lurq.run/
- Changelog RSS feed: https://verifymcp.io/servers/jadenryu-lurq/api.xml
- Changelog JSON feed: https://verifymcp.io/servers/jadenryu-lurq/api.json
- HTML version of this page: https://verifymcp.io/servers/jadenryu-lurq/api