github · mcp-server0cc90034bd39

RemediationAI

The problem is that the tool description contains an imperative instruction ('Use this first') that attempts to manipulate LLM routing decisions rather than neutrally describing functionality. Remove the phrase 'Use this first' from the tool description in mcp-manifest.json and replace it with a neutral functional description (e.g., 'Search DataNexus tools by keyword'). This eliminates the attack surface for prompt injection through tool metadata by ensuring all tool descriptions are purely declarative. Verify the fix by reviewing the mcp-manifest.json tool entry and confirming no imperative instructions or priority hints remain in the description field.

RemediationAI

The problem is that CVE data from untrusted external sources (Google OSV.dev and NIST NVD) is returned with free-text fields (severity descriptions, CVSS vectors) that lack provenance delimiters, enabling indirect prompt injection. Wrap all untrusted free-text fields returned by security_fetch_package_vulnerabilities with explicit provenance markers such as `[EXTERNAL_SOURCE: field_name]` or use a structured response envelope that clearly separates trusted metadata from untrusted external content. This prevents the LLM from interpreting injected instructions embedded in CVE descriptions as system directives. Verify by calling the tool and confirming that all external text fields are wrapped with delimiters and that the response structure clearly marks untrusted data.

RemediationAI

The problem is that transitive dependency metadata from deps.dev is returned without visible provenance markers, creating an indirect prompt injection risk through package names and descriptions. Add explicit provenance delimiters (e.g., `[EXTERNAL: deps.dev]`) to all untrusted fields in the security_fetch_dependency_graph response, and structure the output to clearly separate trusted identifiers from external descriptions. This prevents the LLM from treating injected content in package metadata as trusted instructions. Verify by calling the tool and confirming that all external package names and descriptions are marked with provenance labels.

Evidence

"""

datanexus/agents/feedback_classifier.py — Haiku Trigger 2: feedback classification.

Spec: DataNexus_MCP_Spec_v7_4.docx  Section 13.4 / Phase 4

Most important file in Section 13. Closes the loop between user-reported

feedback and automated data quality triage.

Rules (CLAUDE.md):

  S13-1: This is Haiku Trigger T2. Delegate to haiku_classifier.classify() only.

  S13-4: Never raises. All exceptions caught. Always returns structured result.

  S13-5: FeedbackRecord.classification is ONE-WAY onl

RemediationAI

The problem is that the classify() method in feedback_classifier.py calls the Anthropic SDK without a max_tokens cap, allowing unbounded token consumption and potential denial-of-service. Add a max_tokens parameter to the anthropic.messages.create() call in the classify() method (e.g., max_tokens=500) to enforce a hard limit on output tokens. This prevents runaway token usage and protects against resource exhaustion attacks. Verify by calling the feedback classifier and confirming in the Anthropic API response that the max_tokens field is set and respected.

Evidence

"""

datanexus/agents/schema_monitor.py — Haiku Trigger 3: schema change assessment.

Spec: DataNexus_MCP_Spec_v7_4.docx  Section 13.5 / Phase 5

Called when the ingest worker detects a structural change between the

previously-stored schema fingerprint and the newly-fetched payload shape.

Haiku decides whether the change is breaking and what severity to assign.

Rules (CLAUDE.md):

  S13-1: This is Haiku Trigger T3. Delegate to haiku_classifier.classify() only.

  S13-4: Never raises. Always return

RemediationAI

The problem is that the classify() method in schema_monitor.py calls the Anthropic SDK without a max_tokens cap, allowing unbounded token consumption and potential denial-of-service. Add a max_tokens parameter to the anthropic.messages.create() call in the classify() method (e.g., max_tokens=500) to enforce a hard limit on output tokens. This prevents runaway token usage and protects against resource exhaustion attacks. Verify by calling the schema monitor and confirming in the Anthropic API response that the max_tokens field is set and respected.

Evidence

"""

datanexus/agents/anomaly_reviewer.py — Haiku Trigger 1: anomaly review.

Spec: DataNexus_MCP_Spec_v7_4.docx  Section 13.3 / Phase 3

Called when the deterministic validator (validator.py) flags an anomaly

that needs a second-opinion classification before deciding whether to

keep, suppress, or flag the affected record.

Rules (CLAUDE.md):

  S13-1: This is Haiku Trigger T1. Do NOT call Anthropic API directly —

         always delegate to haiku_classifier.classify().

  S13-4: Never raises. All 

RemediationAI

The problem is that the classify() method in anomaly_reviewer.py calls the Anthropic SDK without a max_tokens cap, allowing unbounded token consumption and potential denial-of-service. Add a max_tokens parameter to the anthropic.messages.create() call in the classify() method (e.g., max_tokens=500) to enforce a hard limit on output tokens. This prevents runaway token usage and protects against resource exhaustion attacks. Verify by calling the anomaly reviewer and confirming in the Anthropic API response that the max_tokens field is set and respected.

Evidence

"""

datanexus/agents/haiku_classifier.py — Shared Haiku API wrapper for all 4 triggers.

Spec: DataNexus_MCP_Spec_v7_4.docx  Section 13.2 / Phase 2

Rules (CLAUDE.md):

  S13-1: Called ONLY from the 4 permitted triggers — never directly from tool handlers.

  S13-2: HAIKU_MODEL imported from feedback/config.py. Never hardcoded here.

  S13-3: Daily cap HAIKU_MAX_CALLS_PER_DAY (100) enforced before every call.

         incr → expire → check, in that exact order.

  S13-4: On any API error: return err

RemediationAI

The problem is that haiku_classifier.py's classify() method calls anthropic.messages.create() without passing a max_tokens parameter, allowing unbounded token consumption. Add max_tokens=500 (or an appropriate limit) as a parameter to the anthropic.messages.create() call in datanexus/agents/haiku_classifier.py. This enforces a hard ceiling on token usage across all four trigger tools (feedback_classifier, schema_monitor, anomaly_reviewer, digest_generator) that depend on this shared wrapper. Verify by inspecting the haiku_classifier.py source and confirming the max_tokens parameter is present in the messages.create() call, then test each trigger tool.

Evidence

"""

datanexus/agents/digest_generator.py — Haiku Trigger 4: weekly digest.

Spec: DataNexus_MCP_Spec_v7_4.docx  Section 13.6 / Phase 6

Batches ALL feedback records for a tool into ONE Haiku call (cost control)

and produces a DigestItem with data quality score, top issues, suggested

rules, and sprint recommendations.

Rules (CLAUDE.md):

  S13-1: This is Haiku Trigger T4. Delegate to haiku_classifier.classify() only.

  S13-4: Never raises. Always returns structured DigestItem.

Special case — emp

RemediationAI

The problem is that the classify() method in digest_generator.py calls the Anthropic SDK without a max_tokens cap, allowing unbounded token consumption and potential denial-of-service. Add a max_tokens parameter to the anthropic.messages.create() call in the classify() method (e.g., max_tokens=1000 for batch digests) to enforce a hard limit on output tokens. This prevents runaway token usage and protects against resource exhaustion attacks. Verify by calling the digest generator and confirming in the Anthropic API response that the max_tokens field is set and respected.

Evidence

"""

datanexus/tools/security_stateful.py — Sprint 6 stateful security tools.

Tools:

  fetch_cve_watch     — persistent CVE watchlist (create/check/delete)

  audit_sbom_continuous — continuous SBOM monitoring (register/check/deregister)

Redis key schema (dn: prefix):

  dn:cve_watch:{watch_id}    — Hash (watch data)

  dn:cve_watch_ids           — SET  (watch index)

  dn:sbom_watch:{watch_id}   — Hash (SBOM watch data)

  dn:sbom_watch_ids          — SET  (SBOM watch index)

Scheduler: see datanex

RemediationAI

The problem is that security_stateful.py registers destructive tools (fetch_cve_watch delete, audit_sbom_continuous deregister) but emits no audit event, leaving no trail of who performed the deletion and when. Add an audit logging call (e.g., log_audit_event(actor, action, resource_id, timestamp)) immediately after each destructive operation (fs.unlink, shutil.rmtree, DELETE FROM, etc.) in security_stateful.py, and store the audit record in a separate immutable audit log or Redis key with extended TTL. This enables investigators to answer 'who deleted record X on day Y?' and closes the OWASP MCP08 gap. Verify by performing a delete operation via fetch_cve_watch or audit_sbom_continuous and confirming an audit event appears in the audit log with actor, action, resource, and timestamp.

Evidence

# ── Structured error response shape ──────────────────────────────────────────

# Return this dict on ANY error. Never raise. Never return str(e).

# error_code must come from ErrorCode enum below.

#

# {

RemediationAI

The problem is that datanexus/core/schema.py returns full exception details or stack traces to the caller, exposing internal paths, library versions, and query structure useful for reconnaissance. Replace all instances of str(exc) or traceback output with a generic error message from the ErrorCode enum (e.g., 'SCHEMA_VALIDATION_ERROR') and log the full exception internally using logger.exception(). This hides implementation details from the caller while preserving debugging information in server logs. Verify by triggering an error condition in schema.py and confirming the response contains only the generic error code, not the full traceback.

