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 flag destructiveHint and idempotentHint; the description adds specificity by identifying the target as a 'previously stored memory' and mentioning the sensitive-data cleanup use case. 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?
Two concise sentences, front-loaded with the action, followed by usage guidance and related tool pairing. Every sentence earns its place with no filler.
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 one-parameter destructive tool with strong annotations and no output schema, the description fully covers purpose, usage, and related tools. It is sufficient for an agent to select and invoke the tool 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, so baseline is 3. The description adds minimal extra meaning by calling it a 'previously stored memory' but doesn't elaborate on key format or constraints 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 begins with 'Delete a previously stored memory by key' – a specific verb and resource that clearly distinguishes it from siblings like 'remember' and 'recall'.
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?
Explicitly provides use cases: 'Use when context is stale, the task is done, or you want to clear sensitive data the agent saved earlier.' Also mentions pairing with remember and recall, giving practical context, though it doesn't explicitly state when not to use.
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 tool clusters overlap: ask_pipeworx/ask_pipeworx_beta/ask_pipeworx_grounded/deep_research all route to the same source catalog, the six Polymarket tools have fuzzy boundaries between research, edge scanning, arbitrage, and fill checking, and available vs quote_list both enumerate B3 tickers. The descriptions are detailed and try to differentiate, but an agent could still easily pick the wrong meta-tool.
The overwhelming majority follow lower_snake_case verb_noun naming (ask_pipeworx, resolve_entity, scan_dependency, validate_claim, list_subscriptions). Deviations like available, quote, crypto, currency, inflation, and prime_rate are bare nouns, and forget is a lone verb, but the convention remains readable and largely predictable.
38 tools is excessive for what the server name (Brapi) suggests, and the set spans unrelated domains: Brazilian market data, a 5,798-tool universal data router, Polymarket betting analytics, memory, subscriptions, AI visibility, npm dependency scanning, and llms.txt generation. The count crosses the 25+ threshold and dilutes the server's focus.
Within each sub-domain the surface is fairly complete: brapi.dev quotes/directory/rates, Pipeworx routing/grounding/research/entity resolution/validation, prediction-market arbitrage/fill checks, memory CRUD, and subscription lifecycle all cover their core workflows. Minor gaps exist, such as no dedicated historical stock-price series beyond quote's OHLC window and deep_research requiring an account, but agents can work around them.