What can you do with this server?

This server provides an MCP interface to a MISP (Malware Information Sharing Platform) instance, enabling LLMs to perform comprehensive threat intelligence operations. Event Management * Search, retrieve, create, update, publish, tag/untag, and delete MISP events * Filter by IOC value, type, tags, date range, or organization Attribute (IOC) Management * Search IOCs across all events with filters for type, category, tags, and time range * Add single or bulk IOCs to events with type, value, category, and IDS flags * Delete attributes (soft or hard delete) Correlation & Analysis * Correlate observable values (IPs, domains, hashes, URLs) across all MISP events * Find related events through shared attributes and correlations * Check values against MISP warninglists for known benign/false positive indicators Export * Export IOCs in CSV, STIX, Suricata, Snort, text, or RPZ formats with time/tag/type filters * Export file hashes (MD5, SHA1, SHA256) for HIDS integration Tags & Taxonomy * List, search, and apply tags (TLP, MITRE ATT&CK, custom) to events and attributes * Browse available taxonomies and tag usage statistics Sightings * Report IOC sightings — confirm seen in the wild, mark as false positive, or set expiration MITRE ATT&CK & Galaxy * Search ATT&CK galaxy clusters and attach techniques to events or attributes Structured Objects * List and add structured objects (file, domain-ip, email) with grouped attributes using templates Feed Management * List, toggle, fetch, and cache threat intelligence feeds Organizational & Server Administration * List local and remote sharing partner organizations and their details * Check server status, version, permissions, and list sharing groups Information Browsing * Access supported attribute types, instance statistics, and available taxonomies Guided Workflows (Prompts) * Facilitate guided IOC investigations, incident event creation, and threat report generation

Which integrations are available for this server?

Provides tools to export threat intelligence Indicators of Compromise (IOCs) from a MISP instance in Snort format, facilitating integration with network intrusion detection and prevention systems.

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 Check if the domain malicious-site.com has any correlations or sightings" 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.

de en es ja ko ru zh

misp-mcp

by lidless-labs

Overview Schema Related Servers Score Discussions

TypeScript

Remote

misp-mcp is a Model Context Protocol server for MISP, the open-source threat-intelligence sharing platform. It lets an LLM client such as Claude run IOC lookups, manage events, discover cross-event correlations, and export indicators directly against your own MISP instance. Unlike a generic HTTP wrapper, it ships 36 purpose-built tools, MISP-aware resources and prompts, and a confirmation gate that refuses destructive writes (delete, publish, untag) unless you explicitly approve them.

What it does

misp-mcp connects an AI agent to a MISP (Malware Information Sharing Platform & Threat Intelligence Sharing) instance over MISP's REST API and exposes it as Model Context Protocol tools, resources, and prompts. Point it at your MISP server with an API key and an LLM can search threat-intelligence events, look up and add indicators of compromise (IOCs), correlate indicators across events, attach MITRE ATT&CK galaxy clusters, check warninglists for false positives, and export IOCs as Suricata, Snort, STIX, CSV, RPZ, or hash lists. Read paths are safe by default. Destructive and publishing operations (delete, publish, untag) are gated behind explicit confirmation flags so an agent cannot delete an event or publish to sharing partners without approval. Other state-changing writes, including creating events, adding IOCs, attaching galaxy clusters, and toggling feeds, execute immediately when called.

36 MCP tools covering events, attributes, correlations, tags, exports, sightings, warninglists, objects, galaxies, feeds, organisations, and server administration.
3 MCP resources for browsing attribute types, instance statistics, and available taxonomies.
3 MCP prompts for guided IOC investigation, incident event creation, and threat reporting.
Confirmation-gated destructive actions: delete, publish, and untag refuse to run without confirm: true (and confirmHard: true for permanent deletes); ordinary writes execute without confirmation.
MITRE ATT&CK integration via galaxy cluster search and attachment.
Export formats including CSV, STIX, Suricata, Snort, text, RPZ, and hash lists.
SSL flexibility for the self-signed certificates common in on-prem MISP deployments.

Related MCP server: Cyberbro MCP Server

Quickstart

No checkout required. With Node.js 20+ installed, register the published package with any MCP client. For Claude Code:

claude mcp add misp \
  --env MISP_URL=https://misp.example.com \
  --env MISP_API_KEY=your-api-key-here \
  --env MISP_VERIFY_SSL=false \
  -- npx -y misp-mcp

Add --scope user to make it available from any directory instead of only the current project.

Before wiring a client, verify that the package can reach MISP with the same environment:

MISP_URL=https://misp.example.com \
MISP_API_KEY=your-api-key-here \
MISP_VERIFY_SSL=false \
npx -p misp-mcp mispctrl status

This calls /servers/getVersion and prints the MISP version, recommended PyMISP version, TLS setting, and target URL. If this fails, fix the URL, API key, or TLS setting before debugging the MCP client.

MCP client config (copy-paste)

For Claude Desktop, Cursor, or any client that reads a JSON mcpServers block, add:

{
  "mcpServers": {
    "misp": {
      "command": "npx",
      "args": ["-y", "misp-mcp"],
      "env": {
        "MISP_URL": "https://misp.example.com",
        "MISP_API_KEY": "your-api-key-here",
        "MISP_VERIFY_SSL": "false"
      }
    }
  }
}

Claude Desktop reads this from ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows). Restart the client after editing.

Prerequisites

Node.js 20 or later.
A running MISP instance with API access.
A MISP API key (MISP UI: Administration > List Auth Keys).

Configuration

Variable	Required	Default	Description
`MISP_URL`	Yes	-	MISP instance base URL
`MISP_API_KEY`	Yes	-	API authentication key
`MISP_VERIFY_SSL`	No	`true`	Set `false` for self-signed certs
`MISP_TIMEOUT`	No	`30`	Request timeout in seconds (positive integer, 1–3600)
`MISP_ALLOW_DESTRUCTIVE`	No	`false`	Set `true` to pre-authorize destructive tools so the per-call `confirm` flag is not required. Permanent (`hard`) deletes still require `confirmHard`.

Destructive action safety

Not every write requires confirmation. Read-only tools and most state-changing writes execute immediately when called. Only destructive or publishing actions are confirmation-gated.

Execute immediately (no confirm flag):

Event writes: misp_create_event, misp_update_event
Attribute writes: misp_add_attribute, misp_add_attributes_bulk
Object writes: misp_add_object
Tag writes: misp_tag_event when adding a tag (remove is false or omitted)
Sightings: misp_add_sighting
Galaxies: misp_attach_galaxy_cluster
Feeds: misp_toggle_feed, misp_fetch_feed, misp_cache_feed

Require confirm: true (or MISP_ALLOW_DESTRUCTIVE=true):

misp_delete_event
misp_delete_attribute
misp_delete_object
misp_publish_event
misp_tag_event when remove: true

Setting MISP_ALLOW_DESTRUCTIVE=true pre-authorizes the gated actions above so the per-call confirm flag can be omitted (useful for trusted automation).

Permanent hard deletes (hard: true on misp_delete_attribute / misp_delete_object) require a second confirmation, confirmHard: true, in addition to confirm: true. The env opt-in does not bypass confirmHard.

Future destructive CLI commands use the same policy: MISP_ALLOW_DESTRUCTIVE=true plus --confirm --destructive, with --confirm-hard still required for permanent deletes.

A guarded call returns an error (isError: true) with a Refused: message and performs no MISP request.

Tools

Verified against the server source (36 tools, registered in src/tools/).

Event tools (6)

Tool	Description
`misp_search_events`	Search events by IOC value, type, tags, date range, organization
`misp_get_event`	Get full event details including attributes, objects, galaxies, related events
`misp_create_event`	Create a new event with threat level, distribution, and analysis status
`misp_update_event`	Update event metadata (info, threat level, analysis, publish state)
`misp_publish_event`	Publish an event to trigger alerts to sharing partners (requires `confirm:true`)
`misp_tag_event`	Add or remove tags (TLP, MITRE ATT&CK, custom) from an event (removal requires `confirm:true`)

