novelty
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ANTHROPIC_MODEL | No | Model to use (defaults to claude-opus-5 with fallback to claude-opus-4-8). | claude-opus-5 |
| ANTHROPIC_API_KEY | Yes | Your Anthropic API key for the reasoning layer. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| healthA | Show Novelty MCP status: which reasoning model is wired in and the tools available. |
| http_sendA | Send an HTTP(S) request and log it to history (like Burp Repeater + Logger). Args: method: GET, POST, PUT, DELETE, … url: full target URL (a target you're authorized to test) headers_json: optional JSON object of request headers body: optional request body (for POST/PUT) Returns the logged entry id, status, timing, and a response preview. |
| http_historyA | List recently logged requests (the HTTP history / Logger view). |
| http_getA | Show the full request and response (headers + body) for one logged entry. |
| http_replayA | Re-send a logged request with optional edits (Repeater tweak-and-resend). Any argument left blank keeps the original request's value. Supplied headers are merged onto the original. Logs a new history entry. |
| intruderA | Replay a logged request substituting Bounded to a small list — for enumeration/IDOR/auth checks, not stress testing. Args: request_id: a logged request to base the attack on marker: the placeholder string to replace (put it in the URL/body first) payloads_json: a JSON array of payload strings (e.g. ["1","2","3"]) |
| reconA | Read-only recon of a web target: tech stack, headers, forms, script bundles, backend/third-party services, missing security headers, and exposed-file checks. |
| huntA | Run recon then an AI vulnerability hunt over the high-value classes (BOLA/BFLA/XSS/SQLi/business logic/RCE/auth). Non-destructive; authorized targets only. Returns findings with exploit scenarios, impact, a confirm test, and a fix. |
| review_codeA | Security-review a source file's contents with Claude (BOLA/BFLA/XSS/SQLi/ business-logic/RCE/auth). Pass the file text you have open; returns line-referenced findings with exploit + fix. Whole-file reasoning, not regex. |
| review_fileB | Same as review_code, but reads the file from a local path first. |
| report_webA | Hunt a web target and produce a polished security-assessment report. Runs recon + the AI hunt, then renders a Markdown report (returned) and, if save_html is given, a styled self-contained HTML report written to that path. Authorized, non-destructive; authorized targets only. Args: url: the target to assess save_html: optional path for the styled HTML report (e.g. "reports/dvwa.html") |
| report_sourceA | Security-review a source file and produce a polished report (Markdown + optional HTML). Args: path: local source file to review save_html: optional path for the styled HTML report |
| reportA | Render a report from findings you have ALREADY collected — e.g. the output of hunt/review combined with your own http_send/intruder evidence. Args: findings_json: a JSON array of finding objects (Novelty or your own shape: title, severity, vuln_class, endpoint/file, exploit, impact, confirm_test, fix) target: the assessed target's name/URL (for the report header) kind: "web" or "source" save_html: optional path for the styled HTML report |
| scope_setA | Set the authorized testing scope — an allowlist of hosts. Once set, the traffic tools (http_send, recon, hunt, secrets_hunt, param_discover) refuse anything out of scope. Supports wildcards, e.g. ["*.example.com","api.foo.io"]. Args: hosts_json: a JSON array of hostnames/domains (or a plain comma list) |
| scope_showA | Show the current authorized scope (empty = not enforced). |
| secrets_huntA | Pull a target's page + JS bundles and flag leaked secrets (cloud keys, tokens, JWTs, private keys, provider keys). Read-only, non-destructive. |
| param_discoverA | Mine parameters, endpoints, and forms from a target's HTML + JS — the attack surface you then probe with http_send / intruder. Read-only. |
| arsenalA | Consult Novelty's arsenal — a HackTricks-style bypass/technique reference — when a hunt is blocked by a control. Pull a class page or search all pages. Args: vuln_class: one of sqli, xss, idor-bola-bfla, auth-jwt, rce, ssrf, traversal, logic, waf (aliases like "idor","jwt","lfi" also work) query: free-text search across the arsenal if you don't know the class Call with neither to list the available pages. |
| hunt_logA | Read Novelty's persistent hunt memory — recent milestones (recon/hunt/ finding/report), optionally filtered to a target. Secrets are never logged. |
| rememberA | Append a milestone/lead to Novelty's hunt memory so a later session can pick it up. Do NOT put credentials/tokens here (they'd be scrubbed anyway). |
| chainA | Reason across findings for exploit CHAINS that raise impact (self-XSS + login-CSRF = ATO, info-leak + SSRF = cloud creds, …). Args: findings_json: a JSON array of finding objects (from hunt/review/report) |
| triageA | Adversarially triage ONE finding: is it real, exploitable and non-duplicate? Returns a verdict, dup-likelihood, adjusted severity, and the SAFE negative control to run to confirm or kill it. Args: finding_json: a single finding object as JSON |
| mail_newA | Create a throwaway inbox (mail.tm) for registering a test account on an app you're authorized to test. Returns an address to poll with mail_inbox(). |
| mail_inboxA | Poll a throwaway inbox created by mail_new(). Returns messages and any links found (e.g. the verification link to finish signup). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 24 tools
Some tools overlap in purpose: recon is a subset of hunt, and report_web wraps hunt; similarly review_file vs review_code vs report_source overlap heavily. However, descriptions clarify the distinctions (e.g., review_file reads from path, review_code takes content, report_source adds report generation), and most HTTP/memory tools are clearly distinct.
The naming convention is inconsistent. Some tools use bare verbs (recon, hunt, remember, chain, triage), some use noun_verb (http_send, scope_show, secrets_hunt, param_discover), and others use noun_noun (http_history, hunt_log, mail_inbox). There is no single predictable pattern, making it harder to guess tool names.
24 tools is on the high side and borders on the 'heavy' range. The server covers a broad security testing domain, but there is some redundancy (three report tools, three code-review tools, three recon/hunt tools) that could be consolidated. Still, each tool has a role and the count is not excessive for a full-featured security toolkit.
The toolset covers the core security testing lifecycle well: recon (recon, param_discover), active testing (http_send, intruder), vulnerability analysis (hunt, review_code), reporting (report, report_web, report_source), and auxiliary support (arsenal, mail, memory, triage). Minor gaps exist (e.g., no dedicated session/cookie management, no tool for comparing HTTP responses), but these are workarounds.