Skip to main content
Glama
SVerITG

Metis

by SVerITG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Metis · Librarian — Delete Knowledge Database

delete_knowledge_database

Delete a knowledge layer and all its indexed passages and vectors while leaving your source PDFs on disk untouched, so the layer can be rebuilt by re-indexing the same folders.

Instructions

Remove a knowledge background layer and everything indexed under it.

Deletes the layer's registry row, its indexed passages and its vectors. Your
PDFs on disk are NOT touched — only the search index built from them, so the
layer can always be rebuilt by pointing at the same folders again.

Args:
    database: The layer's slug (e.g. 'my-custom-layer').
    confirm: Must be True to proceed. Without it, this reports what WOULD be
        deleted and changes nothing.

Input Schema

NameRequiredDescriptionDefault
confirmNo
databaseYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.5

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 carries the full behavioral burden and does so well: it names exactly what is deleted (registry row, passages, vectors), what is not (PDFs on disk), that the layer is rebuildable, and that confirm=False produces a dry-run report with no changes.

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 action and scope, then the safety semantics, then parameter notes. It is slightly verbose with the Args section, but every sentence adds useful information and nothing is wasted.

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 not be described. For a destructive two-parameter tool with no annotations, the description covers impact, safety, rebuildability, and parameter meaning completely.

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 compensate, and it does: 'database' is defined as the layer's slug with an example, and 'confirm' is explained as required for actual deletion, with the safe default behavior spelled out.

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 specific verb and resource ('Remove a knowledge background layer') and immediately clarifies scope: the registry row, indexed passages and vectors. This clearly distinguishes it from create_knowledge_database and list_knowledge_databases.

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?

Usage is implied by the destructive 'Remove' wording and the confirm flag, but there is no explicit comparison to alternatives such as set_knowledge_layer_enabled or archive-type siblings, and no statement of when deletion is preferred over disabling.

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

Deploy Server

Other Tools