Attribute tools (4)

Tool	Description
`misp_search_attributes`	Search IOCs across all events with type, category, and correlation filters
`misp_add_attribute`	Add a single IOC to an event
`misp_add_attributes_bulk`	Add multiple IOCs to an event in one operation
`misp_delete_attribute`	Soft or hard delete an attribute (requires `confirm:true`; hard delete also requires `confirmHard:true`)

Correlation & intelligence tools (3)

Tool	Description
`misp_correlate`	Find all events and attributes matching a value, with cross-event correlations
`misp_get_related_events`	Discover events related through shared IOCs
`misp_describe_types`	Get all available attribute types and category mappings

Tag & taxonomy tools (2)

Tool	Description
`misp_list_tags`	List available tags with usage statistics
`misp_search_by_tag`	Find events or attributes by tag

Export tools (2)

Tool	Description
`misp_export_iocs`	Export IOCs in CSV, STIX, Suricata, Snort, text, or RPZ format
`misp_export_hashes`	Export file hashes (MD5, SHA1, SHA256) for HIDS integration

Sighting & warninglist tools (2)

Tool	Description
`misp_add_sighting`	Report a sighting, false positive, or expiration for an IOC
`misp_check_warninglists`	Check if a value appears on known benign/false positive lists

Object tools (4)

Tool	Description
`misp_list_object_templates`	List available MISP object templates (file, domain-ip, email, etc.)
`misp_get_object_template`	Get template details with required/optional attributes
`misp_add_object`	Add a structured object (grouped attributes) to an event
`misp_delete_object`	Delete an object from an event (requires `confirm:true`; hard delete also requires `confirmHard:true`)

Galaxy tools (4)

Tool	Description
`misp_list_galaxies`	List galaxies (MITRE ATT&CK, threat actors, malware, tools, etc.)
`misp_get_galaxy`	Get galaxy details with all clusters
`misp_search_galaxy_clusters`	Search clusters by keyword (find ATT&CK techniques, threat actors)
`misp_attach_galaxy_cluster`	Attach a cluster (ATT&CK technique, etc.) to an event or attribute

Feed tools (4)

Tool	Description
`misp_list_feeds`	List configured threat intel feeds
`misp_toggle_feed`	Enable or disable a feed
`misp_fetch_feed`	Trigger a fetch/pull from a feed
`misp_cache_feed`	Cache feed data locally for correlation

Organisation tools (2)

Tool	Description
`misp_list_organisations`	List local and remote sharing partner organisations
`misp_get_organisation`	Get organisation details

Server & admin tools (3)

Tool	Description
`misp_server_status`	Get MISP version, permissions, and diagnostics
`misp_list_sharing_groups`	List sharing groups for controlled distribution
`misp_delete_event`	Delete a MISP event (requires `confirm:true`)

Resources

Resource URI	Description
`misp://types`	All supported attribute types, categories, and their mappings
`misp://statistics`	MISP instance statistics
`misp://taxonomies`	Available taxonomies (TLP, MITRE ATT&CK, etc.)

Prompts

Prompt	Description
`investigate-ioc`	Deep IOC investigation: search, correlate, check warninglists, summarize threat context
`create-incident-event`	Guided event creation from an incident description with IOC ingestion
`threat-report`	Generate a threat intelligence report from MISP data

Usage examples

Search for an IOC

"Search MISP for the IP address 203.0.113.50"

Uses misp_search_events and misp_search_attributes to find all events and attributes referencing this IP.

Investigate a suspicious domain

"Investigate suspicious-domain.example in MISP"

Triggers the investigate-ioc prompt workflow: searches for the domain, checks correlations, queries warninglists, and provides a structured threat assessment.

Create an incident event

"Create a MISP event for a phishing campaign targeting our finance team. The phishing emails came from attacker@phish.example and linked to https://harvest.phish.example/login"

Uses misp_create_event followed by misp_add_attributes_bulk to create a fully populated event.

Export Suricata rules

"Export all IOCs from the last 7 days as Suricata rules"

Uses misp_export_iocs with format "suricata" and last "7d".

Check for false positives

"Is 192.0.2.123 on any MISP warninglists?"

Uses misp_check_warninglists to verify if the value is a known benign indicator.

Find MITRE ATT&CK techniques

"Search for phishing techniques in MITRE ATT&CK"

Uses misp_search_galaxy_clusters to find relevant ATT&CK techniques, then misp_attach_galaxy_cluster to link them to events.

Add structured objects

"Add a file object to event 1 with filename encrypt.exe, SHA256 hash, and file size"

Uses misp_add_object with the "file" template to create a structured group of related attributes.

Supported attribute types

Type	Category	Example
`ip-src`	Network activity	Source IP address
`ip-dst`	Network activity	Destination IP address
`domain`	Network activity	Domain name
`hostname`	Network activity	Hostname
`url`	Network activity	Full URL
`email-src`	Payload delivery	Sender email address
`md5`	Payload delivery	MD5 file hash
`sha1`	Payload delivery	SHA1 file hash
`sha256`	Payload delivery	SHA256 file hash
`filename`	Payload delivery	File name

Use misp_describe_types for the complete list of supported types and categories.

Other clients & local development

From source

git clone https://github.com/lidless-labs/misp-mcp.git
cd misp-mcp
npm install
npm run build

Then point any client's command/args at node /absolute/path/to/misp-mcp/dist/mcp-bin.js instead of npx -y misp-mcp.

Claude Code (source checkout)

claude mcp add misp \
  --env MISP_URL=https://misp.example.com \
  --env MISP_API_KEY=your-api-key-here \
  --env MISP_VERIFY_SSL=false \
  -- node /absolute/path/to/misp-mcp/dist/mcp-bin.js

OpenClaw

openclaw mcp set misp '{
  "command": "npx",
  "args": ["-y", "misp-mcp"],
  "env": {
    "MISP_URL": "https://misp.example.com",
    "MISP_API_KEY": "your-api-key-here",
    "MISP_VERIFY_SSL": "false"
  }
}'

For a source checkout, use "command": "node" with "args": ["/absolute/path/to/misp-mcp/dist/mcp-bin.js"]. Then restart the gateway and confirm registration:

systemctl --user restart openclaw-gateway
openclaw mcp list   # confirm "misp" is registered

Codex CLI

codex mcp add misp \
  --env MISP_URL=https://misp.example.com \
  --env MISP_API_KEY=your-api-key-here \
  --env MISP_VERIFY_SSL=false \
  -- npx -y misp-mcp

Codex writes the entry to ~/.codex/config.toml under [mcp_servers.misp]. Verify with codex mcp list.

Hermes Agent

Hermes Agent reads MCP config from ~/.hermes/config.yaml under mcp_servers:

mcp_servers:
  misp:
    command: "npx"
    args: ["-y", "misp-mcp"]
    env:
      MISP_URL: "https://misp.example.com"
      MISP_API_KEY: "your-api-key-here"
      MISP_VERIFY_SSL: "false"

Then /reload-mcp inside a Hermes session.

Docker

docker build -t misp-mcp .
docker run -e MISP_URL=https://misp.example.com -e MISP_API_KEY=your-key -e MISP_VERIFY_SSL=false misp-mcp

Standalone

MISP_URL=https://misp.example.com MISP_API_KEY=your-key node dist/mcp-bin.js
MISP_URL=https://misp.example.com MISP_API_KEY=your-key node dist/cli.js status

Development

MISP_URL=https://misp.example.com MISP_API_KEY=your-key npm run dev

Testing

npm test                  # Unit tests (mocked)
npm run test:integration  # Integration tests against a live MISP instance
npm run test:watch        # Watch mode
npm run lint              # Type check

Integration tests require MISP_URL, MISP_API_KEY, and optionally MISP_VERIFY_SSL=false environment variables.

Project structure

