Skip to main content
Glama
zackscriven

ghl-mcp-server-v2

by zackscriven

ghl_kb_delete_file

DestructiveIdempotent

Deletes an uploaded file from a knowledge base so the AI no longer uses it. Use it to remove documents by file ID after locating the ID.

Instructions

Delete a file from knowledge base Deletes one uploaded file from the authenticated location so the AI no longer uses it. WHEN TO USE: use this when you need to remove a document; use getFilesByKnowledgeBasePublic to find the file id; use deleteTrainedUrlsForKnowledgeBase for crawled pages instead. RETURNS: whether the delete succeeded. Endpoint: DELETE /knowledge-bases/files/{fileId} (Version header: v3; source: v3/knowledge-base-v3.json) Requires a Sub-Account (location) token. OAuth scopes: knowledge-bases.write

Input Schema

NameRequiredDescriptionDefault
fileIdYesFile ID to delete

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.1.0

TDQS

A4.6/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, but the description adds real context beyond them: the downstream effect (the AI stops using the document), the required Sub-Account/location token, the OAuth scope knowledge-bases.write, and the exact endpoint and API version. It stops short of stating irreversibility or what happens when the file id does not exist, 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 action, then segmented into WHEN TO USE / RETURNS / endpoint metadata, which scans well. The opening line is slightly redundant with the sentence that follows it, a minor cost against otherwise dense, purposeful text.

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?

For a single-parameter destructive tool this covers everything an agent needs: how to find the id, which sibling to prefer, confirmation that a success flag is returned (no output schema exists, so this is the only return-value signal), and the auth/scope prerequisites.

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% for the single fileId parameter, so the baseline would be 3. The description earns extra credit by telling the agent where to source that id (getFilesByKnowledgeBasePublic), turning a bare identifier into an actionable lookup step.

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 ("Delete a file from knowledge base") and immediately narrows the scope to "one uploaded file from the authenticated location so the AI no longer uses it." This distinguishes it cleanly from the sibling deletes for crawled URLs and whole knowledge bases, so an agent can select it 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 Guidelines5/5

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

Provides an explicit WHEN TO USE block that names the two relevant alternatives and the condition selecting each: use getFilesByKnowledgeBasePublic to obtain the file id, and deleteTrainedUrlsForKnowledgeBase for crawled pages instead. No inference is required to route correctly.

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