
Itsoc Mcp
io.github.Ankit512Published by GitHub account Ankit512v0.1.0Updated Oct 24, 2026
Read-only MCP server over a local log-analysis backend; a client that computes no verdicts.
Overview
Read-only MCP client that proxies a local log-analysis backend, letting an assistant run analyses, inspect findings and evidence, export runs, and propose IP…
- What you can do
- Run and list log analyses: start analysis on a local path or http(s) URL, list saved runs and the current run
- Inspect findings and evidence: filter findings by severity, rule or host, and pull evidence lines, rule predicate and timeline for one finding
- Explain a finding: request an advisory explanation from the backend's model endpoint
- Export a run: proxy export in csv, html, xml, json or md
- Look up threat intel: offline STIX-to-MITRE lookup for one IPv4 address
- Propose a block: create a pending IP-block approval record on the backend console
- When to use it
- Use it when you already run the project's local log-analysis backend and want an MCP-capable assistant to drive its analysis, triage findings, and draft block proposals without leaving the chat. It is not a standalone detector: it relays backend results and computes no verdicts of its own.
- Requirements
- A local Python environment with the MCP SDK installed (pip, uvx or pipx), and the backend running and reachable, by default at Optional environment variables: ITSOC_BASE_URL for the backend address, ITSOC_MCP_TRUSTED_LOCAL to return raw text, and ITSOC_STIX_BUNDLE for a local STIX bundle. Offline threat intel needs a repo checkout.
Installation
In SourceWeft
- Open Itsoc Mcp in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
itsoc-icp — an MCP server over the local analysis backend
mcp-name: io.github.Ankit512/itsoc-icp
itsoc-icp (Python package itsoc_mcp) exposes this project's existing log-analysis capabilities as
Model Context Protocol tools, so an
MCP-capable agent (Claude Code / Claude Desktop) can drive them. It is an
isolated sibling package: it imports nothing from anomaly_detector.py,
changes no /api/* route, and adds no dependency to the core backend.
What it is (and is not)
- A client, not a brain. Every tool proxies the already-running local backend
(
http://127.0.0.1:8765by default). This server computes no verdicts: severities, correlation, and rule verdicts are owned by the frozen deterministic detector on the backend. Tools relay; they never re-decide. - No action execution and no approval authority. No tool can approve, reject,
execute, or revoke actions.
propose_block_ipcan create a proposal in thependingstate only; all execution and approval authority strictly resides on the backend console with human-in-the-loop step-up authentication.analyze_logkicks off log analysis andexplain_findingrequests an advisory explanation via the existing endpoint — an explanation never changes, suppresses, or escalates a verdict. - Honest by construction. Backend
null/ "0 lines parsed" / idle states are passed through verbatim — never a fabricated all-clear or an empty file. - Redacted by default. Any field carrying raw log text is masked through the
project's existing egress choke point (
console/redact.py) before it leaves, unless you opt into a trusted local session (see below).
Every tool response carries a provenance block stating: verdicts are
deterministic/rule-owned, explanations are advisory, MITRE tags are derived (not
verdicts), plus the running detector's detector_sha256.
Tools
Every tool declares all four MCP hints as explicit booleans (readOnlyHint,
destructiveHint, idempotentHint, openWorldHint) so hosts can warn before
invoke and OpenAI's directory will accept the contract. Read tools
(list_runs, get_findings, get_evidence, export_run, threat_intel_lookup)
are readOnlyHint: true. analyze_log, explain_finding, and propose_block_ip
are writes (additive, not destructive). All backend-facing tools are
openWorldHint: true.
Install
The core backend stays stdlib-only — do not install anything to run it. Install the MCP SDK only if you want to run this server:
Run
-
Start the backend (from the repo root), stdlib-only, no extra installs:
-
Launch the MCP server over stdio (from the repo root):
Configuration (environment)
Register with an MCP client (stdio)
Paste into your MCP client config (e.g. Claude Desktop's
claude_desktop_config.json, or .mcp.json for Claude Code). Replace
/ABSOLUTE/PATH/TO/itsoc with the repo root:
To allow raw evidence/export on a trusted local machine, add
"ITSOC_MCP_TRUSTED_LOCAL": "1" (and optionally "ITSOC_STIX_BUNDLE": "...") to
that env block. The backend (python3 console/serve.py) must be running.
Tests
Network-free, no SDK, no ATT&CK cache required — the client is faked and the offline mapper is stubbed:
It asserts each tool's shape, that get_evidence/get_findings/explain_finding
are redacted by default and raw only with ITSOC_MCP_TRUSTED_LOCAL=1, and
that idle/unrecognized/error states return honest errors, not empty payloads.
Standalone install (uvx / pipx)
pyproject.toml builds an itsoc-icp distribution with an itsoc-icp console
script (itsoc_mcp.server:main) and pins mcp>=1.9,<2 — MCP clients speak the
stable 1.x API; mcp 2.0 changed the server API. The package is self-contained:
designed to run with no repo checkout.
Two honesty points, stated plainly:
- The egress guard is never weakened standalone. Redaction has a single source
of truth —
console/redact.py— used whenever the repo is importable. In a bare install it falls back to a verbatim vendored mirror (_redact_vendored.py) that masks identically (redact-by-default; raw only withITSOC_MCP_TRUSTED_LOCAL=1). A drift-guard test asserts the two never diverge, so the vendored copy can never silently mask less.redaction.redact_source()reports which is active. If neither could load, the module fails to import rather than pass text through — it fails closed, never open. threat_intel_lookupneeds the repo. Its offline STIX→MITRE path reuses the repo's siblingthreat_intel/package, which a bare install does not ship. In a standalone install that one tool fails closed with an honest "offline threat-intel unavailable … NOT a clean verdict / not an all-clear" message — never a fabricated match or a fake all-clear. Run from the repo (python -m itsoc_mcp) to use offline threat-intel. Every other tool is a client of the backend API and works identically standalone or in-repo.
Standalone means no repo checkout is needed for the MCP package — the backend
(python3 console/serve.py) still runs separately and must be reachable at
ITSOC_BASE_URL.
License
MIT — see the repository's top-level LICENSE.
Source: itsoc_mcp/README.md at commit c05a31e
Tools
0Version history
1- v0.1.0LatestSep 16, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts