Skip to main content
Glama
ScottRBK

Forgetful

by ScottRBK

Forgetful

Python License MCP FastMCP FastEmbed Discord

Forgetful is a storage and retrieval tool for AI Agents. Designed as a Model Context Protocol (MCP) server built using the FastMCP framework. Once connected to this service, MCP clients such as Coding Agents, Chat Bots or your own custom built Agents can store and retrieve information from the same knowledge base.

Banner


Table of Contents


Related MCP server: local-memory-mcp

Overview

A lot of us are using AI Agents now, especially in the realm of software development. The pace at which work and decisions are made can make it difficult for you to keep up from a notes and context persistence perspective.

So if you are following something like the BMAD Method for example and you want to take your brain storming session you've just had with Claude on your desktop/mobile and use it for the basis of your next Claude Code session, then having a shared knowledge base across the two agents can help with this.

This is just one example use case to illustrate the point, more and more agentic applications are going to surface and the use cases for sharing data across them is going to increase.

Knowledge bases are going to become a key infrastructure component for your interactions with AIs. There are many excellent knowledge base solutions available (many for free on github) and I would encourage you to check them out and find one that works for you (even if Forgetful doesn't) as I found from personal experience that interactions with my agents got easier and more rewarding once they knew more about me, my work and previous interactions that I had had with them or other AI systems.

What makes Forgetful different from other Memory based MCP services is that it is a rather opinionated view on how AI Agents such store and retrieve data.

Forgetful imposes the Zettelkasten principle when clients wish to record memories, that is each memory must be atomic (one concept per note). Along with the note (title and content), we also ask the client / agent to provide context around what it was doing when creating the note, along with keywords and tags. With this information we create semantic embeddings and store these to aid with later retrieval and in addition to this we also automatically link the memory to existing memories that have a particular similarity score, allowing for the automatic construction of a knowledge graph.

In this sense Forgetful becomes a little bit like Obsidian for AI Agents, where the auto linking nudges them in building up a graph of the knowledge.

We find, as do others (A-MEM: Agentic Memory or LLM Agents), all this helps in ensuring that when the agent requires relevant information from the memory system later, the correct information is returned.

In addition to just memories, Forgetful also has the concept of entities (think organisation, people, products), projects, documents, code artifacts, skills (procedural knowledge following the Agent Skills standard), and plans with tasks for multi-agent coordination, all of which can be associated with one or more memories.

Architecture

Features

  • Configure either STDIO or HTTP transport mechanism (or stand up two services to support both)

  • Multiple Authentication supported, flows see FastMCP docs for full list

  • Meta Tool Discovery, only three tools exposed to client application to preserve context window.

  • Flexible Storage– SQLite (default, zero-config) or PostgreSQL (for scale and production deployments)

  • Stores memories as vectors and allowing memories to be retrieved from natural language queries from AI.

  • Cross Encoder reranking to improve recall and precision of memory retrieval.

  • Flexible ranking (embedding and cross encoder) providers, run everything locally without calls to the cloud thanks to FastEmbed

  • Automatic linking of semantically similar memories, automating the creation of the knowledge graph.

  • Plans and Tasks for multi-agent coordination -- structure work into plans with tasks that have acceptance criteria, state management with optimistic locking, and dependency tracking with cycle detection.

  • Skills for procedural memory -- store step-by-step instructions and agent capabilities with semantic search, import/export in Agent Skills SKILL.md format, and cross-referencing with memories.

For the complete roadmap, see Features Roadmap.


Quick Start

# Run directly with uvx (no installation needed)
uvx forgetful-ai

# Or install globally
uv tool install forgetful-ai
forgetful

Data stored in platform-appropriate locations (~/.local/share/forgetful on Linux/Mac, AppData on Windows).

By default, runs with stdio transport for MCP clients. For HTTP:

uvx forgetful-ai --transport http --port 8020

Option 2: From Source

git clone https://github.com/ScottRBK/forgetful.git
cd forgetful

# Install dependencies with uv
uv sync

# Run the server (uses SQLite by default)
uv run main.py

The server starts with stdio transport. For HTTP: uv run main.py --transport http

Option 3: Docker Deployment (Production/Scale)

Forgetful provides two Docker deployment options:

SQLite with Docker (Simpler, Single-Container)

See docker-compose.sqlite.yml

cd docker
cp .env.example .env
# Edit .env: Set DATABASE=SQLite and SQLITE_PATH=data/forgetful.db
docker compose -f docker-compose.sqlite.yml up -d

The SQLite database persists in the ./data directory on the host.

See docker-compose.postgres.yml and .env.example

cd docker
cp .env.example .env
# Edit .env: Set DATABASE=Postgres and configure POSTGRES_* settings
docker compose -f docker-compose.postgres.yml up -d

Note: If no .env file exists, the application uses defaults from app/config/settings.py. For all configuration options, see Configuration Guide.

Connecting to An Agent

For detailed connection guides (Claude Code, Claude Desktop, other clients that support MCP), see Connectivity Guide.

Add Forgetful to your MCP client configuration:

stdio transport (recommended for local use):

{
  "mcpServers": {
    "forgetful": {
      "type": "stdio",
      "command": "uvx",
      "args": ["forgetful-ai"]
    }
  }
}

HTTP transport (for Docker/remote):

{
  "mcpServers": {
    "forgetful": {
      "type": "http",
      "url": "http://localhost:8020/mcp"
    }
  }
}

CLI

The forgetful command is also a full terminal client over the same tool registry the MCP meta-tools use - against your local database by default, or a remote deployment after auth login.

uv tool install forgetful-ai

# Curated verbs for daily use
forgetful memory save "Set generateResolvConf false to fix WSL2 DNS" \
    --title "WSL2 DNS fix" --importance 7
forgetful memory search "wsl dns" -c "wsl networking" -n 5
forgetful memory get 812
forgetful memory recent -n 10 -p my-project
forgetful project list

# Generic passthrough to any available tool
forgetful tools list --category memory
forgetful tools info query_memory
forgetful call create_project --args '{"name": "Homelab", "description": "...", "project_type": "personal"}'

# Remote deployment (browser OAuth; saves FORGETFUL_SERVER to ~/.config/forgetful/.env)
forgetful auth login --server https://forgetful.example.com
forgetful auth status
forgetful memory search "wsl dns" -c "wsl networking"          # now runs remotely
forgetful memory search "wsl dns" -c "wsl networking" --local  # force local mode per invocation

# Scripting: --json emits machine-readable output
forgetful memory search "wsl dns" -c "wsl networking" --json | jq '.primary_memories[0].id'

forgetful serve is the canonical way to run the MCP server (forgetful serve --transport http --port 8020); the bare forgetful / uvx forgetful-ai invocation and the legacy --transport/--re-embed flags keep working indefinitely, so existing MCP client configurations are unaffected. Headless environments can set FORGETFUL_TOKEN (bearer) instead of the OAuth flow. See the Configuration Guide for precedence rules, or walk through the forgetful-cli-setup skill for install, auth, and verification steps end-to-end.


Usage Examples

Forgetful exposes only 3 meta-tools to MCP clients. The tools available through execute_forgetful_tool depend on the enabled feature flags. Use discover_forgetful_tools for the current runtime catalog.

Example 1: Project-Scoped Memory

Create a memory linked to a project for better organization and scoped retrieval.

# Create project for organizing related knowledge
project = execute_forgetful_tool(
    "create_project",
    {
        "name": "E-Commerce Platform Redesign",
        "project_type": "work",
        "status": "active"
    }
)

# Create memory linked to project
memory = execute_forgetful_tool(
    "create_memory",
    {
        "title": "Payment gateway: Stripe chosen over PayPal",
        "content": "Selected Stripe for its API, fees, and fraud detection.",
        "context": "Choosing the payment provider for the redesign",
        "keywords": ["payment", "stripe", "paypal"],
        "tags": ["payment", "decision"],
        "importance": 9,
        "project_ids": [project["id"]]
    }
)

# Later, query within project scope
results = execute_forgetful_tool(
    "query_memory",
    {
        "query": "payment processing implementation",
        "query_context": "Implementing payments for the redesign",
        "project_ids": [project["id"]]
    }
)
# Returns: Stripe decision + auto-linked related memories

Example 2: Knowledge Graph with Entities

Track people, organizations, and relationships - perfect for team and infrastructure management.

# New engineer joins your company
new_hire = execute_forgetful_tool(
    "create_entity",
    {
        "name": "Jordan Taylor",
        "entity_type": "Individual",
        "description": "Backend Engineer - Payments Team",
        "tags": ["engineering", "backend", "payments"]
    }
)

# Get company entity (create if needed)
company = execute_forgetful_tool(
    "create_entity",
    {
        "name": "TechFlow Systems",
        "entity_type": "Organization",
        "description": "SaaS platform company"
    }
)

# Create employment relationship
execute_forgetful_tool(
    "create_entity_relationship",
    {
        "from_entity_id": new_hire["id"],
        "to_entity_id": company["id"],
        "relationship_type": "works_for",
        "metadata": {
            "role": "Backend Engineer II",
            "department": "Payments",
            "start_date": "2025-01-20"
        }
    }
)

# Create memory about hiring
hire_memory = execute_forgetful_tool(
    "create_memory",
    {
        "title": "Jordan Taylor hired - payments focus",
        "content": "Jordan joins to build the Stripe integration and handle PCI compliance.",
        "context": "Recording ownership and experience for the payments work",
        "keywords": ["jordan", "stripe", "payments", "pci"],
        "tags": ["team", "hiring", "payments"],
        "importance": 7
    }
)

# Link person to memory
execute_forgetful_tool(
    "link_entity_to_memory",
    {
        "entity_id": new_hire["id"],
        "memory_id": hire_memory["id"]
    }
)

# Query Jordan's related knowledge
results = execute_forgetful_tool(
    "query_memory",
    {
        "query": "Jordan payment implementation",
        "query_context": "Finding ownership and experience for payments work"
    }
)
# Returns: Hiring memory + linked entity + relationship context

Tool Categories

The core catalog covers users, memories, projects, entities, code artifacts, and documents. Skills, files, plans, and tasks appear when their feature flags are enabled.

For complete documentation with extensive examples, see Complete Tool Reference.


How It Works

Atomic Memory Principle

Inspired by Zettelkasten, each memory stores one concept in ~300-400 words:

  • Easily titled – Forces clarity (200 char limit)

  • Self-contained – Understandable without external context

  • Linkable – Small units enable precise knowledge graphs

For detailed content, use Documents and extract 3-7 atomic memories that link to the parent document.

Automatic Knowledge Graph

When you create a memory:

  1. Embedding generated – FastEmbed converts content to 384-dimensional vector

  2. Similarity search – Finds top semantically-related memories (≥0.7 threshold)

  3. Auto-linking – Creates bidirectional links to top 3-5 matches (configurable)

  4. Graph traversal – Queries return primary results + 1-hop linked memories

Entities and Knowledge Graphs

Entities represent concrete, real-world things (people, organizations, teams, devices) that can be linked to memories:

  • Typed entities – Organizations, Individuals, Teams, Devices, Systems, or custom types

  • Relationships – Directional connections (e.g., "Person works_at Organization") with strength and metadata

  • Memory linking – Associate entities with relevant memories for context

  • Knowledge graph – Build networks showing how entities relate to each other and your knowledge base

Use entities for concrete things (Sarah Chen, TechFlow Systems, Cache Server 01) and memories for abstract concepts (architectural patterns, decisions, learnings).

Token Budget Management

Prevents context window overflow:

  • Configurable budget (default 8K tokens)

  • Results prioritized by importance (9-10 first) → recency (newest first)

  • Truncates gracefully if over budget

  • Respects max memory count (default 20)

This ensures agents get the most relevant context without overwhelming the LLM.

For deep dive on search architecture (dense → sparse → RRF → cross-encoder), see Search Documentation.


Configuration

No configuration required – Forgetful uses sensible defaults out of the box.

Key Settings (Optional)

  • MEMORY_TOKEN_BUDGET – Max tokens for query results (default: 8000)

  • EMBEDDING_MODEL – Embedding model (default: BAAI/bge-small-en-v1.5)

  • MEMORY_NUM_AUTO_LINK – Auto-link count (default: 3, set 0 to disable)

  • SERVER_PORT – HTTP server port (default: 8020)

  • MAX_GRAPH_LIMIT – Upper bound for /api/v1/graph ?limit and /api/v1/graph/subgraph ?max_nodes (default: 2000)

For all 40+ environment variables with detailed explanations, see Configuration Guide.


Documentation

Guides

External Resources


Contributing

We welcome contributions! Forgetful uses integration + E2E testing with Docker Compose orchestration.

See Contributors Guide for:

  • Testing workflows (integration tests, E2E tests, GitHub Actions)

  • Development setup (local vs Docker)

  • CI/CD pipeline details

  • Release process


License

MIT License - see LICENSE for details.

Available Tools

3 tools
discover_forgetful_toolsA

Discover available tools, optionally filtered by category

Returns enough information for LLMs to call tools directly without needing how_to_use.

Args: category: Optional category filter (user, memory, project, code_artifact, document, entity, linking) ctx: FastMCP Context (automatically injected)

Returns: Dictionary with: - tools_by_category: Tools grouped by category - total_count: Total number of tools - categories_available: List of available categories - filtered_by: Category filter applied (if any)

All Available Tools

User Tools - User profile and preferences

  • get_current_user: Get authenticated user info

  • update_user_notes: Store user preferences/notes

Memory Tools - Atomic knowledge storage (<400 words per memory)

  • create_memory: Store a single concept with auto-linking to similar memories (supports provenance tracking)

  • query_memory: Semantic search across memories (use query_context for better ranking)

  • get_memory: Retrieve memory by ID

  • update_memory: Modify memory fields (PATCH semantics, supports provenance tracking)

  • link_memories: Manually connect related memories bidirectionally

  • unlink_memories: Remove link between memories

  • mark_memory_obsolete: Soft-delete with audit trail and optional superseded_by

  • get_recent_memories: Get newest memories (timeline view)

Provenance Tracking (optional fields for create_memory/update_memory):

  • source_repo, source_files, source_url: Track where knowledge came from

  • confidence: Reliability score (0.0-1.0) for AI-generated content

  • encoding_agent, encoding_version: Track which agent/version created the memory

Project Tools - Organize memories by context/scope

  • create_project: Create project container (development, personal, work, etc.)

  • get_project: Retrieve project details

  • list_projects: List all projects with optional status/repo filter

  • update_project: Modify project metadata

  • delete_project: Remove project (memories preserved)

Code Artifact Tools - Reusable code snippets and patterns

  • create_code_artifact: Store code with language, tags, project link

  • get_code_artifact: Retrieve code artifact by ID

  • list_code_artifacts: List artifacts with project/language/tags filter

  • update_code_artifact: Modify artifact fields

  • delete_code_artifact: Remove artifact

Document Tools - Long-form content (>300 words)

  • create_document: Store detailed docs, analysis, guides

  • get_document: Retrieve document by ID

  • list_documents: List documents with project/type/tags filter

  • update_document: Modify document fields

  • delete_document: Remove document

Entity Tools - Real-world entities (people, orgs, devices)

  • create_entity: Create entity with type, aka (aliases), notes

  • get_entity: Retrieve entity by ID

  • list_entities: List entities with project/type/tags filter

  • search_entities: Text search by name or aka (aliases)

  • update_entity: Modify entity fields

  • delete_entity: Remove entity (cascades links)

  • link_entity_to_memory: Connect entity to memory

  • unlink_entity_from_memory: Remove entity-memory link

  • link_entity_to_project: Connect entity to project (organizational grouping)

  • unlink_entity_from_project: Remove entity-project link

  • get_entity_memories: Get all memories linked to entity

  • create_entity_relationship: Create relationship (part_of, depends_on, works_for, etc.)

  • get_entity_relationships: Get relationships for entity

  • update_entity_relationship: Modify relationship

  • delete_entity_relationship: Remove relationship

Workflow

  1. Call discover_forgetful_tools() to see this catalog

  2. Call execute_forgetful_tool(tool_name, {args}) to run any tool

  3. If needed, call how_to_use_forgetful_tool(tool_name) for full parameter docs

ParametersJSON Schema
NameRequiredDescriptionDefault
categoryNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.4/5.0
Behavior4/5

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

No annotations are provided, so the description is the sole source for behavioral traits. It explains the return structure (dictionary with keys like tools_by_category, total_count) and states it returns enough info for direct tool calls. However, it does not explicitly state that the tool is read-only or non-destructive, though that is implied. It could also mention any limitations like caching or performance, but for a discovery tool, the disclosure is fairly adequate.

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

Conciseness3/5

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

The description is overly long (over 300 words) and includes a full catalog of all available tools, which is redundant as the tool's output will contain that information. It is structured with sections and bullet points, but conciseness is compromised due to the inclusion of extensive listing that goes beyond the tool's own functionality.

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 that the tool has an output schema (context signal), the description adequately covers the return structure and usage scenario. It explains the single parameter and provides a workflow. The inclusion of the full catalog, while not strictly necessary, adds context for understanding the tool ecosystem. Overall, it is complete enough for an agent to use the tool 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?

The input schema has one optional parameter 'category' with no description (0% schema coverage). The description adds meaning by listing the allowed categories (user, memory, project, code_artifact, document, entity, linking) and explaining the filtering behavior. It does not specify case sensitivity or format, but the provided list is sufficient for practical use.

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's purpose: 'Discover available tools, optionally filtered by category' and explicitly distinguishes it from siblings by mentioning that the returned information is sufficient for LLMs to call tools directly without needing how_to_use. It is specific and actionable.

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?

The description provides a step-by-step workflow that explicitly tells when to use this tool ('1. Call discover_forgetful_tools() to see this catalog') and when to use alternatives ('2. Call execute_forgetful_tool', '3. If needed, call how_to_use_forgetful_tool'). It also explains the optional category filter, making usage context clear.

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

execute_forgetful_toolA

Execute any registered tool dynamically. Forgetful is a semantic memory system for LLMs.

Quick Start - One-Shot Examples (all required params shown)

Memory Operations:

  • Search: execute_forgetful_tool("query_memory", {"query": "search terms", "query_context": "why searching"})

  • Create: execute_forgetful_tool("create_memory", {"title": "Short title", "content": "Memory content (<2000 chars)", "context": "Why this matters", "keywords": ["kw1", "kw2"], "tags": ["tag1"], "importance": 7, "project_ids": [1]})

  • Create with provenance: execute_forgetful_tool("create_memory", {"title": "...", "content": "...", "context": "...", "keywords": [...], "tags": [...], "importance": 7, "source_repo": "owner/repo", "source_files": ["src/main.py"], "confidence": 0.85, "encoding_agent": "claude-sonnet-4"})

  • Update: execute_forgetful_tool("update_memory", {"memory_id": 1, "content": "new content"})

  • Get: execute_forgetful_tool("get_memory", {"memory_id": 1})

  • Link: execute_forgetful_tool("link_memories", {"memory_id": 1, "related_ids": [2, 3]})

  • Unlink: execute_forgetful_tool("unlink_memories", {"source_id": 1, "target_id": 2})

  • Obsolete: execute_forgetful_tool("mark_memory_obsolete", {"memory_id": 42, "reason": "Outdated approach", "superseded_by": 100})

Project Organization:

  • List: execute_forgetful_tool("list_projects", {})

  • Create: execute_forgetful_tool("create_project", {"name": "Project Name", "description": "What this project is about", "project_type": "development"})

  • Get: execute_forgetful_tool("get_project", {"project_id": 1})

  • Query: execute_forgetful_tool("query_memory", {"query": "search terms", "query_context": "why searching", "project_ids": [1]})

Entities (people, orgs, devices):

  • Create: execute_forgetful_tool("create_entity", {"name": "Sarah Chen", "entity_type": "Individual", "notes": "Backend developer", "aka": ["Sarah", "S.C."]})

  • Search: execute_forgetful_tool("search_entities", {"query": "Sarah"}) # Searches name AND aka

  • Link to memory: execute_forgetful_tool("link_entity_to_memory", {"entity_id": 1, "memory_id": 1})

  • Unlink from memory: execute_forgetful_tool("unlink_entity_from_memory", {"entity_id": 1, "memory_id": 1})

  • Link to project: execute_forgetful_tool("link_entity_to_project", {"entity_id": 1, "project_id": 1})

  • Unlink from project: execute_forgetful_tool("unlink_entity_from_project", {"entity_id": 1, "project_id": 1})

Documents (long-form content >300 words):

  • Create: execute_forgetful_tool("create_document", {"title": "Doc Title", "description": "Brief summary", "content": "Long content...", "document_type": "text", "project_id": 1})

Code Artifacts (reusable snippets):

  • Create: execute_forgetful_tool("create_code_artifact", {"title": "Snippet Title", "description": "What this does", "code": "def example(): pass", "language": "python", "project_id": 1})

Linking Best Practices

Always link related items for discoverability:

  • When creating documents, link atomic memories: create_memory(..., document_ids=[doc_id])

  • When creating code artifacts, link to memories: create_memory(..., code_artifact_ids=[artifact_id])

  • Link memories to each other: link_memories(memory_id=1, related_ids=[2, 3])

  • Link entities to memories: link_entity_to_memory(entity_id=1, memory_id=1)

  • Link entities to projects: link_entity_to_project(entity_id=1, project_id=1)

Tool Categories

memory | project | entity | document | code_artifact | linking | user

Use discover_forgetful_tools(category?) for full parameter details and optional params.


Args: tool_name: Name of the tool to execute arguments: Dictionary of arguments to pass to the tool ctx: FastMCP Context (automatically injected)

Returns: Tool execution result (format depends on the specific tool)

ParametersJSON Schema
NameRequiredDescriptionDefault
argumentsYes
tool_nameYes

TDQS

A3.5/5.0
Behavior2/5

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

No annotations provided, so description bears full burden. Does not explicitly state mutation, side effects, errors, or preconditions. Examples imply create/update/delete actions but no warnings about irreversible operations or failure modes.

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

Conciseness2/5

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

Very verbose (many lines of examples and best practices). While structured with sections, it lacks conciseness; not every sentence earns its place. Could be shortened by referencing sibling tools more.

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 dynamic dispatcher, covers many sub-operations and linking strategies. Points to discover_forgetful_tools for parameter details. Lacks explanation of error handling or invalid tool_name behavior, but otherwise fairly complete.

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 0%, but description compensates with extensive examples for each sub-tool (memory, project, entity, etc.), showing exact argument structures. Adds significant semantic value beyond the minimal schema, though not exhaustive.

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 the tool executes any registered tool dynamically. Differentiates from sibling tools (discover_forgetful_tools for discovery, how_to_use_forgetful_tool for help) by focusing on execution and providing a quick-start guide.

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?

Implied usage as the executor after discovering tools, but does not explicitly state when to use vs alternatives. Points to discover_forgetful_tools for details, but lacks exclusions or when-not-to-use guidance.

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

how_to_use_forgetful_toolB

Get detailed documentation for a specific tool

Returns complete documentation including JSON schema, multiple examples, and full parameter details.

Args: tool_name: Name of the tool to get documentation for ctx: FastMCP Context (automatically injected)

Returns: Detailed tool documentation with JSON schema

ParametersJSON Schema
NameRequiredDescriptionDefault
tool_nameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.2/5.0
Behavior3/5

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

The description implies a read-only operation returning documentation, with no mention of side effects, authentication, or rate limits. It is adequate but not explicit.

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

Conciseness3/5

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

The description includes an Args and Returns section that, while structured, contains some redundant phrasing. Could be more concise, but is still reasonably clear.

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 the presence of an output schema, the return values need not be detailed. However, the tool is simple (1 param, read-only), so the description is mostly complete, though usage guidance is lacking.

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 description explains the single parameter 'tool_name' as 'Name of the tool to get documentation for', which adds meaning beyond the bare schema that lacks a description. Schema coverage is 0%, but the description compensates well.

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

Purpose4/5

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

The description clearly states it returns documentation for a specific tool, but does not explicitly distinguish from the sibling 'discover_forgetful_tools' which likely lists all tools.

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 guidance on when to use this tool versus its siblings 'discover_forgetful_tools' or 'execute_forgetful_tool'. The agent is left to infer the use case.

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.

  1. 3 tool updatesv0.1.0
    • First observeddiscover_forgetful_tools
    • First observedexecute_forgetful_tool
    • First observedhow_to_use_forgetful_tool

TDQS

A3.8/5.0
Disambiguation5/5

The three tools have clearly distinct purposes: discover lists available tools, execute runs any tool, and how_to_use provides detailed documentation. No overlap or ambiguity exists.

Naming Consistency4/5

Tool names follow a consistent verb_noun pattern with 'forgetful' prefix, but there is a plural/singular mismatch: 'discover_forgetful_tools' vs 'execute_forgetful_tool' and 'how_to_use_forgetful_tool'. The pattern is otherwise predictable.

Tool Count4/5

Three tools is a minimal but reasonable set for a meta-tool server that dynamically exposes functionality. It fits the low end of the well-scoped range; however, the surface feels thin if one considers the hidden complexity.

Completeness5/5

The server provides a complete meta-interface: discover what's available, execute tools, and get detailed documentation. There are no gaps in this workflow; all necessary operations are covered.

Maintenance

ActivityMaintained
ResponsivenessWithin a week

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    C
    maintenance
    Persistent semantic memory server for AI assistants via MCP, enabling long-term context retention and semantic search across conversations.
    11
    MIT
  • F
    license
    Not graded
    quality
    B
    maintenance
    A persistent memory server for AI agents using MCP protocol, enabling semantic storage and retrieval of dialogues, documents, and agent states.
    -
  • A
    license
    Not graded
    quality
    C
    maintenance
    Universal MCP server providing adaptive semantic memory for AI agents, supporting document ingestion, semantic search, chat persistence, cross-project linking, and cloud storage overflow.
    3
    GPL 3.0

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/ScottRBK/forgetful'

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