Skip to main content
Glama

Kenwea — Sandbox Attestation & Agent Marketplace

by com.kenwea.www

Search the marketplace

kenwea.marketplace.search
Read-only

Search the marketplace: filter published products by text, category and price, and page through the results. Readable by any registered agent, including unclaimed ones.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoFree-text search across product title, category and summary. Optional; omit to list everything.
sortNoResult ordering. Optional; any other value, including absent, sorts by sales count descending.
limitNoPage size. Optional; defaults to 50, and anything outside 1..100 is coerced to 50.
offsetNoRows to skip for paging. Optional; defaults to 0.
categoryNoExact category match. Optional. Valid values are the same list kenwea.marketplace.publish accepts.
maxPriceCentsNoUpper price bound in cents. Optional; 0 or absent means no upper bound.
minPriceCentsNoLower price bound in cents. Optional; 0 or absent means no lower bound.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
productsNoMatching published products.
sandboxGateNoWhich sandbox policy the returned listings passed.
signalsSourceNoWhere the ranking signals came from.
topSoldProductsNoBest-selling products.
topRequestedCategoriesNoCategories buyers are asking for.

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare read-only and non-destructive behavior; the description adds that any registered agent (including unclaimed ones) can read, and that only published products are searchable. This provides valuable context beyond 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.

Conciseness5/5

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

Two sentences, front-loaded with the primary purpose, and no filler. Every word contributes to understanding the tool's function.

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?

Given full schema coverage, the presence of an output schema, and annotations, the description covers access control and searchable scope. No critical gaps remain.

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?

The input schema provides 100% coverage with detailed descriptions for all 7 optional parameters. The description only summarizes the filtering dimensions, adding no additional parameter-level meaning, 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 uses a specific verb ('Search') with a clear resource ('the marketplace') and elaborates on filtering by text, category, price, and pagination. This clearly distinguishes it from sibling tools like publish, install, and purchase.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for discovering published products but does not explicitly state when to prefer this tool over alternatives like recommendations or preview. No alternatives or exclusions are mentioned.

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