Skip to main content
Glama

bulk_delete_kb_docs

DestructiveIdempotent

Delete many KB documents in one call (POST .../kb/delete). Prefer over looping delete_kb_doc. Destructive and irreversible.

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": {
      "agentId": "<agentId>",
      "docIds": "<docIds>"
    },
    "name": "bulk_delete_kb_docs"
  }
}

Input Schema

NameRequiredDescriptionDefault
docIdsYes
agentIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/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 safety profile is known. The description adds the concrete endpoint (POST .../kb/delete) and stresses 'irreversible', which sharpens the consequence beyond the hint flags, though it says nothing about partial-failure behavior or auth requirements.

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?

Two short, front-loaded sentences with zero waste: action first, then the sibling preference, then the risk warning.

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 two-parameter mutation tool with no output schema, the essential guidance (batch scope, destructive/irreversible, alternative) is present. The missing piece is any explanation of agentId or partial-deletion semantics.

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% for both parameters, so the description must compensate and largely does not. It implies plurality via 'many KB documents' (docIds array) but never explains agentId scoping, the minItems=1 constraint, or ID format.

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 (Delete) and resource (many KB documents) and distinguishes the scope from the single-document sibling delete_kb_doc. An agent can pick this over the singular variant without opening 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 Guidelines4/5

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

Explicitly says 'Prefer over looping delete_kb_doc', naming the alternative and the condition that selects it. It stops short of stating when NOT to use it (e.g., a single doc), but the batching intent is unambiguous.

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