How do I use Tiger Memory MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Tiger Memory MCP Server store that my favorite color is blue" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Tiger Memory MCP Server

Official

by timescale

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Tiger Memory MCP Server

A simple memory system designed to allow LLMs to store and retrieve information. This provides some focused tools to LLMs via the Model Context Protocol.

API

All methods are exposed as MCP tools and REST API endpoints.

Related MCP server: codebase-memory

Development

Cloning and running the server locally.

git clone git@github.com:timescale/tiger-memory-mcp-server.git

Building

Run npm i to install dependencies and build the project. Use npm run watch to rebuild on changes.

Create a .env file based on the .env.sample file.

cp .env.sample .env

Testing

The MCP Inspector is very handy.

npm run inspector

Field	Value
Transport Type	`STDIO`
Command	`node`
Arguments	`dist/index.js`

Testing in Claude Desktop

Create/edit the file ~/Library/Application Support/Claude/claude_desktop_config.json to add an entry like the following, making sure to use the absolute path to your local tiger-memory-mcp-server project, and real database credentials.

{
  "mcpServers": {
    "tiger-memory": {
      "command": "node",
      "args": [
        "/absolute/path/to/tiger-memory-mcp-server/dist/index.js",
        "stdio"
      ],
      "env": {
        "PGHOST": "x.y.tsdb.cloud.timescale.com",
        "PGDATABASE": "tsdb",
        "PGPORT": "32467",
        "PGUSER": "readonly_mcp_user",
        "PGPASSWORD": "abc123"
      }
    }
  }
}

Deployment

We use a Helm chart to deploy to Kubernetes. See the chart/ directory for details.

The service is accessible to other services in the cluster via the DNS name tiger-memory-mcp-server.savannah-system.svc.cluster.local.

Database setup

Creating the database user:

CREATE USER tiger_memory WITH PASSWORD 'secret';
GRANT CREATE ON DATABASE tsdb TO tiger_memory;

Secrets

Run the following to create the necessary sealed secrets. Be sure to fill in the correct values.

kubectl -n savannah-system create secret generic tiger-memory-mcp-server-database \
  --dry-run=client \
  --from-literal=user="tiger_memory" \
  --from-literal=password="secret" \
  --from-literal=database="tsdb" \
  --from-literal=host="x.y.tsdb.cloud.timescale.com" \
  --from-literal=port="32467" \
  -o yaml | kubeseal -o yaml

# https://logfire-us.pydantic.dev/tigerdata/tigerdata/settings/write-tokens
kubectl -n savannah-system create secret generic tiger-memory-mcp-server-logfire \
  --dry-run=client \
  --from-literal=token="pylf_v1_us_" \
  -o yaml | kubeseal -o yaml

# https://login.tailscale.com/admin/settings/keys
kubectl -n savannah-system create secret generic tiger-memory-mcp-server-tailscale \
  --dry-run=client \
  --from-literal=authkey="tskey-auth-" \
  -o yaml | kubeseal -o yaml

Update ./chart/values/dev.yaml with the output.

Available Tools

4 tools

forgetDelete an existing memoryC

This endpoint deletes an existing memory in the database, using the provided id to identify the memory to delete.

ParametersJSON Schema

Name	Required	Description	Default
`id`	No	The id of a specific memory to delete.
`scope`	Yes	A unique identifier for the target set of memories. Can be any combination of user, application, contextual ids, as needed for scoping and personalization.

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes	The unique identifier of the deleted memory.

TDQS

C2.9/5.0

Behavior2/5

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

Description only says 'deletes' without detailing consequences, reversibility, or authorization needs. Annotations lack readOnlyHint/destructiveHint, so the description carries the burden, which it does not meet. No mention of what happens if id is omitted or scope-based behavior.

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 a single sentence that is front-loaded with the verb and resource. It could be more concise (e.g., 'Deletes a memory by id.') but is acceptable.

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?

Output schema exists, so return values are managed. However, for a destructive tool, details on prerequisites (e.g., ownership, scope implications) are missing, leaving the agent uncertain about side effects.

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?

Schema coverage is 100% with clear descriptions for both parameters. The description adds the notion of 'using the provided id' but doesn't clarify the optionality or relation to scope, so it adds little beyond the schema.

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?

Description clearly states deletion of a memory using an id, distinguishing it from siblings recall (read), remember (create/update), and update (modify). However, it mentions 'using the provided id' while id is optional in the schema, which could cause slight 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 forget versus siblings recall, remember, or update. The description assumes the agent knows the context, but fails to provide usage scenarios or exclusions.

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

recallRetrieve memories by scopeA

This endpoint retrieves memories from the database, using the provided scope.

ParametersJSON Schema

Name	Required	Description	Default
`scope`	Yes	A unique identifier for the target set of memories. Can be any combination of user, application, contextual ids, as needed for scoping and personalization.

Output Schema

ParametersJSON Schema

Name	Required	Description
`memories`	Yes	The list of memories found.
`scope`	Yes	A unique identifier for the target set of memories. Can be any combination of user, application, contextual ids, as needed for scoping and personalization.

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations for readOnlyHint or destructiveHint, the description carries the full burden. It indicates a read operation ('retrieves'), but lacks details on error handling, empty results, or performance implications. The description is minimally adequate.

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 a single, well-formed sentence that directly states the tool's action and data source. No extraneous words, making it efficient and easy to parse.

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 simple parameter set (1 param, 100% coverage) and the presence of an output schema, the description captures the essential behavior. It could be more complete by hinting at return format, but for a retrieval tool it is sufficient.

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 schema covers the 'scope' parameter with 100% description, but the tool description adds semantic value by explaining that scope can combine user, application, and contextual IDs. This goes beyond the schema's generic description.

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 'retrieves' and the resource 'memories', which distinguishes it from sibling tools like 'forget', 'remember', and 'update' that perform other operations.

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?

The description provides no guidance on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage solely from the tool name.

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

rememberStore a new memoryC

This endpoint stores a new memory in the database, using the provided scope.

ParametersJSON Schema

Name	Required	Description
`scope`	Yes	A unique identifier for the target set of memories. Can be any combination of user, application, contextual ids, as needed for scoping and personalization.
`content`	Yes	The content to remember.
`source`	Yes	The source or origin of this memory. A deep URI to the origin of the fact is preferred (e.g., a specific URL, file path, or reference).

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes	The unique identifier of the new memory.

TDQS

C2.9/5.0

Behavior2/5

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

Annotations are minimal (title only), so the description carries the full burden of behavioral disclosure. It states 'stores in the database', implying a write operation, but does not disclose authorization needs, side effects, rate limits, or whether the operation is reversible. Compared to the calibration example for 'update_drive' (score 2), this is similar in lacking transparency.

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 with no wasted words. It is concise and front-loaded. However, it lacks any structural organization, such as separating purpose from usage notes, which could improve scannability.

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

Completeness2/5

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

Given that there are three required parameters and the tool is a write operation, the description is incomplete. It does not provide any guidance on scope naming conventions, content length limits, or example usage. Since an output schema exists, return value documentation is not needed, but the lack of behavioral and usage context leaves gaps for the agent.

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?

Schema description coverage is 100%, so the baseline is 3. The description adds only a vague mention of 'using the provided scope' without elaborating on the 'scope' parameter's role. It does not clarify the 'source' parameter's purpose or format beyond the schema. Thus, it adds marginal value beyond the structured parameter descriptions.

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 the tool stores a new memory in the database using the provided scope. It uses a specific verb ('stores') and resource ('memory'). However, it does not differentiate this tool from siblings like 'forget', 'recall', or 'update', which could cause confusion over which tool to use for memory operations.

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 is provided on when to use this tool versus alternatives. There is no mention of prerequisites, conditions, or exclusions. For example, it does not clarify that one should use 'update' for modifying existing memories or 'forget' for removal. The agent is left to infer usage from the name alone.

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

updateUpdate an existing memoryB

This endpoint updates an existing memory in the database, using the provided id to identify the memory to update.

ParametersJSON Schema

