forgetDelete a previously stored memory by key. Use when context is stale, the task is done, or you want to clear sensitive data the agent saved earlier. Pair with remember and recall.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Memory key to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true; the description adds that the operation targets 'a previously stored memory by key' and frames it as clearing sensitive data, offering useful context about what is destroyed. It stops short of describing irreversibility or idempotent behavior in detail, but the annotations cover the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, followed by concrete use cases. Every sentence earns its place and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter delete operation with destructiveHint and idempotentHint annotations, the description covers what is deleted, when to delete, and how it fits with related tools (remember, recall). It is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage; the only parameter 'key' is described as 'Memory key to delete'. The description simply echoes 'by key' without adding further semantic detail, so the schema carries the parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Delete a previously stored memory by key', which uses a specific verb and resource and clearly distinguishes it from sibling memory tools like remember and recall. It fully states the tool's core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit use cases: 'Use when context is stale, the task is done, or you want to clear sensitive data the agent saved earlier.' It also names complementary tools with 'Pair with remember and recall', giving clear context for when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Multiple tools have overlapping purposes: ask_pipeworx, ask_pipeworx_beta, ask_pipeworx_grounded, deep_research, and validate_claim all answer research questions, and the Kitsu-specific tools are mixed with unrelated Polymarket, memory, and utility tools. Despite detailed descriptions, the boundaries between many tools are unclear.
The server mixes single-word nouns (anime, manga, categories), verb_noun pairs (search_anime, top_anime), verb phrases (ask_pipeworx, generate_llms_txt), and domain-prefixed families (polymarket_*, pipeworx_*) with no consistent overall convention. While some sub-families are internally consistent, the set as a whole lacks a predictable pattern.
38 tools is excessive for a server ostensibly about Kitsu anime/manga, with only 7 tools actually serving that domain. The rest are unrelated (Pipeworx research, Polymarket trading, memory, subscriptions), making the set bloated and unfocused for its stated purpose.
The Kitsu domain lacks common operations like filtered search, character/episode data, or user lists. Meanwhile, the Pipeworx/prediction-market tools form an arbitrary subset of their domains (e.g., no general Kalshi data, no SEC full-text search), so the overall surface is incomplete for any single purpose.