Evidence

"error":           str(exc),

            "haiku_available": False,

        }))

        return {"error": str(exc), "haiku_available": False}

RemediationAI

The problem is that haiku_classifier.py returns full exception details (str(exc)) to the caller, exposing internal library versions and API structure. Replace str(exc) with a generic error message such as 'Classification service unavailable' and log the full exception internally using logger.exception(). This hides implementation details while preserving debugging information in server logs. Verify by triggering an exception in haiku_classifier and confirming the returned error field contains only a generic message, not the full traceback.

Evidence

schedule_seconds=_SCHEDULE,

        )

    async def fetch(self) -> bytes:

        """Fetch and cache EPO OPS OAuth token; probe fallback sources."""

        client_id     = os.environ.get("EPO_CLIENT_ID", "")

        client_secret = os.environ.get("EPO_CLIENT_SECRET", "")

RemediationAI

The problem is that t11_worker.py makes network/IO calls without an explicit timeout, allowing a hung upstream to pin threads and exhaust connection pools. Add timeout=30 (or appropriate seconds) to the httpx.AsyncClient() or httpx.get() call in the fetch() method of t11_worker.py. This enforces a bounded timeout on all HTTP requests to the EPO OPS OAuth endpoint. Verify by inspecting the fetch() method and confirming timeout is set, then test with a slow upstream to confirm the request times out gracefully.

Evidence

schedule_seconds=_SCHEDULE,

        )

    async def fetch(self) -> bytes:

        """

        Fetch NPPES data for top specialities. Returns a summary JSON blob

        for the base class to hash and store. Per-speciality cache entries

RemediationAI

The problem is that t22_worker.py makes network/IO calls without an explicit timeout, allowing a hung upstream to pin threads and exhaust connection pools. Add timeout=30 (or appropriate seconds) to the httpx.AsyncClient() or httpx.get() call in the fetch() method of t22_worker.py. This enforces a bounded timeout on all HTTP requests to the NPPES data endpoint. Verify by inspecting the fetch() method and confirming timeout is set, then test with a slow upstream to confirm the request times out gracefully.

Evidence

schedule_seconds=_SCHEDULE,

        )

    async def fetch(self) -> bytes:

        """Pre-seed top keyword categories."""

        seeded = 0

        async with httpx.AsyncClient(

RemediationAI

The problem is that t18_worker.py makes network/IO calls without an explicit timeout, allowing a hung upstream to pin threads and exhaust connection pools. Add timeout=30 (or appropriate seconds) to the httpx.AsyncClient() call in the fetch() method of t18_worker.py. This enforces a bounded timeout on all HTTP requests to pre-seed keyword categories. Verify by inspecting the fetch() method and confirming timeout is set on the AsyncClient, then test with a slow upstream to confirm the request times out gracefully.

Evidence

self.ttl_seconds      = ttl_seconds

        self.schedule_seconds = schedule_seconds

    async def fetch(self) -> bytes:

        """

        Override in subclass. Must return raw upstream response bytes.

        Raise any exception on failure — run_forever will catch it.

RemediationAI

The problem is that the base ingest_base.py class does not enforce timeouts on network/IO calls in the fetch() method, allowing hung upstreams to pin threads. Add timeout=30 (or appropriate seconds) as a parameter to all httpx.AsyncClient() instantiations and httpx.get() calls in the fetch() method and run_forever() loop of ingest_base.py. This enforces a bounded timeout across all subclass workers. Verify by inspecting ingest_base.py and confirming timeout is set on all HTTP client calls, then test with a slow upstream to confirm the request times out gracefully.

Evidence

schedule_seconds=604800,  # weekly — data updates monthly

        )

    async def fetch(self) -> bytes:

        """Download all 4 regional CSVs and index every EIN into Redis."""

        total_rows = 0

RemediationAI

The problem is that t04_worker.py makes network/IO calls without an explicit timeout, allowing a hung upstream to pin threads and exhaust connection pools. Add timeout=30 (or appropriate seconds) to the httpx.AsyncClient() or httpx.get() call in the fetch() method of t04_worker.py. This enforces a bounded timeout on all HTTP requests to download regional CSVs. Verify by inspecting the fetch() method and confirming timeout is set, then test with a slow upstream to confirm the request times out gracefully.

Evidence

schedule_seconds=_SCHEDULE,  # 21600 — rate limit awareness

        )

    async def fetch(self) -> bytes:

        """Pre-seed top regulatory keyword categories."""

        api_key = os.environ.get("REGULATIONS_GOV_KEY", "")

        if not api_key:

