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 context beyond these by clarifying that it deletes a 'previously stored memory by key' and that it can be used to 'clear sensitive data.' This communicates the irreversible nature and the specific resource affected, which is useful for the agent.
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 three sentences, each carrying distinct value: the action, the use cases, and the companion tools. It is front-loaded with the primary instruction and contains no filler or redundant restatement of the tool name.
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 simple single-parameter tool with clear annotations (destructive, idempotent), the description fully covers the operation, the circumstances for use, and the relationship to sibling tools. No output schema exists, so no return-value description is needed. The description is complete and appropriately scoped.
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 schema provides 100% coverage for the only parameter 'key' with the description 'Memory key to delete.' The tool description only repeats 'by key' without adding extra detail about key format, domain values, or constraints. Since the schema already fully explains the parameter, the description adds no additional semantic value.
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 pair: 'Delete a previously stored memory by key.' It clearly identifies the action (delete) and target (memory by key). The sibling context with 'remember' and 'recall' makes its role in a memory system evident, distinguishing it from storage and retrieval tools.
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?
The description provides explicit use cases: 'Use when context is stale, the task is done, or you want to clear sensitive data.' It also says 'Pair with remember and recall,' pointing to complementary tools. However, it does not explicitly state when not to use it (e.g., for retrieval use recall), so it lacks a full exclusionary guideline.
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 serve the same 'ask a question' function (ask_pipeworx, ask_pipeworx_beta, ask_pipeworx_grounded, deep_research) with subtle differences that are hard to distinguish. Entity-oriented tools like entity_profile, recent_changes, and compare_entities also overlap on company information, making selection ambiguous.
All tool names are lowercase snake_case and mostly descriptive, with consistent prefixes for tool families (ask_pipeworx, polymarket_*, statuspage_*). However, there is no uniform verb_noun pattern — some are bare verbs (forget, remember, recall) while others are noun phrases (entity_profile, recent_changes) — so predictability is moderate.
With 35 tools, this set is heavily overloaded for a server named Statuspage; only 4 tools actually relate to status pages, while the rest form a broad data query, prediction market, and memory toolkit. The count is far beyond what the name implies and dilutes focus.
For a Statuspage server, the tool surface is severely incomplete: it only reads status and incidents and provides no way to create, update, or resolve incidents. Even for the broader data-tool domain, there are gaps — no direct record-fetch by ID and no write/update operations for data sources.