Skip to main content
Glama

Kenwea Notary

by com.kenwea.www
OverviewDiscussionsAdmin

Check a whole dependency tree

kenwea_notary_check_tree
Read-onlyIdempotent

Answer for every package in a project's npm dependency tree at once, from records the notary already holds. Input: lockfile, the text of a package-lock.json (lockfileVersion 2 or 3, or its JSON), a pnpm-lock.yaml (v5, v6, v9), a yarn.lock (v1 or berry) or a project's package.json (its ranges resolved as npm would today, devDependencies included); or packages, a list of {name, version, hasInstallScript}, with directs, the project's own dependencies as {name, version}. Behavior: the lockfile says which packages run something at install (hasInstallScript, or requiresBuild in pnpm up to v6), and where it does not (pnpm v9, yarn) the registry is asked for each version (usually a few percent run something); the rest run nothing of their own and are only counted. A step runs inside the project, under the package that pulled it in (@scarf/scarf reports telemetry only for the package that depends on it), so the tree is checked through the project's direct dependencies: each one under which something runs at install is answered by its own record, made with its whole tree installed, and the packages under it come back as covered, with coveredBy naming it. A yarn.lock does not say which packages are direct, so there each package that runs something is checked on its own, and checkedThrough says which way it went. Each record is a stored signed record, made by kenwea_notary_check's sandbox run with decoy credentials; one that has none yet is queued and checked in the background, about two a minute, so ask again later with the same tree to collect it. Nothing runs during the call and it does not spend the per-address check quota (60 tree calls an hour per address). Returns: summary, counts (total, runNothing, runSomething, answered, queued), findings (packages whose level is network, reads_credentials or sends_credentials), checkedThrough (direct_dependencies or each_package), and packages, each with status (answered, queued, not_queued, covered) and, for a direct dependency, covers; when answered, level, summary, verdict, reasonCode, observed and signedAttestation. Verify each record with kenwea_notary_verify or your own Ed25519 code; the tree summary itself is not signed. Not for: one package you want checked now (use kenwea_notary_check). A lockfileVersion 1 file has no hasInstallScript flags and is refused with a reason.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
directsNoWith packages: the project's own dependencies, so the tree is checked through them.
lockfileNoThe contents of a package-lock.json (lockfileVersion 2 or 3, as text or as the JSON object), a pnpm-lock.yaml, a yarn.lock or a project's package.json, as text.
packagesNoAlternatively, the installed packages.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / directs
      Added value: +{
+  "description": "With packages: the project's own dependencies, so the tree is checked through them.",
+  "items": {
+    "properties": {
+      "name": {
+        "type": "string"
+      },
+      "version": {
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "type": "array"
+}
    • changedInput schema / properties / lockfile / description
      Previous value: -"The contents of a package-lock.json (lockfileVersion 2 or 3, as text or as the JSON object), a pnpm-lock.yaml or a yarn.lock, as text."New value: +"The contents of a package-lock.json (lockfileVersion 2 or 3, as text or as the JSON object), a pnpm-lock.yaml, a yarn.lock or a project's package.json, as text."
  2. Changed1 schema field changed
    • changedInput schema / properties / lockfile / description
      Previous value: -"The contents of package-lock.json (lockfileVersion 2 or 3), as text or as the JSON object."New value: +"The contents of a package-lock.json (lockfileVersion 2 or 3, as text or as the JSON object), a pnpm-lock.yaml or a yarn.lock, as text."
  3. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds traits they cannot express: nothing runs during the call, the per-address check quota is not consumed (60 tree calls/hour), uncached records are queued at roughly two per minute, records are stored signed attestations while the tree summary itself is not signed, and lockfileVersion 1 is rejected. This is unusually rich operational disclosure.

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

Conciseness3/5

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

It is front-loaded with purpose and organized into input/behavior/returns/not-for sections, so no part is wasted. However, the behavioral paragraph is a dense wall of semicolon- and parenthesis-laden sentences (e.g. the @scarf/scarf explanation) that is hard to scan, and the returns list is packed into one long sentence.

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?

With no output schema, the description fully documents the return surface: summary, counts (total, runNothing, runSomething, answered, queued), findings, checkedThrough, and per-package status/level/verdict/reasonCode/observed/signedAttestation, plus guidance to verify records with kenwea_notary_verify. Nothing an agent needs to call or interpret the result is missing.

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 goes beyond the schema: it explains that package.json ranges are resolved as npm would today with devDependencies included, that yarn.lock cannot identify directs so each package is checked alone, and that hasInstallScript/requiresBuild drives which packages are considered. It adds genuine semantics the schema only hints at.

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 opening sentence states a specific verb and resource ('Answer for every package in a project's npm dependency tree at once') and the explicit 'Not for' clause contrasts it with the sibling kenwea_notary_check for single-package checks. An agent can distinguish it from all three siblings without opening another schema.

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?

It names the alternative tool and the exact condition that selects it ('one package you want checked now (use kenwea_notary_check)'), and lists all accepted input shapes (package-lock.json v2/3, pnpm-lock.yaml v5/v6/v9, yarn.lock v1/berry, package.json, or a packages list) so the caller knows when each input form applies. It also warns that lockfileVersion 1 is refused with a reason.

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

All Kenwea Notary toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources