WritersLogic verifiable AI agents

cra-readiness

EU CRA Readiness Check — Repository or manifests in, EU Cyber Resilience Act Art. 14 position out: dependency-advisor resolves every declared package to its locked version (deterministic, no model), those versions go to cra-exploit-clock as package URLs (OSV, CISA KEV, EPSS, EUVD), and each actively exploited component is joined back to the manifest that declares it with the fixed versions and the advisor's findings. Repo

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "cra-readiness"
  }
}

Input Schema

Name	Required	Description
`ref`	No	Branch, tag or commit; defaults to the default branch.
`repo`	No	Public GitHub repository: owner/repo, https://github.com/owner/repo[/tree/ref], a commit URL, or a pull request URL (analyzed at the PR head).
`files`	No	Alternative to repo: manifests (package.json, lockfile, pyproject.toml, requirements.txt, Cargo.toml) and source files with repository-relative paths.
`product`	No	Your product with digital elements; used only to fill the draft fields (defaults to the SBOM's own product name).
`ecosystems`	No	Restrict the analysis; default all detected.
`repoLicense`	No	SPDX id of the repository's license, for alternative ranking; detected from manifests or LICENSE when absent.
`awareness_time`	No	When 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_at`	No	When 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.

First observedNov 15, 2026

TDQS

A4/5.0

Behavior4/5

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

With no annotations supplied, the description does real work: it discloses that resolution is 'deterministic, no model', names the external vulnerability sources (OSV, CISA KEV, EPSS, EUVD), explains that exploit-clock gets package URLs, and that findings are joined back to the declaring manifest. It omits operational traits such as rate limits, auth needs, failure behavior for unresolvable packages, and whether any state is persisted.

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

Conciseness3/5

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

The core purpose is front-loaded, but the body is a single long run-on sentence dense with parentheticals, and it terminates with a dangling fragment ('Repo') that reads as truncated content. It is information-rich but noticeably harder to parse than it needs to be.

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

Completeness4/5

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

For an 8-parameter, nested-object tool with no output schema, the description does carry the return-value burden reasonably well by describing the Art. 14 position, per-component fixed versions, and advisor findings. Gaps remain around output shape (is it a draft report, JSON, markdown?) and edge cases like repos with no lockfiles.

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 coverage is 100%, so all eight parameters are already documented, including the repo/files alternative and the Art. 14 timing fields. The description reinforces the input split ('Repository or manifests in') but adds no syntax, precedence, or conflict-resolution detail (e.g. what happens if both repo and files are given) beyond what the schema already provides.

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

Purpose5/5

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

The description states a specific verb and resource ('EU CRA Readiness Check') and a concrete output ('EU Cyber Resilience Act Art. 14 position out'), then names the two engines it composes (dependency-advisor, cra-exploit-clock) so the agent can tell it apart from those siblings. The input modality ('Repository or manifests in') is stated up front.

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 makes clear this is the end-to-end orchestration path: rather than calling dependency-advisor or cra-exploit-clock individually, you supply a repo or manifest set and get the joined Art. 14 position. It does not, however, explicitly state when to prefer the narrower siblings (e.g. for a quick advisory-only or clock-only lookup), and the trailing truncated 'Repo' leaves the entry sentence unfinished.

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

All WritersLogic verifiable AI agents tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?