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 and idempotentHint=true, so the baseline is lower. The description adds context beyond annotations by explaining the purpose ('clear sensitive data the agent saved earlier') and the deletion semantics ('previously stored memory'). It also notes the pairing with remember/recall, which is useful behavioral context. No contradiction found.
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 action. Every sentence provides value: what it does, when to use it, and its relationship to sibling tools. No redundant or filler content.
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?
The tool is simple with one parameter, no output schema, and annotations covering destructive/idempotent behavior. The description covers purpose, usage conditions, and pairing with related tools. There are no critical gaps for an agent to select and invoke it 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?
Schema coverage is 100% for the single 'key' parameter, with description 'Memory key to delete'. The tool description only repeats 'by key' without adding format, examples, or further semantics. Baseline 3 applies since the schema fully documents the parameter.
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 clearly states the action: 'Delete a previously stored memory by key.' The verb 'delete' and resource 'memory' are specific, and the phrase 'previously stored' distinguishes it from remembering or recalling. It also names the sibling tools 'remember' and 'recall', making the deletion purpose unambiguous.
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?
Explicit conditions are provided: 'Use when context is stale, the task is done, or you want to clear sensitive data the agent saved earlier.' This tells the agent exactly when to invoke the tool. It also says 'Pair with remember and recall,' giving clear alternatives and integration context.
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.
Most tools have distinct purposes with clear descriptions, but some overlap exists (e.g., ask_pipeworx, ask_pipeworx_grounded, deep_research all retrieve structured data with subtle differences). Competitor analytics (ai_visibility_check, scan_competitor_ai_presence) also share similar goals.
Names follow loose patterns within subgroups (get_crypto_*, polymarket_*, ask_pipeworx*), but overall there is no single consistent convention. Verbs and noun orders vary (e.g., get_crypto_price vs. validate_claim vs. remember).
35 tools is high; many exceed the core 'crypto' domain (company profiles, npm dependencies, memory management, subscriptions). While each tool seems justified, the count feels heavy for a single server, risking cognitive load.
The tool set covers crypto basics (price, market, history), company data, prediction markets, and general data retrieval comprehensively. Minor gaps exist (e.g., no direct on-chain crypto data), but cross-domain coverage is strong.