Skip to main content
Glama
Sign In
@writerslogic/ai-agents-mcp

@writerslogic/ai-agents-mcp

Official
by writerslogic
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

cra_exploit_clock

Check SBOM or purl components against OSV, CISA KEV, ENISA EUVD and EPSS, then compute EU CRA Article 14(2) 24-hour, 72-hour and 14-day vulnerability reporting deadlines with source evidence.

Instructions

CRA Exploited-Vulnerability Evidence and Art. 14 Deadline Clock. Takes a CycloneDX or SPDX JSON SBOM (or a purl list), asks OSV.dev for the advisories that affect each exact component version (OSV evaluates the version ranges per ecosystem), then checks each CVE against the CISA Known Exploited Vulnerabilities catalog and the ENISA EUVD exploited-vulnerability index, and adds FIRST EPSS scores. Returns a per-component verdict, the evidence with source URLs and SHA-256 digests, and the Regulation (EU) 2024/2847 Article 14(2) dates computed in UTC from the awareness time and fix time you supply: early warning within 24 h, notification within 72 h, final report 14 days after a corrective or mitigating measure is available. Also drafts Art. 14(2) content from quoted feed text. Reports evidence and arithmetic, not a legal conclusion. Not legal advice: whether a vulnerability is actively exploited, when you became aware, and what to notify are your determination. A separate standalone awareness record is added only when issue_record is true; every response is in any case a hub-signed credential over its output and input digests. Fan-out is capped (1000 components, 120 advisory records); EUVD is checked per CVE up to 20 CVEs and above that by one read of its whole exploited list; partial results name what is missing. Deterministic, no model call.

Cost: 2.00 USDC per call, paid automatically over x402 on Base when AGENT_PRIVATE_KEY is configured and the price is within MAX_USDC_PER_CALL.

Input Schema

NameRequiredDescriptionDefault
sbomNoCycloneDX 1.4-1.6 or SPDX 2.2/2.3 JSON SBOM, as an object or a JSON string, up to 5 MB. Components need a purl with a version (SPDX: a purl externalRef). Exactly one of sbom or purls.
purlsNoAlternative to sbom: versioned package URLs, e.g. pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1. Ecosystems: npm, pypi, maven, golang, cargo, nuget, gem, composer, hex, pub, swift.
productNoYour product with digital elements; used only to fill the draft fields (defaults to the SBOM's own product name).
issue_recordNoDefault false. When true, adds a standalone awareness_record (evidence snapshot, SBOM digest, evaluation time; signed with the hub attestation key when configured) for you to retain. It does not switch off the hub's standard signed response credential, which every response carries and which already binds the output and input digests to a timestamp.
awareness_timeNoWhen the manufacturer became aware, ISO 8601 with UTC offset (e.g. 2026-11-04T09:30:00Z). Defaults to now. Taken as given; this agent cannot verify it.
fix_available_atNoWhen a corrective or mitigating measure became available, ISO 8601 with UTC offset; sets the Art. 14(2)(c) final-report date.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations it discloses cost (2.00 USDC via x402 on Base, gated by AGENT_PRIVATE_KEY and MAX_USDC_PER_CALL), fan-out caps (1000 components, 120 advisory records, EUVD per-CVE up to 20 then whole-list read), partial-result reporting, determinism with no model call, and that every response is a hub-signed credential. These are exactly the operational traits an agent needs and none are in the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The pipeline is front-loaded in the first sentence and the caveats, caps, and cost follow in a logical order with no filler. It is dense and long, but nearly every clause carries distinct information; only the repeated signing/credential point is slightly redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description still explains what is returned (per-component verdict, evidence with source URLs and SHA-256 digests, computed Art. 14(2) dates, drafted content) and how degradation is surfaced. For a six-parameter, nested, open-world tool this is complete enough to call correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all six parameters, including the sbom/purls exclusivity and the ISO 8601 formats. The description adds only marginal meaning (awareness_time is taken as given and unverifiable, issue_record does not disable the standard credential), so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb chain and resource: takes an SBOM or purl list, queries OSV.dev, cross-checks CISA KEV and ENISA EUVD, adds EPSS, and computes Art. 14(2) deadlines. It is clearly distinguishable from the sibling cra_readiness, which does not do exploited-vulnerability evidence or deadline arithmetic.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the input forms accepted (CycloneDX/SPDX SBOM or purl list) and the scope boundary ('reports evidence and arithmetic, not a legal conclusion'), which tells the agent what this tool will and will not decide. It never explicitly names an alternative sibling or a when-not-to-use condition, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools