com.super-log/super-log
NPM · @SUPER-LOG/MCP · SCANNED SEP 25
Query your local super-log bench from an AI agent - read-only log tools over the hub.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →
Supply Chain Security100
- No malware found by supply-chain analysis.Pass
- No known CVEs affecting this package version or its production dependencies.Pass
- No install/post-install scripts declared.Pass
- No production dependencies, so there is no dependency health to assess. View diagnostics → Pass
Provenance & Transparency48
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
- Clear OSI-approved license (MIT).Pass
- Actively maintained (last published 10 days ago).Pass
- Publishes a security disclosure policy (SECURITY.md).Pass
Schema Quality & AI Usability82
- 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 1525 tokens (~169/item across 9 items; 9 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management33
- Stability observed for 10 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 9 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 10 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities60
- Spec-recency check failed: implements MCP spec 2025-06-18; the latest is 2026-07-28. See how to fix → Fail
How do I install the com.super-log/super-log MCP server?
com.super-log/super-log runs locally as an npm package, launched with npx -y @super-log/mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
npm · @super-log/mcp
claude mcp add com-super-log-super-log -- npx -y @super-log/mcp
{
"mcpServers": {
"com-super-log-super-log": {
"command": "npx",
"args": [
"-y",
"@super-log/mcp"
]
}
}
} {
"servers": {
"com-super-log-super-log": {
"command": "npx",
"args": [
"-y",
"@super-log/mcp"
]
}
}
} codex mcp add com-super-log-super-log -- npx -y @super-log/mcp
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"com-super-log-super-log": {
"type": "local",
"command": [
"npx",
"-y",
"@super-log/mcp"
],
"enabled": true
}
}
} openclaw mcp add com-super-log-super-log --command npx --arg -y --arg @super-log/mcp
mcp_servers:
com-super-log-super-log:
command: "npx"
args: ["-y", "@super-log/mcp"] {
"McpServers": {
"com-super-log-super-log": {
"Transport": "stdio",
"Command": "npx",
"Arguments": [
"-y",
"@super-log/mcp"
]
}
}
} assistant mcp add com-super-log-super-log -t stdio -c npx -a -y @super-log/mcp
{
"mcpServers": {
"com-super-log-super-log": {
"command": "npx",
"args": [
"-y",
"@super-log/mcp"
]
}
}
} Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 25 Sept 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 23 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 23 to 27. That category is still filling its 30-day observation window: 7 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes.
- 22 Sept 26 +3
- Stability: unverified → 0.23 ▲ functional
- 15 Sept 26 71
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 25 Sept 2026 · Analysed npm/@super-log/mcp@0.4.1
Provenance No attestation
The registry publishes no build provenance for this version, so there is nothing to verify.
| Result | No attestation |
|---|---|
| Ecosystem | npm |
Background: How many MCP packages publish verified provenance →
Dependencies 0 packages
| Packages resolved | 0 |
|---|---|
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
agent_report ~302
Put yourself on the bench's AGENTS blotter: say who you are, which LLM you run on, what you are doing, and how often to expect you. For a long job (an 8-hour build, an overnight proof search), call this on a schedule - every interval_s, default 900 (15 minutes) - AND on events: milestones, errors (level WARN/ERROR), and done. The blotter shows your last status and greys you when you miss your own promised cadence, so a silent agent LOOKS silent. This is the single deliberate write this otherwise read-only server performs, and it can only land on agent.* status topics.
| Name | Type | Req | Description |
|---|---|---|---|
| agent | string | yes | Your name on the blotter (e.g. "proof-search", "nightly-builder") |
| interval_s | number | – | How often you promise to report (default 900); the blotter greys you at 2x |
| level | string | – | Default INFO; WARN/ERROR when the status IS the problem |
| llm | string | yes | The model you run on (e.g. "claude-fable-5") - the blotter displays it |
| pct | number | – | Percent complete, when the job has a shape |
| status | string | yes | One line: what is happening right now |
| task | string | – | The overall job (e.g. "8h proof search, mathlib bump") |
No output schema declared.
No examples provided.
hub_status ~47
Check whether the super-log hub is running and how much traffic it has seen. Call this first when logs seem missing - it distinguishes "the bench is down" from "the app logged nothing".
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
list_streams ~75
Summarise which log streams (topics) are active and their level mix. Cheap orientation - call this before tail_logs so you know what topics exist and where the errors are, instead of guessing topic names.
| Name | Type | Req | Description |
|---|---|---|---|
| window | number | – | How many recent events to summarise (default 1000, max 1000) |
No output schema declared.
No examples provided.
list_webhooks ~116
List the alarm gateway's routes: the production alarm door and every provisioned webhook endpoint (capture / relay / forward) with its PUBLIC URL, health light, ping latency and kind. Use this to find the URL to hand a webhook sender (Stripe, GitHub, a partner) - deliveries then arrive as wh.<name> events (tail_logs with topic wh.<name>; fields carry the signature verdict, relay status and up to 32KB of body). Ask stream_guide about "wh" for how to read them.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
search_history ~268
Search the on-disk journal: hours or days of history, not the few minutes the hub keeps in memory. This is the tool for "what happened at 3am" or anything older than the live ring - tail_logs and search_logs cannot see that far back. Needs superlog-journal to have been running at the time.
| Name | Type | Req | Description |
|---|---|---|---|
| contains | string | – | Case-insensitive substring of the whole event, fields included |
| dir | string | – | Journal directory (default ./superlog-journal, or $SUPER_LOG_JOURNAL) |
| level | string | – | Minimum level |
| limit | number | – | Max events (default 50, cap 200); the NEWEST matches |
| since | string | – | Start of the window: 30m, 2h, 3d, 03:00 (today, UTC), 2026-08-22, or a full ISO timestamp. Windows on hub arrival time, which is the only reliable clock across streams |
| topic | string | – | Exact topic (cpp.clock), a prefix ending in a dot (expo. matches every device stream), or * |
| trace | string | – | One correlation id, across every stream |
| until | string | – | End of the window, same forms as since |
No output schema declared.
No examples provided.
search_logs ~100
Find events matching text across the recent window - use when you know what the message says (an exception, an order id, a URL) but not which stream it is in.
| Name | Type | Req | Description |
|---|---|---|---|
| contains | string | yes | Text to find (case-insensitive) |
| level | string | – | Optional minimum level |
| limit | number | – | Max matches (default 50, cap 200) |
| topic | string | – | Optional topic or prefix to narrow the search |
No output schema declared.
No examples provided.
stream_guide ~129
Detailed documentation for a bench capability, before working with an unfamiliar topic: what its events and metrics mean, how to read them, and the gotchas (what a stall escalation is, why power says not root, why a diff can be silent). No arguments lists everything; name one entry or a playbook for the detail.
| Name | Type | Req | Description |
|---|---|---|---|
| name | string | – | A stream entry (power, dl, build, fs, vitals, gpu, os-app, net, history) or a playbook (triage, follow-a-trace, silent-stream, power-incident, watch-a-download) |
No output schema declared.
No examples provided.
tail_logs ~201
Read recent log events, newest last. ALWAYS narrow with topic and/or level - the firehose can be thousands of events per second. Returns a cursor; pass it back as `since` to read only what is new since your last call.
| Name | Type | Req | Description |
|---|---|---|---|
| contains | string | – | Only events whose text contains this (case-insensitive) |
| level | string | – | Minimum level; ERROR is the usual choice when hunting a bug |
| limit | number | – | Max events (default 50, cap 200) |
| since | number | – | Cursor from a previous call; 0 or omitted starts from the oldest kept |
| topic | string | – | Exact topic (cpp.clock), a prefix ending in a dot (cpp. matches all cpp streams), or * for all |
| trace | string | – | Follow ONE user action across every stream by its correlation id. This is the best tool for "what happened when X was pressed" - it deliberately ignores topic. |
No output schema declared.
No examples provided.
wait_for ~146
Block until a matching event appears, then return it. This is the one to use after you trigger something: start the action, then wait for its log line or error rather than sleeping and hoping. Returns promptly on the first match.
| Name | Type | Req | Description |
|---|---|---|---|
| contains | string | – | Text the event must contain (case-insensitive) |
| level | string | – | Optional minimum level, e.g. ERROR |
| since | number | – | Only consider events after this cursor. Take a cursor BEFORE triggering your action so you cannot match something old. |
| timeout_ms | number | – | How long to wait (default 30000, max 120000) |
| topic | string | – | Optional topic or prefix |
No output schema declared.
No examples provided.
What is the com.super-log/super-log MCP server?
com.super-log/super-log is an MCP server listed in the public MCP registry as com.super-log/super-log. Query your local super-log bench from an AI agent - read-only log tools over the hub. This page covers its npm package (@super-log/mcp).
Is the com.super-log/super-log MCP server safe to use?
com.super-log/super-log scores 75 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 25 September 2026. It declares no install or post-install scripts. 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 com.super-log/super-log MCP server expose?
com.super-log/super-log exposes 9 tools: hub_status, agent_report, list_webhooks, list_streams, tail_logs, and 4 more. Their descriptions and schemas cost roughly 1,384 tokens of context every time the server is loaded.
Is the com.super-log/super-log MCP server still maintained?
com.super-log/super-log is still listed as active in the MCP registry. We last reached this channel on 25 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.
What licence is the com.super-log/super-log MCP server under?
com.super-log/super-log declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.