A
licenseA
qualityC
maintenanceA Model Context Protocol server that facilitates integration with OpenCTI, allowing users to query and retrieve cyber threat intelligence data via a standardized interface.
16
40
MIT
Mallory MCP Server
Officialby malloryai
The Mallory MCP Server provides AI assistants with access to a comprehensive cyber threat intelligence database, enabling real-time queries for vulnerabilities, threat actors, malware, exploits, and related security intelligence.
Core Capabilities:
Vulnerability Intelligence - Find specific CVEs with detailed information including CVSS scores, EPSS predictions, and CISA KEV status; search vulnerabilities with filtering by CVE, UUID, or keywords; retrieve detection signatures, exploitation records, and vulnerable configurations (CPE data) to identify affected products and versions.
Threat Actor Intelligence - Get detailed threat actor profiles by UUID or name, including TTPs, target sectors, and intelligence mentions; list and search threat actors with filtering and sorting; monitor recent threat actor mentions from intelligence sources to track emerging threats and active campaigns.
Exploitation Tracking - Get specific exploitation records by UUID with details on when/how vulnerabilities were exploited; list exploitation data with filtering to identify actively exploited vulnerabilities and detection methods.
Additional Capabilities - Access malware research, MITRE ATT&CK patterns, breach intelligence, organization security profiles, product security information, advisories, threat intelligence stories, mention monitoring across entities, and search across all entity types.
Key Use Cases - Risk assessment and vulnerability prioritization based on active exploitation; threat intelligence gathering for security briefings; building detection rules from published signatures; asset vulnerability mapping using CPE data; monitoring the threat landscape; incident response investigation and attribution.
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., "@Mallory MCP Serverget details on the latest critical vulnerability affecting Apache servers"
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.
Mallory MCP Server (deprecated)
⚠️ This package is deprecated and no longer maintained.
The local
mallorymcpstdio server has been replaced by Mallory's hosted Remote MCP service. The remote service is fully managed, always up to date, and requires no local install.➡️ Migrate to the Remote MCP service: https://docs.mallory.ai/use/agent/mcp
What changed
mallorymcp was a local MCP server you ran via uvx/pip that proxied the
Mallory API to your AI client over stdio. It is no longer published with new
features and will receive no further updates.
All functionality now lives in the Mallory Remote MCP service, a hosted endpoint you connect your AI client to directly. It exposes the same threat intelligence capabilities (vulnerabilities, threat actors, malware, exploits, organizations, attack patterns, breaches, products, advisories, stories, mentions, search, and sources) without any local package to install or keep up to date.
Related MCP server: Cyberbro MCP Server
How to migrate
Follow the setup guide for your AI client (Cursor, Claude Desktop, Claude Code, and others) here:
https://docs.mallory.ai/use/agent/mcp
Once you've connected the Remote MCP service, you can remove the local server from your MCP client config and uninstall this package:
pip uninstall mallorymcpLicense
Apache 2.0.
Available Tools
10 toolsfind_vulnerabilityA
Find a vulnerability by CVE identifier
Use this tool when you need detailed information about a specific vulnerability, including its severity scores, description, and whether it has been exploited in the wild. This is particularly useful for threat assessment, prioritizing patching, or understanding the technical details of a specific CVE.
Args: cve (str): The CVE to search for
Returns: Dict[str, Any]: Dictionary containing vulnerability details including: - uuid: Unique identifier for this vulnerability record - cve_id: The CVE identifier - description: Detailed description of the vulnerability - created_at/updated_at: Timestamps for record creation and updates - cvss_base_score: Severity score (0.0-10.0, higher is more severe) - cvss_version: Version of the CVSS scoring system used - cvss_vector: Detailed scoring vector showing attack characteristics - cvss_data: List of all available CVSS scores from different sources - epss_score: Exploit Prediction Scoring System score (probability of exploitation) - epss_percentile: Percentile ranking of the EPSS score - cisa_kev_added_at: When CISA added this to Known Exploited Vulnerabilities catalog (if applicable) - weaknesses: List of CWE identifiers associated with this vulnerability - mentions_count: Number of references to this vulnerability - detection_signatures_count: Number of detection signatures available - exploits_count: Number of known exploit implementations - exploitations_count: Number of recorded instances of exploitation in the wild - vulnerable_configurations_count: Number of affected system configurations
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cve | No |
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by explaining what the tool returns (detailed vulnerability data) and its practical applications. It doesn't mention rate limits, authentication needs, or error conditions, but provides substantial behavioral context about the type and structure of information returned.
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?
Well-structured with purpose statement, usage guidelines, and detailed return documentation. The return value section is comprehensive but lengthy; however, every sentence adds value. Could be slightly more concise in the returns section but overall efficient.
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 single-parameter lookup tool with no annotations and no output schema, the description provides complete context: clear purpose, usage guidelines, parameter explanation, and exhaustive documentation of return values. The detailed return field descriptions effectively substitute for a missing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (parameter 'cve' has no description in schema), but the description fully compensates by clearly explaining the parameter: 'cve (str): The CVE to search for'. This adds crucial meaning beyond the bare schema type definition.
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's purpose: 'Find a vulnerability by CVE identifier' with specific details about what information is retrieved (severity scores, description, exploitation status). It distinguishes from siblings like 'get_vulnerabilities' (likely a list operation) by focusing on a single CVE 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?
Explicitly states when to use: 'when you need detailed information about a specific vulnerability' and provides concrete use cases (threat assessment, prioritizing patching, understanding technical details). It differentiates from siblings by specifying this is for detailed info on a single CVE, not lists or other related data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_exploitationA
Get a specific exploitation
Use this to look up exploitation data when you want to know if a vulnerability has been exploited in the wild, and who detected the exploitation. This function retrieves detailed information about a specific exploitation incident using its unique identifier.
Args: identifier (str): The unique UUID of the exploitation to retrieve. Example format: "123e4567-e89b-12d3-a456-426614174000"
Returns: Dict[str, Any]: Dictionary containing detailed exploitation data including: - uuid: Unique identifier for the exploitation - begins_at: When the exploitation was first observed - ends_at: When the exploitation activity ended - count: Number of exploitation occurrences detected - detection_signature_uuid: UUID of the detection signature - detection_signature_name: Name of the detection signature - detection_signature_source: Source of the detection (e.g., vendor, tool) - detection_signature_method: Method used for detection - created_at: When this record was created - updated_at: When this record was last updated
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes |
TDQS
A4/5.0
Behavior3/5
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 describes the tool as a retrieval function for detailed information, which implies it's a read-only operation, but does not explicitly state permissions, rate limits, or error behaviors. It adds some context about what data is returned, but lacks comprehensive behavioral traits like side effects or performance characteristics.
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 well-structured with a clear purpose statement, usage guidelines, and detailed parameter and return value sections. It is appropriately sized and front-loaded, but could be slightly more concise by integrating some details more tightly, as it uses multiple sentences that are all relevant but not minimal.
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 complexity (a single-parameter retrieval tool with no annotations and no output schema), the description is quite complete. It covers purpose, usage, parameter details, and return value structure. However, it lacks explicit behavioral disclosures like error handling or authentication needs, which prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It provides detailed semantics for the single parameter 'identifier', including its type (str), purpose (unique UUID of the exploitation to retrieve), and an example format ('123e4567-e89b-12d3-a456-426614174000'), which adds significant value beyond the basic schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a specific exploitation' and 'retrieves detailed information about a specific exploitation incident using its unique identifier.' It specifies the verb ('get', 'retrieve') and resource ('exploitation', 'exploitation incident'), but does not explicitly differentiate it from sibling tools like 'list_exploitations' or 'get_vulnerability_exploitations', which is why it doesn't reach a score of 5.
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 provides clear context on when to use it: 'Use this to look up exploitation data when you want to know if a vulnerability has been exploited in the wild, and who detected the exploitation.' It implies usage for specific exploitation incidents, but does not explicitly state when not to use it or name alternatives like 'list_exploitations', so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_mentioned_threat_actorsA
Get mentioned threat actors
Use this tool when you need to monitor recent threat actor activities mentioned in threat intelligence sources. This is especially valuable for:
Tracking emerging threats and active threat actors
Monitoring the latest threat intelligence reporting
Identifying which threat actors are currently active or trending
Building situational awareness of the current threat landscape
Obtaining recent summaries of threat actor tactics and campaigns
Unlike list_threat_actors() which returns basic threat actor records, this function returns actual mentions with context from recent intelligence sources.
Args: offset (int, optional): The number of items to skip before starting to collect the result set. Defaults to 0. limit (int, optional): The maximum number of items to return. Minimum value is 1. Defaults to 10. sort (str, optional): Field to sort by - either 'name', 'created_at', or 'updated_at'. Defaults to 'created_at'. order (str, optional): Sort order - either 'asc' or 'desc'. Defaults to 'desc'.
Returns: Dict[str, Any]: Dictionary containing: - total: Total number of threat actor mentions available - offset: Current pagination offset - limit: Number of items returned per page - message: Status message (usually null when successful) - data: List of recent threat actor mentions, each containing: - uuid: Unique identifier for this mention - overview: Summary of the threat actor's recent activities or campaigns - created_at: Timestamp when this mention was first added to the system - updated_at: Timestamp when this mention was last updated - published_at: Original publication date of the source material - collected_at: When this intelligence was collected - reference_url: URL of the source article or report - reference_source: Name of the intelligence source (e.g., "securityaffairs") - reference_user_generated_content: Whether this is from user-generated content - threat_actor_uuid: UUID of the referenced threat actor - threat_actor_name: Name of the referenced threat actor
This function provides timely intelligence about threat actors from recently published sources, making it ideal for staying current on the threat landscape.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | ||
| limit | No | ||
| sort | No | created_at | |
| order | No | desc |
TDQS
A4.7/5.0
Behavior4/5
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 effectively describes the tool's behavior: it's a read operation (implied by 'Get' and 'monitor'), returns paginated results with offset/limit parameters, includes sorting options, and provides detailed return data structure. It also mentions the tool's value for 'timely intelligence' and 'staying current,' though it doesn't specify rate limits or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose statement, usage guidelines, parameter documentation, and return value explanation. While comprehensive (necessary given the lack of annotations and output schema), it's efficiently organized with bullet points for scenarios and a detailed Returns section. Some sentences could be more concise, but overall it's appropriately sized for the complexity.
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 (4 parameters, no annotations, no output schema), the description provides complete context. It covers purpose, usage guidelines, parameter semantics, and a detailed return structure. The Returns section documents all fields in the response dictionary, compensating for the missing output schema. This makes the tool fully understandable to an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage (no descriptions in the input schema), the description fully compensates by providing detailed parameter documentation. It explains all four parameters (offset, limit, sort, order) with their purposes, default values, constraints (e.g., 'Minimum value is 1'), and allowed values (e.g., sort fields and order options). This adds significant meaning beyond the bare 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's purpose as 'Get mentioned threat actors' and elaborates that it returns 'actual mentions with context from recent intelligence sources.' It explicitly distinguishes this from the sibling tool 'list_threat_actors()' which returns 'basic threat actor records,' providing specific differentiation. The description uses precise verbs like 'monitor,' 'track,' and 'obtain' to clarify the action.
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 provides explicit usage guidelines with 'Use this tool when you need to monitor recent threat actor activities mentioned in threat intelligence sources.' It lists five specific scenarios (e.g., 'Tracking emerging threats') and clearly contrasts it with 'list_threat_actors()' as an alternative for basic records. This gives comprehensive guidance on when to use this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_threat_actorA
Get threat actor by identifier
Use this tool when you need detailed intelligence about a specific threat actor or advanced persistent threat (APT) group. This information is valuable for:
Understanding the tactics, techniques, and procedures (TTPs) of threat actors
Researching who might be behind a security incident
Evaluating the sophistication level of potential adversaries
Gathering threat intelligence for security briefings
Understanding which sectors or regions a threat actor typically targets
Args: identifier (str): The identifier of the threat actor - can be either: - UUID (e.g., "a9b46d37-42b8-4b27-8b69-583dbcb2f5e1") - Name (e.g., "dark_cloud_shield")
Returns: Dict[str, Any]: Detailed threat actor information including: - uuid: Unique identifier for this threat actor - name: Machine-readable name (typically lowercase with underscores) - display_name: Human-readable name with proper formatting - created_at/updated_at/enriched_at: Timestamps for record management - gen_description: Generated description (if available) - mentions: List of references to this threat actor from various sources, each containing: - uuid: Unique identifier for this mention - overview: Summary of the threat actor's activities from this source - published_at: When the source material was published - collected_at: When this mention was collected - reference_url: URL of the source material - reference_source: Name of the source (e.g., "talos_intelligence_blog") - reference_user_generated_content: Whether this is user-generated content - Other metadata about the mention and reference
These mentions provide valuable context about the threat actor's:
Known attack vectors and exploited vulnerabilities
Target sectors, regions, or organizations
Tools and malware used
Attribution confidence and alternate names
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | No |
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by describing the tool as a read operation ('Get'), specifying the return format (Dict[str, Any]), and detailing the structure of returned data including timestamps and mentions. It could improve by mentioning potential errors (e.g., if identifier not found) or rate limits, but it provides substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, usage guidelines, args, returns) and uses bullet points for readability. It could be slightly more concise by reducing some detail in the returns section, but overall it's efficient and front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides excellent context by detailing the return structure and use cases. It could improve by explicitly mentioning what happens with invalid identifiers or if no data is found, but it covers most aspects needed for a single-parameter read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It does so by clearly explaining the 'identifier' parameter as accepting either UUID or Name, providing examples of both formats, and specifying it's for retrieving a specific threat actor. This adds crucial meaning beyond the bare 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's purpose as 'Get threat actor by identifier' and specifies it provides 'detailed intelligence about a specific threat actor or advanced persistent threat (APT) group.' It distinguishes from sibling tools like 'list_threat_actors' by focusing on retrieving detailed information for a single actor rather than listing multiple.
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 states 'Use this tool when you need detailed intelligence about a specific threat actor' and provides five specific use cases (e.g., understanding TTPs, researching security incidents). It implicitly distinguishes from 'list_threat_actors' by focusing on single-actor details versus listing, and from other siblings like vulnerability tools by focusing on threat actors specifically.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_vulnerabilitiesA
Get vulnerabilities
Use this tool when you need to search or browse multiple vulnerabilities, such as when:
Discovering recently added vulnerabilities in the database
Searching for vulnerabilities by keywords in their descriptions
Finding all vulnerabilities related to a specific technology
Creating reports on vulnerability trends or statistics
Looking for high-severity vulnerabilities based on CVSS or EPSS scores
Args:
filter (str, optional): A string used to filter vulnerabilities. It can start with specific prefixes:
* cve:: Filter by CVE ID.
* uuid:: Filter by UUID.
* desc:: Filter by description.
* If the filter string matches the pattern CVE- or a UUID pattern, it will be treated as a specific filter.
* If no prefix is provided, it defaults to a description filter.
Defaults to "".
offset (int, optional): The number of items to skip before starting to collect the result set.
Defaults to 0.
limit (int, optional): The maximum number of items to return. Minimum value is 1.
Defaults to 10 (API default is 100).
sort (str, optional): Field to sort by - either 'cve_id', 'created_at', 'updated_at',
'cvss_3_base_score', 'epss_score', or 'epss_percentile'.
Defaults to 'created_at'.
order (str, optional): Sort order - either 'asc' or 'desc'.
Defaults to 'desc'.
Returns: Dict[str, Any]: Dictionary containing: - total: Total number of vulnerabilities matching the filter criteria - offset: Current pagination offset - limit: Number of items returned per page - message: Status message (usually null when successful) - data: List of vulnerability records, each containing: - uuid: Unique identifier for the vulnerability - cve_id: The CVE identifier - description: Detailed description of the vulnerability - created_at/updated_at: Timestamps for record creation and updates - cvss_base_score: Severity score (if available) - cvss_version: Version of the CVSS scoring system used - cvss_vector: Detailed scoring vector - cvss_data: Additional CVSS scoring information - epss_score: Exploit Prediction Scoring System score - epss_percentile: Percentile ranking of the EPSS score - cisa_kev_added_at: Date added to CISA's Known Exploited Vulnerabilities catalog - gen_description/gen_name: Generated content (if available)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | ||
| offset | No | ||
| limit | No | ||
| sort | No | created_at | |
| order | No | desc |
TDQS
A4.5/5.0
Behavior4/5
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 and does so well. It explains the pagination behavior (offset/limit), sorting capabilities, filtering logic with prefix rules, and provides detailed return structure. The only minor gap is not mentioning rate limits or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, usage scenarios, args, returns) and efficiently conveys necessary information. While comprehensive, it maintains good information density with minimal redundancy. The only minor improvement would be slightly tighter phrasing in the usage scenarios section.
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 tool with 5 parameters, 0% schema description coverage, no annotations, and no output schema, the description provides exceptional completeness. It covers purpose, usage guidelines, detailed parameter semantics, and comprehensive return value documentation, making this fully self-contained for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing comprehensive parameter documentation. It explains all 5 parameters in detail, including filter prefixes (cve:, uuid:, desc:), offset/limit pagination logic, sort field options, and order direction. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Get vulnerabilities' and 'search or browse multiple vulnerabilities', which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'find_vulnerability' (singular vs plural), leaving some ambiguity about when to use one over the other.
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 provides excellent usage guidelines with five specific scenarios when to use this tool, including discovering recent vulnerabilities, searching by keywords, finding technology-specific vulnerabilities, creating reports, and looking for high-severity vulnerabilities. This gives clear context for when 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.
get_vulnerability_configurationsA
Get configuration information for a specific vulnerability
Use this tool when you need to understand exactly which systems, products, or versions are affected by a vulnerability. This information is essential for:
Determining if your specific product versions are vulnerable
Planning targeted remediation efforts
Conducting accurate asset vulnerability mapping
Filtering out false positives in vulnerability scanning
Understanding the scope of affected software/hardware configurations
The configuration data follows CPE (Common Platform Enumeration) standards to precisely identify affected systems.
Args: identifier (str): The unique CVE ID or UUID of the vulnerability to retrieve. Example formats: "CVE-2023-1234" or "123e4567-e89b-12d3-a456-426614174000"
Returns: Dict[str, Any]: List of vulnerable configurations for the specified vulnerability, where each configuration contains: - uuid: Unique identifier for this configuration record - cpe_id: Identifier for this CPE configuration - set_id: Identifier for the set this configuration belongs to - is_vulnerable: Boolean indicating if this configuration is vulnerable - vendor/vendor_display_name: The vendor of the affected product - product/product_display_name: The affected product name - product_type: Type of product (e.g., "application", "os") - Version range indicators: - versionStartIncluding/versionStartExcluding: Minimum affected version - versionEndIncluding/versionEndExcluding: Maximum affected version - updateStartIncluding/updateEndIncluding: Update version specifiers - Platform details: - edition: Edition of the product - language: Language of the product - sw_edition: Software edition information - target_sw: Target software environment (e.g., "wordpress") - target_hw: Target hardware environment - other: Additional targeting information - created_at/updated_at: Timestamps for record management - cve_id: The CVE identifier associated with this configuration
An empty list indicates no specific configuration information is available.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes |
TDQS
A4.7/5.0
Behavior4/5
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 effectively describes the tool's behavior: it retrieves configuration data following CPE standards, returns a detailed dictionary structure with specific fields, and clarifies that an empty list indicates no configuration info is available. It doesn't mention rate limits, authentication needs, or error handling, but covers core operational aspects well.
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 well-structured with clear sections (purpose, usage guidelines, parameter details, return format). It's appropriately detailed for a tool with rich output, though slightly lengthy. Every sentence adds value, such as the use cases and CPE standard mention, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (1 parameter but detailed output) and lack of annotations/output schema, the description is highly complete. It covers purpose, usage, parameter details, and a comprehensive return structure with field explanations. The note about empty lists handling edge cases adds robustness, making it sufficient for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must fully compensate. It provides comprehensive parameter semantics: explains the 'identifier' parameter as 'The unique CVE ID or UUID of the vulnerability to retrieve', gives example formats ('CVE-2023-1234' or UUID), and clarifies its purpose. This adds significant value beyond the bare 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's purpose with specific verbs ('Get configuration information') and resources ('for a specific vulnerability'), distinguishing it from siblings like 'get_vulnerabilities' (which likely lists vulnerabilities) or 'get_vulnerability_detection_signatures' (which focuses on detection). It explicitly explains what configuration information entails (affected systems, products, versions).
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 provides explicit guidance on when to use this tool ('Use this tool when you need to understand exactly which systems, products, or versions are affected by a vulnerability') and lists five specific use cases (e.g., determining if versions are vulnerable, planning remediation). It implicitly distinguishes from siblings by focusing on configuration details rather than general vulnerability info or exploitation data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_vulnerability_detection_signaturesA
Get detection signatures for a specific vulnerability
Use this tool when you need to understand how a specific vulnerability can be detected in your environment. Detection signatures provide technical indicators that can help security teams identify if they're exposed to or being targeted by a particular vulnerability. This is particularly useful for:
Building detection rules for security monitoring tools
Understanding the technical indicators of compromise
Verifying if detection capabilities exist for a specific vulnerability
Determining which sources (vendors, researchers) have published detection methods
Args: identifier (str): The unique CVE ID or UUID of the vulnerability to retrieve. Example formats: "CVE-2023-1234" or "123e4567-e89b-12d3-a456-426614174000"
Returns: Dict[str, Any]: List of detection signatures for the specified vulnerability, where each signature contains: - uuid: Unique identifier for this detection signature - source: Origin of the detection signature (e.g., "cisa_kev", "snort", "yara") - method: How the signature was created (e.g., "manual", "automated") - description: Human-readable description of what the signature detects - upstream_id: Original identifier from the source system - created_at: Timestamp when this signature was first added - updated_at: Timestamp when this signature was last modified
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes |
TDQS
A4.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes what the tool returns (detection signatures with technical indicators) and hints at its read-only nature by using 'get' and focusing on retrieval. However, it lacks details on permissions, rate limits, error handling, or pagination, which are important for a tool with security data.
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 and front-loaded: it starts with the core purpose, then usage guidelines, followed by bulleted use cases, and ends with parameter and return details. Every sentence adds value, with no redundancy or fluff, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and low schema coverage, the description does an excellent job covering purpose, usage, parameters, and return structure. It explains the return format in detail, compensating for the lack of output schema. However, it could improve by mentioning potential limitations (e.g., data availability, authentication needs) given the security context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides detailed semantics for the single parameter 'identifier', explaining it as 'The unique CVE ID or UUID of the vulnerability to retrieve' with example formats. This adds significant value beyond the bare schema, fully documenting the parameter's purpose and format.
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's purpose: 'Get detection signatures for a specific vulnerability.' It specifies the verb ('get'), resource ('detection signatures'), and scope ('for a specific vulnerability'), distinguishing it from siblings like 'get_vulnerability' or 'get_vulnerability_configurations' that focus on different aspects of vulnerability data.
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 states when to use this tool: 'Use this tool when you need to understand how a specific vulnerability can be detected in your environment.' It provides specific use cases (e.g., building detection rules, verifying detection capabilities) and implicitly distinguishes it from siblings by focusing on detection signatures rather than configurations, exploitations, or threat actors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_vulnerability_exploitationsA
Get exploitation data for a specific vulnerability
Use this tool when you need to determine if a vulnerability has been actively exploited in the wild. This information is critical for risk assessment, incident response, and prioritization of remediation efforts. Exploitation data can help you:
Validate that a vulnerability is being actively used by threat actors
Understand when exploitation began and if it's ongoing
Identify which detection mechanisms observed the exploitation
Determine the frequency or prevalence of exploitation (count)
Make data-driven decisions about patching priorities
Args: identifier (str): The unique CVE ID or UUID of the vulnerability to retrieve. Example formats: "CVE-2023-1234" or "123e4567-e89b-12d3-a456-426614174000"
Returns: Dict[str, Any]: List of exploitation records for the specified vulnerability, where each record contains: - uuid: Unique identifier for this exploitation record - begins_at: Timestamp when exploitation was first observed - ends_at: Timestamp when exploitation activity ended - count: Number of exploitation occurrences detected - created_at: Timestamp when this record was first added - updated_at: Timestamp when this record was last modified - detection_signature_uuid: UUID of the signature that detected this exploitation - detection_signature_name: Name of the detection signature - detection_signature_source: Source of the detection (e.g., "cisa_kev") - detection_signature_method: Method used for detection (e.g., "manual")
An empty list indicates no known exploitation events for this vulnerability.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes |
TDQS
A4.7/5.0
Behavior4/5
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 effectively describes what the tool does (retrieves exploitation records), the return format (list of records with detailed fields), and edge cases (empty list indicates no known exploitation). It lacks details on rate limits, authentication needs, or error handling, but provides substantial context beyond basic function.
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 well-structured with a clear purpose statement, usage guidelines, bullet-pointed benefits, and detailed parameter/return sections. While comprehensive, it could be more front-loaded; the core function is stated upfront, but the bullet points, though useful, add length. Every sentence earns its place by adding 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?
Given the tool's complexity (retrieves detailed exploitation data), lack of annotations, and no output schema, the description provides complete context. It explains the tool's purpose, when to use it, parameter details, and a full breakdown of return values, making it self-sufficient for an agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate fully. It does so by clearly explaining the 'identifier' parameter: its purpose (CVE ID or UUID of the vulnerability), format examples ('CVE-2023-1234' or UUID), and that it's required. This adds essential meaning not present in the bare 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's purpose with specific verb ('Get exploitation data') and resource ('for a specific vulnerability'), distinguishing it from siblings like 'get_vulnerability_configurations' or 'list_exploitations'. It explicitly mentions what the tool retrieves (exploitation data) and for what (a specific vulnerability), making its function unambiguous.
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 provides explicit guidance on when to use this tool: 'Use this tool when you need to determine if a vulnerability has been actively exploited in the wild.' It lists specific use cases (risk assessment, incident response, prioritization) and contrasts with siblings by focusing on exploitation data for a single vulnerability, unlike 'list_exploitations' which might list multiple or 'get_vulnerability_configurations' which handles different data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_exploitationsA
Get exploitation data
Use this to look up exploitation data when you want to know if vulnerabilities have been exploited in the wild, and who detected the exploitations. This function retrieves a list of exploitation incidents with filtering and sorting options.
The data can help identify:
Recent exploitations in the wild
Which detection signatures identified the exploitations
Frequency of exploitation activities (count)
Timeframes of exploitation activities
Args: offset (int, optional): The number of items to skip before starting to collect the result set. Defaults to 0. limit (int, optional): The maximum number of items to return. Minimum value is 1. Defaults to 10 (API default is 100). sort (str, optional): Field to sort by - either 'count', 'created_at', or 'updated_at'. Defaults to 'created_at'. order (str, optional): Sort order - either 'asc' or 'desc'. Defaults to 'desc'.
Returns: Dict[str, Any]: Dictionary containing: - data: List of exploitation records with fields including: - uuid - begins_at - ends_at - count - detection_signature_uuid - detection_signature_name - detection_signature_source - detection_signature_method - created_at - updated_at
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | ||
| limit | No | ||
| sort | No | created_at | |
| order | No | desc |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool retrieves data (implying read-only, non-destructive) and mentions filtering/sorting options, but lacks details on rate limits, authentication needs, error handling, or pagination behavior beyond offset/limit. It adds some context (e.g., data helps identify specific insights) but doesn't fully cover behavioral traits for a tool with 4 parameters.
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 well-structured with a purpose statement, usage context, bulleted insights, and detailed parameter explanations. It's appropriately sized for a tool with 4 parameters and no output schema. However, the bulleted list could be more concise, and some redundancy exists (e.g., repeating 'exploitation' in insights).
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 4 parameters with 0% schema coverage and no output schema, the description does a good job explaining inputs and returns. It details parameter semantics and provides a clear return structure with field examples. However, it lacks output schema details like data types or nested objects, and doesn't address error cases or behavioral constraints, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides detailed semantics for all 4 parameters: offset (items to skip), limit (max items, with min and default noted), sort (fields to sort by), and order (sort direction). It includes default values, constraints (e.g., 'Minimum value is 1'), and clarifies API defaults, adding significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Get exploitation data' and specifies it retrieves 'a list of exploitation incidents with filtering and sorting options.' It distinguishes from siblings like 'get_exploitation' (singular) by indicating it returns multiple records. However, it doesn't explicitly differentiate from 'get_vulnerability_exploitations' or 'list_threat_actors' in terms of scope or focus.
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 provides clear context for when to use it: 'when you want to know if vulnerabilities have been exploited in the wild, and who detected the exploitations.' It also lists specific use cases (e.g., identifying recent exploitations, detection signatures). However, it doesn't explicitly state when NOT to use it or name alternatives among siblings, such as 'get_vulnerability_exploitations' for a different scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_threat_actorsA
Get threat actors
Use this tool when you need to search, browse, or list multiple threat actors. This is particularly useful for:
Discovering recently added threat actors in the database
Searching for specific threat actors by name
Creating reports on threat actor landscapes
Building comprehensive threat intelligence briefings
Comparing multiple threat actors
Args:
filter (str, optional): A string used to filter threat actors. It can start with specific prefixes:
* name:: Filter by Name.
* uuid:: Filter by UUID.
* If no prefix is provided, it defaults to a name filter.
Defaults to "".
offset (int, optional): The number of items to skip before starting to collect the result set.
Defaults to 0.
limit (int, optional): The maximum number of items to return. Minimum value is 1.
Defaults to 10 (API default is 100).
sort (str, optional): Field to sort by - either 'name', 'created_at', or 'updated_at'.
Defaults to 'created_at'.
order (str, optional): Sort order - either 'asc' or 'desc'.
Defaults to 'desc'.
Returns: Dict[str, Any]: Dictionary containing: - total: Total number of threat actors matching the filter criteria - offset: Current pagination offset - limit: Number of items returned per page - message: Status message (usually null when successful) - data: List of threat actor records, each containing: - uuid: Unique identifier for the threat actor - name: Machine-readable name (typically lowercase with underscores) - display_name: Human-readable name with proper formatting - gen_description: Generated description (if available) - misp_uuid: Reference ID in MISP (Malware Information Sharing Platform) - created_at: Timestamp when this record was first added - updated_at: Timestamp when this record was last modified - enriched_at: Timestamp when this record was last enriched with additional data
Note: This function returns summary information about threat actors. To get detailed information including mentions and intelligence sources for a specific threat actor, use the get_threat_actor() function with the uuid or name.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | ||
| offset | No | ||
| limit | No | ||
| sort | No | created_at | |
| order | No | desc |
TDQS
A4.7/5.0
Behavior4/5
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 effectively describes the tool's behavior including pagination (offset/limit), filtering capabilities, sorting options, and return format. It also clarifies that this returns summary information rather than detailed intelligence. The only minor gap is lack of explicit mention about rate limits or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, use cases, args, returns, note) and efficiently communicates necessary information. While comprehensive, it maintains focus without unnecessary verbosity. The only minor improvement would be slightly tighter phrasing in the use cases section.
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 tool with 5 parameters, 0% schema description coverage, no annotations, and no output schema, the description provides complete context. It covers purpose, usage guidelines, detailed parameter explanations, return format documentation, and sibling tool differentiation. This gives the agent everything needed to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema description coverage, the description fully compensates by providing comprehensive parameter documentation. It explains each of the 5 parameters in detail, including default values, valid values for sort and order fields, filter prefix behavior, and practical usage guidance. This adds significant value beyond what the bare schema provides.
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's purpose with specific verbs ('search, browse, or list multiple threat actors') and distinguishes it from sibling tools by explicitly mentioning get_threat_actor() as the alternative for detailed information. It goes beyond just restating the name by explaining the scope and functionality.
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 provides explicit guidance on when to use this tool ('when you need to search, browse, or list multiple threat actors') and when not to use it (directing users to get_threat_actor() for detailed information). It includes specific use cases and clearly distinguishes from the sibling tool for detailed lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
A4.4/5.0
Disambiguation4/5
Most tools have distinct purposes focused on different aspects of threat intelligence (vulnerabilities, threat actors, exploitations), but there is some overlap between 'get_exploitation' and 'get_vulnerability_exploitations' that could cause confusion. The descriptions help clarify that one is for a specific exploitation incident and the other is for exploitations of a specific vulnerability, but the naming doesn't make this distinction clear.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with snake_case throughout. The naming convention is predictable with 'get_' for retrieving specific items, 'list_' for collections, and 'find_' for search operations, creating a coherent naming scheme.
Tool Count5/5
With 10 tools, this server is well-scoped for a threat intelligence domain. Each tool serves a distinct purpose in vulnerability analysis, threat actor intelligence, and exploitation tracking, providing comprehensive coverage without being overwhelming.
Completeness5/5
The tool set provides complete coverage for threat intelligence operations with clear CRUD-like patterns: find/get vulnerabilities, get vulnerability configurations/detection signatures/exploitations, list/get threat actors, and get/list exploitations. There are no obvious gaps for the stated domain of vulnerability and threat actor intelligence.
Maintenance
ActivityStale
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Cybersecurity MCP server for URL scanning, threat intelligence, and domain reputation.
AI-security knowledge as MCP: standards-mapped tools (OWASP, NIST, MITRE) for AI agents.
MCP server for building and testing AI agents with multi-model experimentation and insights.
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
Related MCP Servers
- AlicenseAqualityAmaintenanceAn MCP server that extracts Indicators of Compromise (IoCs) from unstructured text and checks their reputation across multiple threat intelligence services. It enables real-time analysis of IPs, domains, hashes, and URLs, providing enriched context for security workflows within LLMs.519MIT
- FlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that connects AI assistants to MISP threat intelligence platforms. It enables threat intelligence search, IOC lookup, and event analysis through natural conversation.
- FlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that connects AI assistants to OpenCTI threat intelligence platforms. It enables natural language interaction for searching threat intelligence, analyzing reports, managing indicators, and monitoring connectors.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/malloryai/mallorymcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server