Small Print

Advisories that name an entry

advisories_for

Read-onlyIdempotent

Check if a specific version is affected by known security advisories. Returns each advisory's source, severity band, and affected version range for one named entry.

Instructions

Every public security advisory on record that names one entry, each attributed to the database or report that published it, with its severity criterion and the affected version range. Use it when deciding whether a specific version is inside a known advisory, or after lookup_entry reported advisories; it adds nothing for an entry with none. Small Print attributes and never judges: the severity is the source's or a printed CVSS band. Read-only: one HTTPS GET to smallprint.dev per call, no account, no key, nothing about the caller sent, and the server or skill asked about is never run or contacted. Rate limited to one entry per request; a 429 answer says to wait a minute. A name not in the catalog returns a plain error, not a guess.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	Yes	The entry, with its registry prefix when known: npm:@scope/name, pypi:name, mcp-registry:io.github.owner/server, skills.sh:owner/repo/skill, oci:ghcr.io/owner/image. A bare name is read as an npm package. Case-sensitive, up to 300 characters.
`version`	No	A version string to read the affected ranges against, for example 1.4.2. Optional; the ranges are returned either way and the caller compares.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`url`	Yes
`total`	Yes
`advisories`	Yes
`canonicalName`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.1.1Sep 17, 2026

addedInput schema / properties / name / description

Added value: +"The entry, with its registry prefix when known: npm:@scope/name, pypi:name, mcp-registry:io.github.owner/server, skills.sh:owner/repo/skill, oci:ghcr.io/owner/image. A bare name is read as an npm package. Case-sensitive, up to 300 characters."

changedInput schema / properties / version / description

Previous value: -"A version to read the ranges against"New value: +"A version string to read the affected ranges against, for example 1.4.2. Optional; the ranges are returned either way and the caller compares."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "advisories": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "id": {
+            "type": "string"
+          },
+          "severity": {
+            "type": "string"
+          },
+          "source": {
+            "type": "string"
+          },
+          "url": {
+            "type": "string"
+          },
+          "versionRange": {
+            "type": [
+              "string",
+              "null"
+            ]
+          }
+        },
+        "required": [
+          "id",
+          "severity",
+          "source",
+          "versionRange",
+          "url"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "canonicalName": {
+      "type": "string"
+    },
+    "total": {
+      "type": "number"
+    },
+    "url": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "canonicalName",
+    "url",
+    "advisories",
+    "total"
+  ],
+  "type": "object"
+}

First observedv0.1.0Sep 17, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnly, openWorld, and idempotent, but the description adds concrete behavioral facts: a single HTTPS GET to smallprint.dev, no account/key, no caller data sent, the target server never run or contacted, and a one-entry-per-request rate limit with a 429 meaning wait a minute. It also states error handling for unknown names, which is not in the schema.

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

Conciseness5/5

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

Six sentences, each carrying distinct information: purpose, usage, attribution policy, network behavior, rate limiting, and error behavior. No filler or repetition; the most important scoping info is front-loaded.

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?

Given the two parameters, the presence of an output schema (which the description summarises), and the annotation set, the description covers everything an agent needs: what it returns, when to use it, behavior under rate limit and unknown names. It leaves no critical gap.

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?

Both parameters already have complete descriptions in the schema (100% coverage), spelling out prefix formats, case-sensitivity, and length limits for 'name' and the purpose of 'version'. The description adds only a passing reference to reading affected ranges, which the schema already states, so it contributes nothing new; baseline 3 is appropriate.

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 opens with a precise statement of what the tool returns: every public security advisory that names one entry, with source attribution, severity criterion, and affected version range. It distinguishes itself from the sibling lookup_entry by noting it adds nothing for entries with no advisories, going well beyond a restatement of the name.

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

Usage Guidelines5/5

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

The description explicitly tells an agent when to reach for this tool ('when deciding whether a specific version is inside a known advisory, or after lookup_entry reported advisories') and when not to (it adds nothing for an entry with none). It names the relevant sibling, giving clear routing guidance.

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

Deploy Server