A security analyst-oriented MCP server for investigating, pivoting, reporting on, and (with strict approval gates) writing to MISP threat intelligence — without exposing the full MISP API.
Read-Only Investigation
search_ioc — Search MISP for an IOC and return normalized attribute matches.
investigate_ioc — Full IOC investigation combining MISP matches, warninglist checks, related events, scoring, and recommended next steps.
summarize_event — Summarize a MISP event by ID without dumping raw JSON.
check_warninglists — Check an IOC against MISP warninglists to identify known-safe or noisy indicators.
Pivoting & Event Intelligence
pivot_ioc — Pivot from one IOC into related events and indicators for threat hunting.
find_related_iocs — Return a ranked list of IOCs related to a given indicator.
extract_event_iocs — Extract and deduplicate supported IOC types from a specific MISP event.
explain_event_context — Get an analyst-friendly explanation of what a MISP event represents.
find_events_by_tag — Find MISP events associated with a specific tag.
Reporting
generate_ioc_report / generate_event_report — Generate structured analyst reports for an IOC or event.
generate_markdown_ioc_report / generate_markdown_event_report — Generate Markdown-formatted reports suitable for SOC notes or escalation.
Proposal-Only Tools (never write to MISP)
propose_event — Build a reviewable MISP event creation proposal without writing anything.
propose_attribute — Build a reviewable attribute creation proposal without writing anything.
Approval-Gated Write Tools
submit_ioc_with_approval — Add an attribute to MISP only when write mode is enabled, the role permits it, and explicit approval is granted.
add_sighting_with_approval — Add a sighting only when policy and approval allow.
tag_event_with_approval — Tag a MISP event only when policy and approval allow.
publish_event_with_approval — Publish a MISP event only for curator/admin roles with explicit approval.
Key Safety Constraints: Read-only by default (writes require AGENTIC_MISP_MCP_ENABLE_WRITE=true); all write tools are approval-gated (approved=false by default); no raw MISP API proxy; every tool call is audited to a JSONL log.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@agentic-misp-mcp Investigate IOC 8.8.8.8 and summarize related events"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MISP workflows for agents — investigate, pivot, report, and propose controlled writes without turning your MCP server into a raw API proxy.
agentic-misp-mcp is an MCP (Model Context Protocol) server that lets AI agents work with
MISP threat intelligence safely. Instead of exposing the whole
MISP API, it exposes 25 bounded, analyst-oriented workflows: search an IOC, investigate its
context, pivot through related indicators, summarize events, check warninglists, observe feed
health, generate reports, and prepare tightly controlled write proposals.
The safety model is simple and enforced in code:
Read-first. Every investigation tool is read-only; writes are disabled by default.
Approval-gated writes. The four write tools require write mode, a permitted role, and an explicit approval step — in production mode, a one-time operator-approved request ID.
Audit logging. Every tool call (allowed, blocked, failed, or errored) is written to a JSONL audit log with sanitized arguments.
Redaction. API keys, approval tokens, and feed secrets never appear in responses or logs.
Role policy. read_only / analyst_write / curator / admin roles bound what any
agent session can even attempt.
Compatibility baseline: live-validated against MISP 2.5.42 (most recently the
v0.3.0 release, 14/14 live checks — see
docs/live-validation-report-v0.3.0.md). Other MISP
versions are untested; see docs/misp-compatibility.md.
SOC analysts — ask an agent to investigate an IOC and get verdict, confidence, freshness, related events, and next steps instead of raw JSON dumps.
Threat intelligence analysts — pivot, correlate, and produce Markdown/JSON reports from live MISP data.
Detection engineers — extract actionable (to_ids) indicators and event context with
bounded, predictable output.
Security automation teams — wire MISP into agent workflows without handing the agent an unrestricted API key surface.
Regulated / banking environments — every call is audited, writes need out-of-band operator approval, and the write surface is small and explicit.
Related MCP server: MISP MCP Server
Workflow | Tools involved |
IOC investigation |
|
Event search and context |
|
Sightings |
|
Warninglist checks |
|
Feed observability (read-only) |
|
Markdown / JSON reporting |
|
Approval-gated writes |
|
Age-aware scoring / stale-intel labeling |
|
Access levels: read-only (never writes to MISP), dry-run (builds a reviewable payload, never calls a MISP write endpoint), approval-gated write (blocked unless write mode, role, and approval all allow it).
Tool | Access | What it does |
| read-only | Find normalized MISP attribute matches for an indicator. |
| read-only | Verdict, confidence, freshness, warninglists, related events, next steps. |
| read-only | Pivot from one IOC into related context. |
| read-only | Rank related indicators worth hunting. |
| read-only | Bounded event summary (never full raw event JSON). |
| read-only | What an event appears to represent. |
| read-only | Extract supported IOC types from an event. |
| read-only | Events associated with a tag. |
| read-only | Discover events by bounded date/publication/org filters. |
| read-only | Bounded sighting summaries for an IOC. |
| read-only | Check an IOC against MISP warninglists. |
| read-only | MISP version and warninglist capability status. |
Tool | Access | What it does |
| read-only | List configured feeds with bounded, redacted metadata. |
| read-only | One feed's redacted status and fetch/cache age. |
| read-only | Group feeds by health label (fresh/stale/never-fetched/disabled). |
Feed enable/disable/fetch/cache/edit/delete remain operator-only MISP admin actions and are
not exposed as MCP tools. See docs/feed-observability.md.
Tool | Access | What it does |
| read-only | Deterministic structured (JSON) IOC report. |
| read-only | Deterministic structured (JSON) event report. |
| read-only | Markdown IOC report for notes/escalation. |
| read-only | Markdown event report. |
Tool | Access | What it does |
| dry-run | Build and validate an event-creation proposal. Never writes to MISP. |
| dry-run | Build and validate an attribute-creation proposal. Never writes to MISP. |
Tool | Access | What it does |
| approval-gated write | Add an attribute to an event. |
| approval-gated write | Record a sighting. |
| approval-gated write | Tag an event. |
| approval-gated write | Publish an event (curator/admin roles only). |
Write-tool results are explicit: blocked, invalid, pending_approval, executed, or
failed (MISP itself rejected the write). There are no silent writes. See
docs/approval-flow.md.
Prerequisites: Python 3.11+ and uv (or Docker — see
Docker), a reachable MISP instance, and a MISP API key.
# 1. Clone and install
git clone https://github.com/hdyrawan/agentic-misp-mcp.git
cd agentic-misp-mcp
uv sync --extra dev
# 2. Configure (at minimum MISP_URL and MISP_API_KEY)
cp .env.example .env
# edit .env
# 3. Validate configuration (no MISP connection is made; the API key is redacted)
uv run agentic-misp-mcp config-check
# 4. Run the test suite
uv run --extra dev pytest -q
# 5. Start the MCP server over stdio (the primary supported transport)
uv run agentic-misp-mcp --transport stdioThen:
Connect an MCP client — see MCP client examples below.
Run a first read-only tool — get_misp_status is a good zero-risk smoke test; it
confirms connectivity and reports the MISP version.
Review the audit output:
tail -n 20 logs/audit.jsonl | jq .A good first-five sequence for a new operator, all read-only: get_misp_status →
check_warninglists → investigate_ioc → search_events → summarize_feed_health.
docker build -t agentic-misp-mcp:local .
# keep the env file outside the repository; never commit real credentials
mkdir -p /path/to/runtime/logs
cp .env.example /path/to/runtime/.env # edit it
docker run --rm --env-file /path/to/runtime/.env \
-v /path/to/runtime/logs:/app/logs \
agentic-misp-mcp:local config-check
docker run --rm -i --env-file /path/to/runtime/.env \
-v /path/to/runtime/logs:/app/logs \
agentic-misp-mcp:local --transport stdioPrefer Compose? See docker-compose.example.yml and
docs/configuration.md.
Production note: the Dockerfile declares /app/logs and /app/approvals as VOLUMEs. If you
run the image with docker run --rm and omit the -v bind mounts shown above, Docker silently
creates anonymous volumes for both paths instead — audit logs and the approval database then
disappear when the container is removed. Always bind-mount both paths explicitly in any
production-write deployment.
All configuration is via environment variables (or an .env file). Placeholders below are
fake — never commit real credentials.
Variable | Example | Notes |
|
| Base URL of your MISP instance. |
|
| Runtime-only automation key. Loaded from the environment only; never passed as a tool argument. |
Variable | Default | Notes |
|
| Keep |
|
| HTTP timeout, > 0 and <= 300. |
|
| Default result limit. |
|
| Maximum accepted result limit. |
|
| Attribute cap for event summaries/investigations. |
|
| Related-event expansion cap. |
|
| Max MISP HTTP response body size, enforced (fail-closed) before JSON parsing. |
Variable | Default | Notes |
|
|
|
|
| Global write-mode gate. Leave |
|
| Lab-mode gate requiring explicit |
|
|
|
| unset | Optional lab shared-secret hardening; redacted in audit logs. Not the production approval mechanism. |
|
| SQLite store for production approvals. The agent must not have write access to it. Persist it. |
|
| Production approval lifetime. |
| unset | Production guardrail: allowlist of submittable attribute types. |
| unset | Production guardrail: allowlist of attribute categories. |
| unset | Production guardrail: allowlist of event tags ( |
|
| Dedicated publish kill switch; publish also requires curator/admin role and approval. |
|
| JSONL audit log path. Persist it (mount a volume under Docker). |
|
| Application log level. |
|
| Experimental HTTP transport refuses non-loopback binds unless this is set. Keep |
Variable | Default | Notes |
|
| Age-aware IOC scoring. |
|
| Newest signal at or below this age is |
|
| Upper bound for |
|
| Upper bound for |
|
| Score multipliers for fresh/aging/stale/expired, each 0–1. |
|
| Feed fetch/cache age at or below this is fresh. |
|
| Feed fetch/cache age above this is stale. |
Full reference and examples: docs/configuration.md. Before any
production run, also use the deeper check:
uv run agentic-misp-mcp config doctorIt validates write/approval-mode pairing, approval-store and audit-log permission safety, allowlist coverage, and more — without connecting to MISP or printing secrets.
All examples use the stdio transport (the primary supported transport) and generic paths —
replace /path/to/agentic-misp-mcp with your checkout (e.g. /home/user/agentic-misp-mcp or
/opt/agentic-misp-mcp).
stdio MCP clients (Hermes, Claude Desktop, Claude Code, etc.) start this server as a subprocess
and do not source your shell's rc files or the repo .env. Pointing a client straight at
uv run agentic-misp-mcp --transport stdio can therefore fail (e.g. Hermes reporting
"Connection closed") because MISP_URL/MISP_API_KEY are never visible to the subprocess.
The repo ships two wrapper scripts that load an env file and then exec the real command:
scripts/agentic-misp-mcp-stdio — starts the MCP server over stdio.
scripts/agentic-misp-mcp-config-check — runs config-check with the same env loading, so
you can confirm MISP_URL/MISP_API_KEY resolve correctly before wiring up a client.
Both scripts resolve the repo root from their own file location (not your current working
directory), then load ${AGENTIC_MISP_ENV_FILE} if that variable is set, otherwise
<repo-root>/.env if it exists. Neither script echoes env values or secrets.
# Validate configuration before connecting a client
scripts/agentic-misp-mcp-config-check
# Point a stdio MCP client at the launcher, e.g. Hermes:
hermes mcp add agentic-misp-mcp --command "/path/to/agentic-misp-mcp/scripts/agentic-misp-mcp-stdio"
# Use an env file stored outside the repo instead of <repo-root>/.env
AGENTIC_MISP_ENV_FILE=/path/to/secure/agentic-misp.env scripts/agentic-misp-mcp-config-checkNever commit .env (or any file referenced via AGENTIC_MISP_ENV_FILE) — it holds
MISP_API_KEY and other secrets. .gitignore already excludes .env by default.
npx @modelcontextprotocol/inspector \
uv --directory /path/to/agentic-misp-mcp run agentic-misp-mcp --transport stdioHeadless/CI mode (no browser):
npx -y @modelcontextprotocol/inspector --cli \
uv --directory /path/to/agentic-misp-mcp run agentic-misp-mcp \
--method tools/listOn a headless host, either use --cli mode or forward the Inspector UI ports over SSH:
ssh -L 6274:localhost:6274 -L 6277:localhost:6277 user@mcp-host.example.local.
claude mcp add agentic-misp-mcp -s local -- \
uv --directory /path/to/agentic-misp-mcp run agentic-misp-mcp --transport stdioVerify with claude mcp list (should show ✔ Connected), then start a new Claude Code
session — tools appear in sessions started after the add. Remove with
claude mcp remove agentic-misp-mcp -s local. Avoid -s project unless every teammate has the
same paths, since it writes a shared .mcp.json verbatim.
Add to claude_desktop_config.json:
{
"mcpServers": {
"agentic-misp-mcp": {
"command": "uv",
"args": [
"--directory", "/path/to/agentic-misp-mcp",
"run", "agentic-misp-mcp", "--transport", "stdio"
],
"env": {
"MISP_URL": "https://misp.example.local",
"MISP_API_KEY": "your_misp_api_key_here"
}
}
}
}Prefer --env-file/OS-level secrets over inlining the key when your client supports it, and
never commit a client config containing a real key.
If the client spawns a subprocess (as Claude Desktop, OpenCode, and Hermes do above), point it at
docker run instead of uv. Bind-mount /app/logs and /app/approvals explicitly — see the
production note in Docker — and never bake MISP_URL/MISP_API_KEY into the image:
{
"mcpServers": {
"agentic-misp-mcp": {
"command": "docker",
"args": [
"run", "--rm", "-i",
"--env-file", "/path/to/runtime/.env",
"-v", "/path/to/runtime/logs:/app/logs",
"-v", "/path/to/runtime/approvals:/app/approvals",
"agentic-misp-mcp:local",
"--transport", "stdio"
]
}
}
}Hermes spawns the server as a subprocess and does not load the repo .env, so use the
stdio launcher script rather than invoking uv directly:
hermes mcp add agentic-misp-mcp --command "/path/to/agentic-misp-mcp/scripts/agentic-misp-mcp-stdio"Hermes performs a live discovery handshake and prompts to enable tools — answer y for all 25,
or use select to enable a read-only subset (everything except the four _with_approval and
two propose_* tools). Verify with hermes mcp list / hermes mcp test agentic-misp-mcp,
then start a new Hermes session.
{
"mcp": {
"agentic-misp-mcp": {
"type": "local",
"command": [
"uv", "--directory", "/path/to/agentic-misp-mcp",
"run", "agentic-misp-mcp", "--transport", "stdio"
],
"environment": {
"MISP_URL": "https://misp.example.local",
"MISP_API_KEY": "your_misp_api_key_here"
}
}
}
}Any MCP client that can spawn a stdio subprocess works the same way: run
uv --directory /path/to/agentic-misp-mcp run agentic-misp-mcp --transport stdio (or the
docker run --rm -i ... --transport stdio equivalent from Docker).
Transport note: stdio is the recommended production transport. The HTTP transport is
experimental, has no built-in auth or TLS, and refuses to bind a non-loopback host unless
AGENTIC_MISP_MCP_ALLOW_INSECURE_HTTP_BIND=true; if you must use it, put it behind an
authenticated TLS-terminating gateway.
Before pointing agents at a production MISP:
Create a dedicated least-privilege MISP API key for this server (not a personal or site-admin key).
Keep AGENTIC_MISP_MCP_ROLE=read_only and AGENTIC_MISP_MCP_ENABLE_WRITE=false for
normal agent use; enable writes only when a workflow genuinely needs them.
If writes are enabled, use AGENTIC_MISP_MCP_APPROVAL_MODE=production and keep the
approval CLI and approval database out of the agent's reach.
Persist audit logs (AGENTIC_MISP_MCP_AUDIT_LOG_PATH; mount a volume under Docker).
Persist the approval store (AGENTIC_MISP_MCP_APPROVAL_STORE_PATH).
Protect MISP_API_KEY — environment/secrets manager only; keep .env files out of git
and out of client configs that get shared.
Keep MISP_VERIFY_TLS=true; fix certificate problems with your internal CA, don't
disable verification.
Run agentic-misp-mcp config-check and agentic-misp-mcp config doctor after every
config change.
Run the test suite (uv run --extra dev pytest -q) on the deployed revision.
Smoke test with MCP Inspector (tools/list, then get_misp_status).
Review audit.jsonl after the first real tool calls, and periodically thereafter
(manual audit review is the accepted control — there is no built-in alerting).
Keep feed administration (enable/fetch/cache) in the MISP UI/API, outside MCP.
Deeper guidance: docs/production-readiness.md,
docs/production-write.md,
docs/rollback.md.
These are design boundaries, enforced in code and preserved across releases:
No raw MISP API proxy. Only the 25 workflow tools exist; there is no generic endpoint-passthrough tool.
No feed mutation. No feed enable/disable/fetch/cache/edit/delete tools exist. Feed
observability (list_feeds, get_feed_status, summarize_feed_health) is strictly
read-only, with URLs and header/token-like fields redacted.
No approval-store exposure. No MCP tool can create, approve, reject, or read approval records; production approvals happen only through the operator CLI.
No ungated writes. Every write path goes through role policy, the write-mode gate, and
the approval gate; results are explicit (blocked/pending_approval/executed/failed).
No hidden mutation in read tools. Read tools call read endpoints only.
propose_* tools are dry-run only. They build and validate payloads; they never invoke
a MISP write endpoint.
No secret passthrough. API keys, tokens, passwords, and authorization headers are never accepted as tool arguments and are redacted from audit logs.
No shell execution or unrestricted filesystem tools; no user/org/server/settings admin tools.
See docs/security.md for the full security model and audit semantics.
Since v0.3.0, IOC scoring is age-aware by default. investigate_ioc,
generate_ioc_report, and pivot_ioc responses include a freshness block that labels the
intel behind a verdict:
Label | Meaning (defaults) |
| Newest signal ≤ 30 days old. |
| 31–90 days. |
| 91–365 days. |
| Older than 365 days. |
| No usable timestamps found. |
How it affects scores:
Old intel scores lower by default. Positive score factors are discounted by intel age
(default weights 1.0 / 0.75 / 0.4 / 0.15 for fresh/aging/stale/expired).
Penalties are never age-discounted. Warninglist hits and benign-tag penalties apply at full strength regardless of age.
Expired intel cannot become likely_malicious on its own — expired-only intel is capped
below that threshold and needs fresh corroboration to cross it.
AGENTIC_MISP_MCP_AGE_WEIGHTING=false restores exact v0.2.x scoring (the freshness
block is still reported).
This is a confidence-quality improvement, not a replacement for analyst judgment: a fresh
hit on a 10-year-old OSINT event that was recently re-published still deserves human
correlation with current telemetry before blocking or escalation.
Symptom | Likely cause | Fix |
Connection error, | Wrong | Verify the URL (scheme + host, no trailing API path); test |
Authentication error, | Invalid or revoked | Regenerate the automation key in MISP; confirm the env var actually reaches the process ( |
TLS verification failure | Self-signed or internal-CA certificate | Add the CA to the system trust store. |
MISP returns permission denied | The API key's MISP role lacks the needed permission | Grant the minimal MISP permission the workflow needs (e.g. sighting creation for sightings), keeping the key least-privilege. |
Tool returns | Policy working as intended: role or write-mode gate | Check |
Write returns | Approval required (the default) | Lab mode: re-call with |
| Audit log directory missing or not writable | Create the directory / fix permissions; under Docker, mount a writable volume at the audit path. |
Approvals disappear after restart | Approval DB not persisted | Point |
"Response too large" error | MISP response exceeded | Narrow the query (smaller |
MCP client can't spawn the server | Wrong command/path in the client config | Use absolute paths ( |
Import errors / wrong Python | Wrong environment or Python < 3.11 | Use |
Latest release: v0.3.2 — date-validation hardening patch on v0.3.1 (search_events
now rejects calendar-invalid dates like 2026-02-30; no MCP tool, scoring, write-surface, or
approval-workflow changes). See CHANGELOG.md.
Functional baseline: v0.3.0 — age-aware scoring, six new read-only tools (sightings,
event search, status, feed observability), read-tool response envelope.
Supported MISP baseline: 2.5.42, live-validated 14/14 —
docs/live-validation-report-v0.3.0.md.
Latest pre-merge review findings:
docs/review-v0.3.0-findings.md.
Tool count: 25. Tests: 358 (mocked MISP responses; live validation is a separate manual pass).
Scope of the production claim: v0.2.0 was declared GA for the MCP-server scope of
this project only (server behavior, MISP API behavior, approval workflow, audit/redaction,
config safety) — not a SIEM/SOAR/SOC platform claim. v0.3.x extends that same scope. See
docs/ga-production-readiness-plan.md.
Known limitations: only MISP 2.5.42 is validated; a live HTTP 429 has mocked coverage
only (no safe way to trigger one in the lab); container/dependency/secret scanning and signed
release artifacts are not yet part of CI/release; HTTP transport is experimental; historical
OSINT hits should be correlated with current telemetry (mitigated but not removed by
age-aware scoring).
uv run --extra dev ruff check .
uv run --extra dev ruff format --check .
uv run --extra dev pytest -qEquivalent Make targets: make lint, make format-check, make test, make check.
CI runs the same checks on Python 3.11 and 3.12.
docs/configuration.md — full environment-variable reference,
Docker/Compose, client config shapes, config doctor.
docs/security.md — security model, tool boundary, audit semantics.
docs/roles.md — role policy matrix.
docs/approval-flow.md — lab and production approval flows.
docs/production-write.md — production write deployment guidance.
docs/production-readiness.md — the broader readiness
checklist and what it still requires.
docs/feed-observability.md — feed tools and the feed safety
boundary.
docs/testing.md — what the mocked suite covers.
docs/misp-compatibility.md — MISP version matrix.
docs/live-validation-report-v0.3.0.md — latest
live validation evidence (earlier reports live alongside it in docs/).
docs/rollback.md — rollback playbook for a mistaken controlled write.
Contributions are welcome, but the project boundary is not up for debate in a PR: no raw MISP
API proxy, no secret passthrough, no unaudited tool path, and no write behavior that skips the
policy/approval gates. Before writing code, read PROJECT_STATE.md,
docs/security.md, and src/agentic_misp_mcp/tools/registry.py so your
change lands inside that boundary instead of against it.
Fork and branch. Fork the repository and create a feature branch off main (for example
fix/search-events-date-validation or feat/short-description) — don't work directly on
main.
Make the change. Keep the diff scoped to one concern. If you're touching a policy-gated
write tool, a scoring calculation, or anything under misp/, policy/, or audit.py, explain
the reasoning in your PR description — these paths get read closely (see "Security-sensitive
changes" below).
Add or update tests. New behavior needs new test coverage; changed behavior needs its existing tests updated to match. Run the suite locally:
uv run pytest -qRun Ruff before you push. Both lint and format are enforced in CI (.github/workflows/ci.yml)
and must pass clean:
uv run ruff check .
uv run ruff format --check .(make check runs all three — lint, format check, and tests — in one command.)
Write clear commits. Each commit should describe one change and why it was made, not just what changed — the diff already shows what changed. Squash exploratory or fixup commits before opening the PR.
Open the pull request with real context. Describe the problem, the fix, and how you verified it (test output, and live-lab evidence if you ran any against a real MISP instance). State explicitly whether the change affects the MCP tool surface, scoring behavior, or the write/approval workflow — reviewers will check that claim against the diff.
Anything touching credential handling, the policy engine, approval workflows, audit logging, or
the MISP client's write methods gets extra scrutiny before merge — that's the core of this
project's safety model, not incidental code. Do not include real MISP URLs, API keys, tokens, or
production event data in commits, issues, or PR descriptions; use the placeholders already used
throughout this README and .env.example. If you find a security issue rather than proposing a
fix, follow the reporting process in SECURITY.md instead of opening a public PR.
MIT.
Add a sighting to MISP only when policy and approval allow. Otherwise returns a blocked/proposal result.
| Name | Required | Description | Default |
|---|---|---|---|
| value | No | ||
| source | No | ||
| approved | No | ||
| event_id | No | ||
| attribute_id | No | ||
| sighting_type | No | 0 | |
| approval_token | No | ||
| approval_request_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the core conditional behavior and the blocked/proposal result, but lacks details about side effects, idempotency, error handling, or the approval workflow. With no annotations, more transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently conveys the core behavior. However, it lacks structure such as parameter descriptions or usage examples, which would improve clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no annotations, and an output schema, the description is insufficient to fully understand tool behavior, prerequisites, return values, or error conditions. The presence of approval-related parameters is not explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description provides no explanation for any of the 8 parameters (value, source, event_id, attribute_id, sighting_type, approved, approval_token, approval_request_id). The schema itself has no descriptions, leaving the agent to infer meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: adding a sighting to MISP subject to policy and approval, with an explicit fallback behavior (blocked/proposal). This distinguishes it from sibling tools like propose_attribute or propose_event which handle different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description implies usage for approved sightings, it does not explicitly state when to use this tool versus alternatives like propose_attribute or other add tools without approval. No 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.
Check an IOC against MISP warninglists when available.
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 mentions 'when available' without explaining what happens if warninglists are unavailable (e.g., error or empty result), nor does it indicate side effects or authorization needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence, which is concise. However, it is arguably too brief, sacrificing necessary detail for the sake of brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, but the description says nothing about the return value. Additionally, with 18 siblings, the description does not differentiate this tool's specific role or output format, making it incomplete for effective agent selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the 'value' parameter at all, nor its expected format (e.g., IP, domain, hash). With 0% schema description coverage, the description fails to add meaning beyond the schema, leaving the parameter underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Check' and the resource 'IOC against MISP warninglists', which distinguishes it from siblings like search_ioc or investigate_ioc. However, it does not specify what 'check' returns, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. The phrase 'when available' hints at a prerequisite but does not explain conditions for use or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain what a MISP event represents in deterministic, analyst-friendly language.
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 does not disclose whether the operation is read-only, requires authentication, or has any side effects. The description is minimal and lacks behavioral traits beyond the implied 'explain' action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, concise and front-loaded with the purpose. However, it could be structured to include more details without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema covering return values, the description is minimally adequate. However, it does not elaborate on the scope of the explanation (e.g., tags, attributes, context), which would be helpful for an agent to understand the tool's output boundaries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the sole parameter 'event_id' or add any meaning beyond the schema. With 0% schema description coverage, the description fails to compensate, leaving the agent without guidance on what the parameter represents or its format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('explain') and the resource ('a MISP event'), and adds specificity with 'deterministic, analyst-friendly language'. However, it does not explicitly distinguish from sibling tools like 'summarize_event' or 'generate_event_report', which could have overlapping purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. For example, it does not contrast with 'summarize_event' or 'generate_event_report', leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract supported IOC types from a MISP event, grouped and deduplicated.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| event_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions grouping and deduplication but does not specify which IOC types are supported, what happens when an event has no IOCs, or whether the operation is read-only. The lack of annotation makes this gap more significant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words, but it is too brief to cover essential details. It earns a 3 because it is concise but at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not mention what the output contains (e.g., list of IOCs, counts). Two parameters exist, but only one is implicitly referenced. The tool's behavior is not fully specified for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions). The description implies event_id but does not explain the limit parameter or their expected values/formats. This fails to add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('extract'), resource ('supported IOC types from a MISP event'), and key features ('grouped and deduplicated'). This distinguishes it from sibling tools like search_ioc (which likely searches across events) or find_related_iocs (which finds related IOCs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as search_ioc or investigate_ioc. There is no mention of prerequisites, limitations, or conditions that would inform tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find MISP events associated with a tag.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It fails to mention any behavioral traits: no info on read/write nature, pagination, ordering, or permissions. The existence of an output schema is not utilized.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise but at the cost of essential information. It lacks structure and does not adequately fulfill the role of a tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters and an output schema, the description is critically incomplete. It does not clarify how tags are matched, what the limit parameter controls, or what the output contains. The output schema's presence does not offset the lack of narrative context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It does not mention 'tag' or 'limit', leaving the agent to infer meaning from the schema alone, which provides no semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the basic purpose (find events by tag) but is essentially a tautology of the tool name. It does not specify what 'associated' means (exact tag match?) and does not differentiate from other event-searching tools like 'find_related_iocs'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 siblings, no prerequisites, and no scenarios where it should be avoided. The description provides no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a deterministic, structured analyst report for a MISP event.
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits beyond the basic action. It does not state whether this tool is read-only or has side effects, what permissions are needed, or that output is deterministic. With no annotations, the description carries the full burden and 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the core purpose without redundancy. Every word earns its place, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, output schema exists), the description is adequate but lacks contextual clues like what 'structured analyst report' entails or how it complements siblings. The presence of an output schema mitigates the need for return value details, but missing usage and behavioral context lowers completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'event_id' (integer) has zero schema description coverage and the description adds no meaning, simply implying it identifies the event. The baseline for 0% coverage is low, and the description does not compensate with context like expected range or validation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (generate a report) and the target (MISP event), with qualifiers 'deterministic' and 'structured analyst report' that hint at a specific output format, distinguishing it from siblings like generate_markdown_event_report. However, it could explicitly mention that it differs from Markdown or IOC reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as generate_markdown_event_report or generate_ioc_report. There is no mention of prerequisites (e.g., event existence) or context for optimal use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a deterministic analyst report for an IOC.
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only says 'generate deterministic report' without disclosing whether it's read-only, requires authentication, what happens to existing data, or rate limits. Safety profile is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise. However, it is too terse and sacrifices informative value; it is not structured to highlight key aspects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low schema coverage and no annotations, the description lacks explanation of output format, behavior, or what constitutes a 'report'. While there is an output schema, it is not referenced or summarized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain the 'value' parameter (e.g., what type of IOC? format constraints?). It adds no meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'Generate' and resource 'analyst report for an IOC' are clear. However, it doesn't distinguish from sibling 'generate_markdown_ioc_report' which likely produces different output format. The term 'deterministic' adds some specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 investigate_ioc, search_ioc, or generate_markdown_ioc_report. No when-to-use or when-not-to-use context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a Markdown-formatted MISP event report suitable for SOC escalation.
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only says 'generate', but does not state whether this is a read-only operation or if it modifies data, requires permissions, or has side effects. Minimal information beyond the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise and front-loaded. However, it is underinformative, lacking detail that would justify its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description provides minimal context. It does not explain what a 'MISP event report' entails, what the output format looks like, or any constraints. For a tool with one parameter and no annotations, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter is event_id (integer), but the description does not mention it or provide any context beyond the schema name. Schema description coverage is 0%, so the description adds no value for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Generate' and the specific resource 'Markdown-formatted MISP event report suitable for SOC escalation'. While it distinguishes from siblings like 'generate_event_report' by implying a Markdown format, it does not explicitly differentiate from 'generate_markdown_ioc_report'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs alternatives such as generate_event_report or generate_ioc_report. The description lacks context about appropriate scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a Markdown-formatted IOC report suitable for SOC documentation.
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description fails to disclose any behavioral traits such as whether the tool is read-only, modifies data, requires authentication, or has rate limits. With zero annotation coverage, the description must provide this context but does not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but insufficient. It lacks key details and is not structured to convey important information upfront.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and poor parameter semantics, the description is incomplete. Even with an output schema, it fails to provide enough context for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain what the 'value' parameter represents. Without this information, an agent cannot correctly provide the input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates a Markdown-formatted IOC report for SOC documentation, differentiating from sibling tools like generate_ioc_report or generate_markdown_event_report. However, it could be more specific about the report contents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There's no mention of when not to use it or which sibling tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return redacted status and health metadata for one configured MISP feed.
| Name | Required | Description | Default |
|---|---|---|---|
| feed_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states the tool returns data ('redacted status and health metadata'), but fails to explain what 'redacted' means, whether it requires authentication, or any side effects. For a read tool, this is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 9-word sentence, making it concise and front-loaded. However, it is too terse and omits important details that could be included without significant length. It earns its place but could be improved.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 required parameter) and presence of an output schema, the description still lacks completeness. It does not explain what 'redacted status' entails or provide any context about the feed health metadata. The agent would need external 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool has a single required parameter 'feed_id' (integer). The description does not describe this parameter at all, leaving the agent with no semantic guidance beyond the type and required flag. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'redacted status and health metadata' for one MISP feed. It uses a specific verb ('Return') and resource ('status and health metadata'), and distinguishes from sibling 'list_feeds' by focusing on a single feed's status. However, it does not explicitly differentiate from the similar 'summarize_feed_health' tool, so clarity is high but not perfect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list_feeds' or 'summarize_feed_health'. It does not specify prerequisites, context, or exclusion criteria. Usage is implied only by the tool name and basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return bounded sighting summaries for an IOC.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| value | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the basic function, omitting any mention of authentication, rate limits, idempotency, or whether the operation is read-only. The minimal description leaves the agent uninformed about side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it very concise. However, it could include additional context without becoming verbose, such as clarifying what 'bounded' means or the nature of 'sightings'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to explain return values in detail. However, it still leaves ambiguity about what constitutes a 'sighting summary' and how the bounding applies. This is adequate for a simple tool but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no meaning to the parameters. The word 'bounded' hints at the limit parameter but does not explain its purpose or default behavior. The required parameter 'value' is not explained at all, leaving the agent to assume it is the IOC value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns bounded sighting summaries for an IOC, with specific verb 'Return' and resource 'bounded sighting summaries' and 'IOC'. However, it does not explicitly distinguish from sibling tools like 'investigate_ioc' or 'find_related_iocs', which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 lacks any context about prerequisites, typical use cases, or when not to use it, which is especially problematic given the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return MISP version and warninglist read capability status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It implies read-only via 'Return', but does not disclose side effects, authentication needs, or rate limits. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with no wasted words. However, it could be better structured with bullet points or additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has output schema (presumably describing return values), so description need not cover returns. Tool is simple, but given many siblings, more context on when to check status would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters and schema coverage is 100%. Description adds no param info, but baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'Return' is clear, and the resource 'MISP version and warninglist read capability status' is specified. However, 'warninglist read capability status' is slightly vague. It distinguishes from siblings as no other sibling tool explicitly returns status/version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 the many siblings. It does not state prerequisites, context, or alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Investigate an IOC using MISP matches, related events, tags, and warninglists.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| value | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavior. It does not mention whether the tool is read-only, requires authentication, or has side effects. The output schema exists but the description doesn't reference it, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loading key information. However, it could be more structured, e.g., listing parameters or output briefly. No waste, but slight under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool aggregates multiple sources (MISP matches, events, tags, warninglists), the description is too brief. It doesn't explain the output format, return structure, or how results are combined, despite having an output schema. Leaves the agent with incomplete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description only elaborates on the 'value' parameter (IOC) implicitly. The 'limit' parameter is not explained, and the description adds minimal meaning beyond the schema's type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool investigates an IOC using MISP matches, events, tags, and warninglists. It differentiates from siblings like check_warninglists (which only checks warninglists) and search_ioc (which may only search) by implying a broader aggregation. However, 'investigate' is somewhat vague and could be more specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 explain_event_context or search_ioc. The description only states what it does, leaving the agent to infer usage context without explicit exclusions or recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List configured MISP feeds in a bounded, redacted response.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| enabled | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions 'bounded, redacted response', hinting at pagination or truncation and possible field removal. However, it does not disclose whether this is a read-only operation, authentication requirements, or any side effects. Some transparency but insufficient for full behavioral clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action verb, making it easy to scan. It is concise but might be slightly under-specified. However, no unnecessary words are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters and an output schema (not shown), the description is minimal. It does not explain pagination, default behavior, filtering via 'enabled', or the nature of 'redacted'. For a list tool, completeness is lacking, especially with no parameter descriptions in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the parameter definitions lack descriptions. The description does not mention the 'limit' or 'enabled' parameters at all, failing to explain their purpose or effect. This leaves the agent without crucial context for parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists configured MISP feeds, using the verb 'List' and specifying the resource 'configured MISP feeds'. The terms 'bounded' and 'redacted' add nuance, indicating constraints on the response. It is distinct from siblings like 'get_feed_status', though not explicitly distinguishing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., get_feed_status). It does not specify context, prerequisites, or exclusions. The agent is left without direction on optimal invocation scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pivot from an IOC to related events and indicators useful for hunting.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| value | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states only that the tool 'pivots' (likely a read operation) but does not confirm lack of side effects, required permissions, or rate limits. 'Pivot' could imply transformation but is ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence) but at the cost of necessary detail. It is front-loaded with the purpose but omits parameter and usage info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (unseen) and many siblings, the description is incomplete. It does not clarify what 'related events and indicators' means or the structure of the output, leaving the agent without sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no details about the two parameters ('value' and 'limit'). It does not explain what format 'value' expects (e.g., IP, hash) or the meaning of 'limit'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Pivot from an IOC to related events and indicators useful for hunting.' It uses a specific verb ('pivot') and resource ('IOC to related events and indicators'), which distinguishes it from sibling tools like 'investigate_ioc' or 'search_ioc'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for hunting contexts but provides no explicit guidance on when to use this tool over alternatives like 'find_related_iocs' or 'search_ioc'. There is no mention of exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build an attribute creation proposal for an existing event. Never writes to MISP.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | ||
| value | Yes | ||
| to_ids | No | ||
| comment | No | ||
| category | No | ||
| event_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description adds one key behavioral trait (never writes to MISP), but lacks detail on side effects, permissions, or other behaviors. It is helpful but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundant information, front-loaded with the core action and key constraint. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no annotations, and an output schema, the description covers core purpose and a behavioral constraint but lacks parameter guidance and usage context for a tool with many siblings. Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only hints at event_id (for an existing event) without explaining type, value, to_ids, comment, or category. It fails to compensate for the lack of parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds an attribute creation proposal for an existing event and explicitly notes it never writes to MISP, distinguishing it from sibling tools like propose_event or publish_event_with_approval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for proposing attributes without writing, but does not explicitly state when to use versus alternatives like submit_ioc_with_approval or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a MISP event creation proposal. Never writes to MISP.
| Name | Required | Description | Default |
|---|---|---|---|
| info | Yes | ||
| tags | No | ||
| analysis | No | ||
| distribution | No | ||
| threat_level_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description clearly discloses that the tool never writes to MISP, which is a key behavioral trait. This is sufficient to inform the agent of its non-destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, front-loaded with the main action. Exceptionally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists (reducing need for return value description), the complete lack of parameter descriptions and no guidance on when to use this tool relative to siblings leaves gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no additional meaning for any of the 5 parameters, leaving the agent to infer from parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Build a MISP event creation proposal' and explicitly says 'Never writes to MISP', which distinguishes it from sibling tools that perform actual writes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for drafting proposals without writing, but does not explicitly state when to use this over alternatives like publish_event_with_approval or other proposal tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publish a MISP event only when policy and approval allow. Requires curator/ admin-like permission and is always high-risk and approval-gated. Otherwise returns a blocked/proposal result.
| Name | Required | Description | Default |
|---|---|---|---|
| approved | No | ||
| event_id | Yes | ||
| approval_token | No | ||
| approval_request_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes required permissions, risk level, and approval gating, which provides some behavioral context beyond an empty annotation set. However, it does not explain what happens upon successful publication (e.g., event state change) or detail the outcome structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, front-loaded with purpose. Efficient for the agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema existing and no annotations, the description fails to explain the approval-related parameters or how to obtain them. The tool is complex (publish with approval), but the description lacks sufficient detail to invoke it correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no explanation for any of the 4 parameters (event_id, approved, approval_token, approval_request_id). The approval workflow parameters are entirely opaque, leaving the agent unable to use them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 condition 'only when policy and approval allow'. It distinguishes from sibling tools (e.g., propose_attribute) by focusing on the publish action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Specifies that curator/admin-like permission is required and it is always high-risk and approval-gated. Also describes the alternative outcome (blocked/proposal result). However, it does not explicitly list when not to use or compare to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover MISP events by bounded date, publication state, and org filters.
| Name | Required | Description | Default |
|---|---|---|---|
| org | No | ||
| limit | No | ||
| date_to | No | ||
| date_from | No | ||
| published | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implies a read-only search but does not disclose pagination behavior, authentication requirements, rate limits, or whether results are summaries or full events. The return value is not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It could be slightly improved by restructuring to front-load the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no schema descriptions, and no annotations, the description is too sparse. It lacks information about output format, sorting, pagination, and how it relates to sibling tools. The presence of an output schema mitigates this only partially.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description maps 4 out of 5 parameters (org, published, date_from, date_to) to natural language, compensating for the 0% schema coverage. However, it does not explain the 'limit' parameter or default values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool discovers MISP events and specifies the filters: bounded date, publication state, and org. However, it does not differentiate from sibling tools like find_events_by_tag which also searches events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. Given the many sibling search/find tools, the description should indicate scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search MISP for an IOC and return normalized attribute matches.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| value | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits like read-only nature, authentication, rate limits, or side effects. Nothing beyond the basic purpose is disclosed, leaving the agent unaware of important nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for a simple search action, though the brevity sacrifices critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters and an output schema (unprovided), the description fails to explain parameter behavior (defaults, required format) or what 'normalized attribute matches' entails. It is insufficient for an agent to reliably invoke the tool without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description fails to explain any parameter semantics. 'value' and 'limit' are assumed to be self-explanatory, but no default behavior or valid formats are described, making it hard for an agent to correctly construct invocation calls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb 'Search', the resource 'MISP for an IOC', and the output 'normalized attribute matches', which is specific and distinguishes it from sibling tools like 'investigate_ioc' or 'find_related_iocs' that focus on different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 exclusions or prerequisites mentioned. The description lacks any usage context, leaving the agent without decision support for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit an IOC (attribute) to MISP only when write is enabled, role permits write, and approval (when required) has been explicitly given. Otherwise returns a blocked/proposal result.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | ||
| value | Yes | ||
| to_ids | No | ||
| comment | No | ||
| approved | No | ||
| category | No | ||
| event_id | Yes | ||
| approval_token | No | ||
| approval_request_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 discloses that it may return a 'blocked/proposal result' if conditions not met, which adds transparency about failure modes. However, it does not describe side effects (e.g., that it creates an attribute in MISP) or success behavior beyond the condition check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that concisely captures the core purpose and conditions. It is appropriately front-loaded and efficient, though leaving out parameter details reduces its effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters (3 required), 0% schema description coverage, and no annotations, the description is insufficient for an agent to use the tool confidently. It lacks details on parameter meanings, especially approval-related fields, and does not explain the return value despite an output schema existing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it provides no explanation of individual parameters. Parameters like approval_token and approval_request_id are critical for the workflow but are not mentioned. The agent would have no guidance on how to use these parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: submitting an IOC to MISP under specific conditions (write enabled, role permits, approval given). It distinguishes from siblings by mentioning the approval workflow, differentiating it from propose_attribute or direct submission tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells when to use: when you have required write permissions and approval. It implies not to use if you want to propose without direct submission (use propose_attribute). However, it could be more explicit about when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize a MISP event without returning full raw event JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'summarize' and 'without returning full raw event JSON,' implying a read operation, but does not describe the output format, side effects, or any authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core purpose. There is no wasted text, though it could benefit from additional concise details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity (one parameter, output schema present), the description lacks crucial context about the summary format and how it differs from similar sibling tools. The agent is left uncertain about what 'summarize' entails relative to alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single parameter event_id. The description adds no meaning beyond the schema, not even explaining what event_id represents or how to obtain it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (summarize) and the resource (MISP event), and distinguishes from returning full raw JSON. However, it does not explicitly differentiate from sibling tools like 'explain_event_context' or 'generate_event_report', which could also provide summaries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. No explicit when-not or prerequisite information is given, leaving the agent to infer usage from the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize configured feed health grouped by health label.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so full burden falls on description. The description does not disclose behavioral traits such as whether it is read-only, authentication needs, or what 'configured feed health' entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It could be improved with additional context, but it is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks detail about grouping behavior, health label meanings, or how the limit parameter affects results. For a simple tool, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the single parameter 'limit' is not mentioned in the description. No meaning added beyond the schema's default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool summarizes configured feed health grouped by health label, using specific verb and resource. It distinguishes from siblings like get_feed_status, which likely returns per-feed status rather than a grouped summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 mention of prerequisites, context, or when to prefer other tools like get_feed_status or list_feeds.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tag a MISP event only when policy and approval allow. Otherwise returns a blocked/proposal result.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | Yes | ||
| approved | No | ||
| event_id | Yes | ||
| approval_token | No | ||
| approval_request_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool may return a 'blocked/proposal result' if conditions aren't met, which adds behavioral context. However, given no annotations, it lacks details on authentication, side effects, or exact behavior of 'proposal'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. Every word adds value, making it concise and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 5 parameters and sibling tools, the description does not cover how parameters relate (e.g., approved vs approval_token), the output schema is missing, and the approval workflow is not explained. Incomplete for a tool with moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of any parameter. Parameter names like 'approved', 'approval_token', and 'approval_request_id' are not described, leaving their meaning unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'tag', the resource 'MISP event', and a specific condition ('only when policy and approval allow'). This differentiates it from potential simpler tag tools and provides a precise purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when policy and approval are required, but does not explicitly state when not to use it or mention alternatives (e.g., a direct tag without approval). The condition is implied, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a specific action and resource, with clear differentiation even among similar functions (e.g., investigate_ioc vs pivot_ioc vs search_ioc). No two tools appear to do the same thing.
All tool names follow a consistent verb_noun pattern in snake_case, using descriptive action verbs like add, check, explain, generate, etc. No mixing of conventions.
19 tools is slightly above the ideal range but still reasonable for MISP's complexity. Each tool serves a distinct purpose within threat intelligence workflows.
The tool set covers core MISP operations: IOC search/analysis, event exploration, report generation, and write actions with approval. Minor gaps like direct event listing are implicit in other tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Enrich, search, assess, and manage threat intelligence through 80+ typed MCP tools.
SOAR security playbooks for AI agents: fetch, full-text search, and count. Metered via Stripe.
Agent-native security, trust, reliability, data and procurement tools for AI workflows.
Hyperion — MCP tool marketplace for AI agents: web, OSINT, security, research via one key.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hdyrawan/agentic-misp-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
