misp-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct operation: lookup single vs batch, submit single vs batch, event retrieval vs search, correlation, feed stats, status check, and audit submissions. No overlap in purpose.
Naming Consistency5/5
All tools follow a consistent `misp_<verb>_<object>` pattern in snake_case (e.g., `misp_lookup_ioc`, `misp_submit_iocs`). Singular/plural variations are appropriate for batch operations.
Tool Count5/5
10 tools cover the core MISP IOC operations (lookup, submit, correlate) plus event reading, feed stats, and status checks. The count is well-scoped for a focused threat intelligence server.
Completeness4/5
Core workflows (IOC lookup, submission, correlation, event retrieval) are covered. Minor gaps like tag management or event creation for general use are missing but not critical for the server's apparent purpose.
Average 4.4/5 across 10 of 10 tools scored. Lowest: 3.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 21 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable context: redacted hits for TLP:AMBER/RED events, the structure of the summary verdict, and the caveat that 'seen_in_misp: false' does not imply safety. This exceeds what annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long. The first efficiently states the purpose. The second is lengthy but necessary to describe the output structure and key behaviors. No wasted words, though the second sentence could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (IOC lookup with redacted hits and summary verdict) and the presence of an output schema, the description covers essential behavioral aspects including redaction policy and verdict interpretation. Sibling tools exist, but the description adequately distinguishes this tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite context signals reporting 0% schema description coverage, the provided input schema includes descriptions for both parameters ('ioc' and 'limit'). The tool description does not repeat parameter details, but the schema already provides adequate semantic meaning, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches MISP for sightings of an indicator (IP, domain, URL, or file hash). It uses a specific verb ('Search') and resource ('MISP') and distinguishes from siblings like misp_lookup_iocs (plural) and misp_correlate_ioc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives like misp_correlate_ioc or misp_submit_ioc. It mentions that 'seen_in_misp: false' does not mean the indicator is safe, but no when-to-use or when-not-to-use criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly and non-destructive behavior. The description adds value by detailing the exact JSON output format, including the enabled_feeds array with id, name, and provider fields, which annotations do not cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences: one for purpose, one for output format. No extraneous words, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (no parameters, clear output schema in description), it is nearly complete. Minor gap: no mention of edge cases like zero feeds, but that is acceptable for a straightforward read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the description correctly omits parameter details. It effectively communicates the tool's stateless, input-free nature, meriting a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Summarize the instance's threat feeds', using a specific verb and resource. The explicit listing of the JSON output structure differentiates it from sibling tools like misp_instance_status, which likely returns overall instance health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. However, the zero parameters and clear purpose implicitly indicate it's for retrieving aggregate feed statistics. Could mention it's not for individual feed details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses restricted response for TLP:AMBER/RED events, return structure, and attribute limit. Adds value beyond readOnlyHint and idempotentHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise at ~100 words, front-loaded with purpose, structured with return format and restriction note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers return structure and special case; output schema details provided. Lacks error case handling (e.g., event not found) but annotations cover safety and idempotency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema_description_coverage is 0% per context, so description should compensate. It mentions numeric ID and max_attributes but not format details (schema has them). Adds some context but limited.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Fetch one MISP event by numeric ID', listing returned elements. It distinguishes from sibling tools like misp_search_events which retrieves multiple events, and others for IOC lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes when to use (fetch by ID) but does not explicitly contrast with siblings like misp_search_events for bulk searching. No guidance on when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly, idempotent, non-destructive. Description adds critical behavioral info: 'Attributes from TLP:AMBER/RED events are skipped entirely unless the operator has opted in to restricted content.' This goes beyond annotations, fully disclosing limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states function and use case, second summarizes output and security handling. Every word serves a purpose. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers purpose, output format, and security constraints. Given output schema existence and simple parameter set, it is adequately complete. Could mention error scenarios or pagination but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema already describes both parameters (ioc and limit) with good detail, including acceptable formats and constraints. The description adds no additional parameter semantics beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists other indicators in the same MISP event as a given IOC, with explicit examples (IPs, domains, hashes). It distinguishes from sibling tools like misp_lookup_ioc by focusing on co-occurrence rather than existence check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explains it is 'useful for pivoting from one indicator to related infrastructure', providing clear usage context. However, it does not explicitly state when not to use it or compare to alternatives like misp_lookup_ioc, which could be improved.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating safe, read-only behavior. The description adds value by detailing the return format (JSON with specific fields) and the handling of restricted events (only id and restricted:true unless opted in). This goes beyond annotations, but does not conflict with them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three sentences covering purpose, usage constraint, and return format. It is front-loaded with the main action and avoids unnecessary details. Every sentence adds value, making it efficient for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (1 parameter with nested properties, output schema present), the description covers key aspects: filters, constraint, return structure, and restricted event handling. It does not detail pagination or attribute search scope, but those are adequate for a metadata search tool. The output schema fills any gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides detailed descriptions for each parameter (e.g., tag, keyword, dates), so schema description coverage is high, setting a baseline of 3. The description adds the critical constraint that at least one filter is required, which is not evident from the schema alone. This cross-parameter guidance enhances semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Search MISP event metadata by title keyword, tag, and/or date range', specifying the verb (search), resource (MISP event metadata), and scope. It distinguishes itself from siblings like misp_get_event (single event retrieval) by focusing on metadata search. The output format is also described, reinforcing purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mandates 'At least one filter must be provided' and explains that unfiltered listing is refused, providing a critical constraint. However, it does not mention alternative tools for similar tasks, such as misp_get_event for retrieving a single event by ID. The guidance is clear but could be improved by referencing siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant detail beyond annotations: it explains the batch behavior, return format, error handling for invalid indicators, and clarifies that total_hits=0 does not imply safety. This fully discloses behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, front-loading the purpose and using bullet points for the response format. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's batch nature and presence of output schema, the description covers all essential aspects: response format, error handling, and interpretation of results. It is complete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already contains detailed descriptions for both parameters (iocs and limit_per_ioc). The tool description adds no additional parameter-specific information, maintaining baseline adequacy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool triages multiple indicators at once and returns a compact per-IOC summary, distinguishing it from the sibling misp_lookup_ioc which provides full hit detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends using this tool instead of many single lookups when triaging an IOC list. It also contrasts with misp_lookup_ioc for full detail, providing clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds significant behavioral detail: how submitted_by/reporter/justification are parsed from comments, that attributes added via MISP UI will have empty fields, and the exact structure of the JSON return. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief yet comprehensive: first sentence states purpose and use case, second paragraph explains parsing behavior and caveat about UI-added attributes, third paragraph shows return JSON format. No redundant sentences; information is front-loaded and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple optional filters, special parsing, output schema exists), the description covers all relevant aspects: purpose, usage guidance, behavioral quirks, return format, and parameter semantics indirectly. It leaves no critical gaps for an AI agent to understand how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Each parameter in the input schema has its own description (e.g., days, limit, event_id, only_to_ids, submitted_by), so schema coverage for parameters is high. The description adds no new information about parameters beyond what the schema provides, making the added value minimal. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the tool audits recent additions to the submissions event, lists what it reveals (indicators, who, when, detection flags), and distinguishes it clearly from sibling tools like misp_submit_ioc (submission) and misp_search_events (general search). Purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description advises using it 'to spot bad or unwanted IOCs and who submitted them,' which provides a clear use case. It also explains limitations (UI-added attributes lack fields) but does not explicitly mention when not to use it or suggest alternatives. However, the context of siblings makes this implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes live submission (no proposal), exact JSON return structure, submitter authority vs reporter field, rate limiting, and guardrails. Adds significant value beyond annotations (readOnlyHint=false, etc.) with no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with purpose, concise at ~150 words, and well-organized into prerequisites, usage warnings, behavioral notes, and return format. No redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers prerequisites, security considerations, behavioral details, and output structure. With output schema present and detailed schema descriptions, the description is fully adequate for correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema already has detailed descriptions for all parameters (high coverage). The description adds minor context like 'to_ids must be set explicitly' but does not significantly enhance parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds an indicator to MISP's Community IOC Submissions event. It uses specific verb 'Add' and resource 'indicator to event', distinguishing it from lookup tools like misp_lookup_ioc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly warns against submitting untrusted indicators from MISP, requires write-capable MISP key, notes guardrails and rate limits. Could mention alternatives like misp_lookup_ioc more directly, but provides strong contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description goes beyond by detailing the return structure (JSON with reachable, misp_version, server_version) and error handling (returns an error string explaining what to fix), which is valuable context not in the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured sentences: first states the primary purpose and usage context, second details the return format. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with full annotations and an output schema, the description is complete. It covers purpose, usage context, return format, and error scenarios, leaving no ambiguity for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description naturally has no parameter details. With 100% schema coverage (no params), a baseline of 4 is appropriate since no additional param meaning is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies that the tool checks MISP reachability, validates the configured API key, and reports versions. It explicitly labels itself as a 'connectivity/auth smoke test,' distinguishing it from sibling tools like misp_lookup_ioc or misp_submit_ioc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'to run first when other tools fail,' providing explicit usage guidance. It implies this is the initial diagnostic tool, and its simple scope teaches an agent when not to use it (e.g., for specific data operations handled by siblings).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses guardrails (validation, rejection, safelist, rate limit), batch sharing of fields, and return JSON structure. Annotations provide hints, but description adds rich behavioral context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: purpose first, then details, then return format. No wasted sentences; each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage, behavioral details, and return format. Despite no output schema, the JSON structure is documented. Complete for a batch submission tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by explaining batch behavior, dry_run workflow, and shared fields. Schema has some descriptions, but description integrates them into a coherent narrative. Schema coverage is high, so baseline 3, plus extra context gives 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates and adds many indicators in one call, specifically for adding a list from a report. It distinguishes from siblings like misp_submit_ioc (single) and misp_lookup_iocs (lookup).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly guides usage with dry_run=true for review, then dry_run=false to add. It implies when to use the batch tool vs single submit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![misp-mcp MCP server](https://glama.ai/mcp/servers/indranilroy99/misp-mcp/badges/card.svg)](https://glama.ai/mcp/servers/indranilroy99/misp-mcp)

Score Badge

Copy to your README.md:

[![misp-mcp MCP server](https://glama.ai/mcp/servers/indranilroy99/misp-mcp/badges/score.svg)](https://glama.ai/mcp/servers/indranilroy99/misp-mcp)

Latest Blog Posts

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

MCP directory API

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

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

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