misp-mcp/
  src/
    cli.ts                # mispctrl CLI entry point
    mcp-bin.ts            # MCP stdio entry point
    mcp-server.ts         # Shared MCP server factory
    index.ts              # Library export surface
    config.ts             # Environment config + validation
    client.ts             # MISP REST API client
    guards.ts             # Destructive-action confirmation guards
    types.ts              # MISP API type definitions
    resources.ts          # MCP resources
    prompts.ts            # MCP prompts
    tools/                # One module per tool family (events, attributes, ...)
  tests/                  # Unit + integration tests
  Dockerfile
  package.json

Contributing

Issues and pull requests are welcome. See CONTRIBUTING.md for the contribution path and SECURITY.md for how to report a vulnerability privately. By participating you agree to the Code of Conduct.

Why not the MISP web UI or raw API?

The MISP web UI and PyMISP are excellent for analysts working a console. misp-mcp is for the case where the operator is an LLM agent, not a human at a browser. It gives the model a typed, named tool for each common MISP operation, validates inputs with Zod, and shapes responses so a model can reason over them, rather than handing the model a raw REST endpoint and an OpenAPI dump. It also adds a guardrail layer the bare API does not: destructive operations fail closed unless the caller opts in, so an over-eager agent cannot publish or delete intelligence by accident. If you want a human-driven console, use the MISP UI. If you want PyMISP scripting, use PyMISP. Use misp-mcp when you want a chat or agent client to drive MISP safely.

What misp-mcp is not

Not a MISP server. It talks to an existing MISP instance over the REST API; it does not store, host, or replace MISP.
Not a general HTTP proxy. It exposes a curated set of MISP operations as MCP tools, not arbitrary passthrough to every MISP endpoint.
Not a SIEM, EDR, or alerting system. It reads and writes threat intelligence; it does not collect logs or generate alerts on its own.
Not a credential vault. It reads MISP_URL and MISP_API_KEY from the environment; manage and rotate those keys with your own secrets tooling.
Not an autonomous deleter. Destructive and publishing actions are confirmation-gated by design.

License

MIT

Available Tools

36 tools

misp_add_attributeB

Add an IOC/attribute to a MISP event

ParametersJSON Schema

Name	Required	Description
`tags`	No	Tags to apply to the attribute
`type`	Yes	Attribute type (ip-src, ip-dst, domain, md5, sha256, sha1, url, email-src, hostname, filename, etc.)
`toIds`	No	Flag for IDS export (default true for applicable types)
`value`	Yes	The IOC value
`comment`	No	Context/notes about this IOC
`eventId`	Yes	Event ID to add the attribute to
`category`	No	Category (auto-determined from type if omitted)
`distribution`	No	Distribution level (0-4)

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided. The description lacks disclosure of important behaviors such as auto-category assignment, IDS flag defaults, error handling for duplicates, or permission requirements.

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?

Single sentence, no wasted words. Could be slightly expanded with critical usage context without harming conciseness.

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?

With 8 parameters, no annotations, and no output schema, the description is too terse. It omits return value info, side effects, and error scenarios, which are essential for correct usage.

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 covers all 8 parameters with descriptions (100% coverage). The description adds no extra meaning beyond the schema, so baseline score applies.

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 action (Add) and the resource (IOC/attribute) with specific context (to a MISP event). It distinguishes this tool from siblings like misp_add_attributes_bulk and misp_add_object.

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 alternatives (e.g., misp_add_attributes_bulk for bulk addition, misp_add_object for objects). Prerequisites or conditional rules are absent.

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

misp_add_attributes_bulkB

Add multiple attributes (IOCs) to a MISP event at once

ParametersJSON Schema

Name	Required	Description	Default
`eventId`	Yes	Event ID to add attributes to
`attributes`	Yes	Array of attributes to add

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided, so the description carries full burden. It merely restates the name without disclosing behavioral traits like atomicity, error handling, idempotency, or return values.

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 a single sentence with no unnecessary words, and the key information is front-loaded. It is concise, though it could be slightly more informative without becoming verbose.

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 complexity of a bulk mutation tool and no output schema, the description lacks completeness. It does not mention prerequisites (e.g., event existence, permissions), side effects, or return values.

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 coverage is 100% with both parameters described. The description adds no additional meaning beyond the schema, which already documents the parameters adequately. 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 verb 'Add' and the resource 'multiple attributes (IOCs) to a MISP event at once', distinguishing it from the sibling 'misp_add_attribute' which adds a single attribute.

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 implies bulk usage but does not explicitly state when to use this tool over alternatives, nor does it mention any limitations or conditions (e.g., maximum batch size).

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

misp_add_objectB

Add a MISP object (structured group of attributes) to an event

ParametersJSON Schema

Name	Required	Description
`comment`	No	Object-level comment
`eventId`	Yes	Event ID to add the object to
`attributes`	Yes	Attributes to include in the object
`distribution`	No	Distribution level (0-4)
`templateName`	Yes	Object template name (e.g., file, domain-ip, email, network-connection, url)

TDQS

B3.1/5.0

Behavior2/5

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

Without annotations, the description carries the full burden. It only states the tool adds an object, implying mutation, but does not disclose behavioral traits such as side effects, required permissions, or idempotency. Minimal behavioral information.

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 a single sentence with no fluff. While concise, it lacks detail, but it earns a 4 for being appropriately sized for the minimal information it conveys.

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's complexity (5 parameters with nested arrays), the description is too brief. It does not explain object templates, validation, or what happens on success/failure. No output schema, so return behavior is missing.

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 100%, so the description does not need to add much. However, it adds no extra meaning beyond the schema descriptions. 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?

The description clearly states the tool adds a MISP object (structured group of attributes) to an event, distinguishing it from sibling tools like misp_add_attribute which adds a single attribute.

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 usage guidelines are provided. The description does not differentiate when to use this tool over alternatives like misp_add_attribute or misp_add_attributes_bulk, nor does it mention prerequisites or context.

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

misp_add_sightingB

Report a sighting of an IOC (confirms it was observed in the wild, marks as false positive, or sets expiration)

ParametersJSON Schema

Name	Required	Description
`type`	Yes	0=Sighting (seen in the wild), 1=False positive, 2=Expiration
`value`	No	Attribute value to sight (use this or attributeId)
`source`	No	Source of the sighting (e.g., organization name, sensor ID)
`timestamp`	No	Timestamp of the sighting (Unix timestamp)
`attributeId`	No	Attribute ID to sight (use this or value)

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided, so description must fully disclose behavior. It explains the three sighting types but does not mention side effects, permissions, or whether the operation is reversible.

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?

Single sentence that conveys the core action efficiently. Could be more structured but 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?

Missing details on return value, error handling, required parameters (e.g., attributeId or value), and impact of the operation. Incomplete for confident 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?

Schema coverage is 100% and each param has a description. The description adds no new parameter info beyond schema, meeting baseline but not exceeding.

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 action ('Report a sighting'), resource ('IOC'), and the three possible outcomes (observed, false positive, expiration). Distinguishes from sibling tools like misp_add_attribute.

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 explicit guidance on when to use this tool versus alternatives (e.g., misp_add_attribute). No 'when not to use' or prerequisites mentioned.

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

misp_attach_galaxy_clusterB

Attach a galaxy cluster (MITRE ATT&CK technique, threat actor, etc.) to an event or attribute

ParametersJSON Schema

Name	Required	Description
`targetId`	Yes	Event ID or attribute ID
`targetType`	Yes	Attach to an event or attribute
`galaxyClusterId`	Yes	Galaxy cluster ID to attach

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, and the description only states the basic action. It does not disclose side effects, permissions required, or any constraints (e.g., whether attachments are saved immediately, if they can be removed, or how they affect event publication).

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 a single sentence that is concise and front-loaded with the verb 'attach'. It contains no unnecessary words. However, it could be slightly improved by structuring to separate action and parameters.

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 no annotations, no output schema, and three parameters, the description is incomplete. It lacks behavioral details, usage context, and any explanation of the outcome. The agent would need additional knowledge to use the tool effectively.

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 coverage is 100%, so the schema already documents all three parameters adequately. The description adds context by mentioning examples of galaxy cluster types, but it does not provide additional semantic detail beyond what the schema offers.

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 action 'attach a galaxy cluster' with examples of what galaxy clusters are (MITRE ATT&CK technique, threat actor), and specifies the target 'to an event or attribute'. This distinguishes it from sibling tools that add attributes, tags, or objects.

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 usage guidance is provided. The description does not indicate when to use this tool versus alternatives like misp_tag_event or misp_add_attribute. There are no 'when-to-use' or 'when-not-to-use' instructions.

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

