Small Print

Changes to an entry's small print

changes_since

Read-onlyIdempotent

Read the releases where an entry's tool descriptions, schemas, or instructions changed, with diffs, grades, and grading rules. Filter by date or minimum severity to see what actually changed.

Instructions

The releases of one entry whose tool descriptions, schemas or instructions changed, each with its diff, its grade and the rule that graded it (rules at https://smallprint.dev/how-we-grade). Use it to read what actually changed, after lookup_entry or changed_since_approval said something did; use changed_since_approval instead when the question is only whether anything changed since an approved version. Filters: since keeps releases published on or after a date; min_severity drops changes below a grade (default low, so plain version bumps and identical releases are never listed). Returns at most 12 releases in text; the structured result carries all of them. 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.
`since`	No	ISO date, YYYY-MM-DD; only releases published on or after it. Omit for every release on record.
`min_severity`	No	Lowest grade to include: info, low, medium, high or critical. Default low. Use high to see only changes that name a secret, a destination or an instruction to hide something.	low

Output Schema

TableJSON Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.1.1Sep 17, 2026

addedInput schema / properties / min_severity / description

Added value: +"Lowest grade to include: info, low, medium, high or critical. Default low. Use high to see only changes that name a secret, a destination or an instruction to hide something."

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 / since / description

Previous value: -"ISO date; releases published on or after it"New value: +"ISO date, YYYY-MM-DD; only releases published on or after it. Omit for every release on record."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "canonicalName": {
+      "type": "string"
+    },
+    "releases": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "changes": {
+            "items": {
+              "additionalProperties": false,
+              "properties": {
+                "diff": {
+                  "type": "string"
+                },
+                "field": {
+                  "type": "string"
+                },
+                "rule": {
+                  "type": "string"
+                },
+                "severity": {
+                  "type": "string"
+                },
+                "subject": {
+                  "type": [
+                    "string",
+                    "null"
+                  ]
+                }
+              },
+              "required": [
+                "field",
+                "subject",
+                "severity",
+                "rule",
+                "diff"
+              ],
+              "type": "object"
+            },
+            "type": "array"
+          },
+          "from": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "publishedAt": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "summary": {
+            "type": "string"
+          },
+          "to": {
+            "type": "string"
+          },
+          "worst": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "from",
+          "to",
+          "publishedAt",
+          "worst",
+          "summary",
+          "changes"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "total": {
+      "type": "number"
+    },
+    "url": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "canonicalName",
+    "url",
+    "releases",
+    "total"
+  ],
+  "type": "object"
+}

First observedv0.1.0Sep 17, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations: one HTTPS GET per call, no account or key, nothing about the caller sent, the queried server/skill is never run or contacted, rate limit of one entry per request, 429 means wait a minute, and an unknown name returns a plain error rather than a guess. This is exactly the behavioral context annotations cannot carry.

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?

Dense and front-loaded: usage routing first, then filters, then the return cap, then safety/rate-limit notes. Nearly every clause earns its place, though the return-format sentence is slightly long given an output schema exists.

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?

For a filtered read tool with a full output schema, the description covers the remaining gaps an agent needs: the 12-release text cap versus the complete structured result, safety profile, rate limiting, and error behavior on unknown names.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: since filters by publication date, and min_severity's default low is explained as excluding plain version bumps and identical releases, plus what 'high' picks up. It complements rather than merely restates the schema.

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?

States a specific verb+resource: the releases of one entry whose descriptions, schemas or instructions changed, and what each release carries (diff, grade, grading rule). It is clearly distinguishable from lookup_entry and changed_since_approval.

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?

Explicitly routes the agent: use this after lookup_entry or changed_since_approval said something changed, and use changed_since_approval instead when the question is only whether anything changed since an approved version. Names both alternatives and the selecting condition.

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

Deploy Server