UltraProbe

Name: UltraProbe
Author: ppcvote

by ppcvote

Overview Schema Related Servers Score Discussions

TypeScript

Remote

MISP MCP Server

npm version License: MIT MCP

A Model Context Protocol server for MISP (Malware Information Sharing Platform), with built-in prompt injection defense powered by prompt-defense-audit.

Why this exists: MISP holds operational threat intel — IOCs, threat actor profiles, attack patterns. When you connect an LLM agent to MISP via MCP, two new attack surfaces emerge:
Adversarial seeding. A threat actor who can submit content into your MISP instance (or a federated feed) can plant prompt-injection payloads designed to hijack downstream LLM agents.
Sensitive intel leakage. A manipulated LLM can be coerced into returning intel above its authorized TLP level.
This server wraps every outgoing MISP response in prompt-defense-audit's output scanner, blocking high-risk patterns before they reach the LLM. Read-only by design — no write tools exposed.

Tracks: MISP/MISP#10745 — MCP server for MISP

Features

🛡️ Defense built in — every MISP response scanned for prompt-injection / XSS / shell-injection patterns before being returned
🔒 Read-only by design — no event/attribute mutation tools; an LLM cannot modify your threat-intel platform
🧰 8 high-utility tools covering events, attributes, search, tags, feeds, galaxies
⚡ Zero-config beyond MISP_URL and MISP_API_KEY
🪶 Stdio transport — works with Claude Desktop, Cursor, Continue, Cline, any MCP client
📋 MIT license — fork freely, use commercially

Related MCP server: Cyberbro MCP Server

Quick start

1. Install

npm install -g @ultralab/misp-mcp-server

Or use npx directly in your MCP client config (no install needed).

2. Configure your MCP client

Claude Desktop (~/Library/Application Support/Claude/claude_desktop_config.json on macOS, %APPDATA%/Claude/claude_desktop_config.json on Windows):

{
  "mcpServers": {
    "misp": {
      "command": "npx",
      "args": ["-y", "@ultralab/misp-mcp-server"],
      "env": {
        "MISP_URL": "https://misp.your-org.example",
        "MISP_API_KEY": "your_misp_api_key_here"
      }
    }
  }
}

Cursor / Continue / Cline — similar pattern, see your client's MCP config docs.

3. Restart your MCP client and start asking

"What MISP events are tagged tlp:white from the last 7 days?"
"Show me event 12345 — I'm investigating a phishing report."
"What threat actor galaxies do we have configured?"
"Find all attributes matching the IP 198.51.100.42."

Tools exposed

Tool	Purpose
`misp_version`	Health check + server version
`misp_list_events`	Paginated event headers
`misp_get_event`	Full event with attributes (scanned for injection)
`misp_search_events`	Search by tag / type / value / date range
`misp_search_attributes`	Direct IOC lookup
`misp_list_tags`	All configured tags (TLP, taxonomy, etc.)
`misp_list_feeds`	Configured threat-intel feeds
`misp_list_galaxies`	Threat actor / campaign clusters

Mutation tools intentionally not included. An LLM with write access to MISP is a supply-chain compromise vector. If you need agent-driven MISP mutations, build a per-tool allowlist with human-in-the-loop confirmation.

Defense layer

Every tool response is run through prompt-defense-audit's scanOutput before being returned to the LLM client.

High-risk patterns (critical / high severity) — response is blocked and replaced with a safe summary. Example trigger patterns:

Script-tag injection (<script>...</script>)
Iframe / object injection
JavaScript URLs (javascript:)
Shell-command patterns in unexpected contexts
Known prompt-injection vector signatures from prompt-defense-audit's 17+ vector library

Low/medium-risk patterns — response annotated with a [defense] prefix listing matched patterns but still returned.

Opt out (not recommended)

PROMPT_DEFENSE_DISABLED=true

Use only if you fully trust your MISP instance + all federated feeds and need raw response fidelity for a specific debugging scenario.

Environment variables

Variable	Required	Default	Notes
`MISP_URL`	✅	—	Base URL of your MISP instance (e.g. `https://misp.example.com`)
`MISP_API_KEY`	✅	—	MISP automation API key (Profile → Auth Keys)
`MISP_INSECURE_TLS`	❌	`false`	Set to `true` only for self-signed dev instances
`PROMPT_DEFENSE_DISABLED`	❌	`false`	Set `true` to skip output scanning (NOT recommended)

