Skip to main content
Glama
Unilytics MCP Server

Unilytics MCP Server

Official

kb_delete_document

DestructiveIdempotent

Permanently delete a knowledge base document and its indexed chunks. Use it for irreversible removals; already-deleted documents return a not_found error.

Instructions

Permanently delete one document from a KB, including its indexed chunks. Irreversible. A document that is already gone returns error "not_found".

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": {
      "project_id": "<project_id>",
      "document_id": "<document_id>"
    },
    "name": "kb_delete_document"
  }
}

Input Schema

NameRequiredDescriptionDefault
project_idYes
document_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.1.0
    • removedInput schema / properties / config
      Removed value: -{
      -  "default": null,
      -  "title": "config",
      -  "type": "string"
      -}
  2. First observedv1.0.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the description's credit comes from added specifics: deletion is permanent, it removes indexed chunks too, and deleting an already-absent document raises "not_found" rather than silently succeeding. That last point usefully clarifies the idempotency semantics an agent would otherwise have to guess at.

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

Conciseness5/5

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

Three short sentences, front-loaded with the action and its permanence, then the side effect, then the error case. Every clause carries information an agent needs and nothing is repeated.

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?

For a destructive two-parameter operation with annotations covering the safety profile and no output schema, the description covers permanence, collateral effect on indexed chunks, and failure behavior. It is only slightly incomplete in not saying what a successful call returns or whether any authorization or confirmation is required.

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

Parameters2/5

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

Schema description coverage is 0%, so both project_id and document_id are documented only by their titles. The description never explains what either identifier is, where to obtain it, or whether project_id scopes the KB lookup — leaving the description to add no meaning beyond the bare property names.

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 ("Permanently delete one document from a KB") and adds scope ("one document", "including its indexed chunks") that separates it from a bulk delete sibling like kb_delete without needing to open either schema.

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 singular scope ("one document") implicitly signals when to prefer this over a bulk delete, and "Permanently" signals when not to use it casually. However, no alternative tool is named and no prerequisite (e.g., confirm existence first, permissions needed) is stated, so usage is only implied.

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