RemediationAI

The problem is that t19_worker.py makes network/IO calls without an explicit timeout, allowing a hung upstream to pin threads and exhaust connection pools. Add timeout=30 (or appropriate seconds) to the httpx.AsyncClient() or httpx.get() call in the fetch() method of t19_worker.py. This enforces a bounded timeout on all HTTP requests to the Regulations.gov API. Verify by inspecting the fetch() method and confirming timeout is set, then test with a slow upstream to confirm the request times out gracefully.

Evidence

Downloads from the official CISA GitHub mirror (cisagov/kev-data) — see KEV_URL constant.

and stores in Redis as:

  datanexus:kev:catalog    — full catalog JSON (TTL 25h)

  datanexus:kev:fetched_at — ISO timestamp of last successful fetch (TTL 25h)

  datanexus:kev:last_refresh_error — error message if refresh fails (TTL 7d)

Invoked two ways:

RemediationAI

The problem is that kev_refresh.py makes network/IO calls without an explicit timeout, allowing a hung upstream to pin threads and exhaust connection pools. Add timeout=30 (or appropriate seconds) to the httpx.get() or httpx.AsyncClient() call in the refresh() function of kev_refresh.py when downloading from the CISA GitHub mirror. This enforces a bounded timeout on all HTTP requests to fetch the KEV catalog. Verify by inspecting the refresh() function and confirming timeout is set, then test with a slow upstream to confirm the request times out gracefully.

Evidence

Endpoints:

  GET /ops/dashboard          — full HTML dashboard

  GET /ops/api/metrics        — JSON metrics snapshot (same data, for fetch())

  GET /ops/health             — {"ok": true}

The dashboard auto-refreshes every 15 seconds via JavaScript fetch().

RemediationAI

The problem is that dashboard.py makes network/IO calls without an explicit timeout, allowing a hung upstream to pin threads and exhaust connection pools. Add timeout=30 (or appropriate seconds) to any httpx.AsyncClient() or httpx.get() calls in the dashboard endpoints (GET /ops/dashboard, GET /ops/api/metrics, GET /ops/health) in datanexus/ops/dashboard.py. This enforces a bounded timeout on all HTTP requests. Verify by inspecting the dashboard endpoints and confirming timeout is set on all HTTP client calls, then test with a slow upstream to confirm the request times out gracefully.

Evidence

