What can you do with this server?

This server connects to a MISP (Malware Information Sharing Platform) instance, enabling you to query threat intelligence, investigate indicators, explore the knowledge base, and submit new indicators — all in plain language through any MCP-compatible client. It exposes 18 tools across the following areas: Indicator Lookups * misp_lookup_ioc: Search MISP for sightings of a single IPv4/IPv6, domain, URL, or hash (defanged forms accepted). Returns a verdict with event hits, threat level, and detection-flag status. * misp_lookup_iocs: Batch triage up to 20 indicators in one call with a compact per-IOC summary. * misp_correlate_ioc: Pivot from an IOC to find other indicators appearing in the same MISP event(s) — useful for discovering related infrastructure. Event Investigation * misp_get_event: Fetch full details of a MISP event by ID (metadata, tags, attributes). * misp_search_events: Search events by title keyword, tag, and/or date range. Attribute & Object Access * misp_get_attribute: Fetch a single attribute by ID along with its parent event. * misp_get_object: Retrieve a MISP object (group of related attributes) by ID. * misp_search_attributes: Search attributes by type, category, tag, to_ids status, or event ID. Threat Intelligence Knowledge Base * misp_lookup_galaxy: Look up threat actors, malware families, tools, and ATT&CK techniques by name or synonym. * misp_list_galaxies: List all galaxy types available on the instance. * misp_list_taxonomies: View all taxonomies (TLP, kill-chain, PAP, etc.) and their enabled status. * misp_get_taxonomy: Retrieve a specific taxonomy's tags and their meanings. * misp_search_tags: Find tag definitions by name. Feed & Instance Monitoring * misp_feed_stats: See feed counts and which are enabled. * misp_instance_status: Verify connectivity, authentication, and retrieve MISP/server versions. Audit & Review * misp_review_submissions: Audit recent IOC submissions — what was added, by whom, when, and which are detection-flagged. Indicator Submission (requires write-capable API key) * misp_submit_ioc: Add a single, fully attributed indicator with required fields (reporter, justification, last-seen date, tags, detection flag). Guardrails block private/reserved IPs and first-party infrastructure. * misp_submit_iocs: Bulk validate and add up to 50 indicators; defaults to dry_run=true so you can preview before committing. All operations automatically clean defanged indicators (e.g., hxxp://evil[.]com, 1.2.3[.]4), and write operations enforce rate limiting and security guardrails.

How do I use misp-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@misp-mcp look up 102.130.113.9 in MISP" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

misp-mcp

by indranilroy99

Overview Schema Related Servers Score Discussions

Python

Hybrid

This server connects to a MISP (Malware Information Sharing Platform) instance, enabling you to query threat intelligence, investigate indicators, explore the knowledge base, and submit new indicators — all in plain language through any MCP-compatible client. It exposes 18 tools across the following areas:

Indicator Lookups

misp_lookup_ioc: Search MISP for sightings of a single IPv4/IPv6, domain, URL, or hash (defanged forms accepted). Returns a verdict with event hits, threat level, and detection-flag status.
misp_lookup_iocs: Batch triage up to 20 indicators in one call with a compact per-IOC summary.
misp_correlate_ioc: Pivot from an IOC to find other indicators appearing in the same MISP event(s) — useful for discovering related infrastructure.

Event Investigation

misp_get_event: Fetch full details of a MISP event by ID (metadata, tags, attributes).
misp_search_events: Search events by title keyword, tag, and/or date range.

Attribute & Object Access

misp_get_attribute: Fetch a single attribute by ID along with its parent event.
misp_get_object: Retrieve a MISP object (group of related attributes) by ID.
misp_search_attributes: Search attributes by type, category, tag, to_ids status, or event ID.

Threat Intelligence Knowledge Base

misp_lookup_galaxy: Look up threat actors, malware families, tools, and ATT&CK techniques by name or synonym.
misp_list_galaxies: List all galaxy types available on the instance.
misp_list_taxonomies: View all taxonomies (TLP, kill-chain, PAP, etc.) and their enabled status.
misp_get_taxonomy: Retrieve a specific taxonomy's tags and their meanings.
misp_search_tags: Find tag definitions by name.

Feed & Instance Monitoring

misp_feed_stats: See feed counts and which are enabled.
misp_instance_status: Verify connectivity, authentication, and retrieve MISP/server versions.

Audit & Review

misp_review_submissions: Audit recent IOC submissions — what was added, by whom, when, and which are detection-flagged.

