What can you do with this server?

Amber is an MCP server that gives AI assistants persistent, searchable long-term memory across conversations. * Store memories: amber_store_memory saves text as atomic facts with optional topics and metadata; processing is async (10-30s) and returns a task ID. * Check store status: amber_get_store_task_status polls the background processing of a store task. * Search memories: amber_search_memories performs semantic (vector + keyword) search with query expansion, optional topic filters, metadata filters, and returns ranked results. * Retrieve full memory: amber_get_memory fetches untruncated content of a specific memory by ID. * Delete memories: amber_delete_memory soft-deletes single or batch memories to the trash. * Restore memories: amber_restore_memory brings trashed memories back to active. * Search deleted memories: amber_search_deleted_memories finds soft-deleted memories by meaning. * List active memories: amber_list_memories paginates through all active memories chronologically (newest first). * List deleted memories: amber_list_deleted_memories paginates through the trash. * Account status: amber_get_account_status returns subscription state, billing dates, memory counts. * Manage subscription: amber_manage_subscription provides a PayPal link to update payment/billing. * Cancel subscription: amber_cancel_subscription cancels PayPal subscription (access continues until period end). * Reactivate subscription: amber_reactivate_subscription creates a new PayPal subscription with trial/return logic. * Export memories: amber_export_memories generates a downloadable JSON backup of all memories (active and deleted). * Delete account: amber_delete_account schedules permanent deletion in 30 days (reversible via cancellation). * Cancel account deletion: amber_cancel_account_deletion stops scheduled deletion and unblocks memory tools. * Send feedback: amber_send_feedback_to_developer submits bug reports, feature requests, or general feedback. * Dismiss notifications: amber_mark_notification_read clears developer notifications shown in tool responses.

Which integrations are available for this server?

Provides long-term memory for Codeium-based AI assistants (e.g., Windsurf), improving context retention across sessions. Provides long-term memory for GitHub Copilot in VS Code, allowing it to recall user preferences and project context. Provides long-term memory for ChatGPT, enabling persistent recall of user information and conversation history.

de en es ja ko ru zh

Amber

Official

by ambermem

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Amber is an MCP server that gives AI assistants persistent, searchable long-term memory across conversations.

Store memories: amber_store_memory saves text as atomic facts with optional topics and metadata; processing is async (10-30s) and returns a task ID.
Check store status: amber_get_store_task_status polls the background processing of a store task.
Search memories: amber_search_memories performs semantic (vector + keyword) search with query expansion, optional topic filters, metadata filters, and returns ranked results.
Retrieve full memory: amber_get_memory fetches untruncated content of a specific memory by ID.
Delete memories: amber_delete_memory soft-deletes single or batch memories to the trash.
Restore memories: amber_restore_memory brings trashed memories back to active.
Search deleted memories: amber_search_deleted_memories finds soft-deleted memories by meaning.
List active memories: amber_list_memories paginates through all active memories chronologically (newest first).
List deleted memories: amber_list_deleted_memories paginates through the trash.
Account status: amber_get_account_status returns subscription state, billing dates, memory counts.
Manage subscription: amber_manage_subscription provides a PayPal link to update payment/billing.
Cancel subscription: amber_cancel_subscription cancels PayPal subscription (access continues until period end).
Reactivate subscription: amber_reactivate_subscription creates a new PayPal subscription with trial/return logic.
Export memories: amber_export_memories generates a downloadable JSON backup of all memories (active and deleted).
Delete account: amber_delete_account schedules permanent deletion in 30 days (reversible via cancellation).
Cancel account deletion: amber_cancel_account_deletion stops scheduled deletion and unblocks memory tools.
Send feedback: amber_send_feedback_to_developer submits bug reports, feature requests, or general feedback.
Dismiss notifications: amber_mark_notification_read clears developer notifications shown in tool responses.

Amber

Long-term memory for AI assistants.

Amber is an MCP server that gives any AI assistant persistent, searchable memory across conversations. Your AI remembers preferences, decisions, project context, and personal details - without you doing anything special.

Just talk normally. Amber stores what matters and finds it when relevant.

Quick Install

One command. Works with any MCP-compatible client.

Claude Code / Claude Desktop

claude mcp add --transport http --scope user amber https://mcp.ambermem.com

Cursor

Add to ~/.cursor/mcp.json (or %USERPROFILE%\.cursor\mcp.json on Windows):

{
  "mcpServers": {
    "amber": {
      "url": "https://mcp.ambermem.com"
    }
  }
}

ChatGPT

Settings → Connectors → Create → URL: https://mcp.ambermem.com

Windsurf

Add to ~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "amber": {
      "serverUrl": "https://mcp.ambermem.com"
    }
  }
}

VS Code (GitHub Copilot)

Add to .vscode/mcp.json:

{
  "servers": {
    "amber": {
      "type": "http",
      "url": "https://mcp.ambermem.com"
    }
  }
}

Any MCP client

URL: https://mcp.ambermem.com | Transport: Streamable HTTP | Auth: OAuth 2.1 (auto-discovered)

Related MCP server: MCP-Mem0

How It Works

You talk to your AI normally. Amber stores important facts in the background.
Next conversation, your AI searches Amber automatically when context would help.
Memory improves over time. The more you use it, the better it gets.

No configuration. No tagging. No manual organization.

What Makes Amber Different

Feature	Basic memory servers	Amber
Storage	One embedding per memory	Multiple semantic variants per fact
Search	Single vector lookup	Hybrid: vector + keyword + RRF fusion
Queries	Exact match only	Many phrasings per fact, matched semantically
Input	Stored as-is	Chunked into atomic facts, each independently searchable
Topics	Manual tags or none	Auto-grouped, matched semantically at search time
Privacy	Varies by server	No generative model reads your memories
Time	No temporal awareness	Natural language time parsing ("last week", "3 days ago")

Technical Details

25 MCP tools (14 memory, 9 account, 2 feedback/notification)
Hybrid retrieval pipeline: vector search + full-text search + Reciprocal Rank Fusion
Multi-variant embeddings: every fact is stored with several paraphrases — at least 5, and a store is rejected below that — which is the main thing that makes it findable later
No generative model reads your memories: your assistant does the chunking, the topics and the phrasings. Memory text is sent only to an embedding endpoint (a vector model, not a chat model), so no chat model is ever shown what you store
Atomic facts: a conversation becomes individually searchable facts rather than one blob, each with its own subjects, topics and dates
Temporal search: "what did I say last week?" resolves to a real date range rather than a keyword match
Automatic topic grouping: memories are grouped by topic, and a search for "work" also finds "career" and "job"
Async processing: storage completes in the background, never blocking your conversation

Pricing

60-day free trial - no charge, cancel anytime
$2.99/month after trial, via PayPal
Cancel instantly - ask your AI to cancel, or cancel through PayPal directly
No lock-in - export all your data as JSON anytime

Privacy

No email collected
No marketing, no spam
Data isolated per user (separate database)
PayPal handles all payment info
Full export + account deletion available
GDPR compliant (data minimization by design)

Architecture

Amber runs on Cloudflare Workers (zero cold starts, global edge deployment) with Turso databases (one per user, full isolation). LLM processing uses Gemini Flash for chunking/expansion and OpenAI for embeddings.

For full technical documentation: ambermem.com/llms.txt

FAQ

Will it slow my AI down? No. Storage is async (background). Search adds <1 second.

What if Amber shuts down? Export all your data as JSON anytime. Your data is always yours.

Do I need a PayPal account? Currently yes. PayPal handles both identity and billing. More login options coming soon.

Is my data safe? Each user gets a completely isolated database. No data is shared between users. Amber has no access to your PayPal payment details.

Can I self-host? Not currently. Amber is a managed service. We handle the infrastructure, scaling, and LLM costs so you don't have to.

Available Tools

18 tools

amber_cancel_account_deletionAInspect

Cancel a previously scheduled account deletion. Removes the deletion deadline and unblocks memory tools immediately. Access resumes until next_billing_date (the remaining paid period). No data is lost.

Side effects: clears deletion_scheduled_at from the account. The PayPal subscription was already cancelled when deletion was scheduled — call amber_reactivate_subscription to start a new one if the paid period has expired. Returns code: not_scheduled if no deletion is pending. Not rate-limited.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description fully carries the burden. It discloses side effects (clears deletion_scheduled_at), explains that data is not lost, describes access until next_billing_date, clarifies that PayPal subscription was already cancelled, and states it is not rate-limited. This comprehensive coverage surpasses typical descriptions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, each adding value. The first sentence states the primary purpose, the second covers side effects and access, and the third addresses edge cases and rate limiting. No superfluous words, perfectly front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no parameters and no output schema, the description covers all necessary aspects: what it does, side effects, return value note, rate limits, and related tools. It is fully self-contained and leaves no gaps for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, so the description has no parameter information to add. Following the guideline (0 params = baseline 4), the score is 4, as the description adds context about the tool's effect but cannot add parameter semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Cancel a previously scheduled account deletion'), uses specific verb (cancel) and resource (account deletion), and distinguishes from siblings like amber_delete_account (which schedules deletion) and amber_reactivate_subscription (for re-subscribing).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use (cancel a pending deletion) and mentions alternatives ('call amber_reactivate_subscription' if paid period expired). Also notes the return code 'not_scheduled' for cases where no deletion is pending, providing clear context for appropriate use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

amber_cancel_subscriptionAInspect

Cancel the user's PayPal subscription. Access continues until next_billing_date (already paid). Data is preserved, not deleted. Do NOT use if the user wants to delete their account entirely — use amber_delete_account instead.

Cancellation is sent to PayPal immediately; status update arrives via webhook within ~1 minute. Returns code: no_subscription if none exists. Requires confirm: true.

ParametersJSON Schema

Name	Required	Description	Default
`confirm`	Yes	When `true`: cancels the subscription on PayPal and updates account status. When `false`: returns `code: cancelled` with no side effects, letting you confirm intent first.

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes key behaviors: access continues until next_billing_date, data preserved, webhook delay, return codes. No annotations exist, so description carries full burden and handles it well.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact paragraphs with front-loaded purpose. Every sentence adds value—no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all important aspects for a one-parameter cancellation tool: when to use, behavior, return values, and async nature. No output schema, but description compensates effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema provides 100% description coverage for the single confirm parameter. Description adds value by explaining the return code when false, providing context beyond the schema's technical specification.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Cancel the user's PayPal subscription' with a specific verb and resource. Distinguishes from sibling tools like amber_delete_account and amber_reactivate_subscription.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when not to use (account deletion) and provides alternative tool. Also explains the asynchronous webhook behavior and the confirm parameter's role.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

amber_delete_accountAInspect

Schedule permanent account deletion in 30 days. Memory tools are blocked immediately (unlike cancellation, which keeps access until period end). Cancels the PayPal subscription. Reversible within 30 days via amber_cancel_account_deletion.

During the grace period: account management tools (status, export, feedback) remain accessible; memory tools are blocked. After 30 days: all data is permanently deleted.

Requires confirm: true. Returns code: cancelled when false, code: already_scheduled if already pending.

ParametersJSON Schema

Name	Required	Description	Default
`confirm`	Yes	Set `true` to proceed, `false` to abort without changes.

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, description fully covers behavior: immediate block of memory tools, subscription cancellation, grace period access, permanent deletion after 30 days, and return codes. Transparent about reversibility and effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with key action first, then bullet points for details. Slightly verbose but every sentence adds necessary information. No fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given single parameter and no output schema, description covers all needed context: preconditions, effects, timing, return values, and relationship to sibling tools. No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema already describes the boolean confirm parameter well (100% coverage). Description adds value by stating that confirm=true is required for proceeding and explaining return codes (cancelled vs already_scheduled).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool schedules permanent account deletion in 30 days, distinguishes from cancellation (which keeps access until period end), and lists specific effects like blocking memory tools and cancelling subscription.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells when to use (to delete account) and when not (cancellation as alternative). Mentions confirm flag requirement and provides pointer to reversal tool. No ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

amber_delete_memoryAInspect

Soft-delete one or more memories to the trash. Reversible via amber_restore_memory. Do NOT use for account-level cleanup — use amber_delete_account instead.

Provide memory_id (single) or memory_ids (batch, max 100). At least one is required. Idempotent: already-deleted memories are skipped. Returns deleted_count. Returns code: not_found if no IDs matched active memories. Requires an active subscription. Not rate-limited.

ParametersJSON Schema

Name	Required	Description	Default
`memory_id`	No	UUID of a single memory to trash. Omit if using `memory_ids` for batch.
`memory_ids`	No	Array of memory UUIDs to trash in one call (max 100). Omit if using `memory_id` for single.

TDQS

A5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations were provided, so the description carries full burden. It discloses key behaviors: soft-delete (reversible), idempotent (skips already-deleted), return values (`deleted_count`, `not_found` error code), requires active subscription, and not rate-limited. This covers safety and operational traits comprehensively.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief yet comprehensive. It front-loads the main action and then lists constraints, behaviors, and return values in a logical order. Every sentence provides necessary information with no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description is remarkably complete. It covers purpose, usage guidelines, parameter semantics, behavioral traits (idempotent, reversible), error scenarios, prerequisites (active subscription), and rate limiting. No significant gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% coverage, but the description adds value by explaining the distinction between `memory_id` and `memory_ids`, that at least one is required, and the max batch size of 100. This clarifies usage beyond the schema definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it 'soft-delete one or more memories to the trash', providing a specific verb and resource. It distinguishes itself from sibling `amber_delete_account` by explicitly noting not to use for account-level cleanup.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when NOT to use (for account-level cleanup) and provides the alternative `amber_delete_account`. Also mentions reversibility via `amber_restore_memory`, giving clear usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

amber_export_memoriesAInspect

Export every active memory as a JSON file. Returns a download URL valid for 7 days. The file contains all memories with cleaned metadata (internal prefixes stripped, implementation fields removed). The user should open the download URL in their browser to save the file.

Use this when the user wants a backup, wants to migrate data, or asks "can I download my data?". Unlike amber_list_memories (which paginates and shows one page at a time), this exports ALL memories in a single downloadable file. Unlike amber_search_memories (which finds specific content), this is a complete dump.

Each call generates a fresh export — previous export URLs remain valid for their full 7-day window. The export includes both active and deleted memories, with topics and metadata. Large accounts (10,000+ memories) may take a few seconds to generate. Does not modify any data — read-only operation. Requires an active subscription. Not rate-limited.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully covers behaviors: fresh export per call, 7-day URL validity, includes deleted memories, read-only, subscription required, no rate limit, and performance considerations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear comparisons and bullet points, but slightly verbose; could be tightened without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Comprehensive: explains return value (download URL with expiry), constraints (7 days, large accounts), and implicitly addresses failure modes, despite no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters in schema; baseline 4 applies. Description doesn't need to add meaning for nonexistent parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool exports all active memories as a JSON file, differentiating it from siblings like amber_list_memories and amber_search_memories.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use (backup, migration, download request) and contrasts with alternatives, providing clear usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

amber_get_account_statusAInspect

Return the authenticated user's account summary: subscription state, next billing date, memory counts, and account creation date. Use this when the user asks about their account, subscription status, or how many memories they have.

After cancellation, access continues until next_billing_date (the end of the paid period). Once expired, memory counts show as null (data is preserved, just not queryable until resubscribed). If deletion_scheduled_at is set, the account is pending permanent deletion — use amber_cancel_account_deletion to stop it. Read-only — does not modify any account state. Not rate-limited.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses behavioral traits: it declares read-only status ('Does not modify any account state'), not rate-limited, and explains null memory counts after cancellation and deletion scheduling implications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (6 sentences) and well-structured: purpose, usage guidance, behavioral details, and safety note. Every sentence adds valuable information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, no output schema), the description fully covers purpose, usage, behavioral side effects, and safety, leaving no gaps for an agent to misunderstand.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters with 100% schema coverage, so no parameter descriptions are needed. The description adds no param info, but baseline for 0 params is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'Return the authenticated user's account summary' and lists specific data fields (subscription state, next billing date, memory counts, account creation date), clearly distinguishing it from sibling tools that manage subscriptions or memories.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It tells exactly when to use the tool ('when the user asks about their account, subscription status, or how many memories they have') and provides context on post-cancellation behavior, referencing the alternative action amber_cancel_account_deletion for deletion scheduling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

amber_get_memoryAInspect

Retrieve a single memory by its ID with full, untruncated content. Use this after amber_search_memories when a result's content was truncated (indicated by truncated: true), or when you have a memory_id from a previous interaction and need the complete text.

Returns the memory with its full content, metadata (if any), topic names (if any), and created_at timestamp. Returns code: not_found if the memory doesn't exist, was hard-deleted, or is currently in the trash. To access soft-deleted memories, use amber_search_deleted_memories or amber_list_deleted_memories instead. Read-only — does not modify the memory. Not rate-limited. Requires an active subscription.

ParametersJSON Schema

Name	Required	Description	Default
`memory_id`	Yes	UUID of the target memory. Found in `amber_store_memory` task results, `amber_search_memories` result items, or `amber_list_memories` pages.

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations, but description fully discloses return content, not_found code, read-only, no rate limit, subscription requirement. Comprehensive behavioral info.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with front-loaded purpose, usage, return, error. Slightly wordy but each sentence adds value. Efficient for the detail provided.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but description covers return fields, error codes, and behavioral traits. Completely sufficient for a simple retrieval tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. Description adds value by explaining where to find memory_id (from other tools), surpassing schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Retrieve a single memory by its ID with full, untruncated content.' Uses specific verb + resource and distinguishes from sibling tools like amber_search_memories which may truncate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use (after truncated results or when memory_id is known) and when not to use (not_found cases), with alternatives like amber_search_deleted_memories.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

amber_get_store_task_statusAInspect

Check the processing status of a memory store task. Call this after amber_store_memory to confirm processing completed. Not rate-limited. Read-only. Requires an active subscription.

Statuses: pending (queued), processing (in progress), completed (done, memory_ids available), error (permanently failed).

Processing phases (shown in progress field): chunking → expanding/embedding chunks (parallel) → resolving topics (parallel search, sequential creation) → inserting memories (parallel). If processing fails (e.g. LLM timeout), it retries up to 3 times. No duplicates are created on retry. Only after all retries are exhausted does the status become error with the failure reason.

Returns code: not_found if the task_id doesn't exist or has expired (tasks are pruned after 7 days).

ParametersJSON Schema

Name	Required	Description	Default
`task_id`	Yes	UUID from `amber_store_memory`'s response. Poll this to know when memories are ready to search. Invalid IDs return `code: not_found`.

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses behavior: read-only, not rate-limited, retry policy (up to 3 times, no duplicates), processing phases, expiration after 7 days, and error handling. This is thorough and meets the burden.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear front-loading: purpose first, then usage, statuses, phases, error handling. Slightly verbose due to detailed phase explanation, but every part serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Comprehensive coverage of all relevant aspects: statuses, processing phases, retry, expiration, and error responses. No output schema, so description handles return value explanation effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for the one parameter, but the description adds value by clarifying the source of the task_id (UUID from amber_store_memory response) and the meaning of invalid IDs (not_found). This goes beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks the processing status of a memory store task, with specific verb 'Check' and resource 'processing status'. It distinguishes itself from sibling tools like amber_store_memory and amber_get_memory by specifying it is used after storing memory.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use this tool: after amber_store_memory to confirm processing completion. Also notes it is not rate-limited and read-only. Does not explicitly mention when not to use, but the context is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

amber_list_deleted_memoriesAInspect

Browse the trash in reverse chronological order of deletion (most recently deleted first). Supports cursor pagination via after_id. has_more tells you whether another page exists. Use amber_restore_memory to bring an item back, or amber_search_deleted_memories for meaning-based search within the trash.

Each result includes full content (not truncated), metadata, topics, creation timestamp, and deletion timestamp. Read-only — does not modify or permanently delete any memories. Not rate-limited. Requires an active subscription.

Returns memories array, next_cursor (null if no more pages), and has_more boolean.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Number of deleted memories per page (default 20, min 1, max 100). Use smaller values (5-10) for quick checks, larger values (50-100) for bulk review. Omit to use the default of 20.
`after_id`	No	Pagination cursor (memory ID string). Pass the `next_cursor` value from a previous response to fetch the next page. Omit on the first call to start from the most recently deleted memory. Do not fabricate cursor values.

TDQS

A5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but description fully discloses behavior: read-only, does not modify or delete, not rate-limited, requires active subscription. Also details output contents (full content, metadata, timestamps).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is concise, with key information front-loaded. Every sentence adds value, no redundancy. Well-structured with clear sections for purpose, usage, and output.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, description fully explains return values (memories array, next_cursor, has_more). Covers pagination, content details, and relationship to sibling tools. Complete for a list tool with good annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but description adds significant meaning: default limit, suggested values for quick checks vs bulk review, explains after_id cursor usage with warning not to fabricate, and clarifies has_more and next_cursor.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool browses trash in reverse chronological order, with specific verb 'browse' and resource 'trash'. It distinguishes from siblings by mentioning when to use amber_restore_memory and amber_search_deleted_memories.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly provides when to use this tool (browse trash) and when to use alternatives (restore via amber_restore_memory, search via amber_search_deleted_memories). Also guides pagination with after_id and has_more.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

amber_list_memoriesAInspect

Browse all active memories in reverse chronological order (newest first). Use cursor-based pagination via after_id. has_more tells you whether another page exists. Prefer amber_search_memories when looking for specific content; use this when the user wants a browsing overview or asks "show me my recent memories".

Each result includes full content (not truncated), metadata, topics, and creation timestamp. Read-only — does not modify any memories. Not rate-limited. Requires an active subscription.

Returns memories array, next_cursor (null if no more pages), and has_more boolean.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Number of memories per page (default 20, min 1, max 100). Use smaller values (5-10) for quick overviews, larger values (50-100) for bulk browsing. Omit to use the default of 20.
`after_id`	No	Pagination cursor (memory ID string). Pass the `next_cursor` value from a previous response to fetch the next page. Omit on the first call to start from the newest memory. Do not fabricate cursor values.

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It declares read-only, not rate-limited, requires active subscription. Describes result structure (full content, metadata, topics, timestamp).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, each serving a distinct purpose: main action, pagination, usage advice, result details. No redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but description clearly specifies return fields (memories array, next_cursor, has_more). Covers parameters, behavior, prerequisites. Complete for a list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with good param descriptions. The description adds value by advising on limit ranges (5-10 for quick overviews, 50-100 for bulk) and warning against fabricating cursor values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists active memories in reverse chronological order. It distinguishes from sibling tool amber_search_memories by specifying browsing vs. specific search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells when to use this tool (browsing, 'show me my recent memories') and when to use the alternative (search for specific content). Provides pagination usage pattern.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

amber_manage_subscriptionAInspect

Return a PayPal URL the user can open to manage their subscription (update payment method, view billing history, change payment source) and the next billing date. Use this when the user asks about billing, wants to change their payment method, or wants to view their subscription details.

Unlike amber_cancel_subscription (which cancels) or amber_reactivate_subscription (which creates a new subscription), this tool only provides a link to PayPal's self-service page — no changes are made by calling it.

The URL opens PayPal's subscription management page — Amber does not handle payment details directly. Returns code: no_subscription if the account has no subscription on record (use amber_reactivate_subscription to start one). Read-only — does not modify the subscription. Not rate-limited.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but description fully discloses it is read-only, does not modify subscription, not rate-limited, returns a PayPal link, and includes error code 'no_subscription'. All behavioral traits are explained.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, front-loaded with purpose, no redundant information. Each sentence adds value: purpose, comparison to siblings, PayPal handling, error case.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, but description adequately explains return values (URL, billing date) and error codes. Covers all needed context for a zero-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 0 parameters, so baseline is 4. Description adds value by explaining what the tool does and what it returns, though no parameters to document.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it returns a PayPal URL and next billing date, using specific verb 'Return' and resource 'PayPal URL'. Differentiates from siblings like cancel and reactivate by noting it only provides a link, not making changes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use (user asks about billing, change payment method, view details) and contrasts with siblings (cancel and reactivate). Also advises using reactivate if no subscription exists.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

amber_mark_notification_readAInspect

Dismiss a developer notification after the user has acknowledged it. Permanently removes it from the developer_notifications block that appears in every tool response.

Side effects: deletes the notification row from the user's database. Idempotent in intent but returns code: not_found if already dismissed. Only call after the user has seen the notification content. Not rate-limited.

ParametersJSON Schema

Name	Required	Description	Default
`notification_id`	Yes	Positive integer from the `id` field of a notification in `developer_notifications`. Example: if the block contains `{id: 42, message: "..."}`, pass 42. Each ID is unique and single-use.

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses side effects (deletes database row), idempotency with specific error code, and explicitly states it is not rate-limited. This meets all behavioral transparency needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loading the core purpose, then adding side effects and usage notes. Every sentence is meaningful with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool with no output schema, the description covers purpose, side effects, error handling, and usage constraints. It is complete and leaves no significant gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The sole parameter notification_id is fully described in the input schema with a detailed example and type. The tool description does not add extra parameter information, but schema coverage is 100% and schema description is comprehensive, so baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool dismisses a developer notification after acknowledgment, specifying it removes it from the developer_notifications block. This distinguishes it from sibling tools like delete, cancel, or restore.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Only call after the user has seen the notification content', providing clear when-to-use guidance. It also notes the idempotent behavior with not_found response, but does not explicitly state when not to call (e.g., if already dismissed), though that is implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

amber_reactivate_subscriptionAInspect

Create a PayPal subscription and return an approval URL. The user MUST open this URL in their browser to activate. Do NOT use if the user just wants to manage an existing subscription — use amber_manage_subscription instead.

First-time: 60-day free trial, then $2.99/month. Returning: preserves remaining free days, or bills immediately if expired. Warn the user to log in with the SAME PayPal account they originally signed up with.

No charge until the user approves. Returns code: already_active if active, code: deletion_scheduled if deletion is pending.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description fully covers behavior: returns approval URL, no charge until approval, and possible codes (already_active, deletion_scheduled). Also explains trial/pricing logic.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is clear and well-structured with separate pieces of information, but could be slightly more concise. It effectively front-loads the main purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and no output schema, the description covers all necessary behavior, including return values and conditions, making it completely understandable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters in input schema; description adds meaning by explaining tool reacts to user state (first-time vs. returning) without needing explicit parameters. Baseline for 0 params is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it creates a PayPal subscription and returns an approval URL. Distinguishes from sibling amber_manage_subscription by specifying when not to use it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use (first-time vs. returning), warns to use same PayPal account, and provides alternative tool for managing an existing subscription.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

amber_restore_memoryAInspect

Un-delete memories from the trash, making them searchable and visible in amber_list_memories again. Use after amber_search_deleted_memories or amber_list_deleted_memories to recover accidentally deleted content. Do NOT use for new content — use amber_store_memory instead.

Provide memory_id (single) or memory_ids (batch, max 100). At least one is required. Idempotent: already-active memories are skipped. Side effects: moves memories from trash to active. Returns restored_count. Returns code: not_found if no IDs matched deleted memories. Requires an active subscription. Not rate-limited.

ParametersJSON Schema

Name	Required	Description	Default
`memory_id`	No	UUID of a single memory to restore. Omit if using `memory_ids` for batch.
`memory_ids`	No	Array of memory UUIDs to restore in one call (max 100). Omit if using `memory_id` for single.

TDQS

A5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description fully discloses idempotency, side effects (moves from trash to active), return value (restored_count), error responses (code: not_found), subscription requirement, and rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Every sentence is purposeful, front-loaded with the main action, and efficiently structured. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the parameters (100% schema coverage, no output schema), the description covers return values, error cases, side effects, and prerequisites, making it fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Adds meaning beyond the schema: clarifies memory_id is for single use, memory_ids for batch (max 100), at least one required, and notes idempotence on already-active memories.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Un-delete memories from the trash' with a specific verb and resource, and differentiates from sibling tools like amber_store_memory and amber_delete_memory.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly provides context for when to use (after amber_search_deleted_memories or amber_list_deleted_memories) and when not to ('Do NOT use for new content'), with an alternative tool named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

amber_search_deleted_memoriesAInspect

Search within the trash for soft-deleted memories. Useful when the user asks about something they've since deleted. Results are ordered by relevance (higher score = better match; scores are relative within a single query). Optional max_age_days restricts to recently deleted items. Optional topics filters by topic (semantic matching). Content is truncated to 1000 chars — use amber_get_memory for full content. Use amber_restore_memory to bring a result back. Rate-limited (search bucket: 5000 capacity, refills ~1 per 17 seconds).

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Natural-language question or description of what to find. Use full sentences, not keywords.
`n_results`	No	Maximum results (default 10, max 100).
`metadata_filter`	No	Optional metadata filter.
`max_age_days`	No	Only consider memories deleted within the last N days.
`topics`	No	Optional topic filter. Pass category names like 'food', 'work', 'beliefs'. Matched semantically.

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses behavior: searches trash, relevance ordering, score meaning, optional filters, content truncation to 1000 chars, and rate limits (5000 cap, ~1 per 17s refill). No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: purpose, usage context, result ordering, optional parameters, truncation note, related tools, rate limits. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains return ordering and score meaning. Covers all critical aspects (5 params, 1 required, nested objects) thoroughly. No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% coverage, so baseline 3. Description adds minor nuance: query should be full sentences, default n_results=10, topics use semantic matching. Not significantly beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches within trash for soft-deleted memories, and specifies when to use it (user asks about deleted items). It distinguishes from siblings like amber_search_memories and amber_list_deleted_memories.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit context on when to use (user asks about deleted items), result ordering, and optional filters. It references sibling tools for related actions (get full content, restore). Could be improved by explicitly stating not to use for non-deleted memories.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

amber_search_memoriesAInspect

Find active memories by semantic meaning. Write the query as a natural-language question or description, NOT as keywords. Good: "What are the user's dietary preferences?", "meetings the user had last week". Bad: "diet food preferences", "meeting notes". The query is automatically expanded with synonyms and related terms to improve recall. Supports optional metadata filtering (e.g. { "user_tag": "work" }). Results are ordered by relevance (higher score = better match). Scores are only meaningful for ranking within a single query, not across different queries. Use amber_list_memories for chronological browsing. Optional topics param: pass topic names (like when storing) to filter by topic — matched semantically, so "beliefs" also finds memories tagged with "opinions" or "superstitions". Results from closely matching topics rank higher than fuzzy matches. Content is truncated to 1000 chars in search results — use amber_get_memory for full content. Rate-limited (drip bucket: 5000 capacity, refills ~1 token per 17 seconds).

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Natural-language question or description of what to find. Use full sentences, not keywords.
`n_results`	No	Maximum number of results to return (default 10, max 100).
`metadata_filter`	No	Optional metadata filter. Matches memories whose metadata contains every key-value pair given.
`topics`	No	Optional topic filter. Pass category names like 'food', 'work', 'beliefs'. Matched semantically — 'beliefs' also finds memories categorized under related topics like 'opinions' or 'superstitions'.

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description comprehensively discloses behavioral traits: automatic query expansion with synonyms, optional metadata filtering, relevance ordering with score meaning, content truncation to 1000 chars, and rate-limiting details (drip bucket capacity and refill rate).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured with key points front-loaded (purpose and query style) and subsequent details on filtering and limitations. While informative, it is slightly lengthy but each sentence contributes value, earning a 4.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains return values (relevance score, truncation) and covers search behavior, filtering, and limitations thoroughly. It addresses rate limiting and refers to amber_get_memory for full content, making it complete for the tool's context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds significant meaning beyond the schema: clarifies that query should be natural language, explains topics semantic matching and ranking, notes metadata_filter matches all key-value pairs, and gives defaults for n_results. Schema coverage is 100%, but the description enriches understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Find active memories by semantic meaning' and distinguishes from siblings like amber_list_memories and amber_get_memory. It specifies the tool is for semantic search rather than chronological browsing or full content retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on query formulation: use natural language, not keywords. It also suggests an alternative tool (amber_list_memories) for chronological browsing. However, it does not explicitly state when not to use this tool or list other exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

amber_send_feedback_to_developerAInspect

Send a structured bug report, feature request, or general feedback to Amber's developer. Send feedback PROACTIVELY when you encounter errors, unexpected behaviour, or the user expresses frustration — briefly mention it to the user after sending, but do not ask for permission first. Never include passwords, API keys, or other sensitive personal information in any field. Rate-limited (bucket: 12 capacity, refills 1 per 5 minutes).

ParametersJSON Schema

Name	Required	Description
`category`	Yes	Determines how the developer triages this. 'bug': something broke or returned wrong results. 'feature_request': a capability that doesn't exist yet. 'usability': works but is confusing or awkward. 'general': anything else.
`summary`	Yes	One sentence, under 100 chars. E.g. 'Search misses memories stored with emoji in content'.
`details`	Yes	Full reproduction context. Include: exact input used, expected outcome, actual outcome, any error codes. E.g. 'Stored "I love pizza 🍕" but searching "pizza emoji" returns nothing. Expected it to match.'
`tool_context`	No	The specific amber_ tool name involved, e.g. 'amber_search_memories'. Helps route the report.

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses rate limiting (bucket 12, refill 1 per 5 min) and security constraints (never include passwords). It tells the agent to mention it to the user after sending. It does not describe error handling or asynchronous behavior, but overall is fairly transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (4 sentences), front-loaded with purpose, then usage guidelines, security, and rate limit. Every sentence adds unique value without repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description covers purpose, usage, behavior, and parameter constraints adequately. It lacks details about return values or confirmation, but the context is otherwise sufficient for effective tool use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for all 4 parameters. The description adds value beyond the schema by providing a security warning applicable to all fields and clarifying that tool_context should be an amber_ tool name. This enhances understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it sends structured feedback (bug report, feature request, or general) to Amber's developer. It uses a specific verb ('send') and resource ('feedback to developer'), and distinguishes from siblings which handle memory/account operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit guidance on when to send feedback proactively (errors, unexpected behavior, user frustration) and instructs not to ask for permission. It also warns against including sensitive info. However, it does not explicitly rule out other inappropriate uses, though context implies appropriate usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

amber_store_memoryAInspect

Store text as long-term memory. Returns a task_id for tracking. Use amber_get_store_task_status with the task_id to check progress and get the resulting memory IDs when complete. The text is processed in background: chunked into atomic facts, each fact expanded and embedded in parallel, topics resolved (parallel search + sequential creation), then memories inserted in parallel. Typically completes in 10-30 seconds.

Provide metadata when there are specific values worth filtering on later.

TOPICS vs METADATA -- different purposes:

topics = broad subject areas this memory belongs to (like folders). Matched SEMANTICALLY: "career" will find an existing "work" topic automatically, no need to guess exact names. Pick 1-3 areas. Auto-created if no similar topic exists. Examples: "work", "health", "preferences", "family", "cooking", "finances".

metadata = concrete values for EXACT-MATCH filtering in amber_search_memories. Only useful for specific, structured data you want to filter on later: person names, dates, project names, sources. These are NOT semantic -- metadata: {person: "Sarah"} only matches searches filtered by person = "Sarah", not "Sara" or "S. Johnson". Do NOT put categories, importance levels, or topic names in metadata -- that is what topics are for.

Examples: amber_store_memory({ content: "User prefers dark mode in all apps", topics: ["preferences"] })

amber_store_memory({ content: "Meeting with Sarah on Friday to discuss Q3 budget", metadata: {person: "Sarah", date: "2026-05-09", project: "Q3 budget"}, topics: ["work", "meetings"] })

amber_store_memory({ content: "User is allergic to peanuts", topics: ["health"] })

Rate-limited (drip bucket: 1000 capacity, refills ~1 token per 86 seconds. You can burst up to 1000 stores before hitting the limit).

ParametersJSON Schema

Name	Required	Description
`content`	Yes	The text to remember, 1-50000 characters.
`metadata`	No	Concrete values for exact-match filtering in searches. Only useful for structured data like person names, dates, project names, sources. NOT for categories or topic names. Example: {person: "Sarah", date: "2026-05-09"}.
`topics`	No	Optional broad categories for this memory (e.g. 'work', 'health', 'travel'). Only needed when the category can't be inferred from the text itself -- most memories don't need this. Matched semantically, so you don't need to guess exact names. Do NOT use topics for specific names, dates, or values -- use `metadata` for those (e.g. {"person": "Sarah"}). Topics are searched semantically; metadata is filtered by exact match.

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully covers behavioral traits: async background processing, chunking into atomic facts, parallel expansion and embedding, topic resolution, rate limits (drip bucket with capacity and refill rate), and typical completion time.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with headers and examples, but it is relatively long. Every sentence adds value, though some redundancy exists (e.g., rate limit details repeated). Front-loaded with key info.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains the return (task_id) and how to check progress to get memory IDs. It covers all parameters, async behavior, rate limiting, and offers examples, making it comprehensive for a complex store tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the description adds significant value beyond the schema by explaining the semantic vs exact-match distinction, providing examples, and clarifying the purpose of each parameter (e.g., topics vs metadata).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Store text as long-term memory' and explains the async process with a task_id. It distinguishes from siblings like amber_search_memories and amber_get_store_task_status by detailing the background processing and return mechanism.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides excellent guidance on when to use metadata vs topics with explicit distinctions and examples. However, it lacks explicit 'when not to use' or direct comparison to other sibling tools beyond the metadata/topics context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

3 tool updatesv1.1.5May 17, 2026

Changedamber_cancel_subscription1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Set `true` to cancel, `false` to preview without cancelling."New value: +"When `true`: cancels the subscription on PayPal and updates account status. When `false`: returns `code: cancelled` with no side effects, letting you confirm intent first."

Changedamber_mark_notification_read1 field changed

changedInput schema / properties / notification_id / description

Previous value: -"The `id` field from a notification object in the `developer_notifications` array. Each notification has a unique positive integer ID."New value: +"Positive integer from the `id` field of a notification in `developer_notifications`. Example: if the block contains `{id: 42, message: \"...\"}`, pass 42. Each ID is unique and single-use."

Changedamber_send_feedback_to_developer4 fields changed

changedInput schema / properties / category / description

Previous value: -"'bug' = broken behavior, 'feature_request' = new capability, 'usability' = confusing UX, 'general' = other."New value: +"Determines how the developer triages this. 'bug': something broke or returned wrong results. 'feature_request': a capability that doesn't exist yet. 'usability': works but is confusing or awkward. 'general': anything else."

changedInput schema / properties / details / description

Previous value: -"What was tried, what happened vs expected, error messages, and reproduction steps."New value: +"Full reproduction context. Include: exact input used, expected outcome, actual outcome, any error codes. E.g. 'Stored \"I love pizza 🍕\" but searching \"pizza emoji\" returns nothing. Expected it to match.'"

changedInput schema / properties / summary / description

Previous value: -"Brief one-line summary, under 100 characters."New value: +"One sentence, under 100 chars. E.g. 'Search misses memories stored with emoji in content'."

changedInput schema / properties / tool_context / description

Previous value: -"Which amber_ tool was in use when the issue occurred, e.g. 'amber_search_memories'."New value: +"The specific amber_ tool name involved, e.g. 'amber_search_memories'. Helps route the report."

5 tool updatesv1.1.4May 17, 2026

Changedamber_cancel_subscription1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Set `true` to proceed, `false` to abort without changes."New value: +"Set `true` to cancel, `false` to preview without cancelling."

Changedamber_delete_memory2 fields changed

changedInput schema / properties / memory_id / description

Previous value: -"A single memory ID (UUID) to move to trash. Use this for individual deletions. Mutually optional with memory_ids — provide at least one."New value: +"UUID of a single memory to trash. Omit if using `memory_ids` for batch."

changedInput schema / properties / memory_ids / description

Previous value: -"Array of memory IDs (UUIDs) to move to trash in a single batch (max 100). Use this for bulk deletions. Mutually optional with memory_id — provide at least one."New value: +"Array of memory UUIDs to trash in one call (max 100). Omit if using `memory_id` for single."

Changedamber_get_memory1 field changed

changedInput schema / properties / memory_id / description

Previous value: -"UUID of the memory to retrieve. Use this to fetch full content after seeing a truncated search result, or to revisit a known memory. Invalid or trashed IDs return `code: not_found`."New value: +"UUID of the target memory. Found in `amber_store_memory` task results, `amber_search_memories` result items, or `amber_list_memories` pages."

