Loading ToolBench
x402 router for coding agents: one paid decision per lookup, a local wallet that pays each provider per call in USDC on Base. Exposes CLI command cores (search, inspect, buy, outcome, publish, edit, delete, wallet) to an MCP client in-process.
Tenjin CLI exposes 12 tools with significant definition gaps. Tool names follow verb_noun convention (tenjin_search, tenjin_buy, tenjin_publish), which is good. However, descriptions are inconsistent in quality and depth. Most critically, parameter schemas are visible but many lack proper type constraints and validation guidance. The 'request' tool has a vague description ('One free decision per lookup...') that reads like internal documentation rather than LLM-optimized guidance. Several tools (tenjin_publish, tenjin_edit) have complex parameter sets with interdependencies (e.g., 'yes' parameter behavior, 'mode' enum) that are documented but could be clearer. Error handling is mentioned in code comments but not surfaced in tool descriptions. Output schemas are not documented for any tool. The server targets a specialized domain (knowledge marketplace + payments) which adds complexity, but this is not an excuse for incomplete definitions.
One free decision per lookup, then ONE payment to the provider. The query is always sent, and the ID names the service. With an id, the backend binds the query to the capability the hook's line offered and never re-decides which service. Without one, it asks for exactly one fresh decision from the query and the turn's packet.
Purchase a resource from the Tenjin marketplace using the local wallet
Remove a previously published knowledge piece from the Tenjin marketplace
Edit a previously published knowledge piece on the Tenjin marketplace
Fund the local wallet with USDC on Base
Inspect a resource from the Tenjin marketplace to see its full details before purchasing
The 'request' tool has a cryptic, implementation-focused description ('One free decision per lookup, then ONE payment to the provider...') that does not explain WHEN or WHY an LLM should call it. It reads like internal documentation, not a tool contract. LLMs cannot infer intent from this.
No output schemas documented for any of the 12 tools. LLMs cannot plan downstream calls or extract required fields (e.g., resourceId from search results) without knowing the response structure. This forces agents to guess or fail.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2025-06-18+ | v2 |
Report the outcome of a search result (used, partially_used, rejected, regenerated, purchase_declined)
Publish a knowledge piece to the Tenjin marketplace
Search the Tenjin knowledge marketplace for answers to a generalized public question
Check the balance of the local USDC wallet on Base
Create a new local self-custody wallet for USDC payments on Base
Display the wallet address and configuration
Parameter 'yes' appears in tenjin_buy, tenjin_publish, tenjin_edit, tenjin_delete with descriptions stating it 'never clears the price cap' or 'never the marketplace's own hard block'. This is defensive language that confuses intent. The description should explain what 'yes' DOES (e.g., 'Approve a spend that would otherwise require user confirmation'), not what it doesn't do.
tenjin_publish has 10 parameters with complex interdependencies (e.g., 'mode' enum affects 'yes' behavior; 'key' requires KNOWLEDGE_KEYS capability). These dependencies are mentioned but not clearly documented as mutual constraints. LLMs will pass invalid combinations.
tenjin_outcome parameter 'searchId' accepts 'string|array' but the schema shows only array type. Type union is ambiguous, LLMs may pass a string when an array is required, or vice versa. Use separate parameters (search_id vs search_ids) or enforce strict typing.