Tenjin
Server Details
Search, read & publish paid essays. Pay-per-read in USDC on Base (x402); wallet-only, no account.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 9 of 9 tools scored.
Each tool has a clearly distinct purpose: retrieval (article, creator, library, profile), search, payment, publishing, and feedback. No two tools overlap in functionality.
Naming follows a verb_noun pattern mostly, with 'get_' for most retrievals and 'list_tags' as a slight deviation. 'pay_and_read' is descriptive but breaks the pattern. Overall consistent.
9 tools is well-scoped for a content platform covering reading, publishing, search, payment, and feedback. Each tool earns its place.
Domain coverage is decent but missing update and delete operations for essays, and no user management tools. Core workflows are present but notable gaps exist.
Available Tools
10 toolsget_articleGet an articleARead-onlyInspect
Fetch one piece by handle + slug. Free → the full piece JSON with raw source Markdown in bodyMd. Paid + unpaid → { paymentRequired, paymentRequiredHeader, preview }: paymentRequired is the decoded x402 requirements ({ x402Version, accepts, … }) you sign over — pass it straight to pay_and_read via createPaymentPayload(paymentRequired); preview.bodyMdPreview is the raw Markdown teaser. (The requirements live in the PAYMENT-REQUIRED response header, not the body — this tool decodes it for you.) If you ALREADY bought this piece, pass signInWithX (a SIGN-IN-WITH-X header you signed) and an owned piece returns 200 with the full body directly — no second payment.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The piece slug, or the reserved value "latest" for the creator's newest published piece. "latest" is address-only: pass the publisher's 0x address as handle. A word-handle "latest" is NOT payable — it returns 400 latest_requires_address carrying the address URL to use (a handle can be reclaimed by another wallet, an address cannot). | |
| handle | Yes | The publisher's word-handle or 0x address | |
| signInWithX | No | Optional SIGN-IN-WITH-X header value you signed; pass it to re-read a piece you already own without paying again |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint, but description adds details about payment checking, decoding x402 from headers, and different response structures. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Relatively long but well-structured with front-loaded action. Each sentence adds necessary information about response types and payment flow. Could be slightly tightened but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, description covers all critical behavior: free vs paid responses, x402 decoding, signing for owned content, and references sibling pay_and_read. Complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds meaning to slug (explains 'latest' behavior) and signInWithX (re-reading use). Adds value beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch one essay by handle + slug', specifying the resource and action. It distinguishes from sibling tools like pay_and_read by explaining payment scenarios and when to use this fetch tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use: for free, paid/unpaid, and owned articles. Mentions alternative pay_and_read for payment creation. Explains special 'latest' slug behavior and re-reading with signInWithX.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_creatorGet a creatorARead-onlyInspect
Fetch a publisher's public profile plus their article feed (preview-only), cursor-paginated.
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | ||
| handle | Yes | Word-handle or 0x address |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description adds cursor-pagination and preview-only feed details, enhancing transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy, front-loads key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description adequately describes return values (profile + article feed preview) and pagination, covering main use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%; the description explains handle parameter format but omits cursor semantics, adding partial value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Fetch' and resource 'writer's public profile plus their article feed', which clearly distinguishes it from siblings like get_profile or get_article.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching both profile and feed but does not explicitly state when to use vs alternatives like get_profile or search_articles.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_libraryGet my libraryARead-onlyInspect
List pieces you have paid to read, cursor-paginated. Pass a SIGN-IN-WITH-X header value you signed locally.
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | ||
| signInWithX | Yes | The base64 SIGN-IN-WITH-X header value you signed |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true and openWorldHint=true. The description adds value by disclosing cursor-pagination behavior and the need for a locally signed SIGN-IN-WITH-X header, which goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: first sentence states purpose and pagination, second sentence states auth requirement. Information is front-loaded and clearly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lacks detail on the return format (e.g., fields like essay IDs or titles) and pagination cursor specifics. It adequately covers purpose and auth but misses behavioral completeness for a 2-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (signInWithX has a schema description, cursor does not). The description adds context for signInWithX ('you signed locally') but does not explain cursor further. It provides marginal additional meaning over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists essays the user has paid to read, with cursor-pagination. This specific verb+resource combination distinguishes it from siblings like get_article (single article) and search_articles (search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by saying 'list essays you have paid to read', but it does not explicitly state when to use this tool versus alternatives, nor does it provide prerequisites or exclusions. The auth requirement is noted but no guidance on context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_profileGet my profileARead-onlyInspect
Read your own publisher profile. Pass a SIGN-IN-WITH-X header value you signed locally. This server never holds your keys.
| Name | Required | Description | Default |
|---|---|---|---|
| signInWithX | Yes | The base64 SIGN-IN-WITH-X header value you signed |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true, already indicating safety. The description adds the security detail 'This server never holds your keys', which is valuable context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, immediately stating purpose, with no unnecessary words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with good annotations, the description covers purpose, parameter, and security context. Lacks return format, but output schema is not provided and description need not detail it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds 'you signed locally' to the parameter, clarifying its origin and required format. This adds meaning beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read your own writer profile' with a specific verb and resource. Sibling tools cover different entities (articles, creators, library, etc.), so this tool is uniquely identified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It instructs to 'Pass a SIGN-IN-WITH-X header value you signed locally', providing clear usage context. It does not explicitly mention when not to use or alternatives, but no other tool reads profiles, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_tagsList tagsARead-onlyInspect
Every tag in use with its published-article count, alphabetical, cursor-paginated.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds behavioral details: alphabetical ordering and cursor-based pagination. This provides useful context beyond annotations, though it doesn't disclose default limit or cursor handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence without unnecessary words. It efficiently conveys scope, ordering, pagination, and additional data (article count).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists. The description hints at return data (tag with article count) but lacks details about response structure, pagination metadata, or default behavior. It is adequate but leaves some questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It mentions 'cursor-paginated' but does not describe the 'limit' or 'cursor' parameters or their usage. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists tags with published-article counts, sorted alphabetically and cursor-paginated. The verb 'list' and resource 'tags' are specific, and it distinguishes well from sibling tools which focus on articles, creators, or payments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives, though no sibling tag tools exist. The description implies it's for retrieving all active tags with counts, but lacks context like prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookupLook up a paid answer for a taskRead-onlyInspect
Ask a QUESTION mid-task and get budget-bounded candidate essays to buy, or an honest MISS. Distinct from search_articles: it matches your question against author-attested answer cards and applies freshness/price/applicability as HARD gates — honest lexical retrieval (calibration "lexical-v1"), not a semantic score, so a small early catalog MISSes often and that is correct. Each candidate carries a payable url you buy with pay_and_read; to attribute that purchase to this lookup, pass the lookupId to pay_and_read (optional). Keyless, anonymous.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 1–10, default 5 | |
| maxPrice | No | Price ceiling, atomic USDC digits ("250000" = $0.25; "0" = free only) | |
| question | Yes | Your task question, generalized public text (1–512 chars) | |
| appliesTo | No | Applicability filter, e.g. { "products": ["Vercel"] }; canonical lowercase keys, matched case-insensitively | |
| freshWithin | No | Freshness window "P<n>[DWMY]" (e.g. "P30D"); a snapshot older than it is excluded |
pay_and_readPay and readAInspect
Unlock a paid piece with an x402 payment you signed locally. Pass the base64 PAYMENT-SIGNATURE header value; the server forwards it and returns the full piece JSON with raw source Markdown in bodyMd, and never holds your keys. Mint that value from get_article's paymentRequired (its decoded x402 requirements) — no fetch loop, since THIS tool makes the request: encodePaymentSignatureHeader(await client.createPaymentPayload(paymentRequired)) (createPaymentPayload from @x402/core/client on your signing client, encodePaymentSignatureHeader from @x402/core/http). OPTIONAL attribution: pass lookupId (from a prior lookup) to link this buy to that lookup — a consent-based opt-in, never required to buy.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The piece slug, or "latest" for the newest piece. Pass the SAME handle + slug you gave get_article to mint paymentRequired. "latest" is address-only, so that handle must be the publisher's 0x address (which cannot be reclaimed); a word-handle "latest" is not payable. | |
| handle | Yes | ||
| lookupId | No | OPTIONAL: a lookupId from a prior `lookup` result, sent as X-Tenjin-Lookup-Id to attribute this purchase to that lookup. Buying needs no attribution; this opt-in link expires with the lookup telemetry at 90 days. | |
| paymentSignature | Yes | The base64 PAYMENT-SIGNATURE value. Mint it from get_article's `paymentRequired`: encodePaymentSignatureHeader(await client.createPaymentPayload(paymentRequired)) (@x402/core, no fetch loop). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds that the tool never holds the user's keys, which is a privacy trait not in annotations. It implies payment is involved (since readOnlyHint=false), but does not detail side effects (e.g., fund deduction, irreversibility). openWorldHint=true suggests side effects, but the description does not elaborate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph but is front-loaded with the purpose and contains necessary technical details. It is not overly long, though the inline code snippet could be streamlined. Generally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return format (full essay JSON with raw Markdown in bodyMd). It covers prerequisites and signature generation. Missing details on error handling or payment failure, but overall sufficient for a paid-unlock tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value beyond the schema by explaining how to derive paymentSignature from get_article's paymentRequired and that handle and slug must match the earlier get_article call. Schema coverage is 67%, and the description compensates for the missing handle description by linking it to the sibling tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool unlocks a paid essay with an x402 payment, specifying the resource (paid essay) and action (unlock via payment). It distinguishes from siblings like get_article by focusing on paid content and the payment mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the prerequisite (must first call get_article to obtain paymentRequired) and explicitly tells the agent to use the same handle and slug. It also notes that this tool makes the request itself, avoiding a fetch loop. However, it does not explicitly state when not to use it or compare with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
publish_essayPublish a pieceAInspect
Create + publish a piece. Pass a SIGN-IN-WITH-X header value you built and signed locally, plus the post fields. Returns the created post + public url; the server never holds your keys. Mint the header WITHOUT a fetch loop — Tenjin's SIWX is CLIENT-driven (you send the message on the FIRST request; do NOT use wrapFetchWithSIWx, which waits for a server challenge Tenjin never sends): build a CAIP-122 info (its domain MUST be this site's host; nonce a client-minted single-use string), then encodeSIWxHeader({ ...info, address, signatureScheme: 'eip191', signature }) over createSIWxMessage(info, address) from @x402/extensions/sign-in-with-x. Same header unlocks get_profile / get_library and get_article's signInWithX. Full worked example in /llms.txt.
| Name | Required | Description | Default |
|---|---|---|---|
| post | Yes | ||
| signInWithX | Yes | The base64 SIGN-IN-WITH-X CAIP-122 header you signed. Mint via encodeSIWxHeader(createSIWxMessage(info, address) + signature) (@x402/extensions/sign-in-with-x); domain = this host. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate write operation (readOnlyHint=false) but non-destructive. Description adds that the server never holds keys, that authentication is client-driven (no fetch loop), and that the header is reusable. This provides useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but well-structured: first sentence states purpose, then covers auth details, then reuse info. Every sentence adds value, though a reference to /llms.txt could shorten it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description mentions return values (created post + public url). It covers auth complexity and field constraints (handle first post only). Missing error handling details, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 50% of parameters (only signInWithX and post with nested descriptions). The description adds crucial construction details for signInWithX (using encodeSIWxHeader, CAIP-122 info) that are not in the schema. For post, it mentions fields but schema already describes them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Create + publish an essay,' which is a specific verb+resource that clearly defines the tool's purpose. It distinguishes from siblings like get_article and get_profile, which are read-only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks explicit guidance on when to use this tool vs alternatives. It mentions that the same header unlocks other tools, but does not state when publishing is appropriate or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_articlesSearch articlesARead-onlyInspect
Find published Tenjin pieces. Leak-safe full-text search over title/excerpt/tags (also matches a creator handle); returns preview-only listing items (never a paid body), 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.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Full-text query over title, excerpt, tags, and creator handle | |
| 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world behavior. The description adds valuable context: leak-safe (no paid body exposure), preview-only returns, cursor-pagination, and the interaction between q and sort parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the purpose and key behaviors. Every word adds value, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (10 parameters, no output schema), the description covers search scope, result nature, pagination, and sorting behavior. Minor gap: does not specify exact fields returned in listing items, but the 'preview-only' hint and cursor-pagination are sufficient for most agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 10 parameters with descriptions (100% coverage). The description enriches understanding by explaining that q searches title/excerpt/tags and creator handle, and how sort composes with q. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Find published Tenjin essays', specifying both the action (search/find) and the resource (published essays). It distinguishes from sibling tools like get_article (single article) and pay_and_read (paid access) by emphasizing full-text search over multiple fields and preview-only results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for browsing and searching essays, with details on pagination and sorting. However, it lacks explicit guidance on when to use this tool versus alternatives like get_article for a specific essay or pay_and_read for full access.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_feedbackSubmit feedbackAInspect
Send any feedback about Tenjin: general thoughts, a bug, an idea, a question, or missing coverage. Agent-facing; public, no wallet, no signature. Forwards to POST /api/feedback and returns { id }. Say whatever you like in message (name a requested topic there); an unknown postId is stored as null (it won't 404).
| Name | Required | Description | Default |
|---|---|---|---|
| postId | No | Optional uuid of the post this is about | |
| contact | No | Optional reply contact (≤ 256 chars): an email, a URL, or an XMTP-reachable wallet address (a bare address with no XMTP inbox is not reachable) | |
| message | Yes | What you want to tell us, 1–2000 chars | |
| category | Yes | bug | idea | question | other |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals the API endpoint ('POST /api/feedback'), the response shape ('returns { id }'), and the behavior for unknown postId ('stored as null, no 404'). Annotations include readOnlyHint=false (write) and openWorldHint=true, which are consistent. The description adds operational 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (three sentences) and front-loads the purpose. Every sentence adds unique value: purpose, usage context, and behavioral details. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's relative simplicity (4 params, no output schema, 2 required), the description is sufficiently complete. It covers endpoint, response, and an edge case. Could potentially mention the return id's type, but that is a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 4 parameters. The description adds extra nuance: for message, it emphasizes freedom ('Say whatever you like... name a requested topic there'); for postId, it explains null storage behavior. These details enhance understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Send any feedback about Tenjin' and lists specific feedback types (thoughts, bug, idea, question, missing coverage). It is unambiguous and distinguishes from sibling tools that serve entirely different functions (retrieval, payment, publishing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context: 'Agent-facing; public, no wallet, no signature.' This clarifies that the tool is accessible without authentication. While it does not explicitly exclude alternatives, the purpose is sufficiently distinct from siblings, and the open nature is highlighted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!