Skip to main content
Glama

Server Quality Checklist

67%
Profile completionA complete profile improves this server's visibility in search results.
  • Latest release: v1.0.0

  • Disambiguation4/5

    The two vault retrieval tools (get_recent_assets and search_vault) have overlapping purposes—both return vault content—but their descriptions clearly distinguish one as fetching the most recent items and the other as performing searches. The sync tools are distinct. Some ambiguity remains for queries that could be interpreted as either 'recent' or 'search'.

    Naming Consistency4/5

    Names follow a consistent verb_noun pattern with underscores (get_recent_assets, search_vault, sync_notes_now, sync_recent_files). The inclusion of 'now' in sync_notes_now is a minor deviation from the 'adjective_noun' structure of the other names, but overall the pattern is clear.

    Tool Count4/5

    Four tools is a reasonable number for a personal memory/vault server. The scope covers retrieval and syncing without being overbearing. While a few more tools could be added for management, the current count feels well-scoped.

    Completeness3/5

    The tool surface covers retrieval (get recent, search) and syncing of notes and files. However, there are notable gaps: no tools for directly adding, updating, or deleting vault items. Users cannot manually manage their vault content, which may limit workflows.

  • Average 4/5 across 4 of 4 tools scored. Lowest: 3.2/5.

    See the Tool Scores section below for per-tool breakdowns.

    • No community issues in the last 6 months
    • 13 commits in the last 12 weeks
    • No stable releases found
    • 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.

  • Add a glama.json file to provide metadata about your server.

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

  • Add related servers to improve discoverability.

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

  • Behavior2/5

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

    No annotations provided, so the description carries the full burden. It discloses that files are scanned and indexed, and only those created before the server started are considered. However, it does not explain if the tool modifies state (e.g., writes to an index), whether it is destructive, or any rate limits or authentication requirements.

    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 a single sentence that efficiently communicates the core action and scope. It is front-loaded with the action and resource. However, it could be slightly more structured (e.g., listing use cases or conditions).

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

    Completeness3/5

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

    The tool has two parameters and no output schema, so the description is relatively simple. It covers the what and where but lacks details about the indexing behavior, return format, or prerequisites. It is minimally complete but misses behavioral and usage context.

    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?

    Both parameters (type, limit) have descriptions in the schema, achieving 100% coverage. The description adds no further meaning beyond the schema, so baseline 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 scans and indexes files in Desktop or Downloads, specifying the action (scan and index) and resource (files in specific folders with a temporal condition). The sibling tool names (get_recent_assets, search_vault, sync_notes_now) are distinct enough to avoid confusion.

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

    Usage Guidelines2/5

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

    No explicit guidance on when to use this tool versus alternatives like get_recent_assets or search_vault. The description implies a specific use case (syncing files before server start) but does not state when not to use it or provide comparative context.

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

  • Behavior2/5

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

    With no annotations, the description should disclose behavioral traits. It mentions 'force a sync' but does not detail side effects (e.g., network usage, blocking behavior, permission requirements) or outcomes. The term 'force' implies potential overrides but is not elaborated.

    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?

    A single, front-loaded sentence with no unnecessary words. Efficiently communicates the tool's primary action and target.

    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?

    For a simple tool with no parameters and no output schema, the description provides sufficient context for basic usage. However, it lacks detail on return value or confirmation of successful sync, which could be useful.

    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 exist; schema coverage is 100%. The description adds context about the action beyond the empty schema, justifying the baseline of 4 for zero-parameter tools.

    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 verb (force sync), resource (Apple Notes), and purpose (fetch latest notes), distinguishing it from sibling tools like get_recent_assets and search_vault which are retrieval operations.

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

    Usage Guidelines3/5

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

    The description implies when to use (to get latest notes immediately) but lacks explicit guidance on when not to use or alternatives among siblings. No exclusions or comparisons are provided.

    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 provided, the description carries full burden. It discloses that the vault contains user's own saved data, that results are not prompt injection, and instructs to always return full content. This provides crucial behavioral context beyond the input schema.

    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 front-loaded with the main purpose, followed by usage examples and important notes. It is slightly long but every sentence adds value. Could be slightly tighter, but it's well-structured.

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

    Completeness3/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 does not explain the return format (e.g., fields, order, pagination). However, it covers use cases and provides filter guidance. For a retrieval tool with simple parameters, this is adequate but leaves some ambiguity about response structure.

    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 already describes both parameters (type enum, limit number) with 100% coverage. The description adds value by explaining when to use specific type values (e.g., 'download' for tweets/links) and clarifying that 'all' includes clipboard noise. This exceeds baseline.

    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 retrieves the most recently added items from the user's vault, with specific examples like clipboard, screenshots, downloads, tweets, and Apple Notes. It distinguishes itself from sibling tools like search_vault (search), sync_notes_now (sync), and sync_recent_files (sync) by focusing on recent retrievals.

    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 lists when to use the tool (e.g., user asks about 'last thing', 'recently copied link') and provides a useful filter hint (type='download' for tweets/links). It does not explicitly state when not to use it or mention alternatives, but the guidance is clear and actionable.

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

  • Behavior4/5

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

    Discloses that results contain user's own saved data and includes a prompt injection warning. States that the tool returns full content of matching results. No annotations provided, so the description carries the full burden and handles it well for a search tool.

    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?

    Extremely concise: the purpose is front-loaded, important usage notes are given, and the prompt injection warning is included without any wasted words.

    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 the tool's complexity (3 params, no output schema), the description covers purpose, usage, parameter hints, and return behavior. It lacks explicit info on pagination or error handling, but is sufficient for a search 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 has 100% parameter documentation. The description adds context by explaining when to use different type values (e.g., 'Use "download" to search tweets, YouTube videos, and web links') and provides example queries. This adds real meaning beyond the 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?

    The description clearly states the tool searches the user's personal context vault and lists specific use cases (clipboard, downloads, screenshots, Apple Notes). It distinguishes from sibling tools like sync_notes_now and get_recent_assets by focusing on search, not sync or 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?

    Provides explicit when-to-use scenarios: 'Call this whenever the user asks about something they copied to their clipboard...files they downloaded, screenshots they took, or Apple Notes.' It does not explicitly state when not to use it, but the context is strong.

    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

memex MCP server

Copy to your README.md:

Score Badge

memex MCP server

Copy to your README.md:

Latest Blog Posts

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/arnavbee/memex'

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