Indicator Submission (requires write-capable API key)

misp_submit_ioc: Add a single, fully attributed indicator with required fields (reporter, justification, last-seen date, tags, detection flag). Guardrails block private/reserved IPs and first-party infrastructure.
misp_submit_iocs: Bulk validate and add up to 50 indicators; defaults to dry_run=true so you can preview before committing.

All operations automatically clean defanged indicators (e.g., hxxp://evil[.]com, 1.2.3[.]4), and write operations enforce rate limiting and security guardrails.

misp-mcp connects MISP to any MCP client (Claude Desktop, Claude Code, Cursor, and others). You ask in plain language, the client calls MISP, you get the answer. No MISP UI, no REST calls by hand.

It exposes 21 tools: 19 read (indicators, events, feeds, the galaxy / taxonomy / tag knowledge base, warninglist checks, worker/job health) and 2 gated write (add indicators, single + bulk); a 22nd optional enrichment bridge registers only when TI_LOOKUP_URL is set. Every call runs under your own MISP key - the server holds no credential of its own.

How it works

flowchart LR
    C["MCP client<br/>Claude · Cursor · any"] -->|"X-MISP-Key: your key"| S["misp-mcp<br/>stdio or HTTP"]
    S -->|"read (19 tools)"| M[("your MISP")]
    S -->|"write (2 tools, gated)"| M
    S -. "optional (TI_LOOKUP_URL)" .-> E["enrichment service"]
    M -. "authorizes + attributes<br/>every call to you" .-> S

Your key is the credential. It rides in a header; MISP validates it on the real call and attributes the query to you. No shared account.
Read by default, writes gated. A read-only key can look things up; adding indicators needs a write-capable key (held by the security team).
Enrichment is optional. Set TI_LOOKUP_URL to bridge to a MISP-first enrichment service; unset, the tool stays hidden and this is a pure MISP client.

Related MCP server: misp-mcp

Get started

Two ways to use it. If you have your own MISP, run it locally (below). If your org already hosts misp-mcp, skip to Connect to a hosted server.

Run it locally

Your MCP client launches misp-mcp as a local process (stdio) that talks to your own MISP with your key. One user (you), nothing to host.

flowchart LR
    A["Your MCP client<br/>Claude Desktop/Code · Cursor"] -->|"launches (stdio)"| B["misp-mcp<br/>your key in env"]
    B -->|"HTTPS"| M[("your MISP")]

Where's your MISP? MISP_URL is your MISP's address, wherever it runs - a local Docker instance (https://localhost), one on your network (https://misp.lan), or a cloud-hosted one (https://misp.yourco.com). Only the URL changes. For a local or self-signed instance, also set MISP_VERIFY_TLS=false. misp-mcp just needs to be able to reach that URL - join your VPN first if the MISP is private.

Install it from source:
```
git clone https://github.com/indranilroy99/misp-mcp.git
cd misp-mcp
./install.sh
```
install.sh checks your environment, installs the misp-mcp binary, and can auto-write your client config. Manual steps are in ONBOARDING.md.
Point your client at it. Add a stdio server with two env vars - MISP_URL and your MISP_API_KEY. Claude Code, one command:
```
claude mcp add misp --scope user \
  -e MISP_URL=https://misp.example.com \
  -e MISP_API_KEY=YOUR_KEY_HERE \
  -- misp-mcp
```
Other clients: add an mcpServers entry running the misp-mcp command with those two env vars, then fully restart the app.
Try it. Ask your assistant "Is MISP healthy?" or "Look up 8.8.8.8 in MISP." If it answers from MISP, you're set.

Prefer Docker or a team deployment? See Host it for a team.

Connect to a hosted server

If your org runs misp-mcp behind a URL, there's nothing to install - point your client at it with your own key. You must be on the network / VPN that can reach it.

Get your MISP key (one time): open MISP → My Profile → Auth Keys → Add authentication key, comment it misp-mcp <your-name>, copy it (shown once). A read-only key is enough for lookups. Keep it private - every query runs as you.

Add the server - any MCP client that speaks streamable HTTP with custom headers works. It needs three things: transport http, the URL, and two headers.

{
  "mcpServers": {
    "misp": {
      "type": "http",
      "url": "https://misp.example.com/mcp",
      "headers": {
        "X-MISP-Key": "YOUR_KEY_HERE",
        "X-MISP-User": "you@example.com"
      }
    }
  }
}

Check it works: this should print 401 (endpoint reachable, auth required):

curl -s -o /dev/null -w '%{http_code}\n' -X POST https://misp.example.com/mcp

Claude Code (one terminal command):

claude mcp add --transport http misp https://misp.example.com/mcp \
  --scope user \
  --header "X-MISP-Key: YOUR_KEY_HERE" \
  --header "X-MISP-User: you@example.com"

Claude Desktop / Cursor / Windsurf - add the mcpServers block above to the client's MCP JSON config, then fully restart the app.

VS Code (Copilot MCP) - in .vscode/mcp.json or user settings, under "servers", use the same type/url/headers shape.

Cline / Continue / Zed / Goose and others - same URL, http transport, and the two X-MISP-* headers, in whatever config format the client uses. Any client that cannot send custom HTTP headers is not supported (the key must ride in X-MISP-Key).

MCP clients cache the tool list at connect time. If tools are wrong or the server was updated, fully quit and reopen the app (an in-app reconnect or a new chat is often not enough). Still stale: remove the misp server, save, reopen, add it back, reopen again.

Claude Code:

claude mcp remove misp
# then re-add (see above) and fully restart Claude Code

What you can ask

"Look up 102.130.113.9 in MISP."
"Triage these 30 IOCs from the report."
"What else showed up in the same event as evil[.]com?"
"Review the last 30 days of IOC submissions - who added what."
"Is MISP healthy? How many feeds are on?"

Paste indicators however you have them - defanged forms (1.2.3[.]4, hxxp://evil[.]com) are cleaned up automatically; private/reserved IPs are rejected. Behind the scenes a tool returns structured JSON, e.g. a lookup:

{
  "ioc": "102.130.113.9", "ioc_type": "ipv4", "total_hits": 6,
  "summary": { "seen_in_misp": true, "detection_flagged": true,
               "max_threat_level": "Medium", "restricted_hits": 0 },
  "hits": [ { "event_id": "16989", "event_info": "Tor exit nodes feed",
              "value": "102.130.113.9", "to_ids": true, "restricted": false } ]
}

Tools

Tool		What it does
`misp_lookup_ioc`	read	Sightings of one IPv4/IPv6, domain, URL, or hash, with a verdict
`misp_lookup_iocs`	read	Triage many indicators in one call
`misp_correlate_ioc`	read	Other indicators in the same event, for pivoting
`misp_get_event`	read	One event: info, tags, attributes
`misp_search_events`	read	Search events by title, tag, or date
`misp_feed_stats`	read	How many feeds exist and which are on
`misp_instance_status`	read	Reachability + auth check; run first when a tool fails
`misp_review_submissions`	read	Audit recent submissions: what was added, by whom
`misp_lookup_galaxy`	read	Threat actors, malware, tools, ATT&CK techniques by name or synonym
`misp_list_galaxies`	read	Galaxy types available on the instance
`misp_list_taxonomies`	read	Taxonomies (TLP, kill-chain, PAP) and whether each is enabled
`misp_get_taxonomy`	read	One taxonomy's tags and their meanings
`misp_search_tags`	read	Find tag definitions by name
`misp_get_object`	read	One MISP object (grouped attributes, e.g. a file object)
`misp_get_attribute`	read	One attribute by id, with its event
`misp_search_attributes`	read	Search attributes by type, category, tag, to_ids, or event (paginated)
`misp_check_warninglist`	read	Flag IOCs that hit known-good / noise lists (false-positive control)
`misp_worker_status`	read	Background worker / queue health (admin key)
`misp_jobs`	read	Recent background jobs + failures and why (admin key)
`misp_submit_ioc`	write	Add a new indicator (needs a write-capable key)
`misp_submit_iocs`	write	Bulk: validate + add many indicators (dry-run preview first)
`misp_enrich_ioc`	enrich	Optional: combined verdict via a MISP-first enrichment service (`TI_LOOKUP_URL`); may auto-record confirmed-bad IOCs

Security

Your key is the authorization. MISP checks it on every call and attributes the action to you. A read-only key cannot write; only write-capable keys can add indicators.
Guarded write path. Submissions are rate-limited, well-known / first-party infrastructure can never be submitted (anti-poisoning safelist), and the submitter is read from MISP itself, not a value the caller sets.
Fail-closed TLP. With server-side redaction on, an event whose tags can't be read is treated as restricted, never revealed.
Keys stay private. No shared key on the server; the key rides in a header over TLS. Logs never contain keys or IOC values.

Report a vulnerability privately: SECURITY.md.

Host it for a team

Run misp-mcp as an HTTP server so a whole team can use it, each with their own MISP key. It holds no credential - every request carries the caller's X-MISP-Key, which MISP validates and attributes.

flowchart LR
    U1["Analyst A"] --> LB
    U2["Analyst B"] --> LB
    LB["TLS proxy / load balancer<br/>ingress: your VPN CIDRs only"] -->|"HTTP :8080 (private)"| S["misp-mcp (HTTP)<br/>no stored key"]
    S -->|"HTTPS"| M[("your MISP")]

Run it somewhere that can reach your MISP - the same VPC/network if your MISP is cloud-hosted or private, or alongside it (set MISP_URL to its address, as above). TLS terminates at the load balancer; misp-mcp serves plain HTTP on :8080 behind it (or give the process its own cert). Keep ingress scoped to your caller networks - the endpoint is not public. Pick a path:

Path	Use it for	Guide
Docker	Fastest single host	see below
Self-host (VM + systemd)	A team, your own box	DEPLOY.md
Cloud (AWS / GCP / Azure)	Any provider, hand steps	CLOUD.md
AWS Terraform	One `terraform apply`, ALB + TLS	deploy/terraform/

Docker (bind stays on localhost; front it with your own TLS proxy for remote use - the key is a bearer credential):

docker run -d -p 127.0.0.1:8080:8080 \
  -e MCP_TRANSPORT=http -e MCP_HOST=0.0.0.0 \
  -e MISP_URL=https://misp.example.com \
  -e MISP_MCP_ALLOW_INSECURE_BIND=true \
  ghcr.io/indranilroy99/misp-mcp:latest
# or: MISP_URL=https://misp.example.com docker compose up -d

The Terraform modules ship two flavors sharing one networking module: Fargate (serverless, no VM) or EC2 (managed VM, SSM access), each behind an internal ALB with TLS.

Setting	Mode	Default	Meaning
`MISP_URL`	both	required	MISP base URL
`MISP_API_KEY`	local	required	your key (local/stdio mode)
`MCP_TRANSPORT`	both	`stdio`	`stdio` for local, `http` for hosted
`MCP_HOST`	hosted	`127.0.0.1`	bind address
`MCP_PORT`	hosted	`8080`	port
`MISP_VERIFY_TLS`	both	`true`	set `false` only for a self-signed lab
`MISP_MCP_SHOW_RESTRICTED`	both	`true`	`false` turns on server-side TLP hiding
`MISP_SUBMISSION_EVENT_ID`	both	required for writes	event that `misp_submit_ioc` writes to
`MISP_MCP_PROTECTED_DOMAINS`	both	empty	your own domains that can never be submitted
`MISP_MCP_SUBMIT_RATE`	both	`20`	max submissions per key per minute
`MISP_MCP_KEYID_SECRET`	both	random	HMAC secret for the internal key-id (rate-limit/log). Set it to keep ids stable across restarts/replicas; unset uses a per-process random secret
`MISP_MCP_TLS_CERT` / `MISP_MCP_TLS_KEY`	hosted	none	serve HTTPS directly
`MISP_MCP_ALLOW_INSECURE_BIND`	hosted	`false`	allow a public plain-HTTP bind (TLS on a proxy)
`TI_LOOKUP_URL`	both	unset	optional enrichment endpoint (enables `misp_enrich_ioc`)
`TI_LOOKUP_TIMEOUT`	both	`30`	seconds to wait on the enrichment endpoint (floor 5)

python3 -m venv .venv
.venv/bin/pip install -e '.[dev]'
.venv/bin/python -m pytest tests/ -q            # full suite, fully offline

misp_mcp/
  server.py      the tools and the MCP server
  client.py      talks to the MISP REST API (read + write)
  config.py      reads settings from the environment
  http_app.py    hosted mode: header auth + web server
  context.py     carries your identity through one request
  validators.py  cleans, checks, and safelists indicators

Dependencies are pinned in pyproject.toml: mcp, httpx, pydantic, uvicorn, starlette. Licensed under Apache-2.0 (LICENSE). Contributions welcome - see CONTRIBUTING.md.

Available Tools

10 tools

misp_correlate_iocA

Read-onlyIdempotent

List other indicators that appear in the same MISP event(s) as the given IOC - useful for pivoting from one indicator to related infrastructure (an event's other IPs, domains, hashes).

Returns JSON: {"ioc": str, "events_checked": int, "related": [{"event_id", "event_info", "attribute_type", "value"}]}. Attributes from TLP:AMBER/RED events are skipped entirely unless the operator has opted in to restricted content.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior5/5

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

Annotations indicate readOnly, idempotent, non-destructive. Description adds critical behavioral info: 'Attributes from TLP:AMBER/RED events are skipped entirely unless the operator has opted in to restricted content.' This goes beyond annotations, fully disclosing limitations.

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: first states function and use case, second summarizes output and security handling. Every word serves a purpose. 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?

Description covers purpose, output format, and security constraints. Given output schema existence and simple parameter set, it is adequately complete. Could mention error scenarios or pagination but not critical.

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?

Input schema already describes both parameters (ioc and limit) with good detail, including acceptable formats and constraints. The description adds no additional parameter semantics beyond what the schema provides, so baseline 3 is appropriate.

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?

Description clearly states it lists other indicators in the same MISP event as a given IOC, with explicit examples (IPs, domains, hashes). It distinguishes from sibling tools like misp_lookup_ioc by focusing on co-occurrence rather than existence check.

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?

Description explains it is 'useful for pivoting from one indicator to related infrastructure', providing clear usage context. However, it does not explicitly state when not to use it or compare to alternatives like misp_lookup_ioc, which could be improved.

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

misp_feed_statsA

Read-onlyIdempotent

Summarize the instance's threat feeds.

Returns JSON: {"total": int, "enabled": int, "enabled_feeds": [{"id", "name", "provider"}]}.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already establish readOnly and non-destructive behavior. The description adds value by detailing the exact JSON output format, including the enabled_feeds array with id, name, and provider fields, which annotations do not cover.

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 extremely concise at two sentences: one for purpose, one for output format. No extraneous words, and every sentence earns its place.

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 simple nature of the tool (no parameters, clear output schema in description), it is nearly complete. Minor gap: no mention of edge cases like zero feeds, but that is acceptable for a straightforward read-only tool.

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?

With zero parameters and 100% schema coverage, the description correctly omits parameter details. It effectively communicates the tool's stateless, input-free nature, meriting a score above baseline.

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 'Summarize the instance's threat feeds', using a specific verb and resource. The explicit listing of the JSON output structure differentiates it from sibling tools like misp_instance_status, which likely returns overall instance health.

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?

No explicit when-to-use or when-not-to-use guidance is provided. However, the zero parameters and clear purpose implicitly indicate it's for retrieving aggregate feed statistics. Could mention it's not for individual feed details.

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

misp_get_eventA

Read-onlyIdempotent

Fetch one MISP event by numeric ID: metadata, tags, and its attributes (up to max_attributes).

Returns JSON: {"id", "info", "date", "threat_level", "analysis", "creator_org", "tags": [str], "attribute_count": int, "attributes": [{"type", "value", "category", "to_ids"}]}. If the event is TLP:AMBER/RED (or its tags cannot be read) and the operator has not opted in, only {"id", "restricted": true, "note"} is returned.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior5/5

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

Discloses restricted response for TLP:AMBER/RED events, return structure, and attribute limit. Adds value beyond readOnlyHint and idempotentHint annotations.

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?

Concise at ~100 words, front-loaded with purpose, structured with return format and restriction note. 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?

Covers return structure and special case; output schema details provided. Lacks error case handling (e.g., event not found) but annotations cover safety and idempotency.

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 0% per context, so description should compensate. It mentions numeric ID and max_attributes but not format details (schema has them). Adds some context but limited.

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?

Description clearly states 'Fetch one MISP event by numeric ID', listing returned elements. It distinguishes from sibling tools like misp_search_events which retrieves multiple events, and others for IOC lookup.

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?

Describes when to use (fetch by ID) but does not explicitly contrast with siblings like misp_search_events for bulk searching. No guidance on 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_instance_statusA

Read-onlyIdempotent

Check that MISP is reachable with the configured key and report both the MISP version and this server's version - a connectivity/auth smoke test to run first when other tools fail.

Returns JSON: {"reachable": bool, "misp_version": str, "server_version": str} or an error string explaining what to fix (key, network/VPN).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description goes beyond by detailing the return structure (JSON with reachable, misp_version, server_version) and error handling (returns an error string explaining what to fix), which is valuable context not in the annotations.

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 well-structured sentences: first states the primary purpose and usage context, second details the return format. Every sentence adds value without 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 zero-parameter, read-only tool with full annotations and an output schema, the description is complete. It covers purpose, usage context, return format, and error scenarios, leaving no ambiguity for an AI agent.

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, so the description naturally has no parameter details. With 100% schema coverage (no params), a baseline of 4 is appropriate since no additional param meaning 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 specifies that the tool checks MISP reachability, validates the configured API key, and reports versions. It explicitly labels itself as a 'connectivity/auth smoke test,' distinguishing it from sibling tools like misp_lookup_ioc or misp_submit_ioc.

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 states 'to run first when other tools fail,' providing explicit usage guidance. It implies this is the initial diagnostic tool, and its simple scope teaches an agent when not to use it (e.g., for specific data operations handled by siblings).

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

misp_lookup_iocA

Read-onlyIdempotent

Search MISP for sightings of an indicator (IP, domain, URL, or file hash).

Returns JSON: {"ioc", "ioc_type", "total_hits", "summary": {"seen_in_misp", "event_count", "detection_flagged", "max_threat_level", "restricted_hits"}, "hits": [{"event_id", "event_info", "threat_level", "source_org", "attribute_type", "value", "category", "to_ids", "restricted", and when present "comment"/"first_seen"/"last_seen"}]}. Hits from TLP:AMBER/RED events are redacted to {"event_id", "restricted": true, "note"} unless the operator has opted in. The summary is a quick verdict; "seen_in_misp": false means the indicator is not in this instance - not that it is safe.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable context: redacted hits for TLP:AMBER/RED events, the structure of the summary verdict, and the caveat that 'seen_in_misp: false' does not imply safety. This exceeds what annotations alone provide.

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

Conciseness4/5

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

The description is two sentences long. The first efficiently states the purpose. The second is lengthy but necessary to describe the output structure and key behaviors. No wasted words, though the second sentence could be slightly more concise.

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 tool's moderate complexity (IOC lookup with redacted hits and summary verdict) and the presence of an output schema, the description covers essential behavioral aspects including redaction policy and verdict interpretation. Sibling tools exist, but the description adequately distinguishes this tool's role.

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?

Despite context signals reporting 0% schema description coverage, the provided input schema includes descriptions for both parameters ('ioc' and 'limit'). The tool description does not repeat parameter details, but the schema already provides adequate semantic meaning, so a baseline score of 3 is appropriate.

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 for sightings of an indicator (IP, domain, URL, or file hash). It uses a specific verb ('Search') and resource ('MISP') and distinguishes from siblings like misp_lookup_iocs (plural) and misp_correlate_ioc.

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?

The description does not provide explicit guidance on when to use this tool versus alternatives like misp_correlate_ioc or misp_submit_ioc. It mentions that 'seen_in_misp: false' does not mean the indicator is safe, but no when-to-use or when-not-to-use criteria are given.

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

misp_lookup_iocsA

Read-onlyIdempotent

Triage several indicators at once, returning a compact per-IOC summary (not full hit detail — call misp_lookup_ioc for that).

Returns JSON: {"results": [{"ioc", "ioc_type", "total_hits", "has_restricted_hits", "top_event_ids": [str]}]}. Invalid indicators are reported inline as {"ioc", "error"} rather than failing the whole batch. "total_hits": 0 means not present in MISP, not that it is safe.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior5/5

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

The description adds significant detail beyond annotations: it explains the batch behavior, return format, error handling for invalid indicators, and clarifies that total_hits=0 does not imply safety. This fully discloses behavioral traits.

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 and well-structured, front-loading the purpose and using bullet points for the response format. Every sentence adds value without 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?

Given the tool's batch nature and presence of output schema, the description covers all essential aspects: response format, error handling, and interpretation of results. It is complete for effective use.

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 input schema already contains detailed descriptions for both parameters (iocs and limit_per_ioc). The tool description adds no additional parameter-specific information, maintaining baseline adequacy.

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 triages multiple indicators at once and returns a compact per-IOC summary, distinguishing it from the sibling misp_lookup_ioc which provides full hit detail.

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 explicitly recommends using this tool instead of many single lookups when triaging an IOC list. It also contrasts with misp_lookup_ioc for full detail, providing clear usage context.

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

misp_review_submissionsA

Read-onlyIdempotent

Audit recent additions to the submissions event: what indicators were added, by whom, when, and which are detection-flagged (to_ids=true). Use it to spot bad or unwanted IOCs and who submitted them.

submitted_by/reporter/justification are parsed from the attribute comment that misp_submit_ioc writes; submitted_by is the MISP-verified key owner. Attributes added directly in the MISP UI (not via this server) will have those fields empty — check the MISP UI for their real author.

Returns JSON: {"event_id", "window_days", "total", "detection_flagged", "by_submitter": {email: count}, "submissions": [{"attribute_id", "value", "type", "category", "to_ids", "added", "submitted_by", "reporter_claimed", "justification"}]}, newest first.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds significant behavioral detail: how submitted_by/reporter/justification are parsed from comments, that attributes added via MISP UI will have empty fields, and the exact structure of the JSON return. No contradictions with annotations.

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?

Description is brief yet comprehensive: first sentence states purpose and use case, second paragraph explains parsing behavior and caveat about UI-added attributes, third paragraph shows return JSON format. No redundant sentences; information is front-loaded and well-organized.

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 the tool's complexity (multiple optional filters, special parsing, output schema exists), the description covers all relevant aspects: purpose, usage guidance, behavioral quirks, return format, and parameter semantics indirectly. It leaves no critical gaps for an AI agent to understand how to invoke the tool correctly.

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?

Each parameter in the input schema has its own description (e.g., days, limit, event_id, only_to_ids, submitted_by), so schema coverage for parameters is high. The description adds no new information about parameters beyond what the schema provides, making the added value minimal. Baseline 3 is appropriate.

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?

Description explicitly states the tool audits recent additions to the submissions event, lists what it reveals (indicators, who, when, detection flags), and distinguishes it clearly from sibling tools like misp_submit_ioc (submission) and misp_search_events (general search). Purpose is specific and unambiguous.

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?

Description advises using it 'to spot bad or unwanted IOCs and who submitted them,' which provides a clear use case. It also explains limitations (UI-added attributes lack fields) but does not explicitly mention when not to use it or suggest alternatives. However, the context of siblings makes this implicit.

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

misp_search_eventsA

Read-onlyIdempotent

Search MISP event metadata by title keyword, tag, and/or date range. At least one filter must be provided (unfiltered listing is refused to keep responses bounded and avoid dumping the event index).

Returns JSON: {"total": int, "events": [{"id", "info", "date", "attribute_count", "restricted"}]}. Restricted (TLP:AMBER/RED) events appear as {"id", "restricted": true} only, unless opted in.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating safe, read-only behavior. The description adds value by detailing the return format (JSON with specific fields) and the handling of restricted events (only id and restricted:true unless opted in). This goes beyond annotations, but does not conflict with them.

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: three sentences covering purpose, usage constraint, and return format. It is front-loaded with the main action and avoids unnecessary details. Every sentence adds value, making it efficient for an AI agent to parse.

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 tool complexity (1 parameter with nested properties, output schema present), the description covers key aspects: filters, constraint, return structure, and restricted event handling. It does not detail pagination or attribute search scope, but those are adequate for a metadata search tool. The output schema fills any gaps.

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 provides detailed descriptions for each parameter (e.g., tag, keyword, dates), so schema description coverage is high, setting a baseline of 3. The description adds the critical constraint that at least one filter is required, which is not evident from the schema alone. This cross-parameter guidance enhances semantics.

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 'Search MISP event metadata by title keyword, tag, and/or date range', specifying the verb (search), resource (MISP event metadata), and scope. It distinguishes itself from siblings like misp_get_event (single event retrieval) by focusing on metadata search. The output format is also described, reinforcing purpose.

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 explicitly mandates 'At least one filter must be provided' and explains that unfiltered listing is refused, providing a critical constraint. However, it does not mention alternative tools for similar tasks, such as misp_get_event for retrieving a single event by ID. The guidance is clear but could be improved by referencing siblings.

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

misp_submit_iocA

Add an indicator to MISP's Community IOC Submissions event. Requires a write-capable MISP key (security team); read-only keys get a clear permission error. The IOC goes in live (no proposal).

Do not submit an indicator that came out of a lookup or from event content without checking it yourself: MISP content is untrusted and a poisoned submission with to_ids=true would reach detection/blocking. to_ids must be set explicitly. Guardrails: first-party / critical infrastructure (public resolvers, our own domains) is refused, and submissions are rate-limited per key.

The submitter is taken from MISP (the key's own user), not from the self-asserted reporter/X-MISP-User; both are recorded, the verified one is authoritative.

Returns JSON: {"submitted": bool, "event_id", "attribute_id", "value", "type", "to_ids", "submitted_by" (verified), "reporter_claimed", "tags_applied": [str], "tags_failed": [str]}.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior5/5

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

Describes live submission (no proposal), exact JSON return structure, submitter authority vs reporter field, rate limiting, and guardrails. Adds significant value beyond annotations (readOnlyHint=false, etc.) with no contradictions.

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?

Description is front-loaded with purpose, concise at ~150 words, and well-organized into prerequisites, usage warnings, behavioral notes, and return format. No redundant sentences.

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?

Covers prerequisites, security considerations, behavioral details, and output structure. With output schema present and detailed schema descriptions, the description is fully adequate for correct tool selection and invocation.

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?

Input schema already has detailed descriptions for all parameters (high coverage). The description adds minor context like 'to_ids must be set explicitly' but does not significantly enhance parameter meaning beyond the schema.

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 adds an indicator to MISP's Community IOC Submissions event. It uses specific verb 'Add' and resource 'indicator to event', distinguishing it from lookup tools like misp_lookup_ioc.

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 warns against submitting untrusted indicators from MISP, requires write-capable MISP key, notes guardrails and rate limits. Could mention alternatives like misp_lookup_ioc more directly, but provides strong contextual guidance.

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

misp_submit_iocsA

Validate and (optionally) add many indicators in one call — for adding a list from a report. Each indicator runs through the same guardrails as the single submit (validation, private/reserved rejection, protected safelist, per-key rate limit); the batch shares reporter/justification/ last_seen/tags/to_ids.

dry_run=true (default) writes nothing and returns what WOULD happen — use it to review the batch first, then re-run with dry_run=false to add.

Returns JSON: {"event_id", "dry_run", "to_ids", "submitted_by", "total", "counts": {status: n}, "results": [{"ioc", "type", "status", ...}]}, where status is would_add | added | rejected | protected | duplicate_in_batch | rate_limited | error.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

The description discloses guardrails (validation, rejection, safelist, rate limit), batch sharing of fields, and return JSON structure. Annotations provide hints, but description adds rich behavioral context without contradiction.

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 well-structured: purpose first, then details, then return format. No wasted sentences; each sentence adds value.

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?

The description covers purpose, usage, behavioral details, and return format. Despite no output schema, the JSON structure is documented. Complete for a batch submission tool.

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 description adds meaning beyond the schema by explaining batch behavior, dry_run workflow, and shared fields. Schema has some descriptions, but description integrates them into a coherent narrative. Schema coverage is high, so baseline 3, plus extra context gives 4.

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 validates and adds many indicators in one call, specifically for adding a list from a report. It distinguishes from siblings like misp_submit_ioc (single) and misp_lookup_iocs (lookup).

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 guides usage with dry_run=true for review, then dry_run=false to add. It implies when to use the batch tool vs single submit.

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

Install Server

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

TDQS

A4.3/5.0

Disambiguation5/5

Each tool targets a distinct operation: lookup single vs batch, submit single vs batch, event retrieval vs search, correlation, feed stats, status check, and audit submissions. No overlap in purpose.

Naming Consistency5/5

All tools follow a consistent `misp_<verb>_<object>` pattern in snake_case (e.g., `misp_lookup_ioc`, `misp_submit_iocs`). Singular/plural variations are appropriate for batch operations.

Tool Count5/5

10 tools cover the core MISP IOC operations (lookup, submit, correlate) plus event reading, feed stats, and status checks. The count is well-scoped for a focused threat intelligence server.

Completeness4/5

Core workflows (IOC lookup, submission, correlation, event retrieval) are covered. Minor gaps like tag management or event creation for general use are missing but not critical for the server's apparent purpose.

Maintenance

ActivityMaintained

ResponsivenessSyncing

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

Crimson Crawler
com.crimsoncrawler
Enrich, search, assess, and manage threat intelligence through 80+ typed MCP tools.
Security Search Research & Data
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
mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102
Quallaa
com.quallaa
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
AI & Machine Learning Communication
2

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
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 4 months ago (2026-04-21 00:29 UTC)
UltraProbe
Databases Security
ppcvote
A
license
A
quality
D
maintenance
MISP (Malware Information Sharing Platform) MCP server with built-in prompt injection defense via prompt-defense-audit
Updated 3 months ago (2026-05-29 18:12 UTC)
8
2
MIT

Appeared in Searches

Mantis Zugriff - Access and Login Information for Mantis Bug Tracker

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/indranilroy99/misp-mcp'

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