tidbits-memory
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@tidbits-memoryRecord that Python 3.7+ dictionaries preserve insertion order"
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.
tidbits-memory
A memory/tidbits voting framework for AI agents. Agents can record learnings (facts, methods, gotchas) and vote on them to surface the most useful tidbits.
Installation
uv pip install -e ".[dev]"Quick start
from tidbits_memory.adapters.memory import InMemoryAdapter
from tidbits_memory.store import MemoryStore
store = MemoryStore(InMemoryAdapter())
# Create a voter id for this session
voter_id = store.create_voter_id()
# Create a memory
mem = store.create_memory("Python dicts preserve insertion order since 3.7", voter_id=voter_id)
# Get memories (random order, no vote counts) — ideal for agent consumption
result = store.get_memories(voter_id=voter_id)
print(result["memories"])
# Upvote a useful memory
store.upvote_memory(mem.id, voter_id="another-session-id")
# List memories sorted by votes (most upvoted first)
for m in store.list_memories():
print(f"[{m.votes}] {m.content}")
# Downvote an erroneous memory
store.downvote_memory(mem.id, voter_id="yet-another-session")
# Unvote (remove a prior vote)
store.unvote_memory(mem.id, "another-session-id")
# Remove a memory
store.remove_memory(mem.id)Persistent storage (JSON file)
from tidbits_memory.adapters.json_file import JsonFileAdapter
from tidbits_memory.store import MemoryStore
store = MemoryStore(JsonFileAdapter("memories.json"))
store.create_memory("Use `uv` for fast Python packaging")Voter ID generation
When an agent doesn't have a session/conversation ID, use create_voter_id:
voter_id = store.create_voter_id()
# Use this voter_id for all votes in this sessionIf no voter_id is provided when calling get_memories, one is automatically generated and returned in the response.
MCP Tool Wrappers
from mcp.server import FastMCP
from tidbits_memory.adapters.memory import InMemoryAdapter
from tidbits_memory.store import MemoryStore
from tidbits_memory.tools import register_tools
store = MemoryStore(InMemoryAdapter())
mcp = FastMCP("tidbits")
register_tools(mcp, store)
# Registered tool names:
# create_memory, upvote_memory, downvote_memory, unvote_memory,
# list_memory, get_memories, remove_memory, create_voter_idRunning tests
uv run pytestAvailable Tools
8 toolscreate_memoryC
Create a new memory/tidbit. Returns the created memory with its id.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | ||
| creator | No | ||
| tags | No | ||
| voter_id | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool returns the created memory with its ID, which is helpful, but fails to address critical aspects like authentication requirements, rate limits, error conditions, or whether this is a persistent write operation. For a creation tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two short sentences that are front-loaded with the core purpose. Every word earns its place, and there's no wasted verbiage or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return value documentation) but no annotations and poor schema coverage, the description is minimally adequate for understanding the basic operation. However, for a creation tool with multiple parameters, it should provide more context about parameter usage and behavioral expectations to be truly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 4 parameters (1 required, 3 optional), the description provides no information about parameter meanings, formats, or constraints. It doesn't explain what 'content', 'creator', 'tags', or 'voter_id' represent or how they should be used, failing to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new memory/tidbit') and the resource ('memory'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_memory' or 'remove_memory' beyond the basic verb distinction, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'list_memory' or 'remove_memory'. There's no mention of prerequisites, context, or specific scenarios where creation is appropriate versus other operations on memories.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_voter_idB
Generate a new unique voter_id for this agent session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states the tool generates a 'unique voter_id', implying creation, but doesn't disclose behavioral traits like whether this is idempotent, requires specific permissions, or how uniqueness is enforced. The description is minimal and lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose with no wasted words. It's appropriately sized and front-loaded, making it easy to understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, as a creation tool with no annotations, it lacks details on behavioral aspects like idempotency or session-specific constraints, leaving some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The baseline for 0 parameters is 4, as the description appropriately doesn't discuss non-existent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Generate') and resource ('new unique voter_id'), specifying it's for 'this agent session'. It doesn't explicitly differentiate from siblings, but since no sibling tools handle voter IDs, the purpose is sufficiently clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'for this agent session', which provides some context, but offers no guidance on when to use this tool versus alternatives or prerequisites. There's no explicit when/when-not usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
downvote_memoryB
Downvote a memory. Provide voter_id to enforce one vote per session.
| Name | Required | Description | Default |
|---|---|---|---|
| memory_id | Yes | ||
| voter_id | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the 'voter_id' for vote enforcement, adding some context, but lacks details on permissions, rate limits, or what happens on downvoting (e.g., effects on memory visibility or scoring). This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and adds necessary context without waste. Every word earns its place, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with 2 parameters), no annotations, and an output schema present (which handles return values), the description is minimally adequate. It covers the basic action and key parameter context but lacks behavioral details like permissions or side effects, leaving gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description adds meaning by explaining that 'voter_id' enforces 'one vote per session,' which clarifies its purpose beyond the schema. However, it doesn't cover 'memory_id' or provide full compensation for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('downvote') and target resource ('a memory'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'upvote_memory' or 'unvote_memory' beyond the directional difference, missing explicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'voter_id to enforce one vote per session,' suggesting when to use this parameter, but it doesn't explicitly state when to choose this tool over alternatives like 'upvote_memory' or 'unvote_memory,' or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_memoriesB
Get the list of memories.If voter_id is not provided, a new one is generated and included in the response for use in subsequent votes.
| Name | Required | Description | Default |
|---|---|---|---|
| voter_id | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that a new voter_id is generated if not provided, which adds some context about the tool's behavior. However, it fails to describe other key traits such as whether this is a read-only operation, any rate limits, authentication needs, or what the output looks like (though an output schema exists, the description doesn't hint at return values).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's purpose and key behavioral detail without any wasted words. It is front-loaded with the main action and follows with important context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 1 parameter with low schema coverage and an output schema exists (which reduces the need to describe return values), the description provides basic purpose and some parameter context. However, as a tool with no annotations, it lacks details on behavioral traits like safety or performance, making it incomplete for fully informed use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, so the schema provides no semantic information. The description adds meaning by explaining that 'voter_id' is optional and if omitted, a new one is generated for use in subsequent votes, which clarifies its purpose beyond the schema. However, it doesn't detail the format or constraints of 'voter_id', leaving some gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('list of memories'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'list_memory' which might serve a similar function, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explaining that if 'voter_id' is not provided, a new one is generated for subsequent votes, suggesting context for when to use this parameter. But it lacks explicit guidance on when to choose this tool over alternatives like 'list_memory' or 'create_voter_id', leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_memoryB
List all memories sorted by votes descending (most upvoted first).
| Name | Required | Description | Default |
|---|---|---|---|
| order_by | No | votes | |
| limit | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions sorting by votes descending, which is useful, but fails to cover critical aspects like whether this is a read-only operation (implied by 'list' but not explicit), pagination behavior, rate limits, authentication needs, or what the output contains. This leaves significant gaps for a tool with potential complexity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action and sorting detail with zero wasted words. It is appropriately sized for a simple listing tool, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is incomplete. It covers the sorting behavior but misses usage guidelines, parameter details, and behavioral traits. The presence of an output schema reduces the need to explain return values, but the description still lacks sufficient context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It implicitly references 'votes' as a sorting criterion, which relates to the 'order_by' parameter, but doesn't explain the 'limit' parameter or provide details on parameter formats or constraints. This adds minimal value beyond the schema, meeting the baseline for low coverage without fully addressing the gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all memories') and specifies the sorting method ('sorted by votes descending'), which distinguishes it from siblings like 'get_memories' (which might have different filtering) and 'create_memory' (a write operation). However, it doesn't explicitly differentiate from 'get_memories' in terms of scope or filtering, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'get_memories' or 'create_memory'. It lacks context such as use cases, prerequisites, or exclusions, leaving the agent to infer usage based on the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
remove_memoryB
Remove a memory by id.
| Name | Required | Description | Default |
|---|---|---|---|
| memory_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Remove' implies a destructive mutation, but the description doesn't disclose whether this is permanent, requires specific permissions, has side effects, or what happens on success/failure. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and uses minimal words to convey the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 (which handles return values), the description's main gaps are behavioral transparency and parameter semantics. For a destructive operation with no annotations and 0% schema coverage, it's minimally adequate but leaves significant questions unanswered about how the tool behaves.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'by id', which adds meaning by indicating the parameter identifies a specific memory, but doesn't explain the ID format, source, or constraints. This provides some value but doesn't fully address the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('remove') and resource ('memory'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'downvote_memory' or 'unvote_memory', which might also involve memory modification, so it doesn't reach the highest clarity level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. With siblings like 'downvote_memory', 'unvote_memory', and 'get_memories', the description offers no context about when removal is appropriate versus other memory operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
unvote_memoryC
Remove a prior vote from a memory by voter_id.
| Name | Required | Description | Default |
|---|---|---|---|
| memory_id | Yes | ||
| voter_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Remove a prior vote') but doesn't clarify whether this is a destructive operation, what permissions are required, if it's reversible, or what happens if the vote doesn't exist. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place in conveying the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, no annotations, and an output schema (which handles return values), the description is minimally adequate. It states the basic action but lacks details on behavioral traits, parameter meanings, and usage context. The output schema reduces the need to describe returns, but the description should do more for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'voter_id' but doesn't explain what 'memory_id' represents or the format/constraints for either parameter. It adds minimal semantic value beyond naming one parameter, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove a prior vote') and the target resource ('from a memory by voter_id'), making the purpose immediately understandable. It distinguishes this tool from siblings like 'upvote_memory' and 'downvote_memory' by specifying removal rather than addition. However, it doesn't explicitly contrast with 'remove_memory' (which likely deletes the entire memory), leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention prerequisites (e.g., that a vote must exist first), nor does it differentiate from sibling tools like 'remove_memory' or explain the relationship with 'upvote_memory'/'downvote_memory'. The agent must infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
upvote_memoryB
Upvote a memory. Provide voter_id to enforce one vote per session.
| Name | Required | Description | Default |
|---|---|---|---|
| memory_id | Yes | ||
| voter_id | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the 'voter_id' parameter for session-based voting enforcement, which adds some context about behavior, but it lacks details on effects (e.g., does upvoting increment a score, is it reversible, what permissions are needed), response format, or error handling, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Upvote a memory') and adds necessary context without waste. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, mutation action) and the presence of an output schema (which reduces need to explain returns), the description is partially complete. It covers the basic action and a key parameter behavior, but without annotations and with low schema coverage, it should do more to explain effects, errors, or usage nuances.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the purpose of 'voter_id' ('to enforce one vote per session'), adding meaning beyond the schema, but it doesn't address 'memory_id' or provide details on parameter formats, constraints, or interactions, resulting in incomplete coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'upvote' and resource 'a memory', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'downvote_memory' or 'unvote_memory' beyond the obvious directional difference, which keeps it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning 'voter_id to enforce one vote per session', which suggests context for when to provide this parameter, but it doesn't explicitly state when to use this tool versus alternatives like 'downvote_memory' or 'unvote_memory', nor does it provide prerequisites or exclusions.
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.
8 tool updates
v0.1.0- First observed
create_memory - First observed
create_voter_id - First observed
downvote_memory - First observed
get_memories - First observed
list_memory - First observed
remove_memory - First observed
unvote_memory - First observed
upvote_memory
TDQS
Each tool has a clearly distinct purpose with no ambiguity: create_memory, create_voter_id, downvote_memory, get_memories, list_memory, remove_memory, unvote_memory, and upvote_memory. The actions (create, get, list, remove, upvote, downvote, unvote) and targets (memory, voter_id) are well-defined and non-overlapping.
All tools follow a consistent verb_noun pattern using snake_case (e.g., create_memory, downvote_memory, get_memories). The naming is predictable and uniform across all eight tools, with no deviations in style or convention.
With 8 tools, the count is well-scoped for a memory/voting system. Each tool serves a specific function in managing memories and votes, and none appear redundant or unnecessary for the server's purpose.
The tool set provides complete coverage for the memory and voting domain: CRUD operations (create, get/list, remove), voting lifecycle (upvote, downvote, unvote), and voter management (create_voter_id). There are no obvious gaps, and agents can handle all core workflows without dead ends.
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
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
Collective memory for AI agents. One agent solves a bug — every agent gets the fix instantly.
Persistent cross-session memory shared by Codex, Claude Code, ChatGPT, and other AI agents.
Shared long-term memory for AI agents: save and recall context as a searchable knowledge graph.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/brkhrdt/tidbits-memory'
If you have feedback or need assistance with the MCP directory API, please join our Discord server