npm · brilliant-directories-mcp6.45.18

Evidence

#!/usr/bin/env node

/**

 * Brilliant Directories MCP Server (npm package — stdio transport)

RemediationAI

The problem is that the MCP server reads BD_API_KEY and BD_SITE_URL at startup and uses them for all tool calls, without checking the identity or authorization context of each request. Fix this by implementing a per-request authorization middleware that validates the caller's identity (via MCP request metadata or a custom auth header) and maps it to a specific BD API key and site URL before executing any tool. This ensures each caller only accesses BD resources they are authorized for, preventing privilege escalation. Verify the fix by adding a test that attempts to call a tool with a different caller identity and confirms the request is rejected or uses the correct scoped credentials.

LLM consensus

Evidence

res.on("end", () => {

        if (config.debug) {

          console.error(`[debug] <- ${res.statusCode} ${method} ${fullUrl.href}`);

          console.error(`[debug]   body: ${data.length > 500 ? data.slice(0, 500) + "...[truncated]" : data}`);

        }

        const retryAfter = res.headers && res.headers["retry-after"];

        try {

RemediationAI

The problem is that `fullUrl.href`, `method`, and `data` are user-controlled values printed directly to stderr without ANSI escape sanitization, allowing an attacker to inject cursor-control sequences that rewrite terminal output or hide commands. Replace the console.error calls with a sanitization function such as `stripAnsi()` from the `strip-ansi` npm package, or manually remove ANSI escape sequences using a regex like `/\x1b\[[0-9;]*m/g`. This prevents terminal injection attacks. Verify by passing a URL with embedded ANSI codes (e.g., `\x1b[2J` to clear screen) and confirming the debug output shows the literal escape sequence, not the control effect.

LLM consensus

Evidence

if (typeof v === "string" && v.includes("?")) {

      const cleaned = sanitizeSingleImageUrl(v);

      if (cleaned !== v) {

        console.error(`[sanitize] ${toolName}: stripped query-string from ${field}`);

        args[field] = cleaned;

      }

    }

RemediationAI

The problem is that `toolName` and `field` are user-controlled values printed to stderr without ANSI escape sanitization. Replace the console.error call with `console.error(`[sanitize] ${stripAnsi(toolName)}: stripped query-string from ${stripAnsi(field)}`)` using the `strip-ansi` package or a custom sanitization function. This prevents ANSI injection attacks that could manipulate terminal display. Verify by injecting ANSI codes into toolName or field and confirming they appear as literal text in the output.

LLM consensus

Evidence

if (result.status >= 200 && result.status < 300 && result.body?.status === "success") {

      console.log(`OK - credentials verified against ${config.apiUrl}`);

      if (result.body.data) {

        console.log(JSON.stringify(result.body.data, null, 2));

      }

      process.exit(0);

    } else {

RemediationAI

The problem is that `result.body.data` is user-controlled API response data printed directly via `JSON.stringify()` without ANSI escape sanitization. Replace `console.log(JSON.stringify(result.body.data, null, 2))` with `console.log(stripAnsi(JSON.stringify(result.body.data, null, 2)))` using the `strip-ansi` package. This prevents malicious API responses from injecting terminal control sequences. Verify by mocking the API to return a response containing ANSI escape codes and confirming they are displayed as literal text.

LLM consensus

Evidence

shuttingDown = true;

    const inflight = IN_FLIGHT_REQUESTS.size;

    if (inflight > 0) {

      console.error(`[${signal}] Draining ${inflight} in-flight request(s)...`);

      // 5000ms drain window on SIGTERM/SIGINT. Enough for most BD calls to

      // complete cleanly (BD median response is <500ms). Hard abort after

      // 5s so the user's MCP client doesn't hang waiting for us to exit.

RemediationAI

The problem is that `signal` and `inflight` (a number) are printed to stderr without sanitizing `signal`, which could be user-influenced in some contexts. Replace `console.error(`[${signal}] Draining ${inflight} in-flight request(s)...`)` with `console.error(`[${stripAnsi(String(signal))}] Draining ${inflight} in-flight request(s)...`)` using the `strip-ansi` package. This prevents ANSI injection if signal is ever attacker-controlled. Verify by confirming the output displays the signal name as plain text.

LLM consensus

Evidence

process.exit(0);

    } else {

      console.error(`FAIL - HTTP ${result.status}`);

      console.error(typeof result.body === "string" ? result.body : JSON.stringify(result.body, null, 2));

      process.exit(2);

    }

  } catch (err) {

RemediationAI

The problem is that `result.body` (a user-controlled API response) is printed directly via `JSON.stringify()` without ANSI escape sanitization. Replace `console.error(typeof result.body === "string" ? result.body : JSON.stringify(result.body, null, 2))` with `console.error(stripAnsi(typeof result.body === "string" ? result.body : JSON.stringify(result.body, null, 2)))` using the `strip-ansi` package. This prevents malicious API responses from injecting terminal control sequences. Verify by mocking an error response with embedded ANSI codes and confirming they appear as literal text.

LLM consensus

Evidence

const orig = args.post_image;

    const cleaned = orig.split(",").map(sanitizeSingleImageUrl).filter(Boolean).join(",");

    if (cleaned !== orig) {

      console.error(`[sanitize] ${toolName}: stripped query-string or whitespace from post_image CSV`);

      args.post_image = cleaned;

    }

    return;

RemediationAI

The problem is that `toolName` is printed to stderr without ANSI escape sanitization. Replace `console.error(`[sanitize] ${toolName}: stripped query-string or whitespace from post_image CSV`)` with `console.error(`[sanitize] ${stripAnsi(toolName)}: stripped query-string or whitespace from post_image CSV`)` using the `strip-ansi` package. This prevents ANSI injection attacks. Verify by passing a toolName with embedded ANSI codes and confirming they appear as literal text in the output.

LLM consensus

Evidence

console.log("OK");

    } else {

      console.log("FAILED");

      console.log(`  HTTP ${result.status}: ${JSON.stringify(result.body)}`);

      console.log("");

      console.log("Setup will still write the config, but your AI agent won't be able to call the API until this is fixed.");

      if (autoYes || nonInteractive) {

RemediationAI

The problem is that `result.body` (user-controlled API response) is printed directly via `JSON.stringify()` without ANSI escape sanitization. Replace `console.log(` HTTP ${result.status}: ${JSON.stringify(result.body)}`)` with `console.log(` HTTP ${result.status}: ${stripAnsi(JSON.stringify(result.body))}`)` using the `strip-ansi` package. This prevents malicious API responses from injecting terminal control sequences. Verify by mocking an error response with embedded ANSI codes and confirming they appear as literal text.

LLM consensus

Evidence

: "";

      console.error(`[debug] -> ${method} ${fullUrl.href}`);

      console.error(`[debug]   headers: ${JSON.stringify(safeHeaders)}`);

      if (safeBody) console.error(`[debug]   body: ${safeBody}`);

    }

    const req = transport.request(options, (res) => {

RemediationAI

The problem is that `fullUrl.href` and `safeBody` are printed to stderr without ANSI escape sanitization. Replace the console.error calls with `console.error(`[debug] -> ${stripAnsi(method)} ${stripAnsi(fullUrl.href)}`)` and `if (safeBody) console.error(`[debug] body: ${stripAnsi(safeBody)}`)` using the `strip-ansi` package. This prevents ANSI injection attacks. Verify by passing a URL with embedded ANSI codes and confirming they appear as literal text in the debug output.

LLM consensus

Evidence

if (cached && (Date.now() - cached.fetchedAt) < POST_TYPES_TTL_MS) return cached.website_id;

  try {

    const url = new URL(`/api/v2/site_info/get`, `https://${domain}`);

    const resp = await fetch(url.toString(), { method: "GET", headers: { "X-Api-Key": apiKey, Accept: "application/json" } });

    if (!resp.ok) return null;

    const body = await resp.json().catch(() => null);

    const msg = body && body.message;

RemediationAI

The problem is that the fetch call to `/api/v2/site_info/get` has no timeout, allowing a hung upstream server to block indefinitely. Add a `signal` parameter using `AbortController` with a timeout: `const controller = new AbortController(); const timeout = setTimeout(() => controller.abort(), 5000); const resp = await fetch(url.toString(), { method: "GET", headers: {...}, signal: controller.signal }); clearTimeout(timeout);`. This ensures the request fails fast if the upstream server is unresponsive. Verify by mocking a slow server and confirming the request aborts after 5 seconds.

LLM consensus

Evidence

url.searchParams.append("property_operator[]", "=");

    url.searchParams.append("property_operator[]", "=");

    url.searchParams.set("limit", "100");

    const resp = await fetch(url.toString(), { method: "GET", headers: { "X-Api-Key": apiKey, Accept: "application/json" } });

    if (!resp.ok) return {};

    const body = await resp.json().catch(() => null);

    const rows = (body && Array.isArray(body.message)) ? body.message : [];

RemediationAI

The problem is that the fetch call to query properties has no timeout, allowing a hung upstream server to block indefinitely. Add a `signal` parameter using `AbortController` with a timeout: `const controller = new AbortController(); const timeout = setTimeout(() => controller.abort(), 5000); const resp = await fetch(url.toString(), { method: "GET", headers: {...}, signal: controller.signal }); clearTimeout(timeout);`. This ensures the request fails fast if the upstream server is unresponsive. Verify by mocking a slow server and confirming the request aborts after 5 seconds.

LLM consensus

Evidence

url.searchParams.append("property_operator[]", "=");

    url.searchParams.append("property_operator[]", "=");

    url.searchParams.set("limit", "100");

    const resp = await fetch(url.toString(), { method: "GET", headers: { "X-Api-Key": apiKey, Accept: "application/json" } });

    let body = null;

    try { body = await resp.json(); } catch {}

    if (!body) return { probed_ok: false, deleted, reason: `probe returned non-JSON (HTTP ${resp.status})` };

RemediationAI

The problem is that the fetch call to query properties has no timeout, allowing a hung upstream server to block indefinitely. Add a `signal` parameter using `AbortController` with a timeout: `const controller = new AbortController(); const timeout = setTimeout(() => controller.abort(), 5000); const resp = await fetch(url.toString(), { method: "GET", headers: {...}, signal: controller.signal }); clearTimeout(timeout);`. This ensures the request fails fast if the upstream server is unresponsive. Verify by mocking a slow server and confirming the request aborts after 5 seconds.

LLM consensus

Evidence

const form = new URLSearchParams();

    form.set("redirect_id", redirectId);

    form.set("new_filename", newFilename);

    const resp = await fetch(url.toString(), {

      method: "PUT",

      headers: { "X-Api-Key": apiKey, Accept: "application/json", "Content-Type": "application/x-www-form-urlencoded" },

      body: form.toString(),

RemediationAI

The problem is that the fetch call to PUT a redirect has no timeout, allowing a hung upstream server to block indefinitely. Add a `signal` parameter using `AbortController` with a timeout: `const controller = new AbortController(); const timeout = setTimeout(() => controller.abort(), 5000); const resp = await fetch(url.toString(), { method: "PUT", headers: {...}, body: form, signal: controller.signal }); clearTimeout(timeout);`. This ensures the request fails fast if the upstream server is unresponsive. Verify by mocking a slow server and confirming the request aborts after 5 seconds.

LLM consensus

Evidence

form.set("meta_id", String(r.meta_id));

        form.set("database", "list_seo");

        form.set("database_id", String(seoId));

        const dr = await fetch(delUrl.toString(), {

          method: "DELETE",

          headers: {

            "X-Api-Key": apiKey,

RemediationAI

The problem is that the fetch call to DELETE a record has no timeout, allowing a hung upstream server to block indefinitely. Add a `signal` parameter using `AbortController` with a timeout: `const controller = new AbortController(); const timeout = setTimeout(() => controller.abort(), 5000); const dr = await fetch(delUrl.toString(), { method: "DELETE", headers: {...}, signal: controller.signal }); clearTimeout(timeout);`. This ensures the request fails fast if the upstream server is unresponsive. Verify by mocking a slow server and confirming the request aborts after 5 seconds.

LLM consensus

Evidence

form.set("meta_id", String(r.meta_id));

        form.set("database", String(database));

        form.set("database_id", String(databaseId));

        const dr = await fetch(delUrl.toString(), {

          method: "DELETE",

          headers: { "X-Api-Key": apiKey, Accept: "application/json", "Content-Type": "application/x-www-form-urlencoded" },

          body: form.toString(),

RemediationAI

The problem is that the fetch call to DELETE a record has no timeout, allowing a hung upstream server to block indefinitely. Add a `signal` parameter using `AbortController` with a timeout: `const controller = new AbortController(); const timeout = setTimeout(() => controller.abort(), 5000); const dr = await fetch(delUrl.toString(), { method: "DELETE", headers: {...}, signal: controller.signal }); clearTimeout(timeout);`. This ensures the request fails fast if the upstream server is unresponsive. Verify by mocking a slow server and confirming the request aborts after 5 seconds.

LLM consensus

Evidence

};

        // If any BD fetches failed outright (network / non-200), surface it so the

        // agent knows some values are fallbacks, not live site data. A missing row

        // on a successful fetch (slot just isn't set) is NOT a failure - fallback

        // silently applies; that's the documented design.

        if (failedSlots.length > 0) {

          kit._warnings = [

RemediationAI

The problem is that one or more fetch calls in this section have no timeout, allowing a hung upstream server to block indefinitely. Add a `signal` parameter using `AbortController` with a timeout to all fetch calls: `const controller = new AbortController(); const timeout = setTimeout(() => controller.abort(), 5000); const resp = await fetch(url, { ..., signal: controller.signal }); clearTimeout(timeout);`. This ensures requests fail fast if the upstream server is unresponsive. Verify by mocking a slow server and confirming the request aborts after 5 seconds.

LLM consensus

Evidence

async function _readSeoTypeForId(domain, apiKey, seoId) {

  try {

    const url = new URL(`/api/v2/list_seo/get/${encodeURIComponent(String(seoId))}`, `https://${domain}`);

    const resp = await fetch(url.toString(), { method: "GET", headers: { "X-Api-Key": apiKey, Accept: "application/json" } });

    if (!resp.ok) return null;

    const body = await resp.json().catch(() => null);

    const row = body && body.message && (Array.isArray(body.message) ? body.message[0] : body.message);

RemediationAI

The problem is that the fetch call to `/api/v2/list_seo/get/{seoId}` has no timeout, allowing a hung upstream server to block indefinitely. Add a `signal` parameter using `AbortController` with a timeout: `const controller = new AbortController(); const timeout = setTimeout(() => controller.abort(), 5000); const resp = await fetch(url.toString(), { method: "GET", headers: {...}, signal: controller.signal }); clearTimeout(timeout);`. This ensures the request fails fast if the upstream server is unresponsive. Verify by mocking a slow server and confirming the request aborts after 5 seconds.

LLM consensus

Evidence

form.set("new_filename", newFilename);

    form.set("type", "custom");

    form.set("db_id", String(seoId));

    const resp = await fetch(url.toString(), {

      method: "POST",

      headers: { "X-Api-Key": apiKey, Accept: "application/json", "Content-Type": "application/x-www-form-urlencoded" },

      body: form.toString(),

RemediationAI

The problem is that the fetch call to POST a new record has no timeout, allowing a hung upstream server to block indefinitely. Add a `signal` parameter using `AbortController` with a timeout: `const controller = new AbortController(); const timeout = setTimeout(() => controller.abort(), 5000); const resp = await fetch(url.toString(), { method: "POST", headers: {...}, body: form, signal: controller.signal }); clearTimeout(timeout);`. This ensures the request fails fast if the upstream server is unresponsive. Verify by mocking a slow server and confirming the request aborts after 5 seconds.

LLM consensus

Evidence

url.searchParams.append("property_operator[]", "=");

    url.searchParams.append("property_operator[]", "=");

    url.searchParams.set("limit", "100");

    const resp = await fetch(url.toString(), { method: "GET", headers: { "X-Api-Key": apiKey, Accept: "application/json" } });

    if (!resp.ok) return { probed_ok: false, deleted, reason: `probe HTTP ${resp.status}` };

    const body = await resp.json().catch(() => null);

    if (!body || body.status !== "success") return { probed_ok: false, del

RemediationAI

The problem is that the fetch call to query properties has no timeout, allowing a hung upstream server to block indefinitely. Add a `signal` parameter using `AbortController` with a timeout: `const controller = new AbortController(); const timeout = setTimeout(() => controller.abort(), 5000); const resp = await fetch(url.toString(), { method: "GET", headers: {...}, signal: controller.signal }); clearTimeout(timeout);`. This ensures the request fails fast if the upstream server is unresponsive. Verify by mocking a slow server and confirming the request aborts after 5 seconds.

LLM consensus

Evidence

const url = new URL(`/api/v2/redirect_301/delete`, `https://${domain}`);

    const form = new URLSearchParams();

    form.set("redirect_id", existing.redirect_id);

    const resp = await fetch(url.toString(), {

      method: "DELETE",

      headers: { "X-Api-Key": apiKey, Accept: "application/json", "Content-Type": "application/x-www-form-urlencoded" },

      body: form.toString(),

RemediationAI

The problem is that the fetch call to DELETE a redirect has no timeout, allowing a hung upstream server to block indefinitely. Add a `signal` parameter using `AbortController` with a timeout: `const controller = new AbortController(); const timeout = setTimeout(() => controller.abort(), 5000); const resp = await fetch(url.toString(), { method: "DELETE", headers: {...}, body: form, signal: controller.signal }); clearTimeout(timeout);`. This ensures the request fails fast if the upstream server is unresponsive. Verify by mocking a slow server and confirming the request aborts after 5 seconds.

LLM consensus

Evidence

url.searchParams.append("property_operator[]", "=");

    url.searchParams.append("property_operator[]", "=");

    url.searchParams.set("limit", "100");

    const resp = await fetch(url.toString(), { method: "GET", headers: { "X-Api-Key": apiKey, Accept: "application/json" } });

    if (!resp.ok) return null;

    const body = await resp.json().catch(() => null);

    const rows = (body && Array.isArray(body.message)) ? body.message : [];

RemediationAI

The problem is that the fetch call to query properties has no timeout, allowing a hung upstream server to block indefinitely. Add a `signal` parameter using `AbortController` with a timeout: `const controller = new AbortController(); const timeout = setTimeout(() => controller.abort(), 5000); const resp = await fetch(url.toString(), { method: "GET", headers: {...}, signal: controller.signal }); clearTimeout(timeout);`. This ensures the request fails fast if the upstream server is unresponsive. Verify by mocking a slow server and confirming the request aborts after 5 seconds.

LLM consensus

Evidence

**Exceptions to the HTML-allowed rules:**

- **Email body — no `<style>` blocks.** Outlook strips them. Use inline `style=""` attributes only. See **Rule: Email template recipe** for full email-client constraints.

- **Widget exception:** `widget_data`, `widget_style`, `widget_javascript` are exempt from all listed patterns. Widgets legitimately need JS and scoped CSS, and anyone with API permission to write widgets already has admin capability. Warn (but do NOT block) if widget_javascript contai

RemediationAI

The problem is that the documentation does not show evidence of a timeout being applied to network calls. Review all fetch() calls in index.js and add explicit timeouts using AbortController with a 5-second limit to every network request. This prevents hung upstream servers from blocking the MCP server indefinitely. Verify by running the server against a slow/unresponsive upstream and confirming all requests abort after 5 seconds.

Evidence

try {

    const url = new URL(`/api/v2/data_categories/get`, `https://${domain}`);

    url.searchParams.set("limit", "100");

    const resp = await fetch(url.toString(), { method: "GET", headers: { "X-Api-Key": apiKey, Accept: "application/json" } });

    if (!resp.ok) return null;

    const body = await resp.json().catch(() => null);

    const rows = (body && Array.isArray(body.message)) ? body.message : [];

RemediationAI

The problem is that the fetch call to `/api/v2/data_categories/get` has no timeout, allowing a hung upstream server to block indefinitely. Add a `signal` parameter using `AbortController` with a timeout: `const controller = new AbortController(); const timeout = setTimeout(() => controller.abort(), 5000); const resp = await fetch(url.toString(), { method: "GET", headers: {...}, signal: controller.signal }); clearTimeout(timeout);`. This ensures the request fails fast if the upstream server is unresponsive. Verify by mocking a slow server and confirming the request aborts after 5 seconds.

LLM consensus

Evidence

url.searchParams.append("property_value[]", oldFilename);

    url.searchParams.append("property_operator[]", "=");

    url.searchParams.set("limit", "1");

    const resp = await fetch(url.toString(), { method: "GET", headers: { "X-Api-Key": apiKey, Accept: "application/json" } });

    if (!resp.ok) return null;

    const body = await resp.json().catch(() => null);

    const rows = (body && Array.isArray(body.message)) ? body.message : [];

RemediationAI

The problem is that the fetch call to query properties by filename has no timeout, allowing a hung upstream server to block indefinitely. Add a `signal` parameter using `AbortController` with a timeout: `const controller = new AbortController(); const timeout = setTimeout(() => controller.abort(), 5000); const resp = await fetch(url.toString(), { method: "GET", headers: {...}, signal: controller.signal }); clearTimeout(timeout);`. This ensures the request fails fast if the upstream server is unresponsive. Verify by mocking a slow server and confirming the request aborts after 5 seconds.

LLM consensus

Evidence

# Official Brilliant Directories MCP Server — Setup Guide

[![npm version](https://img.shields.io/npm/v/brilliant-directories-mcp?color=blue&label=npm)](https://www.npmjs.com/package/brilliant-directories-mcp)

[![license](https://img.shields.io/github/license/brilliantdirectories/brilliant-directories-mcp?color=green)](LICENSE)

[![MCP](https://img.shields.io/badge/MCP-compatible-blue)](https://modelcontextprotocol.io)

Universal AI integration for your BD site. Give any AI agent full access to y

RemediationAI

The problem is that the README does not declare an authentication mechanism for the MCP server, making it unclear how callers are authenticated and authorized. Add an explicit `authentication` field to the MCP manifest (or a new section in README.md) that documents the auth method, such as: `"authentication": { "type": "apiKey", "description": "Requires BD_API_KEY and BD_SITE_URL environment variables" }`. This allows reviewers to audit the security model. Verify by confirming the manifest or README clearly states how authentication is enforced.

Evidence

#!/usr/bin/env node

/**

 * Brilliant Directories MCP Server (npm package — stdio transport)

RemediationAI

The problem is that the tools/list response does not include per-tool version, etag, or digest fields, making it impossible for clients to detect when tool definitions have changed. Add a `version` or `digest` field to each tool in the tools/list response (e.g., computed as a hash of the tool's schema), and increment it whenever the OpenAPI spec is reloaded. This allows clients to detect tool content changes. Verify by reloading the OpenAPI spec and confirming the digest changes in the tools/list response.

LLM consensus

Evidence

#!/usr/bin/env node

/**

 * Brilliant Directories MCP Server (npm package — stdio transport)

 *

 * Exposes all BD API v2 endpoints as MCP tools. Reads the OpenAPI spec and

 * auto-generates tool definitions. Runs as a child process launched by the

 * user's MCP-capable AI client (Claude Desktop / Cursor / Claude Code).

 *

 * Usage:

 *   brilliant-directories-mcp --api-key YOUR_KEY --url https://your-site.com

 *

 * Or via env vars:

 *   BD_API_KEY=YOUR_KEY BD_SITE_URL=https://your-site.com brilli

RemediationAI

The problem is that the code may check if a file exists with `fs.existsSync()` and then open/read/delete it without a lock, allowing an attacker to race a symlink or file replacement between the check and the use. Replace the check-then-use pattern with direct error handling: instead of `if (fs.existsSync(path)) { fs.readFileSync(path) }`, use `try { fs.readFileSync(path) } catch (e) { if (e.code !== 'ENOENT') throw e; }`. This eliminates the race window. Verify by creating a test that attempts to race a symlink replacement and confirming the operation either succeeds atomically or fails safely.

LLM consensus

Evidence

#!/usr/bin/env node

/**

 * Brilliant Directories MCP Server (npm package — stdio transport)

 *

 * Exposes all BD API v2 endpoints as MCP tools. Reads the OpenAPI spec and

 * auto-generates tool definitions. Runs as a child process launched by the

 * user's MCP-capable AI client (Claude Desktop / Cursor / Claude Code).

 *

 * Usage:

 *   brilliant-directories-mcp --api-key YOUR_KEY --url https://your-site.com

 *

 * Or via env vars:

 *   BD_API_KEY=YOUR_KEY BD_SITE_URL=https://your-site.com brilli

RemediationAI

The problem is that destructive operations (DELETE, PUT, PATCH, unlink) are performed without emitting any audit event, leaving no trail for incident response. Add audit logging to every destructive sink: before executing the operation, call an audit function like `auditLog({ action: 'DELETE', tool: toolName, target: recordId, timestamp: Date.now(), caller: requestContext.userId })` and write it to a secure audit log file or external service. This enables investigators to answer "who deleted record X on day Y?". Verify by performing a destructive operation and confirming an audit entry is written with the caller identity, action, and timestamp.

LLM consensus

Evidence

url.searchParams.set("limit", "100");

    const resp = await fetch(url.toString(), { method: "GET", headers: { "X-Api-Key": apiKey, Accept: "application/json" } });

    let body = null;

    try { body = await resp.json(); } catch {}

    if (!body) return { probed_ok: false, deleted, reason: `probe returned non-JSON (HTTP ${resp.status})` };

    // BD returns HTTP 400 + status:error on legitimate empty results — that's

    // a clean "no orphans" not a probe failure.

RemediationAI

The problem is that the `try { body = await resp.json(); } catch {}` silently swallows JSON parsing errors with no log, metric, or trace, blinding incident response. Replace with `try { body = await resp.json(); } catch (e) { console.error(`[error] Failed to parse JSON response: ${e.message}`); }` to log the error. This ensures failures are visible for debugging and monitoring. Verify by passing invalid JSON in a response and confirming an error message is logged to stderr.

LLM consensus