A
licenseA
qualityA
maintenanceEnables AI coding agents and CI to vet npm dependencies before they reach the lockfile, flagging hallucinated, slopsquatted, or otherwise risky packages with evidence-backed verdicts.
3
48 npm
4
MIT
Kenwea Notary
Server Details
Signed third-party verdict on what an npm package or file does when run. No key, no signup.
Ownership verified
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- kenwea-protocol/kenwea
- GitHub Stars
- 0
- Server Listing
- Kenwea Public MCP Server
TDQS
A4.7/5.0
Scored across 2 tools
Disambiguation5/5
The two tools have clearly distinct purposes: check creates a signed attestation by fetching and running an artifact, while verify validates an existing signed record. An agent can trivially choose the right tool based on whether it needs to produce or validate an attestation.
Naming Consistency5/5
Both tools follow the same predictable namespace.tool pattern (kenwea.notary.check and kenwea.notary.verify) with clear action verbs. There is no mixing of conventions or ambiguous naming.
Tool Count4/5
Two tools are sufficient for a stateless notary service that only needs to create and verify attestations. The count is slightly below the typical 3–15 range but each tool is substantial and no extra operations are implied by the domain.
Completeness5/5
The surface covers the full lifecycle: generating a signed attestation and verifying it against the published key. Because the service keeps nothing and is stateless, no additional CRUD or management operations are needed, leaving no dead ends.
Available Tools
2 toolskenwea.notary.checkNotarize what an artifact doesAInspect
Notarize what a file or npm package does at the moment Kenwea fetches it. Give exactly one of artifactRef, a public https URL of a single file, npm tarball or Python wheel, or package, an npm package name such as express@4.18.2 (resolved to the exact tarball npm install would download; no version means latest). Kenwea downloads the bytes (up to 10 MiB), runs executable content in isolation (no network, all capabilities dropped, read-only filesystem, 15 seconds for a file, 45 for a package) and returns a verdict (approved, manual_review or rejected), the sha256 of what it read, and signedAttestation, an Ed25519 signature over those facts that anyone can check with kenwea.notary.verify or any Ed25519 library. A URL that cannot be fetched returns checked false with the reason instead of a verdict, and a limit of our runner comes back as manual_review stated as ours. No key or signup: 20 checks per hour per network address within a shared hourly ceiling, refused with rate_limited and the reset time; a Kenwea API key sent as a Bearer token uses that key's own quota. Keeps nothing but a rate counter.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| package | No | npm package name with an optional version or dist-tag, for example express, express@4.18.2 or @types/node@20.0.0. Omit when using artifactRef. | |
| artifactRef | No | Public https URL of the artifact: a single .js, .mjs, .cjs or .py file, a shebang script, an npm tarball (.tgz) or a Python wheel or zip. Omit when using package. |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations limited to non-read-only, non-idempotent, open-world hints, the description carries the rest and does so thoroughly: download cap (10 MiB), sandbox conditions (no network, dropped capabilities, read-only FS), timeouts (15s file / 45s package), the three verdict values, sha256 and signedAttestation outputs, fetch-failure shape (checked:false), runner-limit behavior, and the full rate-limit/quota model with no key required. Nothing here contradicts 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The content is front-loaded and every sentence carries information an agent needs (inputs, sandbox, outputs, failure modes, quotas). It is dense rather than padded, though the single long paragraph could be broken into input/behavior/limits segments for faster scanning.
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?
There is no output schema, yet the description fully accounts for return values (verdict, sha256, signedAttestation, checked:false, rate_limited with reset time) and the auth model. For a two-parameter, zero-required tool with complex remote behavior, nothing material is left undocumented.
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 genuine semantics beyond the schema: what artifactRef accepts beyond the URI format (single .js/.mjs/.cjs/.py, shebang script, .tgz, wheel/zip), and that a versionless package resolves to the exact tarball npm install would fetch. It adds real meaning rather than restating 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?
The description opens with a specific verb and resource: 'Notarize what a file or npm package does at the moment Kenwea fetches it,' then concretely defines the two inputs it operates on. It is easily distinguished from its sibling kenwea.notary.verify, which is explicitly named as the tool for checking the produced signature rather than producing it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the selection rule plainly ('Give exactly one of artifactRef ... or package ...') and explains the version-resolution behavior for packages, so an agent knows which parameter to populate. It also points to kenwea.notary.verify for attestation checking, but stops short of an explicit 'do not use this when you only need to verify an existing attestation' exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kenwea.notary.verifyVerify a signed Kenwea recordARead-onlyIdempotentInspect
Check a signed record produced by kenwea.notary.check: whether its signature is valid under Kenwea's published Ed25519 key, and what it attests. Pass payload and signature exactly as they appear in the record's signedAttestation; payload is a JSON string and must not be re-serialised, or the signature will not match. Optionally pass contentSha256 to confirm the record is about the bytes you hold. Returns valid, the keyId, and the signed facts (artifactRef, contentSha256, verdict, ran, exitCode, issuedAt); an altered record returns valid false with the reason, not an error. Runs nothing and fetches only the public key. The same check needs no Kenwea server: verify the payload with any Ed25519 library against https://www.kenwea.com/.well-known/kenwea-attestation-key.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | signedAttestation.payload from a check result, byte for byte. | |
| signature | Yes | signedAttestation.signature, base64. | |
| contentSha256 | No | Optional sha256 (hex) of the bytes you hold; the answer then says whether the record is about them. |
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond that: 'Runs nothing and fetches only the public key' and the non-obvious semantics that an altered record returns valid=false with a reason rather than throwing an error.
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 but front-loaded, leading with what the tool does before the invocation caveat and the return shape. Slightly long, but every sentence carries operational value; nothing reads as filler.
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 enumerates the returned fields (valid, keyId, and signed facts including artifactRef, contentSha256, verdict, ran, exitCode, issuedAt) and states the failure mode. Combined with annotations covering safety, an agent has everything needed to call and interpret it correctly.
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 baseline is 3, but the description adds real meaning beyond the schema: payload is a JSON string that 'must not be re-serialised, or the signature will not match' — a byte-exactness constraint the schema does not convey. contentSha256's purpose (confirming the record is about the bytes you hold) is also clarified.
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 and resource ('Check a signed record') and names the sibling that produces the input (kenwea.notary.check), making the check/verify split unambiguous. It also enumerates what is being determined: signature validity under the Ed25519 key and what the record attests.
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?
Specifies the input provenance ('pass payload and signature exactly as they appear in the record's signedAttestation'), the optional confirmation use case for contentSha256, and even the alternative no-server path via any Ed25519 library. An agent knows when and how to reach for this versus the sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- First observed
kenwea.notary.check - First observed
kenwea.notary.verify
Related MCP Connectors
Verify PyPI and npm packages, symbols, and version diffs against real artifacts. Free, no account.
check-package: block malicious npm/PyPI deps before your AI agent installs them. Free, no key.
Provide AI-powered real-time analysis and intelligence on NPM packages, including security, depend…
Detect malicious or vulnerable npm packages: registry search, OSV.dev and GitHub advisory lookups
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceAudits npm packages for supply-chain attacks (typosquatting, malicious install scripts, credential exfiltration) before installation, returning a SAFE/SUSPICIOUS/DANGEROUS verdict.MIT
- AlicenseAqualityBmaintenanceVerifies npm packages for security risks before installation, checking advisories, install scripts, typosquatting, and other factors, providing safe/block verdicts.194 npmApache 2.0
EVIDIQ Lineageofficial
AlicenseNot gradedqualityBmaintenanceDeterministic supply-chain provenance, SBOM/AI-BOM generation, and dependency risk analysis for npm and PyPI packages, with 14 security rules and verifiable reports.1MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.