security-intel
Server Details
Daily Ed25519-signed security intelligence for AI-agent stacks; CVEs & advisories, paid via x402.
- 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.3/5 across 11 of 11 tools scored.
Each tool serves a distinct purpose: lockfile scanning (check_affected, scan_dependencies), single CVE/package checks (check_cve, check_package), exploit status (is_exploited), CVE search (search_cves), and report retrieval (get_since, get_items, get_today, get_sample_report, list_available). Overlap between check_affected and scan_dependencies is clearly differentiated by scope and pricing model.
All tools use lowercase_snake_case with an intuitive verb-noun pattern (e.g., check_affected, get_since, list_available, scan_dependencies). Even the boolean check is consistently named is_exploited. No mixed conventions or irregular names.
With 11 tools, the surface is well-scoped for a security intelligence server. It covers different granularities (single CVE, package, lockfile) and access patterns (on-demand checks, polling deltas, full reports) without being overly numerous or minimal.
The tool set provides comprehensive coverage for vulnerability checking and report retrieval. Minor gap: no tool for signature verification or subscription management, but the descriptions link to external verification. CRUD operations are absent, but the server is read-only by design.
Available Tools
11 toolscheck_affectedAInspect
Check your installed packages against recent security advisories.
Pay-per-value: $0 when nothing affects your versions (status all_clear/verify is always free), otherwise priced per confirmed match via x402 — you only pay when you learn you are actually exposed.
Zero-friction input: paste your dependency file straight into lockfile — no need
to hand-extract package/version. Auto-detected formats: package-lock.json,
yarn.lock, requirements.txt (== pins), poetry.lock, Pipfile.lock, go.mod, go.sum,
Cargo.lock, and CycloneDX / SPDX JSON SBOMs. Or pass an explicit components list
of {package, version, ecosystem?} (you may pass both — they are merged).
Built for agents that poll on their own clock: pass since (a cursor) to match
ONLY advisories first published after your last check, so a repeated poll is free
until something NEW hits you — and you pay at most once per new exposure. The
returned cursor is interchangeable with get_since's cursor; store it and pass it
back next time. Use min_severity to ignore (and not pay for) matches below your
threshold.
Returns advisories that affect (or may affect) your versions, each with the primary-source URL so you can verify independently. Trust-safe: when a version range cannot be parsed, or an advisory is product-level (no version data), it is reported as "verify" rather than silently cleared. Pair with the signed report for an auditable trail.
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | optional cursor — only match advisories first published after it. Omit on the first call; pass the returned `cursor` thereafter. | |
| preview | No | if true, return only the shape (counts + max severity) used to quote a price — no advisory bodies. The gateway uses this; you do not need to set it. | |
| lockfile | No | optional raw lockfile or SBOM text — parsed server-side into components (exact pinned versions only). Auto-detected; combine with `components` if you like. Practical size limit ~1MB; for a larger tree, dedupe or send `components` directly. | |
| components | No | optional list of {package, version, ecosystem?}. | |
| min_severity | No | optional floor — one of low|medium|moderate|high|critical. Matches below it are dropped (and not charged for). | |
| lockfile_type | No | optional hint/filename to force the parser (e.g. "go.mod", "requirements.txt", "cyclonedx") when auto-detect is ambiguous. |
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 behavior: pay-per-value pricing, zero-friction auto-detection, polling with cursor, 'verify' status for unparseable ranges, and auditable trail. Covers all critical behavioral aspects.
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?
Well-structured and front-loaded with purpose, then pricing, input formats, polling, and returns. Every sentence adds value but is somewhat lengthy; could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no annotations, and an output schema (not shown but mentioned), the description covers input, pricing, polling, trust model, and return format. Fully addresses the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% but description adds significant meaning: explains when to use each parameter (since for polling, preview for gateway, lockfile vs components, min_severity for filtering, lockfile_type for disambiguation) and practical size limit for lockfile.
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 installed packages against security advisories, using specific verbs and resource. It distinguishes from siblings like get_since by explaining polling and cursor interchangeability.
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 extensive when-to-use guidance: for checking security advisories, with options for polling (since), threshold (min_severity), and input formats. Does not explicitly contrast with siblings but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_cveAInspect
Normalized, SIGNED verdict for a single CVE: CVSS (v3.1/v4.0, authoritative from NVD with OSV fallback), CISA-KEV exploitation status, and EPSS probability.
PAID ($0.01 USDC via x402). Deterministic JSON; the response carries an Ed25519
SSHSIG signature (_signature) you can verify offline — unlike unsigned CVE APIs.
| Name | Required | Description | Default |
|---|---|---|---|
| cve | Yes | a CVE id, 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?
With no annotations, the description fully discloses behavior: deterministic JSON, Ed25519 signature for offline verification, paid nature, and data sources (NVD, OSV, CISA-KEV, EPSS). It clearly states the output includes a '_signature' field and emphasizes the signed verdict aspect.
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 three sentences, front-loading the core purpose, then cost, then signature verification. Every sentence adds value 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 the output schema exists, the description covers all essential aspects: purpose, cost, data sources, signature verification. It is complete for a single-parameter tool with a well-defined output.
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 one parameter (cve). The description adds minimal extra meaning beyond the schema (e.g., 'single CVE' reinforces the purpose). Baseline 3 is appropriate as the schema already documents the parameter sufficiently.
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 provides a 'normalized, SIGNED verdict for a single CVE' with CVSS, CISA-KEV, and EPSS probability. It distinguishes itself from 'unsigned CVE APIs,' making the purpose specific and distinct from sibling tools like search_cves or check_affected.
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 explicitly mentions the cost ($0.01 USDC via x402), alerting the agent to a paid operation. It implies usage for detailed single CVE lookup but does not name alternative sibling tools or provide when-not guidelines. The contrast with unsigned APIs gives some context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_packageAInspect
SIGNED vulnerability verdict for one package version (OSV.dev) with a CISA-KEV flag per matching advisory.
PAID ($0.002 USDC via x402). Deterministic JSON + Ed25519 signature.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | package name (e.g. "lodash", "requests"). | |
| version | No | exact version to test against advisory ranges (recommended). | |
| ecosystem | No | OSV ecosystem (npm, PyPI, Go, crates.io, …). Inferred-as-given; pass it for precise matching. |
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 transparently discloses the tool is paid ($0.002 USDC via x402), returns a deterministic signed JSON with Ed25519 signature, and includes CISA-KEV flag. It doesn't mention rate limits or authentication, but the key behavioral traits are clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two main sentences and a brief note. It front-loads the core purpose and provides essential details without extra 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 the tool has an output schema, the description sufficiently explains the signed verdict nature. It could mention that the verdict includes vulnerability details, but with output schema present, it is complete enough for agent use.
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 overall purpose but does not add specific parameter meaning beyond what the schema provides.
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 a single package version for a signed vulnerability verdict with a CISA-KEV flag, distinguishing it from sibling tools like check_affected or check_cve which likely have different scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for checking a specific package version but does not explicitly state when to use this tool over alternatives like check_affected or is_exploited. No when-not-to or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_itemsAInspect
Full bodies for items you discovered via get_since (PAID — pay-per-value,
priced per delivered item via x402; $0 if none of the ids are found).
get_since gives you a free index (id, title, severity, …) so you can decide
what matters to you; get_items returns the actionable payload — affected
ranges, primary sources, assessment and remediation — only for the ids you ask
for. Each item carries the report_id of the signed report it was first
published in: fetch that report via get_sample_report(run_id=report_id) to
verify the Ed25519 signature yourself.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | item ids (from get_since's index) to retrieve. | |
| preview | No | if true, return only the shape (count + max severity) used to quote a price — no bodies. The gateway uses this; you do not need to set it. |
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. Discloses pay-per-value cost, $0 if no IDs found, and return content (affected ranges, assessment, etc.). Mentions report_id for verification. Missing rate limits or error behavior, but adequate for read-only 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?
Compact ~100 words, front-loaded with main purpose, efficiently explains workflow and cost. No unnecessary 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 output schema and well-described parameters, description covers cost, workflow, verification, relationship to siblings. Comprehensive for a data retrieval 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 descriptions already cover both parameters 100%. Description adds context: ids come from get_since, preview is for gateway use. Enhances understanding beyond 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 returns full bodies for items from get_since, distinguishes from sibling tools like get_since (free index) and get_sample_report (verification). Specific verb 'get' and resource 'items' with actionable payload.
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?
Explicitly positions tool after get_since, explains pricing model and workflow. Mentions not to set preview parameter. However, no explicit when-not-to-use or alternatives beyond implied sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_sample_reportAInspect
FREE preview — yesterday's full report, identical in format and signing to
the paid get_today. Call this first to see exactly what you get before
paying: real curated security items, severities, recommendations, and an
Ed25519 signature you can verify (https://elsas.it/docs#verify). The only
difference from get_today is freshness (this is the previous day's report).
| Name | Required | Description | Default |
|---|---|---|---|
| stack | No | Optional comma-separated filter (same stacks as get_today). | |
| run_id | No | Optional specific report id (from `list_available`). Defaults to the most recent report that is not today's paid one. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the report format, signing (Ed25519), and that it's from the previous day. With no annotations, the description carries the full burden and does so well, though could mention error cases 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?
Three concise sentences, front-loaded with the core purpose. No unnecessary 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?
With an output schema present, return details are covered. Explains purpose, usage, and differences from siblings well. Minor omission: no mention of what happens if no report is available, but overall sufficient.
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 has 100% description coverage, so baseline is 3. The description adds value by explaining the default behavior for run_id (most recent non-today report) and linking the stack filter to get_today's stacks, making it a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool is a free preview of yesterday's report, identical to the paid get_today, with specific list of contents (security items, severities, recommendations, signature). Explicitly distinguishes from sibling get_today.
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?
Explicitly recommends calling this first to preview before paying, and notes the only difference from get_today is freshness, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_sinceAInspect
Delta feed for agents that poll on their own clock: what's new since you
last checked. Free. Pass the cursor from your previous call (omit on first
call); poll as often as you like.
Returns a lightweight index of new items — id, title, item_type, CVE id,
severity, the signed report_id each was published in, and published_at — plus
a new cursor and count. count == 0 means nothing new since you last looked.
To get the full bodies (affected ranges, sources, assessment, remediation) for
what's new, call the paid get_today (or check_affected to test your own deps).
Optional stack filters by relevant_for tags (same as get_today).
Returns: {cursor, count, index}.
| Name | Required | Description | Default |
|---|---|---|---|
| stack | No | ||
| cursor | No |
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 the tool is free, returns only a lightweight index (not full bodies), lists returned fields, explains count==0 means nothing new, and mentions cursor for pagination. 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?
The description is moderately long but well-structured with front-loaded purpose, then usage, return format, and alternatives. Every sentence adds value; could be slightly more concise but overall 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 the output schema exists, the description adequately summarizes return structure (cursor, count, index with fields) and mentions alternatives for full details. Covers the polling workflow well; slight omission on error handling or rate limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description adds rich meaning: cursor is for pagination (pass from previous call, omit first), stack filters by relevant_for tags. This compensates well beyond the schema's type info.
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 provides a delta feed for polling agents, specifying it returns what's new since the last check. It distinguishes itself from siblings by mentioning paid alternatives for full bodies.
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?
Explicitly tells when to use (for polling agents), how to use (pass cursor, omit on first call, poll freely), and when not to (if full bodies needed, use get_today or check_affected). Also explains optional stack filter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_todayAInspect
Today's full curated security report for the MCP / AI-agent ecosystem (PAID — $0.10 USDC, charged automatically via x402 on Base; no account needed).
Returns the latest signed, independently cross-validated digest of security
incidents, advisories (CVE/GHSA/OSV/KEV) and notable changes affecting MCP
servers, agents and their dependencies — each item with severity, why it
matters, and a recommended action. Every report is Ed25519-signed; verify it
yourself (see https://elsas.it/docs#verify). Try it free first with
get_sample_report (yesterday's report, identical format).
| Name | Required | Description | Default |
|---|---|---|---|
| stack | No | Optional comma-separated filter, e.g. "devops,security", to return only relevant items. Stacks: devops, coding, qa, finance, healthcare, legal, content, security, knowledge. |
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 are provided, so the description carries the full burden. It discloses payment (cost, charging mechanism), authentication (x402, no account needed), and report signing (Ed25519, verification link). This covers key behavioral traits beyond mere functionality.
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 front-loaded with the core purpose and includes important details (payment, signing, sample) without redundancy. While slightly verbose, each sentence contributes value, making it efficient for an agent.
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, signed reports, filter parameter) and the presence of an output schema, the description covers the key aspects: purpose, payment model, verification, and sample tool. It does not mention error handling, but for typical agent use it is sufficiently 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% (parameter 'stack' fully described in schema). The description adds no new information beyond what the schema provides; it merely reiterates the filter option and lists stack values, which are already in the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'Today's full curated security report' with specific details about payment, signing, and links to a free sample. It distinguishes itself from siblings like get_sample_report and get_since.
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 when to use this tool (for today's paid report) and suggests trying get_sample_report first. It does not explicitly exclude other contexts but provides clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
is_exploitedAInspect
Fast boolean: is this CVE known-exploited? SIGNED.
exploited is driven by CISA-KEV (authoritative evidence of in-the-wild
exploitation). EPSS (predictive probability) is included as a secondary signal
but does NOT set the boolean — we report observed exploitation, not a forecast.
PAID ($0.001 USDC via x402). Args: cve — e.g. "CVE-2024-3094". Returns: signed {exploited, kev, epss, basis, _signature}.
| Name | Required | Description | Default |
|---|---|---|---|
| cve | Yes |
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 provided, the description discloses key behaviors: it's signed, paid ($0.001 USDC via x402), driven by CISA-KEV, and that EPSS does not set the boolean. It also outlines the return format. This provides good transparency beyond what would otherwise be unknown.
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 slightly verbose but every sentence serves a purpose: stating the goal, explaining the exploitation signal, noting the pricing, and giving an example. It is front-loaded with the primary question, making it 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 the simple tool (one parameter, checklist output schema), the description covers usage, pricing, behavior, and return format. It does not explicitly mention error handling for missing CVEs, but the output schema likely addresses that. Overall, it is sufficiently 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?
The single parameter 'cve' lacks schema description (0% coverage), but the description adds meaning by providing an example ('CVE-2024-3094') and indicating the expected format (CVE identifier). This compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Fast boolean: is this CVE known-exploited?' and explains it uses CISA-KEV for authoritative exploitation evidence. This clearly defines the tool's purpose and differentiates it from sibling tools like 'check_cve' or 'search_cves' which likely provide broader CVE information.
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 mentions this is a 'fast boolean' and provides an example argument, implying quick checks. However, it doesn't explicitly state when to use this tool versus alternatives like 'check_cve', nor does it specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_availableAInspect
List available validated reports. Cheap to call, returns no full bodies. Only shows reports that passed validation (signed, TL;DR, no AUTO-CORRECTED). The current (newest) report is excluded — it's the paid product.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses cheapness, return type (no full bodies), filtering (validated reports), and exclusion of newest report. Provides sufficient behavioral context for a read operation.
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?
Four sentences, no filler. Each sentence adds value: purpose, cost/details, filtering, exclusion. Front-loaded and 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?
For a no-parameter tool with output schema, description covers key aspects: what is listed, filtering, exclusion, cost. Could mention ordering or pagination but overall adequate.
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 defined; schema coverage is 100% (none). Baseline score of 4 applies as per rubric. Description adds no parameter info but provides context about the list contents, which is helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'List' and resource 'available validated reports', including scope (validated only, excludes newest). Purpose is specific and distinct from sibling tools, though differentiation is implicit rather than explicit.
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?
Indicates cheapness and no full bodies, implying use for overview. No direct comparison to sibling tools or explicit when-not-to-use, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_dependenciesAInspect
Bulk OSV scan of a whole lockfile/SBOM — every dependency checked against OSV.dev, KEV-flagged. SIGNED. PAID pay-per-value: billed per vulnerability HIT (dynamic x402, $0 when the whole tree is clean, capped at $0.10).
Unlike check_affected (matches your deps against elsas's curated CURRENT
advisory set), this runs a FULL OSV scan of the entire dependency graph.
| Name | Required | Description | Default |
|---|---|---|---|
| preview | No | gateway-internal — returns only {affected, max_severity} for pricing. | |
| lockfile | Yes | raw lockfile/SBOM text — package-lock.json, yarn.lock, requirements.txt, poetry.lock, Pipfile.lock, go.mod/go.sum, Cargo.lock, CycloneDX/SPDX JSON (auto-detected, ~1MB cap). | |
| lockfile_type | No | optional parser hint/filename. |
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 are provided, so the description carries the full transparency burden. It discloses the tool is SIGNED and PAID with a pay-per-vulnerability-hit model, including pricing caps and zero cost on clean trees. It does not explicitly state whether the scan is read-only or has any side effects, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The main action is front-loaded, and details are packed efficiently. The structure is clean and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but indicated), the description does not need to explain return values. It covers the tool's purpose, differentiation, pricing, and input format. Missing a note on required permissions or size limits (already in schema), but overall sufficiently complete for a scanning 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%, so the baseline is 3. The description adds no new parameter-level detail beyond the schema; it provides overall context about pricing and scan scope but does not elaborate on individual parameters beyond what the schema already provides.
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 performs a bulk OSV scan of a lockfile/SBOM, checking every dependency against OSV.dev with KEV-flagging. It explicitly distinguishes itself from the sibling check_affected by emphasizing it runs a 'FULL OSV scan of the entire dependency graph' versus a curated set.
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 explicitly compares to check_affected, indicating when to use this full scan vs the curated alternative. However, it does not provide explicit when-not-to-use or other exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_cvesAInspect
SIGNED keyword search over the NVD CVE corpus, each result enriched with a CISA-KEV flag.
PAID ($0.01 USDC via x402). Deterministic JSON + Ed25519 signature.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | max results (1–50, default 20). | |
| since | No | optional ISO date (YYYY-MM-DD); only CVEs published on/after it. | |
| keyword | Yes | free-text (matched by NVD keywordSearch), e.g. "langchain rce". |
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 behavioral traits: paid tool ($0.01 USDC) and deterministic JSON with Ed25519 signature. It does not describe any side effects or destructive actions, but for a search tool these are minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three sentences, each serving a purpose: functionality, payment info, and output format. 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 the complexity (search, enrichment, payment), the description covers the essentials. Output schema exists, so return values are documented. Minor missing aspects like pagination or error handling, but not critical.
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 the schema already documents parameters. The description adds no additional parameter-level details beyond the schema, earning a baseline score of 3.
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 performs a 'SIGNED keyword search over the NVD CVE corpus' with enrichment from CISA-KEV, distinguishing it from sibling tools like check_cve or scan_dependencies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when/when-not guidance or alternatives are provided. The payment mention implies cost-sensitive usage, but no direct context on when to use this vs other search tools.
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!