This server provides read-only MCP tools to query the public Small Print record about MCP servers, skills, and plugins — their versions, small-print changes, advisories, and approval status.
lookup_entry: Look up an entry's record: canonical name, kind, latest version, number of versions on record, tools read, number of releases that changed small print, worst grade, and advisories naming it.
changes_since: List releases of an entry whose tool descriptions, schemas, or instructions changed, with diffs, severity grades, and grading rules; supports date and severity filters.
advisories_for: Get all public security advisories that name an entry, with source, severity, affected version range, and URL; optionally compare a specific version.
changed_since_approval: Check whether an entry's small print has changed since an approved version, content hash, or date; returns UNCHANGED, CHANGED, or UNKNOWN with relevant releases and worst grade.
All tools are read-only, require no account or key, send no caller data, never run or contact the queried server/skill, and are rate-limited to one entry per request.
Two small things that read the Small Print record, the nightly diff of what MCP servers, agent skills and plugins tell your agent. The site, the ingest and the grading rules live elsewhere; the rules themselves are printed at https://smallprint.dev/how-we-grade.
This Action fails a build when the small print in a repository moved away from its lock.
npx smallprint gate asks the record before a session whether any server here moved since the lock or gained a high advisory; exit codes for a shell hook. CLI 0.0.14.
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.
Fails the build when the small print your agents read has moved: 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@v1Write 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.lockThe 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 moved 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.0.14).
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 moved 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 readOnlyHint annotation, the description discloses the exact network behavior (one HTTPS GET to smallprint.dev), privacy guarantees (nothing about the caller sent), rate limiting (429 means wait a minute), and error behavior (name not in catalog returns a plain error). It also clarifies the meaning of UNKNOWN, which is valuable safety-relevant context not present in annotations or 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?
The description is dense but every clause carries useful information: purpose, output format, usage routing, UNKNOWN semantics, read-only/network details, rate limit, and error behavior. The opening 'Yes or no' is slightly at odds with the three-value answer (UNCHANGED/CHANGED/UNKNOWN), but this is minor and the structure is otherwise efficient and 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 tool's complexity and the existence of an output schema, the description covers all necessary operational aspects: when to call it, what the answer looks like, what UNKNOWN means, privacy/network properties, rate limits, and error handling. An agent has enough information to call this tool correctly in all normal situations.
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 both the name and approved parameters are already well documented with formats, length limits, and examples. The description adds a bit of contextual framing (approved can be version, hash, or date) but does not materially expand on what the schema already provides, so the baseline score 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 states the exact purpose: checking whether a server or skill's small print has changed since an approved version, content hash, or review date. It also distinguishes the answer statuses (UNCHANGED, CHANGED, UNKNOWN) and names sibling tools, so an agent can tell this apart from lookup_entry, changes_since, and advisories_for without opening their schemas.
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 gives explicit when-to-use guidance: 'Use it on every run when an approval is on file' and explicitly says to use lookup_entry when nothing was approved yet and changes_since after a CHANGED answer. It also states that UNKNOWN should be treated as 'no answer, not as safe,' which is a clear behavioral condition for invocation.
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 moved 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?
Annotations already mark it read-only and idempotent; the description adds concrete behavioral facts: one HTTPS GET to smallprint.dev, no account, no key, no caller data sent, the target server or skill is never run or contacted, one entry per request, 429 means wait a minute, and unknown names return a plain error. This goes well beyond what annotations provide 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 long but every sentence earns its place: purpose, usage guidance, filters, output limits, privacy guarantees, rate limiting, and error behavior. It is front-loaded with the core result and alternatives before diving into details, with no filler.
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?
It covers output shape (text capped at 12 releases vs structured result carrying all), filter behavior, privacy/security footprint, rate limiting, and error handling. With an output schema present and rich annotations, nothing an agent needs to select or invoke this tool 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 coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema for since and min_severity by explaining their filtering effect and the real-world consequence of the default low (plain version bumps and identical releases are never listed). The name parameter is left to the schema, but the schema already documents it thoroughly.
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 identifies exactly what the tool returns: releases of one entry whose tool descriptions, schemas, or instructions changed, each with its diff, grade, and grading rule. It also explicitly contrasts it with changed_since_approval, so an agent can distinguish it from siblings without opening schemas.
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 states when to use this tool ('to read what actually changed, after lookup_entry or changed_since_approval said something did') and when to prefer changed_since_approval instead ('only whether anything moved since an approved version'). It also explains how the since and min_severity filters shape results.
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 has a distinct role: entry overview, detailed change diffs, advisories, and approval-status check. The descriptions cross-reference each other clearly, though lookup_entry and changed_since_approval both touch on whether changes occurred, which could cause slight boundary confusion.
All names are lowercase snake_case and readable, but they do not follow a single pattern: lookup_entry is verb_noun, changes_since and advisories_for are noun_preposition, and changed_since_approval is a past-tense phrase. The similar changes_since / changed_since_approval pair adds mild confusion.
Four tools is well-scoped for a read-only monitoring service. Each tool earns its place by covering a distinct query need: overview, changelog diffs, advisories, and approval status, with no apparent redundancy.
The set covers the full read-only workflow: confirm an entry exists, inspect what changed, check advisories, and re-verify against an approved version. The main gap is the lack of any search or list-catalog capability, but exact-name lookup with clear errors makes the core workflow workable.
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.
