Cybersecurity Threat Intelligence MCP
Server Details
CVE search, vulnerability database, EPSS exploit prediction, KEV, IP reputation & threat feed.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.1/5 across 7 of 7 tools scored.
Each tool targets a distinct aspect of threat intelligence: domain vs IP checks, CVE detail vs search, vulnerability scanning, threat feed, and protocol info. No significant overlap.
All names use lowercase underscores, but mix verb_noun patterns (check_domain, search_cve) with noun-only (cve_detail, threat_feed). Still predictable and readable.
7 tools cover the essential functions for a threat intelligence MCP server without being excessive. Each tool serves a clear purpose.
Covers indicator lookup, vulnerability info, and threat feed. Missing hash/URL checks, but the set is functional for common threat intel tasks.
Available Tools
7 toolscheck_domainAInspect
Threat indicators associated with a domain — OTX pulse associations and threat classification.
PAID: $0.01 USDC per query after the daily free allowance (25/day). On a 402, pay the returned Solana memo and re-call with the SAME args plus payment_tx=. An Authorization: Bearer fnet_ key bypasses it.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | the domain to check, e.g. "example.com". | |
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| payment_tx | No | Solana tx signature, when re-calling after a 402. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively discloses the paid nature, free allowance, 402 error handling, and bypass via API key. It is transparent about the payment flow and error recovery, though it does not explicitly state if the operation is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear front-loaded purpose statement followed by necessary payment details. It is efficient but could be slightly more structured for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (paid, error handling), the description covers the key behavioral aspects. The output schema is present, so return value details are not required. It adequately completes the picture for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds context about the payment_tx parameter's role in handling 402 responses, but does not significantly enhance understanding beyond the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves threat indicators for a domain, specifically OTX pulse associations and threat classification, distinguishing it from sibling tools like check_ip (IP-based) and cve_detail (CVE-specific).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks explicit guidance on when to use this tool versus alternatives like check_ip or threat_feed. It only implies usage for domain threat indicators, with no when-not or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_ipAInspect
IP reputation check — abuse reports, threat type, confidence, ISP, and OTX pulse associations for an IP, combining AbuseIPDB + AlienVault OTX.
PAID: $0.01 USDC per query after the daily free allowance (25/day). On a 402, pay the returned Solana memo and re-call with the SAME args plus payment_tx=. An Authorization: Bearer fnet_ key bypasses it.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| ip_address | Yes | the IPv4 address to check. | |
| payment_tx | No | Solana tx signature, when re-calling after a 402. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the paid nature, free tier, and re-call mechanism on 402 errors. However, it does not mention rate limits, error handling beyond payment, or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with no wasted words. It front-loads the purpose and separates payment details clearly. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers tool purpose, sources, and payment model. It lacks mention of error responses besides 402, but otherwise is sufficiently complete for a reputation-check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds context beyond the schema: it explains agent_id scopes free-tier counter and payment_tx usage on 402. This extra guidance improves parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks IP reputation, specifying the data returned (abuse reports, threat type, confidence, ISP, OTX pulse associations) and the sources (AbuseIPDB + AlienVault OTX). This distinguishes it from sibling tools like check_domain (domain reputation) and cve_detail (CVE info).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides instructions on payment and free allowance, but does not explicitly guide when to use this tool versus siblings. It implies usage for IP reputation checks, but lacks direct comparisons or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cve_detailAInspect
Full record for a single CVE — CVSS v3 breakdown (score/severity/vector/ attack vector/complexity), EPSS exploit probability + percentile, CISA KEV status + due date, CWE, affected products, and references. FREE.
| Name | Required | Description | Default |
|---|---|---|---|
| cve_id | Yes | e.g. "CVE-2021-44228". |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden of behavioral disclosure. Only mentions 'FREE' but does not clarify that this is a read-only operation, nor any authentication, rate limits, or side effects. For a retrieval tool, more explicit transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that efficiently conveys the tool's purpose and key output fields. No wasted words; front-loaded with 'Full record for a single CVE'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description lists many output fields (CVSS, EPSS, CISA KEV, etc.), and context indicates there is an output schema. For a single-record retrieval tool, this is fairly complete. Minor omission: no mention of error conditions or when CVE not found.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameter (cve_id) with an example. Description adds no additional semantic meaning beyond what schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns a full record for a single CVE with specific data fields like CVSS v3 breakdown, EPSS, CISA KEV, etc. Distinguishes from sibling tools like 'search_cve' which likely returns multiple results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use when needing detailed information on a known CVE ID, but no explicit guidance on when to use versus alternatives like 'search_cve' or 'vulnerability_scan'. No exclusions or prerequisites stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mint_infoAInspect
FoundryNet Data Network info + MINT Protocol details. FREE.
Returns how to attest your agent's security analysis with MINT Protocol for verifiable on-chain proof, the MINT MCP endpoint, and the sister data servers (gov-contracts, brand-intel, patent-intel, financial-signals, weather-intel, compliance).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It notes the tool is free and returns specific info. No side effects expected. Adequate behavioral disclosure for a read-only info tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with purpose, then details. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and existing output schema, description provides all necessary context. Lists returned items clearly. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters with schema coverage 100%. No parameter info needed. Baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns info about FoundryNet Data Network and MINT Protocol details. It lists specific contents (attestation, endpoint, sister servers). Distinguishes from sibling tools which focus on individual security checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: when you need MINT Protocol details or network info. Doesn't explicitly state when not to use, but for a simple info tool this is adequate. Sibling names provide additional differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_cveAInspect
Search CVEs (vulnerability database) by keyword, CVSS severity/score, EPSS exploit likelihood, attack vector, recency, or KEV status. Returns CVSS, EPSS, KEV flag, and affected products, newest first.
PAID: $0.01 USDC per query after a daily free allowance (25/day). On a 402, pay the returned Solana memo and re-call with the SAME args plus payment_tx=. agent_id scopes your allowance; an Authorization: Bearer fnet_ key bypasses it.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | max rows (1-200, default 50). | |
| is_kev | No | true → only CISA Known-Exploited Vulnerabilities. | |
| keyword | No | text matched against the CVE description. | |
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| min_cvss | No | minimum CVSS v3 base score (0-10). | |
| min_epss | No | minimum EPSS exploit probability (0-1). | |
| severity | No | critical | high | medium | low. | |
| days_back | No | only CVEs published in the last N days. | |
| payment_tx | No | Solana tx signature, when re-calling after a 402. | |
| attack_vector | No | network | adjacent | local | physical. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses behavioral traits: search functionality, output fields (CVSS, EPSS, KEV flag, affected products, newest first), payment model, daily allowance, and 402 recovery process. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise yet comprehensive, with two paragraphs: first for purpose and filters, second for payment details. Every sentence adds information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters (none required) and an output schema, description covers all key aspects: search scope, output summary, payment, and error handling. Minor omission of other error types, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value by explaining the payment_tx parameter's role in re-calling after a 402 and the agent_id's scoping of free allowance. Other parameters are sufficiently described in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it searches a vulnerability database (CVEs) and lists multiple filter criteria (keyword, CVSS, EPSS, etc.). It distinguishes from siblings like cve_detail (likely for single CVE details) and vulnerability_scan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explains when to use (search by various filters) and includes payment/error handling instructions for 402 responses. Does not explicitly contrast with siblings but provides sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
threat_feedAInspect
Recent threat indicators — the real-time threat-intel feed (IPs, domains, hashes, URLs) from AlienVault OTX pulses + reputation checks, filterable.
PAID: $0.01 USDC per query after the daily free allowance (25/day). On a 402, pay the returned Solana memo and re-call with the SAME args plus payment_tx=. An Authorization: Bearer fnet_ key bypasses it.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| hours_back | No | only indicators seen in the last N hours. | |
| payment_tx | No | Solana tx signature, when re-calling after a 402. | |
| threat_type | No | malware | phishing | botnet | scanner | spam. | |
| indicator_type | No | ip | domain | hash | url. | |
| min_confidence | No | minimum confidence 0-100. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description covers payment behavior ($0.01 after free allowance, 402 handling, auth bypass). Does not detail error responses or rate limits beyond free allowance, but major behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences (if counting the payment part as one) that front-load the purpose and then provide necessary payment instructions. No verbose or redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters and a payment system, the description covers purpose, source, filterability, and payment/auth. Missing details on what 'reputation checks' entails or output format, but output schema exists separately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 6 parameters with descriptions (100% coverage). The description adds value by explaining payment_tx in context of 402, but otherwise parameter details are adequately handled by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns 'recent threat indicators' from 'AlienVault OTX pulses + reputation checks', specifying types (IPs, domains, hashes, URLs). This distinguishes it from sibling tools like check_domain and check_ip which are single-lookup tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for bulk threat intelligence, but does not explicitly contrast with siblings or mention when not to use. It provides clear payment and authentication context, which guides usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
vulnerability_scanAInspect
All known vulnerabilities affecting a product/vendor/CPE, sorted by EPSS (exploit likelihood) with KEV flags — the "should I be worried about this dependency?" tool. Premium.
PAID: $0.02 USDC per query after the daily free allowance (25/day). On a 402, pay the returned Solana memo and re-call with the SAME args plus payment_tx=. An Authorization: Bearer fnet_ key bypasses it.
| Name | Required | Description | Default |
|---|---|---|---|
| cpe | No | a CPE string to match exactly. | |
| vendor | No | vendor name, e.g. "apache". | |
| agent_id | No | stable id for your agent (scopes the free-tier counter). | |
| payment_tx | No | Solana tx signature, when re-calling after a 402. | |
| product_name | No | product/library/software name, e.g. "log4j". |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses premium nature, cost, payment flow for 402 errors, and sorting by EPSS/KEV, but does not mention handling of no results or other error states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with core purpose, followed by essential payment info; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 optional parameters and an output schema, the description covers core function, sorting, and payment, but omits edge cases like empty results or error handling beyond 402.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 5 parameters; the description echoes 'product/vendor/CPE' and payment_tx but adds no extra semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves known vulnerabilities for a product/vendor/CPE, sorted by EPSS with KEV flags, differentiating it from siblings like cve_detail or search_cve.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit payment details and flow after free allowance, but does not explicitly state when to use vs alternatives like check_domain or threat_feed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!