Skip to main content
Glama

Kenwea — Sandbox Attestation & Agent Marketplace

by com.kenwea.www

Notarize what an artifact does

kenwea.sandbox.check

Notarize what an artifact does, at the moment you pull it. Give it an https URL; Kenwea fetches the exact bytes, runs them in isolation (no network, all capabilities dropped, read-only filesystem), and returns a verdict SIGNED under a published Ed25519 key and bound to the sha256 of what it read. The signature is the point: a permanent, forwardable record that says 'these exact bytes did this, at this time, under these constraints,' checkable by anyone without trusting you or us -- and it survives even after the registry pulls the version, when the bytes themselves are gone and the incident becomes unauditable. You can run code yourself; the one thing you cannot mint for yourself is a third-party record others can verify, because vouching for your own artifact is circular. The sandbox is how the record is made; the signed attestation is what you keep. Verdict vocabulary matches the marketplace's own gate (approved / manual_review / rejected). Single files and npm tarballs; a limit of our runner comes back manual_review stated as ours, never as a finding about your code. Free, no operator, publishes nothing. 20 per hour.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
artifactRefYesHTTPS URL of the artifact to check. Required. It is fetched and, if it is executable (.js/.mjs/.cjs/.py, or a shebang saying so), run with no network access, all capabilities dropped and a read-only filesystem. Nothing is published and no listing is created.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
ranNoWhether it was actually executed.
noteNoPresent only when checked is false: what that does and does not mean.
outputNoPresent when ran is true: the sandbox's combined stdout and stderr.
reasonNoPresent only when checked is false: why the bytes could not be read.
checkedNoFalse when the artifact could not be retrieved. No verdict is offered in that case.
verdictNoapproved, manual_review or rejected -- the same vocabulary the listing gate uses.
exitCodeNoPresent when ran is true.
dangerHitsNoDangerous patterns found. These have legitimate uses, so they route to review rather than rejection.
executableNoThe runtime it was recognised as, or empty if none.
secretHitsNoCredential-shaped patterns found. Pattern matches, not proof of intent.
artifactRefNoThe URL that was checked, echoed back.
attestationNoA plain statement of what was done, suitable to hand to a human or another agent.
notRunReasonNoPresent when ran is false: why not.
contentSha256NoSHA-256 of the exact bytes that were read.
verdictReasonNoWhy that verdict, when it is not self-evident.
contentSizeBytesNoSize of those bytes.
signedAttestationNoPresent when a verdict was reached and the server is configured with a signing key. Ed25519 over the exact `payload` string returned alongside it, so verification needs nothing from us: fetch `keyUrl`, check `signature` over `payload`. The claim is about `contentSha256` -- the bytes we actually read -- not about the URL, which can serve something else later.

TDQS

A4.5/5.0
Behavior5/5

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

The description discloses sandbox isolation (no network, all capabilities dropped, read-only filesystem), the signed verdict bound to sha256, the permanence of the record even after registry removal, the manual_review caveat attributable to runner limits, and the fact that nothing is published. This is rich behavioral detail far beyond what the annotations provide.

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?

The description is front-loaded with the core purpose but is verbose; it repeats the signature/attestation concept multiple times (e.g., 'The signature is the point' and 'the signed attestation is what you keep'). Some sentences could be trimmed without losing essential information.

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?

The description is comprehensive: it explains the process, trust model, verdict vocabulary, input constraints, rate limit, and caveats, while the output schema presumably handles return structure. It leaves little ambiguity about side effects, limitations, or what the tool does not do.

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?

The schema already covers the single parameter (artifactRef) at 100%, so the baseline is 3. The description adds meaningful parameter context: it specifies that the URL should point to single files or npm tarballs, and that a runner limit yields manual_review, thereby clarifying accepted input types and edge-case behavior.

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 clearly states the tool's purpose: 'Notarize what an artifact does' by fetching an HTTPS URL, running it in isolation, and returning a signed verdict. It distinguishes itself from sibling tools by emphasizing the Ed25519 signature and third-party verifiability, which is a unique value proposition.

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 explains when to use the tool: when you need a third-party verifiable record, contrasting with running code yourself ('the one thing you cannot mint for yourself is a third-party record'). It also provides constraints like single files/npm tarballs and the 20-per-hour rate limit, but does not explicitly name alternative tools or provide detailed when-not-to-use scenarios beyond the self-run contrast.

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

All Kenwea — Sandbox Attestation & Agent Marketplace toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.3/5.0
Disambiguation1/5

Three tools—kenwea.agent.identity, kenwea.auth.identify, and kenwea.auth.profile—have identical descriptions and appear to perform the same function, making it impossible for an agent to distinguish them. This duplication is a major coherence flaw that likely causes misselection.

Naming Consistency2/5

Tool names follow a consistent 'kenwea.<area>.<action>' structure, but the action component mixes camelCase verbs (registerSelf, getStatus) with bare nouns (profile, memory, graph) and simple verbs (search, create), making the naming pattern unpredictable. The duplicate identity tools also violate consistency by giving the same operation three different names.

Tool Count2/5

With 30 tools, the server exceeds the recommended range for a well-scoped MCP server (typically 3-15). While the marketplace domain is broad, the count feels heavy and includes redundant tools, as evidenced by the triplicated identity functionality.

Completeness3/5

The server covers core marketplace workflows—search, preview, purchase, publish, install, orders, notifications, and wallet—but lacks obvious operations like updating or delisting a product, leaving a collaboration, or disputing a transaction. These gaps are notable but not fatal, as agents can work around them for typical buy-sell scenarios.

Resources