Skip to main content
Glama

create_knowledge_base

Create a knowledge base.

**Write `description` — it is what routes questions to this base.** Before each answer the
platform reads every attached base's `description` and decides which ones this question needs;
a base whose description is vague or blank gets searched when it should not, or missed when it
should. One line, in the words a visitor would use, naming the subject **and the boundary**:
"Country-by-country medical device registration requirements — not company or pricing
information." It is also the line shown in the console list, but that is the lesser job.

**Write `instructions` at creation time — do not leave it blank.** It is injected next to this
KB's excerpts whenever they are retrieved. It does NOT affect recall (recall is vector search +
max_distance); it governs how the model USES what was retrieved. Derive it from the expected
usage, one line each:
  - Scope: what it covers / does not, and what to do when out of scope
    ("Covers residential mortgages only; for car or personal loans, say so and hand off").
  - Authority: where it ranks ("Current company policy; overrides industry norms").
  - Usage rules specific to this content ("Any quoted rate must state its effective date").
The generic "answer from the excerpts; say when not covered" is built into the platform — never
repeat it here. Blank is acceptable only for generic reference material with no special rules.
Worked examples: search_agent4_docs("knowledge base instructions examples").

max_distance is the relevance cutoff (blank = global default 0.6); tighten for regulatory
content, and calibrate against real queries rather than guessing.

top_k is how many passages this base contributes per turn (1-10, blank = 3). Set it from the
**shape of the documents**, not from how important the base feels: if a typical document is
five passages long, three of them is a third of a record, and the model answers from a
fragment. Measured on an 8,500-record regulation base whose median document is 5 passages —
at k=3 the right record was retrieved 36/40 times but only 4 answers had enough to go on; at
k=6, same hit rate, 12. Going to 10 added 3 more and 77% more material. More is not free:
material in the prompt suppresses tool calls, dose-dependently.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
top_kNo
descriptionNo
instructionsNo
max_distanceNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description takes on full responsibility for behavioral disclosure. It explains how 'description' routes questions, how 'instructions' affects model usage without affecting recall, and how 'top_k' impacts retrieval quality with empirical examples. It even mentions side effects like 'material in the prompt suppresses tool calls, dose-dependently'.

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 description is well-structured with headings, bold text, and bullet points, making it scannable despites its length. It is front-loaded with the core action and most critical guidance (description), but the overall length is substantial and could be trimmed without losing essential information. It earns its place for the most part, but is not concise.

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 the tool's complexity (5 params, no annotations, no schema descriptions), the description is thorough. It covers all significant parameters, provides usage context, and includes worked examples. An output schema exists, so not explaining return values is acceptable. The empirical tuning data for 'top_k' adds real-world context that fully equips an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully compensate. It does so by explaining each parameter in depth: 'description' with routing logic, 'instructions' with structure and examples, 'max_distance' with defaults and calibration advice, and 'top_k' with range, defaults, and evidence-based tuning. Even 'name' is implicitly covered by the creation context.

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 'Create a knowledge base', a specific verb + resource statement. It then elaborates on the tool's key configuration fields, making its function unmistakable and distinct from sibling tools like add_knowledge_file or update_knowledge_base.

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 provides extensive guidance on how to configure parameters (e.g., writing 'description' and 'instructions', setting 'top_k' based on document shape), but it does not explicitly discuss when to use this tool versus alternatives like add_knowledge_text or update_knowledge_base. Usage is implied rather than stated with exclusions.

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.

TDQS

A3.6/5.0
Disambiguation4/5

Tools are mostly distinct by domain and action. A few pairs like add_knowledge_file vs add_knowledge_text or build_knowledge_index vs patch_knowledge_index could cause confusion, but descriptions clearly differentiate them.

Naming Consistency4/5

The vast majority follow a consistent verb_noun snake_case pattern (create_*, list_*, get_*, update_*). A few outliers like tenant_info, usage_stats, and page_context_stats are noun-first, deviating slightly from the otherwise uniform scheme.

Tool Count1/5

With 50 tools, this is a very large surface that exceeds typical well-scoped server sizes. Even for a broad platform management API, the sheer number makes it heavy and potentially overwhelming, matching the '50+' extreme mismatch category.

Completeness2/5

The server covers creation, reading, updating, and listing for most resources but lacks any delete operations (no delete_agent, delete_knowledge_base, delete_skill, delete_share, delete_storyline, delete_page_context). This is a significant gap in lifecycle coverage that will force agents to work around missing functionality.

Resources