Skip to main content
Glama

Rendreal

List help topics

knowledgebase_list
Read-onlyIdempotent

List every question the customer knowledge base can answer — how the service works, what we offer, design, artwork files, ordering, payment, delivery, privacy.

Call this before answering a question about how the service works or what its policies are — even one that sounds obvious ("do I need an account?", "can I cancel after paying?", "what resolution should my images be?"). The entry is the source for this business's policies. Read the index, pick the entry whose question matches theirs, then call knowledgebase_get with its entry_id and answer from that entry. If no question matches, say you don't have that information — never state a policy the corpus does not contain.

The test is whether answering needs a LIVE LOOKUP. If the true answer would differ per product, per job or per order, it is not in here: what sizes or options a product comes in, whether you print a particular thing, what a configured job costs, the turnaround on an offer you already quoted, where a given order stands, the exact bleed measurement for an order's artwork (a general bleed question — "do I need bleed?", "what bleed?" — is a question for here). Those come from catalog_search/catalog_get_schema, order_get_quote, order_get_artwork_spec and order_get/order_lookup. Everything that is the same answer for every customer — delivery, refunds, design ownership, whether they can supply their own logo or artwork, what file formats we take — is a question for here, even when the answer involves numbers. A general question that names no order or product yet (how to track a parcel or check an order, whether a sample is possible, the smallest order) is a question for here too, even when it reads like a request to look one up: read the entry first, then offer the lookup or ask which product. But an order the customer names by its reference is a live lookup, however general it sounds: look that order up and read no entry. Read at most ONE entry per question — the index gives you enough to pick the right one — and don't look it up again later in the conversation.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "session_id": "<session_id>"
    },
    "name": "knowledgebase_list"
  }
}

Input Schema

NameRequiredDescriptionDefault
session_idYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare a read-only, idempotent, closed-world read, and the description adds real operational constraints beyond them: read at most one entry per question, do not re-read later in the conversation, and never assert a policy the corpus does not contain (fall back to saying the information is unavailable). The 'read one entry only' discipline is a behavioral rule an agent could not infer from the annotations or schema.

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

Conciseness4/5

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

The core directive is front-loaded in the first two sentences, and paragraph breaks separate the positive rule, the workflow, and the negative routing cases. It is long for a one-parameter list tool and re-states the live-lookup principle several times with overlapping examples, but the routing complexity against ~30 sibling tools justifies most of the length.

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?

An output schema exists, so return values need no explanation, and the description still tells the agent what to do with the response ('Read the index, pick the entry whose question matches'). Given the tool's role as the policy-routing entry point among many siblings, nothing needed to call it correctly is missing.

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 0% for the single session_id parameter, and the description never mentions it or explains how the session scopes the returned index. The parameter is largely self-explanatory by convention, so this is a modest gap rather than a blocking one, but the description does not compensate for the missing schema documentation.

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 opening sentence gives a specific verb and resource ('List every question the customer knowledge base can answer') and enumerates the domains covered. It clearly distinguishes itself from knowledgebase_get, which it names as the mandatory follow-up step for fetching a single entry by entry_id.

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?

It states explicitly when to call it (any policy/service question, even ones that sound obvious, with concrete example phrasings) and when not to, routing live-lookup cases to catalog_search, catalog_get_schema, order_get_quote, order_get_artwork_spec, order_get and order_lookup by name. It even resolves the hard boundary cases (general bleed question vs. order-specific bleed, generic order tracking vs. a named order reference) and prescribes the workflow: read index, select entry, call knowledgebase_get.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources