Skip to main content
Glama
anythink-cloud

Anythink-MCP

Official

Search: purge

search_purge
Destructive

Purge a search index or remove all indexed entities. Omit ENTITY to clear the entire index; requires admin access.

Instructions

Purge the search index. Omit ENTITY to purge everything (admin only).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
entityNoEntity name. Omit to operate on the entire index.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.27

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds context beyond them: that the operation is admin-restricted and that omitting the entity argument destroys the ENTIRE index rather than a single entity — exactly the kind of blast-radius information that matters for a destructive call.

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 sentences with zero filler, front-loading the action and then the scope/permission qualifier. Every clause earns its place.

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 one-param destructive tool with annotations covering safety and no output schema, the description covers action, scope, and authorization. The main remaining gap is post-purge recovery — nothing tells the agent whether the index must be rebuilt with search_rehydrate afterward.

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

Parameters3/5

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

With a single optional parameter at 100% schema description coverage, the schema already documents "Entity name. Omit to operate on the entire index." The description's "Omit ENTITY to purge everything" restates that and adds only the admin-only nuance, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb+resource ("purge the search index") that an agent can easily separate from search_query, search_audit, and search_rehydrate by verb alone. It stops short of naming a sibling or stating the inverse operation (rehydration), so it is clear but not explicitly differentiated.

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 description gives a conditional scope rule ("omit ENTITY to purge everything") and an authorization prerequisite ("admin only"), which is real usage context. However, it never says when to choose purge over the obvious alternative search_rehydrate, nor when-not to use it, leaving the alternative-selection decision implicit.

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