Amber

Official

by ambermem

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.1.5
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.
Average 4.8/5 across 18 of 18 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- Last stable release on May 17, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![amber MCP server](https://glama.ai/mcp/servers/ambermem/amber/badges/card.svg)](https://glama.ai/mcp/servers/ambermem/amber)

Score Badge

Copy to your README.md:

[![amber MCP server](https://glama.ai/mcp/servers/ambermem/amber/badges/score.svg)](https://glama.ai/mcp/servers/ambermem/amber)

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