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, covering safety and idempotency. The description adds the intent of 'clearing sensitive data' but does not elaborate on error handling or non-existent keys. Given the annotations cover the core behavioral traits, this is acceptable.
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?
Three sentences, each earning its place: the operation, the usage triggers, and the related tools. No redundant phrasing or extra details. It is front-loaded with the core action.
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 single-parameter destructive operation with rich annotations, the description covers purpose, usage, and related tools adequately. No output schema is needed for a delete operation, and the annotations fill the safety profile. The tool is simple, and the description is complete.
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%: the sole parameter key is described with 'Memory key to delete.' The tool description's 'by key' reiterates this without adding new semantics. The baseline of 3 is appropriate since the schema already carries all parameter meaning.
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 a specific verb+resource: 'Delete a previously stored memory by key.' It clearly distinguishes from siblings like remember and recall, which are explicitly mentioned, making the purpose unmistakable.
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 when-to-use conditions: 'Use when context is stale, the task is done, or you want to clear sensitive data.' It also names complementary tools ('Pair with remember and recall'), giving the agent clear workflow context. No exclusions are needed since this is the only deletion tool for memories.
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.
Several tools overlap: ask_pipeworx, ask_pipeworx_beta, ask_pipeworx_grounded, and deep_research all serve as query routers, with the beta variant currently identical to the stable one. However, most other tools have clearly distinct purposes (memory, subscriptions, prediction market analytics), and the detailed descriptions help differentiate them.
All tool names use snake_case and are descriptive, with consistent domain prefixes like pipeworx_ for meta tools and polymarket_ for prediction markets. Some names mix noun-phrase and verb-noun patterns (e.g., ai_visibility_check vs. resolve_entity), but the overall style is predictable and readable.
With 31 tools, the server exceeds the 25-tool threshold for a coherent set. While the broad scope (data querying, prediction markets, memory, subscriptions, AI visibility) justifies many tools, the sheer number creates cognitive load and makes selection harder for agents.
The tool surface is quite comprehensive for its domains: querying has ask_pipeworx, grounded answer, deep research, entity profiles, comparisons, and claim validation; prediction markets have research, arbitrage, edge tracking, and fill risk; memory and subscription lifecycles are covered. Minor gaps exist (e.g., no subscription update) but are workable.