misp_cache_feedA

Cache feed data locally for correlation without creating events

ParametersJSON Schema

Name	Required	Description	Default
`feedId`	Yes	Feed ID to cache

TDQS

A3.9/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 fully disclose behavior. It reveals that caching does not create events, which is key, but omits other traits such as whether caching is idempotent, persistent, or has side effects on existing data. The description is minimal in behavioral context.

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?

A single, clear sentence that is front-loaded with the verb and purpose. No extraneous words; every part earns its place.

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 tool has only one parameter and no output schema, the description provides the core function and key behavioral trait (no event creation). However, it lacks details on cache behavior (duration, overwriting) and prerequisites. It is adequate but not enriched.

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 coverage is 100% with a single parameter (feedId) described as 'Feed ID to cache'. The description does not add any additional meaning beyond the schema, so a baseline 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 uses a specific verb ('cache') and resource ('feed data') and clearly states the purpose ('for correlation without creating events'). It effectively distinguishes from siblings like misp_fetch_feed and misp_toggle_feed by highlighting that no events are created.

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 implies when to use (for correlation without events) but does not explicitly state when not to use or mention alternatives like misp_fetch_feed. The guidance is clear but lacks explicit exclusions.

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

misp_check_warninglistsA

Check if an observable value appears on any MISP warninglists (known benign/false positive lists)

ParametersJSON Schema

Name	Required	Description	Default
`value`	Yes	Value to check against warninglists (IP, domain, hash, etc.)

TDQS

A3.5/5.0

Behavior2/5

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

No annotations exist, so description must carry the burden. It discloses the core action but does not mention output format, side effects, or whether it is a read-only operation, leaving behavioral traits unclear.

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?

Single sentence of 12 words, front-loaded with action, no wasted information.

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?

For a simple one-parameter tool with no output schema, the description is minimal but adequate. However, it lacks information about return values or expected output, which would be helpful for an agent.

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 coverage is 100% for the single parameter 'value', and the description adds no extra meaning beyond the schema's own description. Baseline 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?

Description clearly states the action 'Check if an observable value appears on any MISP warninglists', using a specific verb and resource. It distinguishes itself from sibling tools that add, delete, or search events/attributes, as no other sibling checks warninglists.

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?

Usage is implied (when you have an observable and want to check against known benign lists), but no explicit guidance on when to use vs alternatives or exclusions is provided.

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

misp_correlateB

Find correlations for a specific observable value across all MISP events

ParametersJSON Schema

Name	Required	Description	Default
`value`	Yes	Observable value to correlate (IP, domain, hash, etc.)

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It does not state read-only status, potential latency, response size, or error handling, leaving significant behavioral traits unspecified.

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?

A single, front-loaded sentence with no unnecessary words. Every part contributes to understanding the tool's core function.

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?

The description is minimal but adequate given the tool's simplicity (one parameter). However, it lacks information about the output format or return structure, which would be helpful for an agent.

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

Parameters2/5

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

Schema coverage is 100% and already includes a clear description for the 'value' parameter. The tool description adds no extra meaning beyond restating the parameter's role, making it redundant.

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 uses a specific verb 'Find correlations' and identifies the resource 'observable value across all MISP events', clearly distinguishing it from sibling tools like misp_search_events or misp_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 implies usage for correlation searches but provides no explicit guidance on when to use this tool versus alternatives (e.g., misp_search_attributes), nor any conditions where it should not be used.

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

misp_create_eventA

Create a new MISP event for documenting incidents or threat intelligence. Does not publish - use misp_publish_event separately.

ParametersJSON Schema

Name	Required	Description
`date`	No	Event date (YYYY-MM-DD)
`info`	Yes	Event description/title
`tags`	No	Tags to apply
`analysis`	Yes	0=Initial, 1=Ongoing, 2=Complete
`threatLevel`	Yes	1=High, 2=Medium, 3=Low, 4=Undefined
`distribution`	Yes	0=Organization only, 1=Community, 2=Connected communities, 3=All communities, 4=Sharing group

TDQS

A4/5.0

Behavior3/5

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

No annotations provided. Description notes it does not publish but does not disclose other behaviors like whether the event is created in draft mode, permission requirements, or side effects. More detail expected given no 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 concise sentences with no redundancy. Critical information is front-loaded efficiently.

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?

Adequately covers purpose and key behavior (no publish). Missing explanation of return value or output format, which would be helpful since no output schema is provided.

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 100%, so baseline is 3. The description repeats the schema's parameter details without adding new meaning or usage context.

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 the tool's purpose: 'Create a new MISP event for documenting incidents or threat intelligence.' Distinguishes from sibling by noting it does not publish, guiding to misp_publish_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?

Explicitly directs to use misp_publish_event separately for publishing. Lacks broader context on when to use this versus other creation tools like misp_add_attribute, but provides clear immediate guidance.

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

misp_delete_attributeB

Delete (soft or hard) an attribute from MISP. Destructive: requires confirm:true (or MISP_ALLOW_DESTRUCTIVE=true); hard delete also requires confirmHard:true.

ParametersJSON Schema

Name	Required	Description
`hard`	No	Hard delete (permanent) instead of soft delete
`confirm`	No	Must be true to perform this destructive deletion (unless MISP_ALLOW_DESTRUCTIVE=true)
`attributeId`	Yes	Attribute ID to delete
`confirmHard`	No	Must be true (in addition to confirm) to perform a permanent hard delete

TDQS

B3.4/5.0

Behavior3/5

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

Discloses destructive nature and requirements for confirm and confirmHard. However, without annotations, it fails to describe side effects, soft delete recoverability, or permission needs beyond flags.

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?

Single sentence with essential info, front-loaded. Could be slightly clearer but efficiently conveys purpose and key constraints.

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?

Adequate for a delete operation with 4 params and no output schema. Lacks return value description, error handling, and deeper behavioral details.

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 coverage is 100%, so baseline is 3. The description adds minimal extra value over the schema's parameter descriptions; it reiterates confirm and confirmHard requirements.

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 deletes an attribute from MISP, specifying soft or hard deletion. This differentiates it from siblings like misp_delete_event and misp_delete_object.

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 alternatives like misp_delete_object or misp_delete_event. Lacks context for soft vs hard delete selection or prerequisites.

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

misp_delete_eventA

Delete a MISP event (requires appropriate permissions). Destructive: requires confirm:true (or MISP_ALLOW_DESTRUCTIVE=true).

ParametersJSON Schema

Name	Required	Description	Default
`confirm`	No	Must be true to perform this destructive deletion (unless MISP_ALLOW_DESTRUCTIVE=true)
`eventId`	Yes	Event ID to delete

TDQS

A4.2/5.0

Behavior4/5

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

Given no annotations, the description carries the full burden. It discloses destructive behavior and the need for confirmation (confirm:true). It does not detail cascading effects on attributes or objects, nor specific permissions, but covers key safety 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?

Two concise sentences. No extraneous information. Front-loaded with purpose and permissions.

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 2-parameter delete tool with no output schema, the description is mostly complete. It covers purpose, permissions, and confirmation. Lacks details on return values, error cases, or cascading effects, but these are minor 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 coverage is 100%, so the description adds marginal value beyond the schema. It reiterates that confirm must be true for deletion, which is already in the schema description. No additional parameter 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 deletes a MISP event, distinguishing it from sibling tools like misp_delete_attribute and misp_delete_object. The verb 'delete' and resource 'event' are specific.

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 implies when to use this tool (to delete a MISP event) by naming the resource. It does not explicitly exclude other tools, but the context of sibling tools makes it clear. It mentions permission requirements but no direct alternatives.

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