For enterprise users

The free OSS defense layer ships with prompt-defense-audit (17+ regex-based vectors, ~3ms latency, deterministic).

For deployments that need:

🔍 Persistent audit logs of every MISP query an LLM has made
👥 Team policies (per-role allowlists, per-TLP gating, escalation flows)
🌏 Jurisdictional compliance (EU GDPR / TW 個資法 / 中國 PIPL data-residency)
🚨 Live threat intel updates to the defense ruleset (new injection vectors pushed daily)
📊 SLA-backed uptime and response

→ Upgrade path: route MCP server through Quartz Cloud — Taiwan-domiciled runtime AI firewall, drop-in passthrough.

Development

git clone https://github.com/ppcvote/misp-mcp-server.git
cd misp-mcp-server
npm install
npm test            # smoke tests, no live MISP
npm run dev         # tsx watch mode
npm run build       # produce dist/

Architecture

LLM client (Claude Desktop, Cursor, etc.)
    │ stdio
    ▼
@ultralab/misp-mcp-server
    │
    ├─ src/tools.ts       — 8 read-only tool definitions + dispatch
    ├─ src/misp-client.ts — minimal MISP REST API wrapper
    └─ src/index.ts       — MCP Server + scanOutput() defense layer
    │
    ▼
MISP REST API (/events, /attributes, /tags, /feeds, /galaxies)

Project context

Built by Ultra Lab — a one-person AI products company in Taiwan, focused on AI safety, threat intel, and the supply chain between LLM agents and operational security tooling.

This server is part of a broader thesis: the MCP ecosystem will be a major prompt-injection vector unless servers default to defensive output handling. We're shipping reference implementations for high-leverage targets (MISP first, OpenCTI / TheHive / Vault next) to anchor the standard.

Companion projects:

prompt-defense-audit — the underlying detection engine
ultraprobe — CLI scanner for AI app system prompts
quartz.tw — paid runtime firewall (audit logs, team policies, jurisdictional moat)

License

Contributing

PRs welcome. Please:

Keep the read-only invariant. Mutation tools must be argued explicitly with a threat-model writeup.
Add a test for any new tool.
If you add new MISP API coverage, link to the relevant OpenAPI spec section in your PR.

For discussion, see MISP/MISP#10745.

Available Tools

8 tools

misp_get_eventA

Fetch a single MISP event by id, including its attributes (IOCs). The response is scanned for prompt-injection payloads before being returned.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	MISP event id (numeric or UUID)

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses that the response is scanned for prompt-injection payloads, but does not mention read-only nature, error handling, or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two sentences: one for purpose and one for a behavioral detail. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description includes the inclusion of attributes and the scanning behavior, which is sufficient for a simple fetch tool. No output schema, but the description gives enough context for expected response content.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers the id parameter with a description, and the description does not add additional meaning beyond what is in the schema. Baseline score for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool fetches a single MISP event by id, including its attributes. This distinguishes it from sibling tools like misp_list_events and misp_search_events.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool versus alternatives, but the purpose of fetching a single event by ID is implicit. No exclusions or guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

misp_list_eventsA

List MISP events (most recent first). Returns event headers (id, info, date, threat level, tags). For detailed attributes, call misp_get_event with an id. Default page size is 20; max 100.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`page`	No

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Discloses ordering, return fields, default and max page size, and that it's a listing operation. Could mention error handling or authentication but sufficient for basic behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no redundancy. First sentence states purpose and return, second gives usage guideline and limits. Highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a list tool with 2 simple params and no output schema, description covers return fields, ordering, pagination limits, and sibling relationship. Lacks details on empty results or errors but is reasonably complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage, so description must compensate. Explains limit parameter with default and max values, but page parameter is only implied as part of pagination without explicit explanation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it lists MISP events with ordering (most recent first) and specifies return fields (id, info, date, threat level, tags). Distinguishes from sibling misp_get_event which returns detailed attributes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly directs to misp_get_event for detailed attributes, providing a clear alternative. Implies this tool is for listing headers only, but does not explicitly state when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

misp_list_feedsA

