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 provide destructiveHint=true and idempotentHint=true; description adds context about clearing sensitive data but no further behavioral details.
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 key action, 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?
Single-parameter tool with clear purpose and usage guidelines; sibling references complete the context.
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 provides full coverage (100%) with description 'Memory key to delete'; tool description does not add additional semantic details 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?
Clearly states 'Delete a previously stored memory by key.' with specific verb and resource, and distinguishes from siblings by mentioning '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?
Explicit use cases: 'when context is stale, the task is done, or you want to clear sensitive data...' and suggests pairing with remember/recall.
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 purposes: ask_pipeworx, ask_pipeworx_beta, and ask_pipeworx_grounded are near-identical variants; polymarket_edges, polymarket_arbitrage, polymarket_edge_tracker, polymarket_fill_risk, and polymarket_kalshi_spread all target prediction-market opportunities. Research tools like entity_profile, compare_entities, recent_changes, and validate_claim also blur together, making it hard to pick the right tool.
Naming conventions are inconsistent: some tools use verb_noun (get_candidate, list_applications, remember), others use noun_verb (bet_research, entity_profile) or prefix-only patterns (ask_pipeworx, pipeworx_feedback, polymarket_edges). The Ashby tools use ashby_ prefix, but the rest mix pipeworx_, polymarket_, and bare names, with no uniform style.
36 tools is excessive for a coherent server and spans unrelated domains: ATS (Ashby), data queries (Pipeworx), prediction markets (Polymarket), memory, subscriptions, and web utilities. This feels like a kitchen sink rather than a focused toolset, and the count alone makes selection overwhelming.
The Ashby ATS subset is incomplete: it provides get/list operations but no create, update, or delete for candidates or jobs, and no interview management. The broader server's scope is so mixed that each domain has obvious gaps, leaving agents unable to complete common workflows end-to-end.