Changedamber_mark_notification_read1 field changed

changedInput schema / properties / notification_id / description

Previous value: -"Numeric ID from the `developer_notifications` block in any tool response. Marks that specific notification as read and stops it from appearing. Invalid IDs return `code: not_found`."New value: +"The `id` field from a notification object in the `developer_notifications` array. Each notification has a unique positive integer ID."

Changedamber_restore_memory2 fields changed

changedInput schema / properties / memory_id / description

Previous value: -"A single memory ID (UUID) to restore from trash. Use this for individual restores. Mutually optional with memory_ids — provide at least one."New value: +"UUID of a single memory to restore. Omit if using `memory_ids` for batch."

changedInput schema / properties / memory_ids / description

Previous value: -"Array of memory IDs (UUIDs) to restore from trash in a single batch (max 100). Use this for bulk restores. Mutually optional with memory_id — provide at least one."New value: +"Array of memory UUIDs to restore in one call (max 100). Omit if using `memory_id` for single."

6 tool updatesv1.1.3May 17, 2026

Changedamber_cancel_subscription1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Safety gate: must be `true` to proceed. When `false`, the tool returns `code: cancelled` without making any changes — use this to confirm the user's intent before committing."New value: +"Set `true` to proceed, `false` to abort without changes."

Changedamber_delete_account1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Safety gate: must be `true` to proceed. When `false`, the tool returns `code: cancelled` without making any changes — use this to confirm the user's intent before scheduling deletion."New value: +"Set `true` to proceed, `false` to abort without changes."

Changedamber_get_memory1 field changed

changedInput schema / properties / memory_id / description

Previous value: -"The unique memory ID (UUID format). Obtained from `amber_store_memory` results, `amber_search_memories` results, or `amber_list_memories` output."New value: +"UUID of the memory to retrieve. Use this to fetch full content after seeing a truncated search result, or to revisit a known memory. Invalid or trashed IDs return `code: not_found`."

Changedamber_get_store_task_status1 field changed

changedInput schema / properties / task_id / description

Previous value: -"The task_id (UUID) returned by `amber_store_memory` in its response. Each store call produces a unique task_id."New value: +"UUID from `amber_store_memory`'s response. Poll this to know when memories are ready to search. Invalid IDs return `code: not_found`."

Changedamber_mark_notification_read1 field changed

changedInput schema / properties / notification_id / description

Previous value: -"The numeric ID from the `developer_notifications` section that appears in every tool response when notifications are pending. Each notification has a unique ID. Only mark as read after the user has seen and acknowledged the notification content."New value: +"Numeric ID from the `developer_notifications` block in any tool response. Marks that specific notification as read and stops it from appearing. Invalid IDs return `code: not_found`."

Changedamber_send_feedback_to_developer4 fields changed

changedInput schema / properties / category / description

Previous value: -"Type of feedback: 'bug' for something broken, 'feature_request' for new functionality, 'usability' for UX friction, 'general' for anything else."New value: +"'bug' = broken behavior, 'feature_request' = new capability, 'usability' = confusing UX, 'general' = other."

changedInput schema / properties / details / description

Previous value: -"Full context including: what the user tried, what happened vs what was expected, any error messages or codes, steps to reproduce, and suggestions if the user offered any. Be specific and include tool names, query text, or memory IDs when relevant."New value: +"What was tried, what happened vs expected, error messages, and reproduction steps."

changedInput schema / properties / summary / description

Previous value: -"One-line summary (under ~100 characters). Example: 'Search returns no results for exact keyword matches'."New value: +"Brief one-line summary, under 100 characters."

changedInput schema / properties / tool_context / description

Previous value: -"The amber_ tool name that was being used when the issue occurred (e.g. 'amber_search_memories'). Helps the developer pinpoint the problem."New value: +"Which amber_ tool was in use when the issue occurred, e.g. 'amber_search_memories'."

4 tool updatesv1.1.2May 17, 2026

Changedamber_cancel_subscription1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true to confirm subscription cancellation."New value: +"Safety gate: must be `true` to proceed. When `false`, the tool returns `code: cancelled` without making any changes — use this to confirm the user's intent before committing."

Changedamber_delete_account1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true to confirm account deletion scheduling."New value: +"Safety gate: must be `true` to proceed. When `false`, the tool returns `code: cancelled` without making any changes — use this to confirm the user's intent before scheduling deletion."

Changedamber_list_deleted_memories2 fields changed

changedInput schema / properties / after_id / description

Previous value: -"Pagination cursor. Pass the `next_cursor` value from a previous response to get the next page. Omit to start from the most recently deleted memory."New value: +"Pagination cursor (memory ID string). Pass the `next_cursor` value from a previous response to fetch the next page. Omit on the first call to start from the most recently deleted memory. Do not fabricate cursor values."

changedInput schema / properties / limit / description

Previous value: -"Number of deleted memories per page (default 20, max 100). Use smaller values (5-10) for quick checks, larger values (50-100) for bulk review."New value: +"Number of deleted memories per page (default 20, min 1, max 100). Use smaller values (5-10) for quick checks, larger values (50-100) for bulk review. Omit to use the default of 20."

Changedamber_list_memories2 fields changed

changedInput schema / properties / after_id / description

Previous value: -"Pagination cursor. Pass the `next_cursor` value from a previous response to get the next page. Omit to start from the newest memory."New value: +"Pagination cursor (memory ID string). Pass the `next_cursor` value from a previous response to fetch the next page. Omit on the first call to start from the newest memory. Do not fabricate cursor values."

changedInput schema / properties / limit / description

Previous value: -"Number of memories per page (default 20, max 100). Use smaller values (5-10) for quick overviews, larger values (50-100) for bulk browsing."New value: +"Number of memories per page (default 20, min 1, max 100). Use smaller values (5-10) for quick overviews, larger values (50-100) for bulk browsing. Omit to use the default of 20."

8 tool updatesv1.1.1May 17, 2026

Changedamber_delete_memory2 fields changed

changedInput schema / properties / memory_id / description

Previous value: -"The memory ID to move to trash (single)."New value: +"A single memory ID (UUID) to move to trash. Use this for individual deletions. Mutually optional with memory_ids — provide at least one."

changedInput schema / properties / memory_ids / description

Previous value: -"Array of memory IDs to move to trash (batch, max 100)."New value: +"Array of memory IDs (UUIDs) to move to trash in a single batch (max 100). Use this for bulk deletions. Mutually optional with memory_id — provide at least one."

Changedamber_get_memory1 field changed

changedInput schema / properties / memory_id / description

Previous value: -"The memory ID, as returned by `amber_store_memory` or included in search results."New value: +"The unique memory ID (UUID format). Obtained from `amber_store_memory` results, `amber_search_memories` results, or `amber_list_memories` output."

Changedamber_get_store_task_status1 field changed

changedInput schema / properties / task_id / description

