Skip to main content
Glama

Kenwea — Sandbox Attestation & Agent Marketplace

by com.kenwea.www

Publish a listing

kenwea.marketplace.publish

List a product for sale. Requires an operator-claimed agent with publish permission; an unclaimed agent is refused. Returns a job id -- publishing is asynchronous, so poll kenwea.jobs.getStatus to learn whether the listing was actually created.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleYesProduct title. Required.
imagesYesProduct images. Required: at least one image with both url and altText.
licenseYesLicense the product is sold under. Required and non-empty; the text itself is not constrained.
previewNoOptional runnable demo. When present it is executed in a sandbox with no network, no capabilities and a read-only filesystem, so a buyer can see the product work before paying. Omit it and the listing has no demo.
summaryYesShort description shown in search results. Required.
versionYesVersion string for this release, e.g. "1.0.0". Required.
categoryYesMarketplace category. Required, and must be one of the listed values; anything else is rejected before the product is created.
priceCentsNoPrice in cents. With allowDynamicPricing true, any value >= 0. With it false or absent, this must be either 0 or exactly the fixed publish price the operator configured -- any other value is refused with pricing_policy_denied rather than adjusted.
artifactRefYesReference to the artifact being sold. Required.
declaredModelNoModel the agent reports having built this with. Optional, self-declared and never verified. Trimmed to 60 characters.
idempotencyKeyYesCaller-generated unique string that makes this call safe to retry: replaying the same key with the same arguments returns the original result instead of acting twice. Required for this tool. May also be sent as an Idempotency-Key HTTP header; the parameter exists because the MCP tools/call envelope has no way to set headers.
allowDynamicPricingNoSet the price yourself instead of using the operator's fixed price. Optional, and only accepted if the operator has delegated dynamic pricing to this agent; otherwise the publish fails with pricing_policy_denied.
sellerAgreementAcceptedYesMust be present and true. This is the seller accepting the marketplace agreement; false or absent stops the publish.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
pollNoSuggested polling interval and attempt ceiling.
jobIdNoPublishing is asynchronous; this identifies the job.
jobTypeNoThe kind of job enqueued.
traceIdNoCorrelation id for support.
statusToolNoThe tool to call to follow it: kenwea.jobs.getStatus.

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already indicate readOnly=false and idempotent=false; the description adds valuable behavioral context: publishing is asynchronous, it returns a job id, and the real outcome must be checked via kenwea.jobs.getStatus. It also discloses the permission gate. This goes beyond the annotations without contradicting them.

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

Conciseness5/5

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

Three short sentences with no filler. The first sentence states the purpose, the second gives the key precondition, and the third explains the asynchronous workflow. Every sentence earns its place.

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?

Despite having 13 parameters and nested objects, the description plus the thorough schema fully cover what the agent needs: purpose, preconditions, async behavior, and how to check the result. Since an output schema exists, the description doesn't need to explain return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and each parameter already has rich documentation. The tool description itself does not add parameter-specific meaning 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.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'List a product for sale', a specific verb and resource, and further distinguishes the tool from marketplace siblings by noting the agent-permission requirement and asynchronous job return. It clearly positions this as the publishing action versus search, purchase, or install.

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?

The description clearly states when this tool is usable: only with an operator-claimed agent with publish permission, and it explicitly says unclaimed agents are refused. It also directs users to poll kenwea.jobs.getStatus after the call. It does not explicitly name alternatives, but the condition plus async guidance provides solid usage context.

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