Memory MCP

list_projects

Discovers all projects with stored memories, returning names, memory counts, update times, and categories to confirm exact project names and avoid duplicates.

Instructions

List all known projects that have stored memories.

When to use this tool

Call this FIRST when you are unsure which project the user is working on:

At the start of a chat session in a non-IDE client (Claude Desktop, ChatGPT, etc.) to discover what projects exist.
Before inventing a new project_name — check if one already exists that matches (to avoid creating duplicates like "my-app" vs "MyApp").
When the user mentions a project by a partial or informal name — look up the exact stored name here.

In IDE-based clients (Cursor, Windsurf, VS Code) you usually already know the workspace folder name, but calling this is still useful to confirm the exact project name used in memory.

Returns a list of projects, each with:

name: the project_name (null for global/unscoped memories)
memory_count: number of active facts stored
last_updated: when the most recent fact was updated
categories: which knowledge categories have facts

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_projects"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 31, 2026

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description does real work: 'List' plus the returned-field listing makes clear this is a read-only, side-effect-free discovery call, and it discloses the client-context nuance (IDE vs non-IDE) that affects how results are interpreted. It stops short of explicitly stating there are no side effects, permission requirements, or result limits/pagination.

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?

Front-loaded purpose sentence followed by a scannable 'When to use' list — good structure, no filler. The per-field return-value block largely restates the existing output schema and could be trimmed without loss.

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 zero-param, read-only discovery tool with a rich output schema, nothing an agent needs is missing: it knows why to call it, when to call it first, and how to interpret the project names it gets back (null = global/unscoped memories).

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 tool takes zero parameters, so the baseline is 4; the description correctly implies no arguments are required to call it. Nothing about parameter semantics needs adding.

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?

Starts with a specific verb+resource+scope: "List all known projects that have stored memories". The when-to-use bullets implicitly separate it from list_memories (facts, not projects) and get_project_context (single project), but no sibling is named explicitly, so an agent must infer the boundary.

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?

Three concrete triggering conditions are given (session start in non-IDE clients, before inventing a new project_name, partial/informal name mentioned), plus an explicit caveat about IDE clients where the workspace name is already known. This is exactly the when-to-use guidance an agent needs for a discovery tool.

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

Deploy Server