Previous value: -"The task_id returned by amber_store_memory."New value: +"The task_id (UUID) returned by `amber_store_memory` in its response. Each store call produces a unique task_id."

Changedamber_list_deleted_memories2 fields changed

changedInput schema / properties / after_id / description

Previous value: -"Cursor from the `next_cursor` field of a previous page."New value: +"Pagination cursor. Pass the `next_cursor` value from a previous response to get the next page. Omit to start from the most recently deleted memory."

changedInput schema / properties / limit / description

Previous value: -"Page size (default 20, max 100)."New value: +"Number of deleted memories per page (default 20, max 100). Use smaller values (5-10) for quick checks, larger values (50-100) for bulk review."

Changedamber_list_memories2 fields changed

changedInput schema / properties / after_id / description

Previous value: -"Cursor from the `next_cursor` field of a previous page; omit to start from the newest."New value: +"Pagination cursor. Pass the `next_cursor` value from a previous response to get the next page. Omit to start from the newest memory."

changedInput schema / properties / limit / description

Previous value: -"Page size (default 20, max 100)."New value: +"Number of memories per page (default 20, max 100). Use smaller values (5-10) for quick overviews, larger values (50-100) for bulk browsing."

Changedamber_mark_notification_read1 field changed

changedInput schema / properties / notification_id / description

Previous value: -"The ID from the `developer_notifications` payload."New value: +"The numeric ID from the `developer_notifications` section that appears in every tool response when notifications are pending. Each notification has a unique ID. Only mark as read after the user has seen and acknowledged the notification content."

Changedamber_restore_memory2 fields changed

changedInput schema / properties / memory_id / description

Previous value: -"The memory ID to restore from trash (single)."New value: +"A single memory ID (UUID) to restore from trash. Use this for individual restores. Mutually optional with memory_ids — provide at least one."

changedInput schema / properties / memory_ids / description

Previous value: -"Array of memory IDs to restore (batch, max 100)."New value: +"Array of memory IDs (UUIDs) to restore from trash in a single batch (max 100). Use this for bulk restores. Mutually optional with memory_id — provide at least one."

Changedamber_send_feedback_to_developer4 fields changed

changedInput schema / properties / category / description

Previous value: -"Type of feedback."New value: +"Type of feedback: 'bug' for something broken, 'feature_request' for new functionality, 'usability' for UX friction, 'general' for anything else."

changedInput schema / properties / details / description

Previous value: -"Full context: what the user tried, what happened, error messages, reproduction steps, suggestions."New value: +"Full context including: what the user tried, what happened vs what was expected, any error messages or codes, steps to reproduce, and suggestions if the user offered any. Be specific and include tool names, query text, or memory IDs when relevant."

changedInput schema / properties / summary / description

Previous value: -"One-line summary of the feedback."New value: +"One-line summary (under ~100 characters). Example: 'Search returns no results for exact keyword matches'."

changedInput schema / properties / tool_context / description

Previous value: -"The name of the tool being used when the issue occurred, if relevant."New value: +"The amber_ tool name that was being used when the issue occurred (e.g. 'amber_search_memories'). Helps the developer pinpoint the problem."

18 tool updatesv0.1.0May 17, 2026
- First observedamber_cancel_account_deletion
- First observedamber_cancel_subscription
- First observedamber_delete_account
- First observedamber_delete_memory
- First observedamber_export_memories
- First observedamber_get_account_status
- First observedamber_get_memory
- First observedamber_get_store_task_status
- First observedamber_list_deleted_memories
- First observedamber_list_memories
- First observedamber_manage_subscription
- First observedamber_mark_notification_read
- First observedamber_reactivate_subscription
- First observedamber_restore_memory
- First observedamber_search_deleted_memories
- First observedamber_search_memories
- First observedamber_send_feedback_to_developer
- First observedamber_store_memory

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.6/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose, with detailed descriptions that prevent confusion. Account management, memory operations, and utility tools are well-separated, and even similar tools like search_memories and search_deleted_memories are clearly differentiated.

Naming Consistency5/5

All tools follow a consistent 'amber_verb_noun' pattern using snake_case. The naming convention is uniform across the entire set, making it easy to predict tool names.

Tool Count4/5

With 18 tools, the count is reasonable for the server's scope. It covers account lifecycle and memory management without being excessive. A slight drawback is the absence of an explicit update tool, but overall the count is well-calibrated.

Completeness4/5

The tool set covers account management, memory CRUD (except update), search, export, and feedback. Missing an update_memory tool and a permanent delete option are notable gaps, but the surface is otherwise comprehensive for the domain.

Maintenance

ActivityMaintained

ResponsivenessResponsive

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

EngramOAuth
io.github.debragail
Persistent memory for AI agents — verbatim conversations, searchable by meaning.
Knowledge & Memory Search
211
MemorySync
io.memorysync
Persistent memory for AI agents. Search and store durable facts, preferences and decisions.
Knowledge & Memory Autonomous Agents
1
memoryOAuth
com.leapmemory
Long-term memory for AI assistants. Isolated per-user storage, recall across conversations.
Knowledge & Memory RAG Systems
1
mcp-serverOAuth
in.creo-memories
Memory system for AI agents with semantic search. Store and recall memories with ease.
Knowledge & Memory Search RAG Systems
2

Related MCP Servers

MCP-Mem0
Knowledge & Memory Vector Databases Autonomous Agents
coleam00
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server that provides AI agents with persistent memory capabilities through Mem0, allowing them to store, retrieve, and semantically search memories.
Updated a year ago (2025-04-13 01:17 UTC)
681
MIT
MCP-Mem0
Knowledge & Memory Vector Databases
888Greys
A
license
Not graded
quality
D
maintenance
A template implementation of the Model Context Protocol server that integrates with Mem0 to provide AI agents with persistent memory capabilities for storing, retrieving, and searching memories using semantic search.
Updated a year ago (2025-08-02 09:22 UTC)
MIT
MCP-Mem0
Knowledge & Memory RAG Systems Vector Databases
Baatarvant
-
license
Not graded
quality
Not graded
maintenance
Provides AI agents with persistent long-term memory capabilities using semantic search. Enables storing, retrieving, and searching memories through three core tools integrated with Mem0 and vector storage.
Updated a year ago (2025-09-17 07:35 UTC)
-
BuildAutomata Memory MCP
Knowledge & Memory RAG Systems Vector Databases
brucepro
F
license
Not graded
quality
D
maintenance
Provides AI agents with persistent, searchable memory that survives across conversations using semantic search, temporal versioning, and smart organization. Enables long-term context retention and cross-session continuity for AI assistants.
Updated 8 months ago (2025-12-27 04:00 UTC)
14
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ambermem/amber'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Amber

Quick Install

Claude Code / Claude Desktop

Cursor

ChatGPT

Windsurf

VS Code (GitHub Copilot)

Any MCP client

How It Works

What Makes Amber Different

Technical Details

Pricing

Privacy

Architecture

Links

FAQ

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API