misp_delete_objectA

Delete a MISP object from an event. Destructive: requires confirm:true (or MISP_ALLOW_DESTRUCTIVE=true); hard delete also requires confirmHard:true.

ParametersJSON Schema

Name	Required	Description
`hard`	No	Hard delete (permanent) instead of soft delete
`confirm`	No	Must be true to perform this destructive deletion (unless MISP_ALLOW_DESTRUCTIVE=true)
`objectId`	Yes	Object ID to delete
`confirmHard`	No	Must be true (in addition to confirm) to perform a permanent hard delete

TDQS

A4.3/5.0

Behavior4/5

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

No annotations are provided, so the description must convey behavioral traits. It clearly labels the action as 'Destructive' and explains the confirmation requirements (confirm:true for deletion, confirmHard:true for hard delete). This provides essential safety context.

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 (two sentences) yet packs all essential information. The first sentence states the action, and the second provides the key constraints. 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?

Given the tool's simplicity and the absence of an output schema, the description covers the main behavioral aspects: deletion confirmation and hard delete. However, it does not mention return values, side effects (e.g., cascading deletions), or prerequisites (e.g., the event must exist). Minor gaps exist.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds crucial meaning: it explains that 'confirm' is required for any destructive deletion and that 'confirmHard' is an additional requirement for permanent deletion. It also mentions the MISP_ALLOW_DESTRUCTIVE environment variable, which overrides the confirm 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 specifies 'Delete a MISP object from an event', which is a specific verb+resource. It clearly distinguishes from sibling tools like misp_delete_attribute (deletes an attribute) and misp_delete_event (deletes an entire event).

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 (e.g., misp_delete_attribute for attributes). It only provides implicit guidance through the name and the confirmation requirements. A clear comparison or exclusion would improve it.

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

misp_describe_typesA

Get all available MISP attribute types and categories with their mappings

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior2/5

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

No annotations are present, so the description must cover behavioral traits. It only states the basic function without disclosing authentication requirements, rate limits, or response format details.

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 a single, concise sentence that efficiently conveys the tool's purpose with no extraneous 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?

For a tool with no parameters and a straightforward listing purpose, the description is sufficiently complete. It does not need to explain return values as there is no output schema.

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, and the schema covers 100% of them (none). The description adds no param-specific info, which is acceptable per baseline for 0 parameters.

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 verb 'Get' and resource 'all available MISP attribute types and categories with their mappings', making it distinct from sibling tools like misp_get_event or misp_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?

No explicit when-to-use or when-not-to-use guidance is provided. The usage is implied as a prerequisite for adding attributes, but alternatives are not discussed.

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

misp_export_hashesA

Export file hashes from MISP for HIDS integration

ParametersJSON Schema

Name	Required	Description
`last`	No	Relative time filter (e.g., 1d, 7d)
`tags`	No	Filter by tags
`format`	Yes	Hash format to export

TDQS

A3.7/5.0

Behavior3/5

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

Without annotations, the description indicates a read-only export operation, but does not disclose rate limits, authentication requirements, or output format, leaving the agent with limited behavioral context.

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 a single concise sentence with no wasted words, front-loading the action and purpose effectively.

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?

For a tool with 3 parameters, no output schema, and no annotations, the description covers the basic purpose but lacks details on return format, constraints, or edge cases, making it merely adequate.

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 coverage is 100%, and the description does not add any additional meaning beyond what the schema already provides for each parameter, so it meets the 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 the verb 'export' and resource 'file hashes from MISP' with a specific purpose 'for HIDS integration', distinguishing it from sibling tools like misp_export_iocs which export broader IOCs.

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 provides some context (HIDS integration) but lacks explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or 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_export_iocsB

Export IOCs from MISP in various formats (CSV, STIX, Suricata, Snort, text, RPZ)

ParametersJSON Schema

Name	Required	Description
`last`	No	Relative time filter (e.g., 1d, 7d)
`tags`	No	Filter by tags
`type`	No	Filter by attribute type
`format`	Yes	Export format
`eventId`	No	Specific event ID (or all events if omitted)

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but only states the action is 'export', implying read-only. It does not disclose potential side effects, authentication needs, rate limits, or other behavioral traits beyond the obvious.

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 a single, direct sentence of 13 words, front-loaded with the verb and resource. It efficiently lists formats without extra words, earning its place.

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 tool has 5 parameters and no output schema, the description covers the core purpose and formats but lacks details on return format, filtering behavior, or edge cases. It is adequate but not comprehensive.

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 100%, so the input schema already explains parameters. The description adds no new information about parameter usage or interaction; it merely restates the format options. Baseline of 3 applies.

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 verb 'Export' and the resource 'IOCs from MISP', and lists supported formats, distinguishing it from sibling tools like misp_export_hashes. This provides a specific and unambiguous purpose.

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 is provided on when to use this tool versus alternatives. The description does not mention scenarios, prerequisites, or exclusions, leaving the agent to infer usage from context.

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

misp_fetch_feedB

Trigger a fetch/pull of data from a specific MISP feed

ParametersJSON Schema

Name	Required	Description	Default
`feedId`	Yes	Feed ID to fetch

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description carries full burden, but only states 'trigger a fetch' without disclosing whether it's asynchronous, idempotent, or requires permissions.

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?

Single sentence with no wasted words, perfectly concise for the purpose.

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?

Minimally adequate for a simple trigger tool, but lacks mention of asynchronous behavior or return value; with no output schema, more context would help.

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 coverage is 100%, and the description adds no meaning beyond the schema's 'Feed ID to fetch'; 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?

The description clearly states the verb 'trigger a fetch/pull' and the resource 'data from a specific MISP feed', distinguishing it from siblings like misp_cache_feed and misp_toggle_feed.

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 alternatives, no prerequisites, and no mention of 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_get_eventA

Get full details of a specific MISP event including all attributes, objects, tags, and related events

ParametersJSON Schema

Name	Required	Description	Default
`eventId`	Yes	Event ID to retrieve

TDQS

A4.1/5.0

Behavior4/5

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

In the absence of annotations, the description discloses the return scope (full event details), which is adequate for a read-only operation. It does not explicitly state it is read-only, but the GET nature is clear.

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 one concise sentence (16 words) that is front-loaded with the core action, containing no extraneous information.

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 simple retrieval tool with one parameter and no output schema, the description sufficiently captures what the tool does and what it returns, meeting the needs of an agent.

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 has 100% coverage for the single parameter 'eventId' with description 'Event ID to retrieve'. The description adds no extra meaning beyond the schema, so baseline score applies.

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 verb 'Get', the resource 'MISP event', and the scope 'full details including all attributes, objects, tags, and related events', which distinguishes it from sibling tools like misp_search_events or misp_create_event.

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 guidance on when to use this tool versus alternatives is provided; the usage is implied by the function of retrieving a specific event by ID, but no when-not-to-use or alternative suggestions are given.

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

misp_get_galaxyA

Get a specific galaxy with its clusters (e.g., MITRE ATT&CK techniques, threat actor profiles)

ParametersJSON Schema

Name	Required	Description	Default
`galaxyId`	Yes	Galaxy ID to retrieve

TDQS

A3.8/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It discloses the action and result (galaxy with clusters) but lacks details on permissions, side effects, or 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?

Single sentence with no wasted words. Information is front-loaded and 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 simple get tool with one parameter, the description adequately explains that the response includes the galaxy and its clusters. No output schema, but this covers the essential return value.

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 coverage is 100% with a clear description for the only parameter (galaxyId). Description adds no additional semantic value 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?

Clearly states 'Get a specific galaxy with its clusters' with examples (MITRE ATT&CK techniques, threat actor profiles). Distinguishes from siblings like misp_list_galaxies and misp_search_galaxy_clusters.

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?

