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.
Input schema / examplesAdded value: +[
+ {
+ "key": "user_research_topic"
+ }
+]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, and the description's action 'Delete' aligns with these. The note about clearing sensitive data adds a use case but not a new behavioral trait. No contradiction, but the description adds minimal context beyond what annotations already convey.
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, and every clause serves a purpose. No 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 tool with clear annotations and a comprehensive schema, the description fully equips the agent to select and invoke the tool. It covers purpose, usage, and pairing with related tools, and the output schema absence is fine for a delete operation.
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 description coverage is 100%: the only parameter 'key' is fully described as 'Memory key to delete'. The tool description's 'by key' adds no additional semantic value beyond the schema.
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 uses a specific verb+resource construction: 'Delete a previously stored memory by key.' This clearly states the action and target, and distinguishes it from sibling tools like 'remember' (create) and 'recall' (read).
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 explicitly provides when-to-use guidance: 'Use when context is stale, the task is done, or you want to clear sensitive data the agent saved earlier.' It also names companion tools ('Pair with remember and recall'), giving clear context for selection against alternatives.
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 occupy nearly identical roles: ask_pipeworx_beta is explicitly a behavioral duplicate of ask_pipeworx, and ai_visibility_check is wrapped by scan_competitor_ai_presence; deep_research and ask_pipeworx also overlap at different granularity. The extremely detailed descriptions help separate most tools, but an agent can still easily pick the wrong query or research variant.
Most tools use snake_case, but the naming pattern mixes verb phrases (list_boards, search_items), noun phrases (entity_profile, polymarket_arbitrage), and branded roots (ask_pipeworx, pipeworx_trending). The Monday tools consistently use monday_ prefixed verbs, but there is no single predictable convention across the whole set.
With 36 tools, this is well into the over-packed range, and many entries are meta-tools (suggest_questions, discover_tools, pipeworx_trending, pipeworx_feedback) that inflate the surface. The server bundles a massive Pipeworx data ecosystem with only five Monday tools, making it feel too heavy for one MCP connection.
The data side is extensive: querying, grounded verification, research, comparisons, subscriptions, memory, prediction markets, and feedback are all covered. However, the Monday.com side is only a partial lifecycle—create, get, list, and search exist, but there is no update or delete item, and no board creation or editing, which creates dead ends in basic project-management workflows.