class IngestBase:

    """

    Base ingest worker. Subclasses override fetch() only.

    Args:

        tool_id:          Tool this worker feeds (e.g. 'T04')

RemediationAI

The problem is that the IngestBase class does not enforce timeouts on network/IO calls, allowing hung upstreams to pin threads and exhaust connection pools. Add timeout=30 (or appropriate seconds) as a parameter to all httpx.AsyncClient() instantiations and httpx.get() calls in the run_forever() method and any HTTP operations in datanexus/core/ingest_base.py. This enforces a bounded timeout across all subclass workers. Verify by inspecting ingest_base.py and confirming timeout is set on all HTTP client calls, then test with a slow upstream to confirm the request times out gracefully.

Evidence

schedule_seconds=_SCHEDULE,

        )

    async def fetch(self) -> bytes:

        """Fetch IANA RDAP bootstrap and store in Redis."""

        async with httpx.AsyncClient(

            timeout=_TIMEOUT, headers=_HEADERS, follow_redirects=True

RemediationAI

The problem is that t07_worker.py makes network/IO calls without an explicit timeout, allowing a hung upstream to pin threads and exhaust connection pools. The evidence shows timeout=_TIMEOUT is already set on the httpx.AsyncClient() call; verify that _TIMEOUT is defined with a reasonable value (e.g., 30 seconds) and is not None or infinite. If _TIMEOUT is not defined or is unbounded, add timeout=30 to the AsyncClient() call. Verify by inspecting t07_worker.py and confirming _TIMEOUT is defined with a finite value, then test with a slow upstream to confirm the request times out gracefully.

Evidence

schedule_seconds=3600,

        )

    async def fetch(self) -> bytes:

        """Pre-seed all 50 packages. Returns last raw response bytes."""

        seeded = 0

        last_raw = b""

RemediationAI

The problem is that t10_worker.py makes network/IO calls without an explicit timeout, allowing a hung upstream to pin threads and exhaust connection pools. Add timeout=30 (or appropriate seconds) to the httpx.AsyncClient() or httpx.get() call in the fetch() method of t10_worker.py. This enforces a bounded timeout on all HTTP requests to pre-seed packages. Verify by inspecting the fetch() method and confirming timeout is set, then test with a slow upstream to confirm the request times out gracefully.

Evidence

schedule_seconds=86400,

        )

    async def fetch(self) -> bytes:

        """Download bulk extract and index all main charities into Redis."""

        log.info(json.dumps({

            "ts": _iso_now(), "event": "uk_bulk_download_start", "tool": self.tool_id,

RemediationAI

The problem is that t04_worker.py makes network/IO calls without an explicit timeout, allowing a hung upstream to pin threads and exhaust connection pools. Add timeout=30 (or appropriate seconds) to the httpx.AsyncClient() or httpx.get() call in the fetch() method of t04_worker.py. This enforces a bounded timeout on all HTTP requests to download bulk charity data. Verify by inspecting the fetch() method and confirming timeout is set, then test with a slow upstream to confirm the request times out gracefully.

Evidence

#!/usr/bin/env node

/**

 * DataNexus MCP — stdio proxy for Glama and local MCP clients.

 *

 * Bridges stdio ↔ the live remote server at https://datanexusmcp.com/mcp

 * using mcp-remote. No Python, no Redis, no PostgreSQL required.

 *

 * Usage:

 *   npx -y @datanexusmcp/mcp-server

 *

 * Claude Desktop claude_desktop_config.json:

 *   {

 *     "mcpServers": {

 *       "datanexus": {

 *         "command": "npx",

 *         "args": ["-y", "@datanexusmcp/mcp-server"]

 *       }

 *     }

 *   }

 */

c

RemediationAI

The problem identified is that datanexus-mcp.js is a stdio-to-remote transport proxy that forwards MCP JSON-RPC to a remote server; this is standard remote MCP deployment and not a per-invocation steering instruction injection vulnerability. No remediation is required; this is a LOW finding indicating the architecture is acceptable. Verify by reviewing the mcp-remote protocol documentation and confirming that the proxy only forwards JSON-RPC messages without modification or injection.

Evidence

try:

                r = await get_redis()

                if r:

                    await r.set(cache_key, tier, ex=300)

            except Exception:

                pass

            return tier

        except Exception as exc:

RemediationAI

The problem is that datanexus/main.py contains a bare except Exception: pass clause that silently discards Redis cache-set failures with no log or metric, blinding incident response. Replace the bare except with except Exception as e: logger.warning('Failed to cache tier', exc_info=True) to log the exception at warning level with full traceback. This preserves debugging information in server logs while maintaining graceful degradation. Verify by triggering a Redis connection failure and confirming a warning log entry appears with the exception details.

Evidence

# remaining allowlist domains — any path counts

        for allowed in _PATCH_ALLOWLIST:

            if host == allowed or host.endswith("." + allowed):

                return True

    except Exception:

        pass

    return False

RemediationAI

The problem is that datanexus/tools/cve_sprint7.py contains a bare except Exception: pass clause in the allowlist domain check that silently discards parsing failures with no log or metric. Replace the bare except with except Exception as e: logger.debug('Allowlist check failed', exc_info=True) to log the exception at debug level. This preserves debugging information in server logs while maintaining safe-fail behavior (returning False). Verify by triggering a malformed URL and confirming a debug log entry appears with the exception details.

Evidence

raw = r.hget(key_feedback(tool_id, rid), "data")

                    if raw:

                        try:

                            records.append(json.loads(raw))

                        except Exception:

                            pass

            except Exception:

                pass

        results[tool_id] = records

RemediationAI

The problem is that feedback/dashboard/server.py contains nested bare except Exception: pass clauses that silently discard JSON parsing and Redis failures with no log or metric. Replace both bare excepts with except Exception as e: logger.warning('Failed to load feedback record', exc_info=True) to log exceptions at warning level with full traceback. This preserves debugging information in server logs while maintaining graceful degradation. Verify by triggering a malformed JSON record in Redis and confirming a warning log entry appears with the exception details.

Evidence

try:

        r = _get_redis()

        if r:

            r.set(LAST_ERROR_KEY, msg[:500], ex=7 * 86400)

    except Exception:

        pass

async def refresh() -> bool:

RemediationAI

The problem is that datanexus/kev_refresh.py contains a bare except Exception: pass clause that silently discards Redis cache-set failures with no log or metric, blinding incident response. Replace the bare except with except Exception as e: logger.warning('Failed to cache KEV refresh error', exc_info=True) to log the exception at warning level with full traceback. This preserves debugging information in server logs while maintaining graceful degradation. Verify by triggering a Redis connection failure and confirming a warning log entry appears with the exception details.