Small Print

Look up an entry on the Small Print record

lookup_entry

Read-onlyIdempotent

Look up the Small Print record for a named MCP server, skill, or plugin to confirm it exists and see versions, changes, grades, and advisories. Use it first when nothing is known about an entry.

Instructions

What the record holds for one MCP server, skill or plugin: versions on record, the tools read from the pinned version, how many releases changed the small print and the worst grade, and the advisories that name it. Use it first, when nothing about the entry is known yet, or to confirm an entry exists before the other tools; use changes_since for the diffs and advisories_for for advisory detail. Not for private or unpublished servers, which have no page. 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.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`url`	Yes
`kind`	Yes
`toolsRead`	Yes
`advisories`	Yes
`worstGrade`	Yes
`canonicalName`	Yes
`latestVersion`	Yes
`releasesChanged`	Yes
`versionsOnRecord`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.1.1Sep 17, 2026

changedInput schema / properties / name / description

Previous value: -"The entry's name, with its registry prefix when known"New 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."

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"
+    },
+    "kind": {
+      "type": "string"
+    },
+    "latestVersion": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "releasesChanged": {
+      "type": "number"
+    },
+    "toolsRead": {
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "url": {
+      "type": "string"
+    },
+    "versionsOnRecord": {
+      "type": "number"
+    },
+    "worstGrade": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "canonicalName",
+    "url",
+    "kind",
+    "latestVersion",
+    "versionsOnRecord",
+    "toolsRead",
+    "releasesChanged",
+    "worstGrade",
+    "advisories"
+  ],
+  "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 provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, and the description adds meaningful context: one HTTPS GET, no account or key, no caller information sent, the target server is never contacted, rate limiting with a 429 wait, and a plain error for unknown names. This goes well beyond what annotations alone offer, and does not contradict them.

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?

The description is information-dense yet well organized: purpose and usage are front-loaded, followed by exclusions, protocol behavior, rate limiting, and error handling. Every sentence earns its place; there is no filler or redundant restatement of schema details.

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 single-parameter, read-only lookup with an output schema, the description covers the record contents, when to invoke it, which siblings to use instead, unsupported entry types, network behavior, authentication requirements, rate limits, and error behavior. Nothing an agent needs to correctly call the tool is missing.

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?

The input schema already documents the single name parameter with 100% coverage, including registry prefix formats and case sensitivity. The description adds no parameter-specific semantics beyond what the schema provides, so the baseline of 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 exactly what the record holds for one MCP server, skill, or plugin, and then differentiates itself from siblings by directing to changes_since for diffs and advisories_for for advisory detail. The verb 'look up' plus the concrete catalog content makes the purpose unmistakable.

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 says to use it first when nothing is known about an entry or to confirm an entry exists, and names changes_since and advisories_for as the alternatives for their specific use cases. It also states the exclusion of private or unpublished servers. This gives an agent clear selection criteria.

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

Deploy Server