List configured MISP threat-intel feeds (enabled and disabled). Use this to understand which external sources are feeding the instance.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It states it lists both enabled and disabled feeds, which is useful, but it does not explicitly state that it is read-only or describe any other implications like rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences that get straight to the point. Every sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of a zero-parameter list tool and no output schema, the description sufficiently covers the purpose and usage context. It could mention output format but is not critically incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters, and schema coverage is 100%. With zero parameters, the baseline is 4, and the description does not need to add parameter details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List configured MISP threat-intel feeds' with a specific verb and resource, distinguishing it from sibling tools that handle events, galaxies, tags, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It says 'Use this to understand which external sources are feeding the instance', providing a clear context. However, it does not explicitly exclude other tools or mention alternatives when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

misp_list_galaxiesA

List MISP galaxies (threat actor profiles, campaign clusters, technique catalogs). Galaxies are MISP's structured representation of MITRE ATT&CK, threat actors, etc.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, authentication needs, or rate limits. Listing operations are typically safe, but the description should explicitly state this.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no wasted words. The description is front-loaded with the primary action and includes relevant examples.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameter-less list tool, the description adequately explains what galaxies are and gives examples. However, it could mention the lack of result limits or pagination for completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, and the description provides context about what galaxies represent, which adds value beyond the empty schema. Baseline 4 applies per guidelines.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists MISP galaxies, with specific examples like threat actor profiles and MITRE ATT&CK. It distinguishes the tool's function well from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus sibling tools like misp_list_tags or misp_list_events. No context on prerequisites or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

misp_list_tagsA

List all tags configured on the MISP instance. Useful for discovering taxonomy values (TLP levels, malware families, campaign names) before running a tag-scoped search.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It accurately describes a read-only listing operation with no destructive behavior, which is sufficient for this simple tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences: the first states the purpose, the second provides usage context. No unnecessary words or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless list tool with low complexity, the description fully covers what the tool does and when to use it. No output schema is needed, so completeness is achieved.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters; the description need not add parameter details. Baseline score of 4 applies as no additional information is required.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List all tags configured on the MISP instance' with a specific verb and resource. It also explains the usefulness for discovering taxonomy values, distinguishing it from sibling tools like misp_list_events or misp_get_event.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes a usage scenario: 'before running a tag-scoped search'. While it doesn't explicitly state when not to use, it provides clear context and no sibling tool covers the same purpose.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

misp_search_attributesA

Search MISP attributes (IOCs) directly. Faster than searching events when you have a specific IOC type/value pair to look up.

ParametersJSON Schema

Name	Required	Description	Default
`value`	No
`type`	No
`category`	No
`tag`	No
`limit`	No

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It only mentions speed but does not disclose what the tool returns (e.g., list of attributes, count), authentication needs, or side effects. There is no behavioral context beyond the purpose.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, highly concise, and front-loaded with the purpose. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 5 parameters, 0% schema coverage, and no output schema, the description is incomplete. It lacks parameter explanations, output format, and error handling information. The use case comparison is helpful but insufficient for full agent understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description does not explain any of the 5 parameters (value, type, category, tag, limit). The description adds no meaning beyond what the parameter names imply, leaving the agent with insufficient guidance on how to use each parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it searches MISP attributes (IOCs) and explicitly distinguishes from searching events by claiming it's faster for specific IOC type/value pairs. It differentiates from sibling tools like misp_search_events.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when to use this tool ('when you have a specific IOC type/value pair') and implies when not to use it (for broader events search) by referencing the alternative approach.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

misp_search_eventsA

Search MISP events by tag, type, value, category, or date range. Useful for threat hunting (e.g. all events tagged with a CVE, or matching an IOC value).

ParametersJSON Schema

Name	Required	Description
`value`	No	IOC value to search for (substring match)
`type`	No	Attribute type (e.g. ip-src, domain, sha256)
`category`	No	Attribute category (e.g. Network activity, Payload delivery)
`tag`	No	Tag name (e.g. tlp:white, malware:trickbot)
`from`	No	Start date YYYY-MM-DD
`to`	No	End date YYYY-MM-DD
`limit`	No

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry full burden. It does not disclose behavioral traits such as pagination behavior (though a limit parameter exists), output format, or implications of missing parameters. The description is minimal on what happens when no results are found or how search works (substring? exact?).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two sentences, front-loading the core action and providing a brief example. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of 7 optional parameters, no output schema, and zero annotations, the description is adequate but not complete. It lacks details on return format, search behavior, and when to use this tool over siblings. The example adds some context but leaves gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 86%, so the input schema already provides adequate descriptions for most parameters. The tool description adds no additional meaning beyond the schema, achieving the baseline for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches MISP events by multiple criteria (tag, type, value, category, date range) and provides an example use case for threat hunting. It effectively distinguishes from siblings like misp_get_event (single event) and misp_search_attributes (search attributes).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description suggests use for threat hunting but lacks explicit when-to-use or when-not-to-use guidelines. It does not refer to sibling tools or conditions that would make this tool preferable over others like misp_list_events or misp_search_attributes.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