Name	Required	Description
`id`	No	The id of a specific memory to replace.
`scope`	Yes	A unique identifier for the target set of memories. Can be any combination of user, application, contextual ids, as needed for scoping and personalization.
`content`	Yes	The new content to remember.
`source`	Yes	The source or origin of this memory. A deep URI to the origin of the fact is preferred (e.g., a specific URL, file path, or reference).

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes	The unique identifier of the updated memory.

TDQS

B3.2/5.0

Behavior2/5

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

The description only mentions updating with an id, but lacks details on side effects, error handling, or behavior when id is missing. Annotations provide no safety hints, making transparency weak.

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 concise sentence, well-structured and front-loaded. It could be slightly more informative but avoids unnecessary text.

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 tool has an output schema and four parameters, the description is adequate but incomplete. It does not address the optionality of id or the update behavior without id, leaving ambiguity.

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?

Schema has 100% description coverage, so baseline is 3. The description adds no extra meaning beyond the schema—it simply restates 'using the provided id' which is already in the id parameter description.

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 the tool updates an existing memory, distinguishing it from siblings (forget, recall, remember). However, it implies id is the identifier but the schema does not require id, causing slight confusion.

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 use for updating existing memories, but does not explicitly state when not to use or provide alternatives. Usage context is derived from the tool name and siblings.

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

Install Server

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

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a unique, non-overlapping purpose: create (remember), read (recall), update (update), delete (forget). No ambiguity.

Naming Consistency5/5

All tool names are single-word imperative verbs (forget, recall, remember, update), following a consistent pattern.

Tool Count5/5

4 tools cover the essential CRUD operations for memory management, which is well-scoped and appropriate.

Completeness5/5

The tool set fully covers all CRUD operations (Create, Read, Update, Delete). No obvious gaps for the stated purpose.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

CLS++ Memory
io.github.rajamohan1950
Cross-LLM persistent memory: store context once, recall it from any AI model.
Knowledge & Memory AI & Machine Learning
2
Synap Memory A
ai.maximem
Persistent memory for AI agents — log and recall conversation context over MCP.
Knowledge & Memory AI & Machine Learning
4248
Maindex Smart Memory Service
io.maindex
Simple memory for AI: keep, recall, update, and forget information across sessions.
Knowledge & Memory AI & Machine Learning
2
Memory Vault
io.github.apurv101
Portable AI memory shared across models and harnesses - plain markdown you own.
Knowledge & Memory File Systems
1

Related MCP Servers

engram
Knowledge & Memory RAG Systems
jnMetaCode
A
license
Not graded
quality
C
maintenance
Local, private memory layer for notes and files with temporal reasoning and citation. Enables agents to query and persist memories via the Model Context Protocol.
Updated 3 months ago (2026-06-12 22:47 UTC)
8
2
MIT
codebase-memory
Knowledge & Memory Coding Agents
yuga-hashimoto
A
license
Not graded
quality
D
maintenance
Provides persistent memory for AI coding agents through the Model Context Protocol, enabling them to store and retrieve project knowledge across sessions.
Updated 6 months ago (2026-03-09 13:47 UTC)
36
MIT
agent-memory-mcp-server
Knowledge & Memory Autonomous Agents
AiAgentKarl
A
license
Not graded
quality
D
maintenance
Stores and retrieves key-value memories with metadata and namespaces for AI agents. Enables persistent, searchable memory across sessions using the Model Context Protocol.
Updated 5 months ago (2026-04-03 16:05 UTC)
13
MIT
NovaCortex MCP Serverofficial
Knowledge & Memory RAG Systems
Nova-Cognitive-Systems
A
license
Not graded
quality
A
maintenance
Enables AI agents to store, search, and relate typed memories with a graph-native knowledge base via the Model Context Protocol.
Updated 9 days ago (2026-08-25 04:15 UTC)
Apache 2.0

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/timescale/tiger-memory-mcp-server'

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

Tiger Memory MCP Server

API

Development

Building

Testing

Testing in Claude Desktop

Deployment

Database setup

Secrets

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

NovaCortex MCP Serverofficial

Latest Blog Posts

MCP directory API