Skip to main content
Glama

Create or change a knowledge base store

save_knowledge_base_store
Destructive

[Knowledge base] Without knowledge_base_store_id: a new store (name; strict true by default: the AI uses only its documents). With it: rename it or change strict, which changes how every interview on the store answers. upload_knowledge_base_document adds documents.

Every argument in full, with examples: get_tool_reference.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "save_knowledge_base_store"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoName of the store, 1 to 200 characters. Required for a new store; left out on a change, it stays.
strictNotrue (the default for a new store): the AI uses only these documents. Left out on a change, it stays.
llm_modelNoYour model id, e.g. "claude-opus-4-8"; "unknown" if unsure. For analytics.
merchant_idNoOptional company to act on. Admins and sub-merchant operators only; other callers always use their token's company.
conversation_idNoThe conversation_id this server returned earlier in this conversation, unchanged, including after later user messages. Omit it if you have none. Recorded for the server developer's analytics.
knowledge_base_store_idNoThe store to change (from list_knowledge_base_stores). Left out: a new store is created.

Output Schema

NameRequiredDescriptionDefault
resultYes
_mcp_instructionsNoServer-issued metadata for this conversation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false and openWorldHint=true, so the bar is lower. The description still adds genuine context the annotations cannot: strict is true by default for new stores, omitting name/strict on a change preserves existing values, and toggling strict alters how every interview on that store answers. It never explains why destructiveHint is true or what is irreversibly lost, which keeps it below a 5.

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?

Front-loaded with the create/change branch immediately after a bracketed domain tag, then side effects, then the pointer to get_tool_reference. Three short clauses carry all the value; the trailing reference pointer is useful but is the one sentence that could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Six parameters, none required, an output schema present so return values need no prose, and the description still covers both modes and the main side effect. Remaining gaps are minor: permission behavior for merchant_id is left to the schema, and no guidance is given on a stale or unknown store id.

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 baseline is 3. The description earns an extra point by explaining the semantics of presence versus absence for knowledge_base_store_id and by clarifying that strict defaults to true and means 'the AI uses only its documents', which is interpretive meaning beyond the schema's terse wording.

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?

States a precise dual-mode operation: with knowledge_base_store_id it renames or changes strict on an existing store, without it a new store is created. The resource is named explicitly and the sibling that handles documents (upload_knowledge_base_document) is called out, so an agent can separate this from list_knowledge_base_stores and the upload tool without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The when-to-use split is real and actionable: omit the id to create, supply it to change. It also routes document additions to upload_knowledge_base_document. It stops short of naming the read path (list_knowledge_base_stores) as an explicit alternative, so there is no full when-not clause beyond mode selection.

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.