Tenjin

List articles

list_articles

Read-only

Browse, filter, and paginate the Tenjin article directory. Full-text search over title/excerpt/tags plus the whole body of every piece, a paid body included — a match on gated prose only decides WHICH public row is listed (also matches a creator handle); returns preview-only listing items (never a paid body, snippet, match offset, or score), cursor-paginated — newest-first when browsing (or a chosen sort: oldest, most-read, least-read, cheapest, dearest). q alone is relevance-ranked; q + sort filters by the query and orders the matches by the sort. The content match ORs your plain words (or and - are operators; stopwords drop) and the handle arm matches outside it, so extra terms widen the set and relevance orders it: q is still for SHORT terms (a topic word, a name, a handle), and for a whole QUESTION use the search tool, which matches meaning as well as wording.

Input Schema

TableJSON Schema

Name	Required	Description
`q`	No	Full-text query over title, excerpt, tags, creator handle, and the whole body of every piece (a paid body included; the match only decides which public row is listed, and results stay preview-only). The content match ORs your plain words, so use SHORT terms; a whole question belongs on the `search` tool
`tag`	No	Tag slug to scope to
`sort`	No	Browse order: recency (newest/oldest), public read count (most-read/least-read), or price (cheapest/dearest). Composes with q (query filters, sort orders the matches); omit with q for relevance ranking
`limit`	No	1–100, default 50
`cursor`	No	nextCursor from the previous page
`creator`	No	Publisher word-handle or 0x address to scope to
`maxPrice`	No	Price ceiling, atomic USDC digits ("250000" = $0.25; "0" = free only)
`minPrice`	No	Price floor, atomic USDC digits ("1" = paid pieces only)
`updatedSince`	No	Incremental sync: ISO 8601 UTC instant — re-fetch only pieces updated since your last crawl (combine with the default newest order)
`publishedSince`	No	ISO 8601 UTC instant — keep only pieces published at or after it

TDQS

A4.9/5.0

Behavior5/5

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

Even though readOnlyHint and openWorldHint are present, the description adds substantial behavioral detail: paid-body matches only decide which public row is listed, results are preview-only, no snippets/offsets/scores are returned, and q uses OR semantics with operators and stopword dropping. This goes well beyond the annotations and contains no contradiction.

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?

The description is dense but well-structured and front-loaded with the core operation. Every sentence carries useful selection or invocation guidance, and it avoids repeating the schema's enum values or parameter list.

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 10 parameters and no output schema, the description still tells the agent what kind of result to expect (preview-only listing items, never paid bodies or scores), how pagination works, and how ordering behaves. Combined with 100% schema coverage, this gives an agent everything needed to select and call the tool 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 the baseline is already strong. The description adds meaningful extra semantics for q and sort, such as relevance ranking, extra terms widening the set, and sort composing with filters. However, most other parameters (tag, creator, maxPrice, minPrice, updatedSince, publishedSince) are left for the schema to explain, so it does not quite reach full compensation.

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 operation—'Browse, filter, and paginate the Tenjin article directory'—and clearly names the resource. It also distinguishes itself from the `search` tool by stating that whole questions should go there, and it emphasizes preview-only listing behavior, so an agent can tell it apart from `get_article` and `search`.

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?

The description gives explicit routing guidance: q is meant for SHORT terms, while a whole QUESTION should use the `search` tool. It also explains when to use q alone versus q + sort, and notes the default newest-first browsing order, giving clear decision rules.

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

All Tenjin tools Inspect

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

A4.4/5.0

Disambiguation4/5

Most tools have clearly distinct purposes: answer and search are both search-like but one returns a single synthesized answer vs a shortlist, which is a meaningful difference. A few overlaps exist, like get_article vs pay_and_read where both unlock content, but they handle payment differently. Naming is mostly clear but answer and search could cause temporary confusion.

Naming Consistency4/5

Overwhelmingly uses verb_noun pattern (get_article, delete_essay, list_articles, publish_essay, update_profile), which is predictable. answer and search are exceptions that don't follow the pattern, but they are the primary entry points for a key workflow, so their deviation is understandable and they still convey their purpose. Minor inconsistency keeps it from a 5.

Tool Count5/5

22 tools is on the higher end but wholly appropriate for a content marketplace that involves two distinct roles (creator and buyer) with separate write vs read flows, payment handling, search, trending signals, feedback, and image uploads. Each tool earns its place with a clear role in supporting either the publishing or the discovery/purchase workflow.

Completeness5/5

The tool surface provides complete coverage for both reader and publisher workflows. Readers can search, browse, preview, buy, read articles, and report outcomes. Creators can publish, list, update, soft-delete essays, manage their profile, upload images, track sales and stats. The answer feedback loop via report_search_outcome and get_trending is a notable addition that closes the loop. No obvious gaps for the intended domain.

Resources

Need Help?