Cybersecurity Threat Intelligence MCP
Server Details
CVE search, vulnerability database, EPSS exploit prediction, KEV, IP reputation & threat feed.
- Status
- Unhealthy
- 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.2/5 across 9 of 9 tools scored.
Each tool targets a distinct resource or action: brief_summary/daily_brief are complementary, check_domain and check_ip are separate IOC types, cve_detail vs search_cve serve different needs, threat_feed vs vulnerability_scan cover feed and scanning, and mint_info is administrative. No overlapping purposes.
Most tools follow a verb_noun pattern (e.g., check_domain, search_cve), with mint_info being the only outlier (noun_noun). The pattern is generally consistent and intuitive.
9 tools is well within the ideal 3-15 range for a cybersecurity threat intelligence server. The tool count balances coverage with clarity, neither overwhelming nor sparse.
The set covers core threat intelligence operations: briefs, IOC checks, CVE lookup/search, threat feed, and vulnerability scanning. Missing hash or URL checks, but the coverage is strong for the stated domain.
Available Tools
9 toolsbrief_summaryAInspect
Get the top 5 signals from today's threat brief as structured JSON — a cheap sample of the full daily_brief. Returns the day's highest-priority items (no prose) so an agent can decide whether to buy the full brief.
PAID: $0.50 USDC (vs $15 for the full daily_brief). Defaults to today (UTC). On a 402, pay the returned Solana memo and re-call with the SAME args plus payment_tx=. An Authorization: Bearer fnet_ key bypasses payment.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | brief date YYYY-MM-DD (default today, UTC). | |
| 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 fully discloses behavioral aspects: returns structured JSON, payment of $0.50, 402 handling with Solana memo and payment_tx, optional Authorization header. Also mentions free-tier counter scoping via agent_id, providing complete transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with purpose. However, the payment flow information is somewhat dense and could be structured more clearly, but it still remains efficient without 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?
Despite complexity (payment, free-tier, 402 handling), the description covers all necessary aspects. With 100% parameter coverage and an output schema, the agent has sufficient information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). The description adds meaning beyond schema: date defaults to today UTC, agent_id scopes free-tier counter, payment_tx for re-call after 402. This enhances 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 it returns the top 5 signals from today's threat brief as structured JSON, distinguishing it from sibling 'daily_brief' by noting it's a cheap sample. Verb 'get' is specific and resource 'top 5 signals' is well-defined.
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?
It provides explicit context on when to use (as a cheap sample), payment details, and re-call procedure. However, it does not explicitly state when not to use or mention other alternatives beyond daily_brief.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_domainAInspect
Check domain reputation — threat indicators, OTX pulse associations, and threat classification for a domain. Threat intel from 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 |
|---|---|---|---|
| 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?
No annotations provided, so description carries full burden. It discloses paid nature, daily free allowance, 402 payment mechanism, and threat intel source (AlienVault OTX). No destructive behavior implied; could add more on error states but sufficient.
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?
Compact description with two sentences plus payment details. No fluff, but payment instructions could be more structured. Still efficient and front-loaded with core purpose.
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 output schema present, description focuses on purpose, parameters, and payment model. Covers key aspects for a threat intel tool. Could mention failure responses beyond 402, 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% for 3 parameters. Description adds context beyond schema: 'domain' example, 'agent_id' scopes free-tier counter, 'payment_tx' triggers re-call after 402. Enhances understanding of workflow.
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?
States specific verb 'Check' and resource 'domain', and details what is checked: reputation, threat indicators, OTX pulse associations, and classification. Clearly distinguishes from siblings like 'check_ip' and '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?
Provides detailed payment instructions including free allowance, 402 handling, and how to use 'payment_tx' or Authorization header. Missing explicit when-not-to-use alternatives, but practical usage context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_ipAInspect
Check IP reputation — abuse reports, threat type, confidence, ISP, and OTX pulse associations for an IP. Threat intel combining AbuseIPDB and 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?
The description discloses payment details, free allowance, 402 handling, and auth bypass, compensating for missing annotations. However, it does not explicitly state read-only, latency, or rate limits.
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 two paragraphs, no fluff, but could benefit from a more structured format separating purpose and payment details.
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 output schema exists, the description covers purpose, data sources, and payment behavior. It lacks mention of response format but that is covered by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no extra parameter meaning beyond the schema. Baseline 3 is appropriate as the schema already documents parameters adequately.
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 and lists specific data elements (abuse reports, threat type, confidence, ISP, OTX pulse associations). It also mentions combining two threat intel sources, distinguishing it from sibling tools like check_domain.
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 does not provide when to use this tool versus alternatives (e.g., check_domain for domains). It lacks explicit context on appropriate use cases 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
Get the full record for a single CVE from the vulnerability database — CVSS v3 breakdown (score/severity/vector/attack vector/complexity), EPSS exploit-prediction probability + percentile, CISA KEV status + due date, CWE, affected products, and references. Sources: NVD, EPSS, CISA KEV, GHSA. 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?
The description lists the data sources and fields returned, giving a clear picture of what the tool does. Since no annotations are provided, the description carries the burden; it adequately describes the read-only behavior but omits error handling or missing CVE scenarios.
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 fairly concise, with a front-loaded purpose followed by a bullet-like list of contents. The word 'FREE.' at the end is somewhat redundant but not harmful.
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 an output schema exists and the description lists the key fields returned, the tool is well-documented for its purpose. The agent can understand exactly what to expect without 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?
The schema has 100% description coverage, so the parameter cve_id is fully documented. The description adds no extra semantic beyond implying the CVE identifier; baseline 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?
The description clearly states the verb 'Get' and the resource 'full record for a single CVE'. It distinguishes from siblings like search_cve by specifying it returns the full record for a single CVE with detailed fields (CVSS, EPSS, CISA KEV, etc.).
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 retrieving a single CVE's full record but does not explicitly state when to use it versus search_cve or other siblings. No when-not or alternative guidance is provided, though sibling names help contextualize.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
daily_briefAInspect
Get the curated daily threat-intelligence brief — the day's most significant signals in one package: critical CVEs with high EPSS exploit-prediction, new CISA KEV additions, the most-exploitable vulnerabilities, and active threat indicators. Threat intel from NVD, CISA KEV, EPSS, GHSA, AbuseIPDB, and OTX. Each brief carries a MINT provenance attestation so a buyer can verify it was produced by this server, unaltered.
PAID: $15 USDC per brief. Defaults to today (UTC); a brief expires at the next midnight UTC. On a 402, pay the returned Solana memo and re-call with the SAME args plus payment_tx=. An Authorization: Bearer fnet_ key bypasses payment.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | brief date YYYY-MM-DD (default today, UTC). | |
| 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. | |
| stripe_token | No | Stripe Checkout Session id (cs_…), when re-calling after paying the Stripe payment link (alternative to x402). Can also be supplied via the X-Stripe-Token header. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses key behaviors: it is a paid tool ($15 USDC), with expiration at midnight UTC, provenance attestation, and payment flow (402 + re-call). It does not mention rate limits or logging, but overall transparency is good.
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 detailed but not overly long, covering essential information in a structured manner. It could be slightly more concise, but every sentence contributes to understanding.
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 provides adequate context on content, cost, payment, and expiration. It covers the necessary operational details for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the payment_tx and stripe_token parameters in context of the payment process, and agent_id for free-tier scoping, going beyond the schema 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 'Get the curated daily threat-intelligence brief' with specific content (CVEs, KEV, EPSS, etc.), distinguishing it from sibling tools that focus on individual entities like domains or IPs.
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 explains when to use (daily), payment cost and process (USDC, Stripe), and re-call instructions on 402. However, it does not explicitly state when not to use this tool in favor of siblings, though the distinct purpose is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mint_infoAInspect
Get FoundryNet Data Network info and MINT Protocol attestation details. FREE.
Returns how to attest your agent's security/threat-intelligence 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, academic-intel, fact-check, oss-intel, social-intel).
| 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?
With no annotations, the description carries full burden; it discloses the return contents (attestation details, MCP endpoint, sister servers) and mentions 'FREE', but does not detail potential rate limits or side effects, though for a read-only info tool this is adequate.
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 highly concise, with two sentences that front-load the core purpose and succinctly list additional return fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description adequately explains what the tool returns, though it could be more explicit about any input requirements or limitations.
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?
No parameters exist, and schema coverage is 100%, so the description adds no parameter-specific info beyond the schema; 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?
The description clearly states it retrieves FoundryNet Data Network info and MINT Protocol attestation details, using a specific verb ('Get') and resource, and it is distinct from sibling tools like search_cve or threat_feed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description implies use for obtaining FoundryNet and MINT info, it lacks explicit guidance on when to use versus alternatives or any prerequisites, such as authentication requirements.
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 in the vulnerability database by keyword, CVSS severity/score, EPSS exploit-prediction likelihood, attack vector, recency, or CISA KEV status. Returns CVSS, EPSS, KEV flag, and affected products, newest first. Threat intel from NVD, EPSS, CISA KEV, and GHSA.
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, so description covers all key behavioral traits: paid nature, free allowance, retry on 402, sources, result ordering. No missing or contradictory info.
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 short paragraphs: first describes functionality, second payment. No unnecessary words, efficient.
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, paid nature, and no annotations, the description covers all essential aspects: filters, return values, payment logic, sources. Output schema exists but not needed in description.
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 detailed descriptions. The tool description summarizes filter types but adds no new parameter info beyond the schema. Baseline 3 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?
Description clearly states the tool searches CVEs with multiple filters and specifies return fields (CVSS, EPSS, KEV flag, affected products) and data sources. Distinguishes from siblings like cve_detail and daily_brief.
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?
Provides explicit context on payment, free allowance, and retry logic for 402 errors. Does not explicitly compare to other tools, but the use case is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
threat_feedAInspect
Pull the recent threat-intelligence feed — real-time threat indicators (IPs, domains, hashes, URLs) from AlienVault OTX pulses and reputation checks, filterable by type, threat, confidence, and recency.
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?
With no annotations, the description discloses payment model, free allowance, per-query cost, 402 handling, and authentication bypass. This provides good behavioral context, though rate limits or response structure are not mentioned.
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 clear paragraphs: first defines the tool, second details payment. Front-loaded with the purpose. Could be slightly more concise, but no wasteful sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 optional parameters, output schema existence, and payment complexity, the description covers purpose, filtering, and payment workflow. Complete for the tool's complexity, though output schema renders return structure explanation unnecessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds context for payment_tx usage but does not significantly enhance understanding beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool pulls a recent threat-intelligence feed with specific indicator types and sources (AlienVault OTX), and lists filterable dimensions. It distinguishes from siblings like check_domain and vulnerability_scan which handle specific 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 includes payment details and retry logic, indicating when to use after a 402, but does not explicitly differentiate when to use this feed versus sibling tools for specific checks. Guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
vulnerability_scanAInspect
Scan a product/vendor/CPE for all known vulnerabilities, sorted by EPSS exploit-prediction likelihood with CISA KEV flags — the "should I be worried about this dependency?" security scanning tool. Threat intel from NVD, EPSS, CISA KEV, and GHSA. 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 covers data sources (NVD, EPSS, CISA KEV, GHSA), sorting, and payment behavior. It lacks details on rate limits or caching but provides sufficient 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads the main purpose but includes lengthy payment details that could be separated. Overall, it is reasonably concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output format description, the tool has an output schema. The description adequately covers functionality, data sources, and payment for a premium tool. Slightly incomplete on usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 5 parameters have schema descriptions, so the tool description adds no new meaning. Baseline score of 3 is appropriate as the schema already documents parameter semantics.
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 scans product/vendor/CPE for known vulnerabilities, with sorting by EPSS and CISA KEV flags. This distinguishes it from sibling tools like cve_detail or search_cve, which focus on individual CVEs.
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 positions the tool as a dependency security scanner and includes payment and retry instructions. However, it does not explicitly state when not to use it or recommend alternatives, slightly reducing clarity.
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!