Implies usage for retrieving a specific galaxy by ID but does not explicitly mention when to use vs. alternatives or exclude other tools.

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

misp_get_object_templateA

Get details of a specific MISP object template including required and optional attributes

ParametersJSON Schema

Name	Required	Description	Default
`templateId`	Yes	Object template ID 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 must disclose behavior. It correctly indicates a read operation, but does not mention possible errors (e.g., invalid templateId), authentication requirements, or response specifics. It is adequate but lacks depth.

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 a single, well-formed sentence that efficiently conveys the tool's purpose without extraneous 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?

For a simple retrieval tool with one parameter and no output schema, the description is mostly complete, noting that it returns required and optional attributes. However, it omits details on error handling or the full response structure, which would enhance completeness.

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 100%, so baseline is 3. The description adds no additional meaning beyond what the schema already provides for 'templateId' (description: 'Object template ID or UUID').

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 verb 'Get details' and the resource 'MISP object template', and specifies the scope ('including required and optional attributes'), which distinguishes it from sibling tools like misp_list_object_templates.

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 implies use for retrieving details of a specific template, but does not provide explicit guidance on when to use versus alternatives (e.g., listing templates first to find the ID) or exclude scenarios. No prerequisites or conditions are mentioned.

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

misp_get_organisationB

Get details of a specific MISP organisation

ParametersJSON Schema

Name	Required	Description	Default
`orgId`	Yes	Organisation ID

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, and the description only states 'Get details' without disclosing any behavioral traits such as authentication needs, error handling, or response format. The description carries the full burden but fails to provide sufficient transparency.

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 a single, concise sentence that efficiently states the purpose without unnecessary words. It is appropriately front-loaded.

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 simplicity of the tool (one required param, no output schema), the description is minimally complete. However, it lacks behavioral context and could mention return format or error cases.

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 100% with a single parameter described as 'Organisation ID'. The description adds no additional meaning beyond the schema, 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?

The description clearly states the verb 'Get' and the resource 'details of a specific MISP organisation', distinguishing it from sibling tools like misp_list_organisations which lists all organisations.

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 implies usage when details of a specific organisation are needed, but provides no explicit guidance on when to use or not use, nor mentions alternatives.

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

misp_get_related_eventsB

Get events related to a specific event through shared attributes and correlations

ParametersJSON Schema

Name	Required	Description
`eventId`	Yes	Event ID to find related events for
`maxAttributes`	No	Max number of to_ids attributes to correlate across (default 20). Higher values hit the MISP API more.
`perAttributeLimit`	No	Max matches to fetch per attribute value (default 100).

TDQS

B3.4/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 the full burden of behavioral disclosure. It only mentions 'shared attributes and correlations' but does not state if the operation is read-only, requires specific permissions, or has any side effects. For a tool with zero annotation coverage, this is insufficient.

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 a single sentence that is front-loaded with the essential information. No wasted words. Every part contributes to understanding the tool's purpose.

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?

The tool has 3 parameters and no output schema. The description does not explain the return value (likely a list of related events) or any limitations. Given the complexity and lack of annotations, the description leaves gaps in understanding what to expect from the tool.

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 100%, so baseline is 3. The description adds the context of 'through shared attributes and correlations' but does not add meaning beyond what the schema already provides for each parameter. The parameter descriptions in the schema are clear and complete.

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 action ('Get'), the resource ('events related to a specific event'), and the mechanism ('through shared attributes and correlations'). It distinguishes from sibling tools like misp_get_event (single event) and misp_search_events (search by criteria). The verb and resource are specific.

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 implies when to use (finding related events) but provides no explicit guidance on when not to use or alternatives. Among siblings, there are other correlation/search tools, but no differentiation is made. The context is clear but exclusions are missing.

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

misp_list_feedsB

List configured MISP feeds (threat intel sources, IOC feeds, etc.)

ParametersJSON Schema

Name	Required	Description	Default
`enabled`	No	Filter by enabled/disabled status

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It only states 'List' without disclosing behavioral traits (e.g., pagination, performance, side effects). Minimal disclosure for a read operation.

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?

Single sentence, front-loaded with verb and resource, no unnecessary words. Efficient and clear.

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 low complexity (one optional parameter, no output schema), the description is adequate but could mention that filtering is optional or what the output typically is. Lacks context about usage among sibling feed tools.

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 100%: the only parameter 'enabled' is documented in schema. Description adds no extra meaning beyond restating the resource; 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?

Clear verb+resource: 'List configured MISP feeds' with parenthetical clarification. Distinguishes from sibling tools like misp_fetch_feed and misp_toggle_feed.

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 vs alternatives like misp_fetch_feed, misp_cache_feed, or misp_toggle_feed. No exclusions or prerequisites mentioned.

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 available MISP galaxies (MITRE ATT&CK, threat actors, malware families, tools, etc.)

ParametersJSON Schema

Name	Required	Description	Default
`search`	No	Filter galaxies by name or type
`namespace`	No	Filter by namespace (e.g., mitre-attack-pattern, mitre-intrusion-set, mitre-malware)

TDQS

A3.6/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 fully disclose behavior. It only states the action (list) without any details on authentication requirements, pagination, access control, or return format. For a simple read operation, the description lacks transparency about potential limitations or 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?

The description is a single, well-structured sentence that immediately conveys the core functionality. No superfluous words or redundant information.

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 simplicity (list operation with two optional parameters and no output schema), the description is nearly complete. It could improve by briefly mentioning what the output contains (e.g., list of galaxy names) or any access limitations, but is adequate for an agent to use 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?

Schema description coverage is 100%, and the input schema already clearly defines both parameters (search, namespace) with descriptions. The tool description adds no additional meaning or context beyond what the schema provides. 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?

The description clearly states the verb 'list' and the resource 'MISP galaxies' with specific examples like MITRE ATT&CK, threat actors, malware families, tools. It distinguishes from sibling tools like misp_get_galaxy (retrieves a specific galaxy) and misp_search_galaxy_clusters (searches clusters within a galaxy).

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. While the purpose implies usage for listing available galaxies, there is no comparison to similar tools like misp_get_galaxy or misp_search_galaxy_clusters. The description leaves the agent to infer usage context.

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

misp_list_object_templatesB

List available MISP object templates (file, domain-ip, email, network-connection, etc.)

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max results (default 50)
`search`	No	Filter templates by name

TDQS

B3.2/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 whether the operation is read-only, pagination limits, or any side effects. The basic listing nature is implied but not explicit.

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 a single concise sentence with no wasted words. It is front-loaded with the core action and includes examples efficiently.

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 simple list tool with two parameters and no output schema, the description covers the essential purpose. However, it lacks usage and behavioral context, which keeps it from a 5.

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 100%, so the parameters are already documented. The description adds the context of template examples but does not enhance parameter meaning beyond the schema. Baseline 3 applies.

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

Purpose4/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 object templates and provides concrete examples (file, domain-ip, etc.). While it does not explicitly differentiate from siblings, the examples implicitly distinguish it from tools like misp_get_object_template.

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 is given on when to use this tool versus alternatives. The description does not mention when to prefer it over other list tools or how it relates to object template usage.

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

misp_list_organisationsB

List MISP organisations (local and remote sharing partners)

ParametersJSON Schema

Name	Required	Description	Default
`scope`	No	Filter by local, external, or all organisations

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It does not disclose if the operation is read-only, any authentication requirements, pagination, or what happens if no organisations exist. The description is minimal.

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?

One sentence, six words, front-loaded with the verb. No unnecessary information. Perfectly concise.

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 simple tool (one optional parameter, no output schema), the description provides basic information but lacks any context about output format, filter behavior, or typical use cases. It is minimally adequate but could be improved.

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 coverage is 100% with a well-described enum parameter. The description adds no additional meaning beyond the schema—'local and remote sharing partners' partially mirrors the enum values but does not explain the 'all' option. Baseline 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 action ('List') and the resource ('MISP organisations'), and specifies 'local and remote sharing partners' which distinguishes it from sibling tools like misp_get_organisation (singular) and other list tools for different entities.

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 alternatives like misp_get_organisation. No explanation of the scope parameter options or when to choose each. The description provides no context for appropriate usage.

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