misp_versionA

Health check — return the MISP server version and capability flags. Use this to verify connectivity before issuing other queries.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Since no annotations are provided, the description carries full burden. It reveals the tool is read-only and returns version/flags, but could mention it's lightweight or has no side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with purpose, zero filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters, no output schema, and a simple operation, the description fully covers what an agent needs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so baseline 4 applies. The description adds no param info as none is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool is a health check that returns server version and capability flags. It distinguishes from sibling tools which focus on events, feeds, and filters.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises using it to verify connectivity before other queries, providing clear when-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

8 tool updatesv0.1.0May 29, 2026
- First observedmisp_get_event
- First observedmisp_list_events
- First observedmisp_list_feeds
- First observedmisp_list_galaxies
- First observedmisp_list_tags
- First observedmisp_search_attributes
- First observedmisp_search_events
- First observedmisp_version

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Disambiguation5/5

Each tool targets a distinct operation: event retrieval, listing, feed listing, galaxy listing, tag listing, attribute search, event search, and health check. No overlap in purpose.

Naming Consistency5/5

All tools follow a consistent 'misp_verb_noun' pattern using snake_case, with clear verbs (get, list, search) and nouns describing the resource.

Tool Count5/5

8 tools is appropriate for a read-focused MISP client, covering key browsing and search operations without being excessive or insufficient.

Completeness3/5

Covers essential reading operations (events, attributes, feeds, galaxies, tags) but lacks any creation, update, or deletion tools, limiting its usefulness for full MISP workflows.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Agent Safe AOAuth
io.github.wowcool
Email safety MCP server. Detects phishing, prompt injection, CEO fraud for AI agents.
Security Autonomous Agents
2
MCP FortressOAuth
io.github.mcp-fortress
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Security Testing & QA Tools Penetration Testing
2
meok-mcp-hardening-mcp
io.github.CSOAI-ORG
MEOK MCP Hardening MCP — automated security red-team for any MCP server. Maps OWASP LLM Top 10
Penetration Testing Security
1
mcp-server
com.pentest-tools
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
Penetration Testing Security
23

Related MCP Servers

MISP-MCP-SERVER
Security Monitoring Search
bornpresident
F
license
Not graded
quality
D
maintenance
A Model Context Protocol (MCP) server that integrates with the MISP (Malware Information Sharing Platform) to provide threat intelligence capabilities to Large Language Models.
Updated a year ago (2025-04-09 06:26 UTC)
12
-
Cyberbro MCP Server
Security Search Research & Data
stanfrbd
A
license
A
quality
A
maintenance
An MCP server that extracts Indicators of Compromise (IoCs) from unstructured text and checks their reputation across multiple threat intelligence services. It enables real-time analysis of IPs, domains, hashes, and URLs, providing enriched context for security workflows within LLMs.
Updated a month ago (2026-08-04 14:15 UTC)
5
19
MIT
misp-mcp
Security Search Research & Data
lidless-labs
A
license
A
quality
A
maintenance
An MCP server that enables LLMs to interact with MISP for threat intelligence sharing, IOC lookups, and event management. It provides tools for investigating indicators, discovering correlations, and exporting intelligence in formats like STIX and Suricata.
Updated a month ago (2026-08-08 15:40 UTC)
36
34
2
MIT
MISP MCP Server
Security Search
DarkAngel-agents
F
license
Not graded
quality
D
maintenance
A Model Context Protocol server that connects AI assistants to MISP threat intelligence platforms. It enables threat intelligence search, IOC lookup, and event analysis through natural conversation.
Updated 5 months ago (2026-04-21 00:29 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ppcvote/misp-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server