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 |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true. The description adds contextual value by noting it clears 'sensitive data the agent saved earlier' and applies to 'previously stored memory', which helps the agent understand the nature of what is destroyed. No contradiction with annotations.
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 consists of three short sentences, with the action verb and object front-loaded. It provides purpose, usage guidance, and sibling pairing without any filler or redundancy.
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 deletion tool with destructive and idempotent annotations, the description is sufficiently complete: it covers what the tool does, when to use it, and the type of data involved. It does not mention return values, but there is no output schema, so this is not a significant gap.
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% and the only parameter ('key') has a clear description ('Memory key to delete'). The description's mention of 'by key' adds no additional meaning beyond what the schema already provides, so it meets the baseline without enhancing parameter understanding.
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?
Description starts with 'Delete a previously stored memory by key' – a specific verb (delete) with resource (memory) and mechanism (by key). It clearly distinguishes from siblings 'remember' and 'recall' by positioning itself as the removal counterpart, and 'previously stored' reinforces that it acts on existing memories.
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 'Use when' conditions are provided: stale context, task done, or clearing sensitive data. This gives clear context for when the tool is appropriate. However, it does not explicitly state when not to use it or name direct alternatives, though pairing with 'remember' and 'recall' implies complementary usage.
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 or near-identical purposes: ask_pipeworx, ask_pipeworx_beta, ask_pipeworx_grounded, deep_research, and validate_claim all answer factual questions with varying degrees of grounding. The polymarket_* family (edges, arbitrage, fill_risk, edge_tracker) and bet_research also create boundary confusion. An agent would struggle to consistently select the correct tool without deep reading of each description.
Most tools follow a verb_noun snake_case pattern (search_markets, get_market, compare_entities, resolve_entity), but there are clear outliers like pipeworx_trending, recent_alerts, top_markets, and pipeworx_feedback which use adjective_noun or noun_adjective forms. The pattern is mostly consistent but has enough deviations to feel mixed.
With 34 tools, the surface is decidedly heavy. Many tools serve entirely different domains (memory, subscriptions, AI visibility, npm dependency scanning, cross-venue arbitrage) rather than a unified purpose. This feels like several server concepts merged into one, making the count inappropriate for a single coherent server.
The data-research side is fairly comprehensive: querying, grounding, comparisons, profiles, claim validation, entity resolution, change tracking, and memory are all covered. However, for the nominal Futuur prediction-market domain, only read-only market lookup exists — no trading, account management, or order placement. Subscription CRUD is also missing an update operation, and several research tools only cover US public companies and specific data sources.