This server (smallprint-mcp, registry name dev.smallprint/smallprint) gives read-only answers from the Small Print public record about MCP servers, skills and plugins — their versions, what changed in their small print, and advisories that name them.
lookup_entry — first stop: what the record holds for one entry (versions on record, tools read from the pinned version, how many releases changed the small print and the worst grade, advisories). Use before the other tools.
changes_since — the releases whose tool descriptions, schemas or instructions changed, each with its diff, grade and grading rule; filter by since date and min_severity (default low, up to critical). Max 12 releases in text, all in the structured result.
advisories_for — every public advisory naming one entry, with source, severity and affected version range; optional version to read ranges against.
changed_since_approval — yes/no before use: has the small print changed since an approved version, content hash or date? Answers UNCHANGED, CHANGED or UNKNOWN (UNKNOWN = not safe, just no answer), with releases since and whether the review stands.
Entry naming — registry prefix when known (npm:, pypi:, mcp-registry:, skills.sh:, oci:); a bare name is read as an npm package. Case-sensitive, up to 300 characters.
Read-only and private — one HTTPS GET to smallprint.dev per call, no account or key, nothing about the caller sent, and the entry asked about is never run or contacted; rate limited to one entry per request (429 = wait a minute). Unknown names return a plain error, not a guess. Not for private or unpublished servers.
Provides tools to query the small print record for npm packages, including version changes, diffs, and advisories.
Small Print keeps a record of the text that MCP servers, agent skills and plugins give your AI agent, and tells you when a change is graded high or critical. Every night it fetches the lists of the public registries, reads the new versions it finds, keeps every version it has read, and grades each change by a written rule: https://smallprint.dev.
Get an email the morning a change to something you use is graded high or critical. Sign up with just your email address at https://smallprint.dev/start, from the watch box on any entry's page, or by typing it when npx smallprint check asks. Pin the servers and skills you use; by default the daily brief shows changes graded high or critical and high or critical advisories, by email or Discord, and choosing everything in settings brings every change. No password, and no credit card required.
Check what your agents have installed, free and with no account: npx smallprint@0.1.8 check --no-upload prints what it found and sends nothing; without the flag it asks before sending names and versions to get grades. Or paste a config file at https://smallprint.dev/check.
Plans: every account starts with 30 days of Pro. After that, the Free plan keeps 25 pins, the daily brief, and the off-machine record of your instruction files from each sync you run by hand. Pro adds the scheduled sync, which keeps that record current without you, and removes the pin limit. https://smallprint.dev/pricing
New to this? A step-by-step guide in plain words: https://smallprint.dev/guide
The grading rules are printed at https://smallprint.dev/how-we-grade.
This Action fails a build when the small print in a repository changed since its lock was written.
npx smallprint gate asks the record before a session whether any server here changed since the lock or gained a high advisory; exit codes for a shell hook. CLI 0.1.8.
mcp/: smallprint-mcp, an MCP server with four read-only tools over the public record (npx -y smallprint-mcp; registry name dev.smallprint/smallprint).
Dockerfile builds and runs that server over stdio, for registries that start a server to check it answers.
cli/: the source of the smallprint command, from which the npm package is built, with its tests. npx smallprint@0.1.8 check --no-upload prints what it found and sends nothing.
vscode/: the Small Print extension for VS Code and Cursor, the same files that go to the stores.
tools/verify-chain.mjs: checks the record chain from the public API: every link, every signature, and the entries hash of every day whose lines are kept; node tools/verify-chain.mjs. Rows written before 4 October 2026 link, and their entries cannot be recomputed.
Related MCP server: system-brain-mcp
Fails the build when the small print your agents read has changed: an MCP server's version, a skill's files, or an instruction file such as CLAUDE.md, AGENTS.md or an .mcp.json, compared with a lock you committed.
- uses: gostanos/smallprint-action@v1.10Write the lock from the repository's directory on a machine that has the intended configuration, with --project so it holds only what lives in the repository (the .mcp.json, the .claude/ and .cursor/ folders, CLAUDE.md, AGENTS.md and the rest), and commit it:
npx smallprint lock --project
git add smallprint.lockTo see it working, gostanos/smallprint-demo passes on its main branch, and its open pull request fails because it changes the filesystem server from version 2026.7.4 to 2026.7.10, and the lock check names that change. The check compares versions and file fingerprints; it does not read tool descriptions.
The check is local: it reads the repository's config and instruction files, compares them with the lock, and sends nothing anywhere. It exits 2 when something changed and prints what. When the change is yours, run npx smallprint lock --project again and commit. A lock written without --project also holds the machine's home-directory entries, which a CI runner does not have, so that check would fail on every run; the lock records which kind it is and the check honours it.
Inputs: lockfile (default smallprint.lock), version (the CLI version, default 0.1.8).
The step can write what changed as a SARIF log, and GitHub's upload-sarif action turns each line into a code-scanning alert on the pull request. Needs the --sarif flag, which is in smallprint 0.1.4 and later. The upload needs the security-events: write permission, and if: always() lets it run after the check has failed, so the build still fails when something changed.
permissions:
contents: read
security-events: write
steps:
- uses: actions/checkout@v4
- uses: gostanos/smallprint-action@v1.10
with:
sarif: smallprint.sarif
- uses: github/codeql-action/upload-sarif@v3
if: always()
with:
sarif_file: smallprint.sarifWith pre-commit, the same check runs before every commit, offline. Add this to .pre-commit-config.yaml in the repository that holds the lock:
repos:
- repo: https://github.com/gostanos/smallprint-action
rev: v1.10
hooks:
- id: smallprint-locked # runs smallprint check --locked; the commit stops when anything differs from the lock
- id: smallprint-lock # only when you ask: pre-commit run smallprint-lock --hook-stage manualThe hooks run the pinned version of the command with npx, so the machine needs Node 20 or later.
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.
| 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. |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| total | Yes | |
| advisories | Yes | |
| canonicalName | Yes |
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.
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.
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.
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.
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.
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.
Yes or no, before using a server or skill: has its small print changed since the version, content hash or date that was reviewed? The answer opens with UNCHANGED, CHANGED or UNKNOWN, then the releases that changed it since and their worst grade, then whether the review can stand. Use it on every run when an approval is on file, instead of re-reading the tools; use lookup_entry when nothing was approved yet and changes_since to read the diffs after a CHANGED answer. UNKNOWN means the approved version is not on record or its small print was never read, so nothing is compared; treat it as no answer, not as safe. 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.
| 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. | |
| approved | Yes | What was reviewed: a version string exactly as published (1.4.2), the 64-character hex content hash from an earlier answer, or an ISO date YYYY-MM-DD. A date compares against releases published after it. |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| status | Yes | |
| advisories | Yes | |
| worstGrade | Yes | |
| canonicalName | Yes | |
| latestVersion | Yes | |
| releasesSince | Yes | |
| latestContentHash | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only/idempotent annotations, it discloses the transport and privacy profile (one HTTPS GET to smallprint.dev per call, no account, no key, nothing about the caller sent, target never run or contacted), rate limiting (one entry per request, 429 means wait a minute), error behavior for unknown names, and the critical UNKNOWN-is-not-safe semantic. That is materially richer than 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core question and the three possible answer prefixes, and every clause carries operational content. It is dense and somewhat run-on in the middle, but there is no filler sentence to cut.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-param read tool with full schema coverage, complete annotations, and an output schema, the description still supplies what structured fields cannot: the answer vocabulary, the UNKNOWN interpretation, rate-limit and error behavior. Nothing needed to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 both parameters fully, including registry prefixes and the three accepted forms of 'approved'. The description only echoes the accepted forms ('version, content hash or date') without adding syntax beyond the schema — baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific check ('has its small print changed since the version, content hash or date that was reviewed') with a concrete yes/no outcome, and explicitly names the siblings it is not (lookup_entry, changes_since). An agent can differentiate it from all three siblings without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger ('use it on every run when an approval is on file, instead of re-reading the tools'), an alternative for the no-approval case ('use lookup_entry when nothing was approved yet'), and a follow-up path ('changes_since to read the diffs after a CHANGED answer'). When-to-use, when-not, and alternatives are all covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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 |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| total | Yes | |
| releases | Yes | |
| canonicalName | Yes |
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.
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.
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.
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.
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.
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.
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.
| 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. |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| kind | Yes | |
| toolsRead | Yes | |
| advisories | Yes | |
| worstGrade | Yes | |
| canonicalName | Yes | |
| latestVersion | Yes | |
| releasesChanged | Yes | |
| versionsOnRecord | Yes |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.1advisories_for3 fields changedInput schema / properties / name / descriptionAdded 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."Input schema / properties / version / descriptionPrevious 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."Output 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"
+}changed_since_approvalchanges_since4 fields changedInput schema / properties / min_severity / descriptionAdded 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."Input schema / properties / name / descriptionAdded 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."Input schema / properties / since / descriptionPrevious 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."Output 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"
+}lookup_entry2 fields changedInput schema / properties / name / descriptionPrevious 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."Output 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"
+}v0.1.0advisories_forchanges_sincelookup_entryScored across 4 tools
Each tool targets a distinct aspect of the change-tracking domain: lookup_entry for record overview, changed_since_approval for binary approval status, changes_since for detailed diffs, and advisories_for for advisory details. The descriptions explicitly cross-reference each other and clarify when to use one over another, leaving no meaningful ambiguity.
All names use snake_case, but the grammatical patterns are mixed: changes_since (noun_preposition), lookup_entry (verb_noun), changed_since_approval (adjective_preposition_noun), and advisories_for (noun_preposition). The lack of a uniform verb_noun convention makes the set readable but inconsistently named.
Four tools is well-scoped for a read-only change and advisory tracking service. Each tool covers a distinct lifecycle operation—lookup, approval check, diff inspection, and advisory query—with no redundant tools.
The set covers the core monitoring workflow: entry lookup, change since approval, detailed diffs, and advisories. A minor gap is the lack of a discovery/search tool to find entries by name or list recent changes across the catalog, though agents can typically work around this with known entry names.
Read-only tools over the Safer Agentic AI framework: 238 patterns + 14 heuristics.
Signed security scores for what an AI agent runs and reads: skills, MCP servers, prompts, tokens.
Read-only MCP access to a documented IT fleet: state, changes, posture. 15 tools.
A read-only verified record of agent-operable GTM tools: search, fetch, compare, track changes.