misp_list_sharing_groupsA

List MISP sharing groups for controlled event distribution

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, and the description only says 'list', implying a read-only operation. It does not disclose any behavioral details such as pagination, sorting, or authentication requirements.

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 a single sentence that is front-loaded and efficient. Every word adds value without repetition.

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?

For a simple list tool with no parameters and no output schema, the description is adequate but lacks any detail about return format or ordering. It meets the minimum viable 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 no parameters, so schema description coverage is 100%. With zero parameters, the description cannot add param meaning, but baseline is 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 lists MISP sharing groups, specifying 'for controlled event distribution' which gives context. It distinguishes from sibling tools that deal with events, attributes, feeds, etc.

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 vs alternatives like misp_list_feeds or misp_list_organisations. The description does not provide context for selecting this tool over others.

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

misp_list_tagsB

List available MISP tags with usage statistics

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max results to return
`search`	No	Search filter for tag names

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, and the description lacks behavioral information such as read-only nature, authentication requirements, or rate limits. For a list operation, the read-only trait is implied but not explicitly stated.

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 a single concise sentence that is front-loaded with the core purpose. It contains no unnecessary words, but it could include a bit more context without being verbose.

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 tool's simplicity and the schema coverage, the description is adequate but not complete. It does not explain the format of usage statistics or whether pagination is supported, leaving some ambiguity.

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 100%, so the schema already documents both parameters adequately. The description adds no additional meaning beyond the schema, resulting in a baseline score of 3.

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 action (list) and resource (MISP tags) with an additional detail (usage statistics). It distinguishes from sibling tools, which focus on adding, deleting, or searching events/attributes, not listing tags.

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 any guidance on when to use this tool versus alternatives. No context about use cases or prerequisites is given, leaving the agent to infer usage.

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

misp_publish_eventA

Publish a MISP event, triggering alerts and notifications to sharing partners. State-changing: requires confirm:true (or MISP_ALLOW_DESTRUCTIVE=true).

ParametersJSON Schema

Name	Required	Description	Default
`confirm`	No	Must be true to publish (triggers alerts to sharing partners) unless MISP_ALLOW_DESTRUCTIVE=true
`eventId`	Yes	Event ID to publish

TDQS

A4.2/5.0

Behavior3/5

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

Discloses state-changing nature and triggering of alerts. Lacks details on irreversibility or additional side effects, which would be helpful given no 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 sentences, no fluff, front-loaded with purpose followed by requirement. 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?

Adequately covers purpose and critical condition for a low-complexity tool. Missing explanation of return value or post-publish behavior, but sufficient given context.

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?

Schema covers all parameters; description adds context that confirm is required for destructive action and that publishing triggers alerts, enhancing understandability.

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 verb 'publish' and resource 'MISP event', with explicit effect 'triggers alerts and notifications'. Distinguishes from sibling tools like misp_create_event or misp_update_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?

Specifies requirement for confirm:true or MISP_ALLOW_DESTRUCTIVE=true, guiding when to use. Not explicit about when not to use, but condition clarifies usage.

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

misp_search_attributesB

Search for specific attributes (IOCs) across all MISP events

ParametersJSON Schema

Name	Required	Description
`last`	No	Relative time filter (e.g., 1d, 7d, 30d)
`tags`	No	Tag filters
`type`	No	Attribute type (ip-src, ip-dst, domain, md5, sha256, url, email-src, hostname, etc.)
`limit`	No	Max results (default 50)
`toIds`	No	Only IDS-flagged attributes
`value`	No	IOC value to search
`category`	No	Category filter
`includeCorrelations`	No	Include correlation data

TDQS

B3.4/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 for behavioral disclosure. It does not state that the operation is read-only, nor does it mention authentication, rate limits, or side effects. As a search, it is likely safe, but this is not confirmed.

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?

Single sentence that is front-loaded and contains no unnecessary words. Every part of the description adds value.

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?

No output schema exists, so the description should explain what is returned (e.g., attribute details, event context). It fails to do so, leaving the agent without information about the response format.

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 coverage is 100%, so the schema already documents all 8 parameters. The description adds no additional meaning beyond what is in the parameter descriptions.

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 for attributes (IOCs) across all MISP events, using a specific verb and resource. It distinguishes from siblings like misp_search_events (searches events) and misp_search_by_tag (searches by tag).

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 guidance on when to use this tool versus alternatives. The purpose implies it's for attribute-level search, but no when-not or alternative tool suggestions are provided.

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

misp_search_by_tagB

Search MISP events or attributes by tag (MITRE ATT&CK, TLP, custom tags)

ParametersJSON Schema

Name	Required	Description	Default
`tag`	Yes	Tag name to search for (e.g., tlp:white, mitre-attack:T1059)
`type`	No	Search events or attributes (default: event)

TDQS

B3.4/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 the full burden. It only states 'Search' but does not disclose whether the operation is read-only, destructive, or requires specific permissions. It also fails to mention pagination behavior or result 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 a single, front-loaded sentence with no filler. Every word adds value and efficiently communicates the core functionality.

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?

There is no output schema, so the description should explain return values. It does not mention what the tool returns (events, attributes, or IDs) or any limits. Given the context of sibling search tools, this omission is significant.

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 coverage is 100% with descriptions for both parameters. The description adds tag examples, but the schema already includes example values. No additional meaning beyond the schema is provided.

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 verb 'Search', the resource 'MISP events or attributes', and the method 'by tag', with examples of tag types. It distinguishes from sibling tools like misp_search_events and misp_search_attributes which are separate tools for non-tag-based searches.

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 implies usage for tag-based search but does not explicitly state when to use this tool over alternatives like misp_search_events or misp_search_attributes. No guidance on prerequisites or exclusions is provided.

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

misp_search_eventsC

Search MISP events by IOC value, type, tags, date range, or organization

ParametersJSON Schema

Name	Required	Description
`org`	No	Organization filter
`last`	No	Relative time (e.g., 1d, 7d, 30d, 6m)
`page`	No	Page number for pagination
`tags`	No	Tag filters (e.g., tlp:white, misp-galaxy:mitre-attack-pattern)
`type`	No	Attribute type filter (ip-src, ip-dst, domain, md5, sha256, url, email-src, etc.)
`limit`	No	Max results (default 50)
`value`	No	IOC value to search across all attributes
`dateTo`	No	End date (YYYY-MM-DD)
`eventId`	No	Specific event ID
`category`	No	Category filter (Network activity, Payload delivery, External analysis, etc.)
`dateFrom`	No	Start date (YYYY-MM-DD)
`published`	No	Only published events

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It does not disclose behavioral traits such as read-only nature, pagination behavior, default limits, authentication requirements, or rate limits. The tool name implies 'search' but safety and side effects are not confirmed.

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?

Single sentence efficiently conveys the tool's purpose and supported search criteria. No extraneous information; every word earns its place.

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?

Despite 12 optional parameters and no output schema, the description is minimal. It lacks details on return value format, pagination, default results count (50 per schema), or practical usage examples. Incomplete for a tool of this complexity.

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 has 100% coverage with descriptions for all 12 parameters. The description adds a concise summary grouping parameters into high-level categories (IOC value, type, tags, etc.), but does not provide additional meaning beyond the schema. Baseline is 3 for high coverage.

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

Purpose4/5

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

The description clearly states the verb 'Search' and resource 'MISP events' and lists search criteria (IOC value, type, tags, date range, organization). It distinguishes from sibling tools like misp_search_attributes (searches attributes) and misp_get_event (specific event). However, it does not explicitly differentiate from misp_search_by_tag or other similar tools.

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 explicit guidance on when to use this tool versus alternatives like misp_search_attributes or misp_get_event. The description does not mention when not to use it or provide usage context beyond its basic function.

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

misp_search_galaxy_clustersA

Search galaxy clusters by keyword (find specific MITRE ATT&CK techniques, threat actors, malware, etc.)

ParametersJSON Schema

Name	Required	Description	Default
`search`	Yes	Search term (e.g., 'phishing', 'APT28', 'ransomware', 'T1566')
`galaxyType`	No	Limit to a specific galaxy type (e.g., mitre-attack-pattern, mitre-intrusion-set)

TDQS

A3.6/5.0

Behavior2/5

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

No annotations exist, so the description must disclose behavioral traits. It only states the search function and examples, but fails to mention whether it is read-only, authentication requirements, rate limits, or pagination. For a search tool, the lack of read-only confirmation is a gap.

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 a single front-loaded sentence with examples in parentheses. It is concise with no wasted words, earning 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?

For a simple two-parameter search tool with no output schema, the description covers the essential what and examples. It lacks details about return format or behavior but is complete enough for basic 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?

Schema coverage is 100%, so baseline is 3. The description adds context by giving example search terms (e.g., 'phishing', 'APT28') and example galaxy types (e.g., 'mitre-attack-pattern'), but does not add new semantic meaning beyond the schema descriptions.

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 verb 'Search' and the resource 'galaxy clusters', with specific examples (MITRE ATT&CK techniques, threat actors, malware) that distinguish it from siblings like misp_get_galaxy (get by ID) and misp_list_galaxies (list all). The purpose is unambiguous.

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 implies usage for keyword-based searching, but does not explicitly state when to use this tool versus alternatives like misp_search_attributes or misp_search_events. No exclusions or when-not-to-use 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_server_statusA

Get MISP server version, status, and diagnostic information

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/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 carry the full burden. It states the tool retrieves version, status, and diagnostic info, which implies a read-only operation, but does not explicitly confirm no side effects or permissions needed.

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 a single sentence with no wasted words, efficiently conveying the tool's purpose.

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 simplicity (no parameters, no output schema), the description adequately explains what it returns. However, it could list specific diagnostic fields to be more complete.

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?

There are no parameters, so the baseline score is 4 per instructions. The description adds no parameter info, but 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 uses a specific verb 'Get' and identifies the resource as 'MISP server version, status, and diagnostic information'. It clearly distinguishes this tool from sibling tools, none of which target server status.

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 implies usage when server information is needed, but provides no explicit guidance on when to use it versus alternatives, nor does it 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_tag_eventA

Add or remove a tag from a MISP event (TLP, MITRE ATT&CK, custom tags). Removing a tag is destructive and requires confirm:true (or MISP_ALLOW_DESTRUCTIVE=true).

ParametersJSON Schema

Name	Required	Description
`tag`	Yes	Tag name (e.g., tlp:white, misp-galaxy:mitre-attack-pattern)
`remove`	No	Set to true to remove the tag instead of adding
`confirm`	No	Required (true) when remove is true, unless MISP_ALLOW_DESTRUCTIVE=true. Ignored when adding a tag.
`eventId`	Yes	Event ID to tag

TDQS

A4.5/5.0

Behavior4/5

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

The description discloses the destructive nature of removal and the required confirmation step, which is beyond the schema annotations (none provided). It adds context about tag naming conventions but could mention other behavioral aspects like rate limits or 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 sentences: first defines purpose with examples, second provides critical usage caveat. No filler, front-loaded.

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 read/write tool with no output schema, the description covers both add and remove operations, handles destructive operations, and explains confirm. It is complete given the tool's complexity.

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 to parameters by showing tag examples and explaining the confirm parameter's behavior (required for removal, ignored for addition). Schema coverage is 100%, so this is additive.

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 or removes tags from MISP events, with examples like TLP and MITRE ATT&CK. It distinguishes from sibling tools that handle attributes or other entities.

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 explicitly mentions that removing a tag is destructive and requires confirm:true or an environment variable, providing clear guidance for safe use. However, it does not mention when to use alternative tag-related tools like misp_search_by_tag.

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

misp_toggle_feedB

Enable or disable a MISP feed

ParametersJSON Schema

Name	Required	Description	Default
`enable`	Yes	true to enable, false to disable
`feedId`	Yes	Feed ID

TDQS

B3.4/5.0

Behavior3/5

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

No annotations exist, so the description must carry the burden. It correctly states the effect (enable/disable) but does not disclose any side effects, auth requirements, or irreversible consequences.

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 a single sentence with no extraneous words. It is concise, though it could benefit from a bit more detail without harming conciseness.

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?

For a simple toggle tool with two required parameters and no output schema, the description provides minimal but adequate context. It does not cover return values, error conditions, or feed-specific details.

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 coverage is 100%, so the description adds no extra meaning beyond what the schema already provides. The parameters are well-documented in 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 'Enable or disable a MISP feed' clearly specifies the verb (toggle) and the resource (MISP feed), distinguishing it from sibling tools like misp_list_feeds or misp_fetch_feed.

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 is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., feed must exist) or exclusions.

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

misp_update_eventA

Update an existing MISP event's metadata (info, threat level, analysis status). Publishing is separate - use misp_publish_event.

ParametersJSON Schema

Name	Required	Description
`info`	No	New event description
`eventId`	Yes	Event ID to update
`analysis`	No	0=Initial, 1=Ongoing, 2=Complete
`threatLevel`	No	1=High, 2=Medium, 3=Low, 4=Undefined

TDQS

A4.4/5.0

Behavior4/5

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

No annotations provided, so description carries the burden. It clarifies that publishing is separate, implying no automatic publish. However, it lacks disclosure about permissions, side effects, or overwrite behavior, which would be nice for a mutation 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 with no waste. Front-loaded with purpose and immediate guidance on sibling tool.

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 4-parameter tool with no output schema, the description covers essential use and separates from publishing. But lacks hints on success/error behavior which could be added. Still, adequate for the complexity.

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 coverage is 100%, so baseline is 3. The description only lists the metadata categories (info, threat level, analysis status) without adding new info beyond the schema descriptions for each parameter. No additional value.

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 the tool updates existing MISP event metadata (info, threat level, analysis status) and distinguishes from publishing by referencing sibling misp_publish_event. Verb+resource+scope are specific.

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 says when to use (update metadata) and when not (publishing), and directs to an alternative sibling tool. Provides clear context.

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

A3.7/5.0

Disambiguation5/5

Each tool targets a distinct MISP operation (create, delete, search, export, etc.) with no overlap. Even similar tools like misp_search_events and misp_search_attributes are clearly scoped to events vs attributes.

Naming Consistency5/5

All tools follow the pattern 'misp_verb_noun' in lowercase with underscores, e.g., misp_add_attribute, misp_delete_event, misp_list_feeds. No deviations or mixed conventions.

Tool Count4/5

36 tools is high but appropriate for a comprehensive MISP client covering events, attributes, objects, feeds, galaxies, tags, and more. Slightly heavy but each tool serves a clear purpose.

Completeness5/5

The tool surface covers the full lifecycle of threat intelligence in MISP: creation, deletion, search, export, feed management, galaxy/tag attachment, and server status. No obvious gaps for typical workflows.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

Need Help?

Reddit Discussion

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
sentrysurface
io.github.sentrysurface
Cybersecurity MCP server for URL scanning, threat intelligence, and domain reputation.
Security Penetration Testing
2
anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
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
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
ThreatMCP
Security Search Monitoring
NAXG
A
license
Not graded
quality
D
maintenance
An MCP server that integrates ThreatBook's threat intelligence API, offering 15 specialized tools for security analysis. It enables AI models to perform IP reputation checks, domain investigations, file sandbox analysis, and vulnerability intelligence lookups.
Updated a year ago (2025-06-24 14:31 UTC)
50
MIT
cortex-mcp
Security Autonomous Agents Monitoring
lidless-labs
A
license
A
quality
A
maintenance
An MCP server for the Cortex observable analysis and active response engine. It enables LLMs to automate security investigations by running analyzers on observables like IPs and URLs and executing automated response actions.
Updated a month ago (2026-08-09 02:37 UTC)
31
10
1
MIT

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

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